THE SOFTWARE SIMPLIST

Web Services Wisdom.

September 2006

From the SOA in Action Blog (cross-post):

There has been considerable hand-wringing over the potential performance impact of SOA, and especially XML, on server environments. In a new think piece posted at Search WebServices, ZapThink's Jason Bloomberg sheds some light on the challenge of high-performance SOA -- and yes, he uses "high performance" and "SOA" in the same sentence.

First of all, SOA does not necessarily imply XML. Second of all, even if you use XML in server environment (I do, every day), while performance may be worse than binary serialization, I have yet to see it be the system bottleneck. Sending out unnecessarily large sets of data, or sending the same data over and over again (as occurs in an RPC world) has been problematic in many of the systems that I've seen. While one could blame XML for making the bloat worse, one might also blame the architect for the bloat in the first place.

"Granted, SOA is a services abstraction, and "every abstraction comes at a price," Bloomberg observes. "Loose coupling, composability, agility, and the other benefits of SOA all introduce performance overhead." At large sites with a lot of users and traffic, SOA performance is a huge challenge."

From my experience, the price of the abstraction is negligible. Disregard for the impact of network latency comes with one helluva penalty, much higher than the service abstraction. Poorly designed services often suffer in this regard, so one could mistaken the performance hit as being caused by the abstraction. That is, if one was an analyst and not somebody actually doing the work.

One thing I will grant, though: "At large sites with a lot of users and traffic, ... performance is a huge challenge." Regardless of SOA.

Posted by Udi Dahan at 12:34 PM  Permalink |

After some time off, I return to the wired world and find that things just keep getting better and better. Take, for example, Mohammad Akif's recent posting on Microsoft ESB strategy. While knocking other vendors for trumping up bogus offerings, his discussion of what an ESB can/should support goes against many of the principles of service orientation.

One main thing that gets me every time is the inter-changable use of the terms "bus" and "broker". They are different architectural patterns! An ESB should NOT, either "at the very minimum" or at all, support "Brokered Communication". The idea of necessarily having a single physical point through which all communications go through, be it clustered for high availability or not, is not the implementation of the Bus architectural pattern. Period. I know that that's how Microsoft implemented BizTalk. It still doesn't make it a bus. Topic-based routing, which, when you implement a variation of the DataType Channel pattern, can bring you to a one-to-one mapping of channels to autonomous components.

And then there's message transformation. Has there ever been a more transparent defective gene inherited from the EAI beginnings? SOA is not about hooking together poorly design, hastily shipped legacy systems. Each service is responsible for its own communications with other services. If it needs to "transform" messages, whatever that means, it should do it by itself. If there's anything going on, we're talking about contextual translation - think of those guys in the back rows of the UN, only doing a better job. A service needs to understand the semantic meaning of a message and assimilate the data it brings into the service's own internal domain. No intermediary can, or should, help there.

One parting note: I don't want to come off as attacking Mohammed specifically here. If ever there was an architect who had a more balanced point of view at Microsoft, I haven't met or read them yet :) Look for more discussion around Mo's blog post in the coming days.

Posted by Udi Dahan at 03:48 PM  Permalink |

Get it here.

In this podcast, we address questions about autonomous services, publish/subscribe communication, exceptions, data duplication, reuse, and governance.

Let us know if you like this style of question and answer format.

Resources

1. Autonomous Services and Enterprise Entity Aggregation
2. Visit Udi's blog
3. Ask Udi a question on SOA
4. Subscribe to the Ask Udi podcast

Posted by Udi Dahan at 06:07 PM  Permalink |

In my recent post on "Smart clients and services", I left one topic open on client-service interaction.

Just to recap: there are 3 main scenarios for client-service interaction when the service is an Autonomous Service.

1. The client consists primarily of maintenance screens. The client is really part of the service that it's communicating with - there's no need for pub/sub within a service. Therefore, conventional client-server computing can still hold here.

2. There is some business level functionality left in the client after taking out all the maintenance screens and splitting them among the services. Chances are that there are that the business functionality left belongs in its own service. Create a new service and fold the client into it using conventional communications.

3. The smart client / user combo are, in essence, a service. Let's delve into this one some more, since it's the most interesting/complex.

