David Pallmann's Blog: SOA

Licensed to WSDL

Fri, 23 May 2008 20:23:15 GMT

A long, long time ago in a galaxy far away... way back in January... I decided to order a personalized license plate advertising my area of specialization, SOA and ESB. Little did I know this was going to be an extreme exercise in patience. I finally was able to pick up the plate shown below and puit it on my car today (in May), after a grueling 4-month wait.

I originally wanted to have it read NEURON, the name of our ESB, but that was already taken (by a neurologist, no doubt). Interestingly, I have discovered the acronym ESB is also a neurological term (meaning, "Electrical Stimulation of the Brain"). So if you're ever googling for Neuron ESB and get some medical hits, you'll know why.

Now everyone will know what drives me. :) Or more accurately, the computer people will and no one else will have a clue.

Service-enabling the 3-tier Application Model

Sat, 10 Nov 2007 00:21:12 GMT

3-tier applications have been around for some time now, and the presentation/business/data tier arrangement seems to have held up well despite a variety of underlying technology changes. But how does the arrival of service orientation affect 3-tier applications? While there's a lot of interesting talk now about "composite applications" using shared services, the pattern I am observing right now in the field is a little different than what's commonly being conceived.

First off, if a company is starting to adopt service orientation more and more seriously, you're likely to see 3-tier applications modified so that the business tier becomes a business service tier. It's straightforward and natural to turn the former implementation of your business logic (objects, COM+ components, etc.) into services, especially with a powerful tool such as WCF. So now we have something like this, where the business logic is composed of services. This feels more modern, but the app really hasn't changed a whole lot.

The next step for the application comes when the organization wants to make good on the "maximize reuse" promise of service orientation. The app needs to expose some of its services for public consumption by other applications in the company; and/or, the app is expected to consume services that belong to another application. Now the app has private and public services.

The business services tier is now servicing both its "home app" as well as other apps. This additional traffic to the service layer needs to be carefully analyzed; it's quite possible that the 'extra traffic' from other apps could outweigh the load from the original application. You might find yourself scaling out the business service tier to accommodate the extra demand.

For an application to take this shape, a bit of refactoring is often necessary. In an isolated app, you may find developers have been sloppy and put some business logic in the presentation tier. In an app with shared services, however, the app logic really needs to reside in the business tier. It can't be in the presentation tier for the simple reason that an external client never accesses the presentation tier. Typically, there will be some work to make the presentation tier as thin as possible and devoted just to UI. In the same vein, the business services need to perform strong validation--even if a lot of that validation is also duplicated in the presentation tier. Again, an external caller to the business service layer won't be going through the presentation tier.

A good characteristic of this approach is that ownership doesn't change; that is, the people responsible for "App A" are the people who service-enable and maintain "App A". This pattern for service-enabling applications seems to work equally regardless of the topology you happen to use to interconnect your service-enabled applications (direct, hub-and-spoke, ESB).

Off to the Microsoft SOA/BP Conference

Mon, 29 Oct 2007 06:12:09 GMT

I'm off to the Microsoft SOA & Business Process Conference for the week.

Hopefully there will be some interesting developments worth blogging about.

I'm glad to see SOA and Business Process covered in the same conference. Disciplines such as SOA, EAI, and BPM need to be considered jointly in a holistic way. When they become isolated areas of focus we end up with bad solutions.

Services: Reusable Across Architectures

Fri, 28 Sep 2007 21:39:55 GMT

One of the reasons touted to use services is that they are highly reusable, especially if a few guidelines are followed in their design. One of the aspects of their reusability is that they fit into any architecture. Let's consider three popular architectures:

Point-to-Point architecture. Here clients connect directly to services.
Hub-and-spoke architecture. Here clients and services connect to a central intermediary / message broker.
Bus architecture. Here clients and services connect through a distributed messaging fabric.

You can write a service and use it in all 3 arrangements. Now that's reusable software!

While I have fairly strong feelings about which of these architectures are appropriate in various scenarios, it's not a decision that necessarily impacts the service developer. A good service fits many contexts, and a good service developer will be thinking that way.

Weighing in on SOA

Tue, 23 May 2006 07:00:25 GMT

I first wrote about service orientation in the opening chapters of Programming Indigo, where I dutifully enumerated Don Box's 4 tenets and explained them in the context of WCF application programming. That was a whole year ago, and there have been many SOA developments since. I've found myself immersed in many service oriented customer projects and I also regularly present on SOA and WCF at code camps and other events around the country. So it's time to start blogging my thoughts on SOA. To kick it off, I'll give you my opinion about where SOA is today.

First, let's dispense of the silly SO vs. SOA acronym argument. Some folks don't feel the term 'architecture' is justified, others do. Why is that? If I may, I'd like to remind everyone that there's a lot of disagreement on what 'architecture' is. If the word architecture makes you think of something very defined and standardized, like an OSI network stack, then I understand your hesitancy because we don't have a general architecture (noun) like that for service orientation yet. But service orientation is certainly an architectural consideration, and an important one at that; any time I architect an enterprise solution I begin by figuring out the boundaries of communication, security, etc. So I personally find the term Service Oriented Architecture perfectly appropriate. Ultimately, I think SOA will win over SO if for no other reason that it's the more catchy acronym.

How far can we advance SOA when it's still the subject of much debate? I liken SOA to a hurricane. Sure, there's a lot of chaos at the edges as debates rage on, both technically and politically motivated. But in the eye of the storm there is calm, because there is general agreement on the spirit of SOA: message-based communication, loose coupling, autonomy of services. SOA is young and will continue to be refined, but it's real enough to talk about meaningfully and put into practice.

To make SOA real and practical for people, we have to go beyond the 4 tenets. At Neudesic, we've been doing a lot of thinking about all things SOA. One very interesting group exercise we went through was to collectively list everything we could think of related to SOA, then categorize the items into first principles, benefits, and best practices. This was very illuminating, and also very surprising. I expected many arguments to arise as part of the process; instead, there was a great deal of consensus and only occasional differences of opinion. I'll share our findings on this in a separate article in the near future.

One recent development that shows SOA is progressing is William Oellermann's Enterprise Service Oriented Maturity Model (ESOMM). ESOMM describes stages an enterprise can go through to more deeply embrace SOA. At the onset, enterprises have casual hosting or consumption of services. By the final stage, enterprise are aggregating and orchestrating services in sophisticated ways.

One thing that's become very clear about SOA is that in an enterprise setting customers need a central way to configure, monitor, and manage those decentralzed services. Enter the Enterprise Service Bus (ESB), which provides just those capabilities. I'm skeptical enterprises will move beyond fringe use of services unless they have the centralized control (or the illusion thereof) an ESB provides. I'm doing a lot of ESB work and will have more to share about that in the future as well.

WCF is obviously a great technology for SOA work, as it was designed with service orientation in mind. As good as WCF is, we could wish for a few more SOA features going forward. Discovery of services, so we no longer need to have addresses in our code or config files. Publish-Subscribe communication over topics. Dynamic reconfiguration of running services. Perhaps we'll see some of these in subsequent versions. If not, the good news is you can build these things yourself here and now without too much trouble on top of WCF.