Category Archives: Uncategorized

Component granularity explained as Baby-Bear, Momma-Bear and Papa-Bear

When talking about components people use the same word for different levels of granularity making it very confusing. Is one object considered to be a component? Is a class library a component?

Is a component the boundary between intra-component synchronous and inter-component asynchronous communication?

Pat Helland created an overview using the Three Bears analogy: Baby-Bear, Momma-Bear and Papa-Bear. Below you see a summary but you can always visit his weblog for details.

It is just funny and because of that, developers will remember during discussion about components to ask themselves at what level of component granularity the discussion is going on.

Components

Summary:

  • Baby-Bears are much like the classic object with inheritance, reference-passing, and synchronous interactions with their callers.
  • Momma-Bears (closely related to what is provided by MEF), are comprised of multiple Baby-Bears. While exhibiting synchronous call patterns, they do not support pass-by-reference nor inheritance. They will, however, allow for support of dependency injection.
  • Papa-Bears are the biggest of the three and are most similar to a SOA Service. A Papa-Bear will typically be composed of multiple Momma-Bears. Papa-Bears interact with their partners asynchronously, are frequently remote, do not support pass-by-reference or inheritance, and may be offline.
Share this postSave this post

Will Dublin replace BizTalk Server?

Some time ago Microsoft’s application server Dublin was announced and the BizTalk community was watching closely. Seeing WF and WCF integrated in Dublin got a lot of developers wondering whether it was Microsoft’s intention to replace BizTalk in the long run.

For a detailed discussing you should read Charles’s Young blog ariticle Dublin and BizTalk Server – What’s the difference?  You can find it at: http://geekswithblogs.net/cyoung/archive/2008/10/15/125848.aspx

I?l just give some highlights and quotes I?l gathered reading around on this topic.

Microsoft describes Dublin as an “Application” server, and BizTalk Server as an “Integration” server.

Microsoft architect Igor Sedhukhin: “Dublin is not intended to be an integration server at all,” he said. “We aren’t trying to put all the adaptors in Dublin. BizTalk is really focused on that integration scenario.”

Product Unit Manager Dan Eshner: “Dublin really is a hosting environment for WF and WCF services,” Eshner said. The goal, he added, was to take the heavy lifting and skill requirements out of invoking WCF and WF services. “You can make these services work without Dublin, you just got to do some stuff. You’ve got to get all the configs set up and you got to do some work, create services out of them,” he said.

Dublin won’t have the transforms and adaptors found in BizTalk. “BizTalk as an integration server is much more powerful than what you get with an app server like Dublin.”

So if you hear developers ditching BizTalk already in favor of Dublin “you can persist WF’s to SQL Server and it can talk to anything over WCF; it does everything BizTalk can and its free”… you might want to point out some major differentiators (for details see Charle’s article):

  • Differentiator 1: It’s the Message Box, stupid: fully supported integration.
  • Differentiator 2: Vote XLANG/s for president: complex orchestration.
  • Differentiator 3: Stronger regulation needed: central administration.
  • Differentiator 4: Investing in the market: supported message protocols.
  • Differentiator 5: Putting Lipstick on Pigs (oh come on, give me a break…): rich tooling.
Share this postSave this post

Having a hard time to choose between C# and JAVA … IKVM can bridge between these languages

Some time ago I was working on a project where a new Java based platform was being integrated with an existing message bus, already connecting up C# based services, to create a B2B communication chain between several companies. The Java platform was appliance with a Java application server on it.

In the original architecture we had planned to run a message translator on the appliance. Because of several technical integration issues we got way behind. We ended up in a situation where a team already spent a considerable amount of time and budget on developing mappings for the translator. The same translator we had trouble with integrating into the B2B communication chain.

So, on the one hand, finding another translator was no option because of the work already done on the mappings for the translator. On the other hand, we hadn’t another Java appliance to host our translator.

Looking for a solution I investigated the possibility to host the Java translator in a C# based service and move it to the existing part of the communication chain until we had the integration problems solved.

At first I was very disappointed in finding no easy way to do cross-language interoperation. The best I could come up with was spinning off a process from C# code that would run the Java translator in a Java sandbox for every message that would pass through the message bus. No need to say this was a performance killer!