At the "business" level, this scenario occurs where several, often physically disparate, users cooperate (maybe even in real-time) on a task. Each user being in charge of some part of the task, but all users are using the same smart client. Command & Control systems see this kind of behavior quite often - different units coordinating amongst themselves in achieving a certain goal.

Technically, we can view this either as multiple instances of the same services communicating in a peer-to-peer fashion. In which case, we're talking about intra-service communication. However, each smart client, in this case, doesn't view the information coming from its peers any different than that coming from the outside world. Since each client is indeed autonomous, making its own decisions based on its own data, at whatever times it sees fit, this scenario fits the SOA model quite well.

You could also look at the robot world cup in a similar way. Each robot on the soccer (football) team has a position which dictates the way that it will respond to certain events occurring. The same software is installed on all robots, yet it is designed in such a way to enable real-time distributed collaboration in achieving a common goal - by each client working on its own local goals. Each position is an autonomous service.

Like I said, this probably isn't a very common scenario in the Enterprise, but still, you never know when it might come in handy.

Posted by Udi Dahan at 05:09 PM  Permalink |

This week I'm finally going to get around to a question that's been sitting in my inbox for a while. Jason asks about SOA, asynchronous messaging, smart clients, and service reliability:

"Udi,

Thank you for your time and the guidance you provide to so many."

Well Jason, thank you for your kind words and my apologies for this belated reply.

To your first question, there are two answers. The first answer is that "end clients" can very well be considered part of a service. I expounded on this topic a couple of posts ago and you can find it here. If the end client is not part of the service that it wants to communicate with, we can (again) take one of two views. The first is a technological perspective; how we keep a high-level asynchronous API yet use the underlying protocols in such a way that common infrastructure won't get in our way (i.e. firwalls).

One technical solution is first to have all clients communicate to/through a common gateway which, in turn, communicates with the target service. You may then be able to press the infrastructure guys to open a single port for the gateway, instead of N ports for all the client. Otherwise, given that the clients already are communicating asynchronously, you might be willing to have the gateway communicate synchronously with the service. I think that you're hearing that I don't think much of this technological perspective.

The architectural perspective would state that if the end clients don't belong to the target service, they probably belong to some other service. In which case, you'd maintain loosely coupled communication at the service level, while letting the end client communicate synchronously within their own service. When you're talking at the service level, you usually have the mandate for opening ports to support the enterprise standard of communication.

As for your second question, I over-exagerate the point I'm trying to make. In good network conditions, and when Murphy is on vacation, the service will be able to respond promptly to client requests. The issue I'm raising here is that things always go wrong, and at the worst of times, so design your systems for those worst cases, and then be pleasantly surprised most of the time. However, what you'll be avoiding is system-level race conditions - where system A is waiting for B, which is in turn waiting for C, which is waiting for A, but since all of A's threads are held up waiting for B, it doesn't have any threads available to answer C.

In good conditions, service reliability is just fine, although the more appropriate term would be service availability or the service level agreement (SLA) that the service could support. What we're doing here is improving system-wide robustness.

So, I hope that that answers your question Jason, and thanks for being so patient with the response :) To everybody else who has sent me an email and hasn't seen a response yet, don't worry, I haven't forgotten you! One of these days I'll have to quit my day job and do this full time. What do you think?

Posted by Udi Dahan at 05:38 PM  Permalink |

After reading this article you just might be thinking that business rules management systems (BRMS's) are the key to what SOA was supposed to bring (now that we're in the trough of disillusionment) - that is, if you haven't tried working with these beasts before. {Originally posted here.}

There are several now-well-known fallacies around BRMS's. One is that business analysts write the business rules, in plain English, and these rules do not require a programmer to enter/code them into the system; the BRMS handles all that.

"Costly, time-consuming transformation from business terms to programmer requirements and subsequent implementation can be reduced or eliminated. This in turn empowers business analysts to create and maintain the business logic directly, allowing them to make changes with little or no IT intervention."

But, the author forgets to mention who performs these trivial activities:

"After testing and validation the business logic can be deployed to a business rules server."