I kept looking and finally bumped into IKVM (http://www.ikvm.net). It allowed me to turn the translator java classes into a .NET C# library. Once I got the library, creating the C# code to host the translator was still quiet complex but the performance gain was enormous.

IKVM’s magic is situated under the bonnet were Java byte code is turned into C# intermediate language and vice versa. I used to ikvmc compiler to turn the translator’s JAR into a .Net dll by means of target:library option. This compilation is the power of IKVM because at run-time no time is lost to do complex inter-language interpretation: compile once and (re-) user everywhere!?

I must say I wasn? expecting any result because these kinds of conversions aren’t trivial. Most of the time I?e seen it work for basic Hello World examples but fail for anything with a realistic complexity. I was really amazed finding out that IKVM was up to the job!

It is worth noting that IKVM is still under development and the newest release is 0.4 so still an alpha version. Personally I don’t care because it really saved my day.

Share this postSave this post

Completely blown away by Google Wave!

Just saw a developer’s preview of Google Wave the new collaboration platform of Google, and I must say I was blown away. It is not often that I spend 1h20 watching a video on the internet. Most of the time my attention span drops after like 5 minutes, but what I saw got me hooked.

It is the first time that I see collaboration tool that has in it the things I want. I often misuse e-mail for chatting. You know the feeling. You send a mail to a colleague dealing with item x for project y and get an immediate response because the colleague happens to be online. Instead of switching over to instant messaging you continue e-mailing. I, for long, hoped there was like a magic switch to go from e-mail to instant messaging and back. Guess what Šthe guys of Google nailed it.

Google Wave brings together the different dispersed tools we are using now to exchange information and combines it into one platform. Consider all the tools you use to communicate. I use e-mail, instant messaging and I blog. Moreover, I share information in bulletin boards, wiki’s, social networks, through SMS and so on. Wouldn’t it be nice if you turn an instant messaging conversation into a blog article or go from SMS to a wiki’s.

There is a new interesting approach to communication imbedded in Google Wave.

If you look closely at e-mail you see it is nothing more than an electronic implementation of snail mail. You have a message that you sent out to a group of recipients. Recently E-mail clients became intelligent and can collate a group of mails, dealing with a common subject, together to make up the conversation. So you have a message sent to a network of people. The message is the basis of the conversation.

In Google Wave the communication is based on network of people that have a conversation about something. So you start with a network of people that will exchange messages. The set of users and the messages are what Google calls a Wave. The Wave is the basic object of the conversation.

The thing I really liked about the platform is that it is very interactive. When it’s chatting the other site has to wait until I press enter to see my response. In Google Wave they see me typing from the first key I press. There is intelligent real time spelling checking and correction in it. Multiple participants can edit the same document at the same time. So a discussion becomes a live discussion.

When participants are added to a conversation, they can playback the conversation and see who added or modified what in the shared documents. It is also possible to exchange private remarks with a subgroup of the participants in a Wave. The end-result of a Wave can be extracted without the comments of everyone and be added to, for example, a blog.

Google Wave is an open platform meaning that anyone can add functionality to it.  This also means that everyone can create or host its own Wave server independent of Google. This is very interesting because private conversation between participants could be kept inside the company’s walls for a Wave spreading multiple companies working on the same project.

You should have a look at the Developer’s preview video located at http://wave.google.com/

If you know Google Wave was developed by the same guys that worked on Google Maps and it is an open platform, I can only say “You ain’t seen nothing yet!” The way people added functionality to Google Maps went far beyond the imagination of the original desigers. I think the same will be true for this platform.

Share this postSave this post

DataSets vs. custom Data Transfer Objects

Recently I had a discussion with a developer involving in the ancient discord between using DataSets versus custom Data Transfer Objects (DTO). Personally I’m very pro Data Access Objects and exposing these as custom Data Transfer Objects in the service layer of applications. I always thought that DataSets were missing something. They are just plain containers without the possibility of any real behavior.

The current move for more intelligent objects in the Domain Driven Design paradigm seems to confirm this. I can see DataSets being applied in very simplistic applications where the presentation, required in the GUI, almost maps one-to-one to the database structure. But in any other real life enterprise application this is almost never the case. You have a business layer doing complex manipulations on the domain entities, often involving a rule engine, before these entities are exposed to the session facade.

Another thing is that DataSets and Web Services do not go very good together. You can’t say that DataSets are really platform independent, can you?

During the discussion one argument convinced me to think twice about using DataSets in future projects. The argument was the huge development costs of business entities and custom DTO’s. It is true that even if DataSets are just basic data containers, there is a lot of IDE support for them that make development very easy: ‘Free Code’ But to my opinion this support is misinterpreted as an approval to hammer ‘use DataSets – everything that looks like a nail’ the data for the presentation layer.

Some more extensive comparisons you’ll find in the articles below. For a balanced view you should check out the article by Jelle Druyts. It is written by a former colleague of mine and its promoting datasets (how dare he!).

Share this postSave this post