This brings me to the single most important thing anyone should know about the business rules approach. Employing a rules engine opens up the possibility that the system will behave non-deterministically. Consider that only 3 non-linear equations are needed to create chaotic behavior, and try to imagine what will happen in a system with hundreds and thousands of business rules that affect each other.

Yes, business rules often end up changing data which, in turn, causes other business rules to be activated. No, it is not humanly possible to look at such a set of rules and predict what will happen when a certain event occurs. You can fire such an event in a test environment and see what will happen. When the results aren't what you wanted (that would be all the time), you can use the BRMS's to show you which rules were run as a result of that event. Let's see a business analyst debug that. "Plain English" my butt.

Let's not go too much further on the BRMS on its own, but rather view it in the light of service-oriented architectures.

In the article, an approach is shown that is supposed to bring you the best of both SOA and the Business Rules Philosophy. I'm afraid that my experience has been otherwise. The author states:

"The business rules server may be implemented as a Web Service that is accessible to many SOA enabled applications across the organization. By supporting shared business logic within the SOA architecture that can be addressed by many disparate applications, organizations can reduce redundancy, speed implementation, lessen inconsistency and improve the overall efficiency of both the applications and the business processes they serve."

This desire to concentrate all business logic into a single BRMS embodies the 11th fallacy of enterprise computing, as put forth by James Gosling "Business logic can and should be centralized". Not to mention that this goes against the grain of SOA where each service is autonomous and is entirely responsible for all of its data and behavior. There's another reason why the business rules community is pro centralization - the BRMS's are so damned expensive.

Anyway, I don't want to be all doom and gloom today so I'll end on a positive note. While good OO practices and the use of the Domain Model Pattern will take you VERY far in making business rules explicit, and, therefore, their maintenance and evolution much less costly, sometimes you really neeed a BRMS. Just so you know, the investment you made in the domain model is not written off when you "upsize" to business rules - the rules themselves are written using the concepts exposed in the domain. As for the service, well, its message handlers keep on working the same as they always did; parsing messages and making calls on the domain model. The business rules will just respond to the events raised by the domain; message handlers don't need to call into the BRMS.

Oh, and the next time somebody tells you how business analysts will be doing the work instead of programmers, ask them if they're willing to take the debugging too :)

Posted by Udi Dahan at 06:08 PM  Permalink |

In the EAI heydey, canonical data models were all the rage. Combined together with Brokers, they became the hub of the enterprise, or in technical terms, the bottleneck. Usually version 1.0 got off without too much trouble, it was 2.0, or 1.1 that couldn't extricate itself from 1.0. Steve Jones gives some background with his post "Single Canonical form - not for SOA".

Canonical data models are the anti-pattern at the opposite end of the spectrum from "A billion little services can't be wrong". When running away from the total lack of cohesion of little services, you may just end up in spaghetti land where not only is it cohesive, it's monolithic, something that SOA was supposed to get us away from.

One of the things going against single canonical form is that the business isn't single-faceted. Different departments give different meanings to the same terms. Sales has an entirely different view of "Customer" than does Accounting. By trying to integrate both perspectives into a single model, you end up either with the lowest common denominator (which is pretty uselss - Id, name, and address don't give us much), or an amalgam of properties from both domains with no way of knowing (come version 1.1) which are used where.

By modeling your SOA according to the structure of the business, you'll find that both the Accounting Service and the Sales Service have a customer entitiy in them. Yet besides the minor commonalities in basic data, these entities are totally different. If you were to design your services using OO principles, you'd find the Customer class in the domain model to have very different behavior from one service to the next. This is to be expected since the business rules in each domain are so very different.

This also gets back to the "re-use" fallacy of SOA. It would seem that concentrating all customer data in a single service, we could reap the benefits of re-use by employing that service anywhere customers are needed. Hurray! Lower costs, faster turn-around, business agility, right? Well, it turns out that giving each entity in a single canonical model its own service brings you the worst of both worlds. "A billion little services", each a slice of the giant ball of spaghetti.

In my recent podcast on Business & Autonomous Components, I described how keeping coherent business processes localized to a single service leads to better service decomposition and interaction.

Don't let yourself be led astray by the siren song of re-use and historically ineffective techniques like single canonical form. The services they bring may make you smile, but not in a good way.

Posted by Udi Dahan at 06:14 PM  Permalink |