Q: Could you tell you your thoughts or preference for a distributed or centralized ESB?

DON: there is no such thing as a centralized ESB.

This is the problem with a lot of the products that call themselves ESBs. They are centralized brokers which may be clustered for availability. But they are in no way an implementation of the Bus Architectural Pattern. Please check this before cutting a check to your vendor.

Also, understand that if you do security related things in your ESB, possibly as a part of your routing rules, that if the security infrastructure is centralized that means your ESB is too. Even if it really was distributed to begin with.

Buyer beware.

Download via the Dr. Dobbs’ site.

Or download directly here.

And here’s this week’s question:

Hi Udi,

Thanks again for your continued assistance. I was very much interested by your advice to consolidate each of the services related to each product family into a single service, but as autonomous components.

From your description of autonomous components from a prior podcast, it seems that they are much the same as services – in that they communicate only via loosely coupled messaging, and can have their own databases. Would you say that the main difference between autonomous components is that different autonomous components within a service may in fact share business logic and databases? If so, it would seem that combining these services into a single service with 3 autonomous components would be a matter of definition, rather than an architectural shift. Any information you could provide to clarify this distinction would be fantastic.

Something else that’s been playing on my mind of late – is whether or not you would consider a topic as having to belong to a specific service. That is, would you say it is bad practice to have multiple services publish on a common topic? I suppose if we have multiple services publishing on a common topic, then they should be defined as autonomous components, belonging to a single larger service – in which case that common topic would belong to that new service.

As usual your advice is always extremely helpful. Please keep those podcasts coming!

Best Regards,
Bill

Additional References

• Podcast on Message Schemas between multiple Publishers and Subscribers
• Podcast on Business and Autonomous Components in SOA

In his previous post Is it service-oriented if the message cannot be intermediated, Nick defines intermediability as “SOA should give us the ability to intercept a message going from point A to point B, and react to that message without informing either end of that pipe.”. I’ll respond to this in due course.

Anyway, he continues on by saying “SOA [is] an architecture for Enterprise Application Integration.”

I can’t agree with that statement. The main reason is that EAI puts the application in the center, and that integrating existing applications one of the primary purposes of it. It is my assertion that in order to solve many of the problems that we are having today, we need to take a broader, business based view of the enterprise and model that with services. A service may be implemented with one or more applications. However, my experience has been that these services tend to use parts of existing applications, with multiple services using different parts of the same application. The reason for this is that the applications we have today, especially the ERP monoliths, do a lot, and at the same time, not everything. This is part of the reality that EAI tried to solve, but then got mired down in cross system hell. You just can’t solve poor business decomposition in the technology domain.

The value of putting services at the fore makes it possible to gradually phase out and evolve legacy applications, and migrate costly mainframe apps bit by bit without having these changes ripple out and break other services. The same is true for those systems’ data – backup strategies are defined at the service level, impacted primarily by their Service-Level Agreements.

While I whole-heartedly agree with what Nick has to say in terms of OO intermediation of the Dependency Injection variety, and that scaling up those same concepts in terms of messaging is the right way to go, I take issue with orchestration in the intermediation area. These “tactical changes” need to be done in the context of the top, business-level service strategy. That means that all logic belongs within a service. The “network” between services is just that, a “dumb” network – no business logic of any kind, just technological capabilities like knowing which physical server to route messages to.

In this spirit, I’d like to suggest an alternative solution to the example Nick gives. Here’s the scenario:

Let’s say that system 1 generates an invoice. It sends an event to the world saying “invoice here” and system 2 captures that message. System 2 asks for details about the invoice… perhaps it will place the information on a web site for internal support teams.

Let’s say that we are moving to a CRM solution in our internal support groups. We want to create the information in the CRM system related to the invoices that specific customers have been issued. We need to integrate these two systems. The existing web app needs to have a link to the CRM system’s data, to allow the user to move across easily.

And here is the solution he prescribes:

We can intercept the request for further information from the web app to the publisher. When the publisher responds with information about the invoice, we can insert the invoice in the CRM system, add a link to the CRM record for that invoice to the data structure, and resume our response to the web app. Assuming that our canonical schema has a field for ‘foreign key’, we have just integrated our CRM and web information portal… without changing either one.

Without getting into the business-level analysis of what the correct service decomposition might be, here’s what I suggest (although all of these “systems” might just end up within the same service, or having parts of them being used by multiple services).

First of all, have all information about the invoice available via the message only. This could be done by actually putting all the invoice data in the message, or by placing a URI instead where other systems can HTTP GET it from – REST style. This decreases coupling between the publisher and its subscribers. However, we haven’t solved the problem of our web apps getting access to the relevant data in the CRM system.

The solution presents itself at the business level. The invoice is not “complete” without the appropriate CRM data. Therefore, it does not make sense for a service to publish it that way. Let’s call this service the Purchasing Service. It would handle the workflow of receiving the first system’s event, adding the invoice to the CRM system, and taking the resulting full invoice data and publishing that. All external systems like the web apps would see just the final event. Orchestration, if there even is such a thing, occurs within the service boundary. This technological level intermedation isn’t even a blip at the business level. We can also imagine other services, say a Sales Service, that would use the CRM system as well.

In summary, when moving to SOA, intermediation provides many technological benefits in getting data and behavior to work across existing systems and applications, however it’s laregly a NO-OP at the service level. After phasing out many of those existing applications behind the service boundaries, the same service-level interactions would persist. Your Service-Oriented Architecture would not be any different. That’s the technical agility aspect of SOA.

The goal of Microsoft Codename Astoria is to enable applications to expose data as a data service that can be consumed by web clients within a corporate network and across the internet. The data service is reachable over HTTP, and URIs are used to identify the various pieces of information available through the service. Interactions with the data service happens in terms of HTTP verbs such as GET, POST, PUT and DELETE, and the data exchanged in those interactions is represented in simple formats such as XML and JSON.

To me, this sounds like an unarchitected mashup of REST and the irrelevant part of SDO.

Please, Microsoft, just stop. You’re going the wrong way. We really don’t need yet another data access strategy from you.

Patrick Logan is still waiting to see anything concrete come out before weighing in. While Sam Gentile has given it the “New and Notable” stamp. Fabrice Marguerie will be investigating as well. And Paul Gielens also finds the REST path worthwhile.

But I’ve got to say, I’ve been against these “data services” from day one. The REST style is most applicable for large, chunky resources – while this seems to be targeting single tables in the database. Look at this discussion on REST vs SOA for some examples.

I am skeptical but will keep watching. But, what with all these fine bloggers giving me the low-down, I’m sure we’ll be finding out the important part soon – you know, the part Microsoft doesn’t put online

I’ve been getting some questions on how these upcoming standards correspond to what I’ve been describing about SOA. Specifically, how does SCA relate to the Business Components and Autonomous Components I podcasted about.

First of all, I’d say that the SDO thing is, in my opinion, “much ado about nothing”. These are “merely” the messages that are sent between services. We don’t need further standardization there, if the WS-Splat has taught us anything it’s that more is definitely not better.

In terms of SCA, it’s components seem to correspond to the Service Layer of an Autonomous Component.

What does all this have to do with Web Services? Well, in both the SCA/SDO case and in my ESB/SOA case, we add constraints and guidelines on top of the generic ways WSDL has been mangled by the tooling.

In all cases, we still need to discuss what makes a good contract – what is good message design. I’ll be dealing with that in the next coming days.

More information:

Info from IBM on SCA.
Info from IBM on SDO.

The tenets of Service Orientation as put forth by Microsoft include one about “autonomy”. The tenet states that “Services should be autonomous”. After some digging, I found out that the intent of the authors was “The teams that develop different services should not be dependent on each other”, or in shortened form “Autonomous Teams”. This revelation was surprising to me since the real meaning of the tenet was less profound than what I had imagined – autonomous computing.

The idea of autonomous computing has been around for some time and presents a view of the world in which computing units cooperate to achieve global goals yet are not dependent even on the existence of other computing units to function. (If you’re envisioning tiny robots playing soccer, you’re not far off.)

So when I first saw the autonomy tenet, I was thinking of autonomous services: services so loosely coupled that the correct functioning of a service would not be dependent on the correct functioning of other cooperating services. Services loosely coupled in time as well as in code. Obviously this would mean that if Service A needed to cooperate with Service B, and Service B was not even available, Service A would continue to function, and live up to its service-level-agreement. But before we start drifting off into the outer reaches of business-IT alignment, let’s bring this down to earth.

Before we get into a detailed analysis of the how, let’s first agree on the why. Despite being a historical trend, architectures these days tend to be more loosely coupled than before. Loose coupling being a good thing that enables us to better manage the complexity inherent in large software projects. The practical test of loose coupling in a system is changing the public interface of a class and seeing how much of the system doesn’t compile any more (dynamic languages aside). Service Orientation brings us tenets that, when followed, lead to more loosely coupled architectures than if we actively did not follow them. I think that we can agree then that if we could somehow achieve the loose coupling in time mentioned above, without paying an arm and a leg, that would move our architectures another step forward.

Looking back on the evolution of the field of distributed computing, we can see that, over time, less and less things are being assumed. It is now well understood that anything that goes over the network takes much longer than those calls that stay on the same machine, yet once systems were built that abstracted the network communication into looking just like local calls. The performance of those systems was matched only by their lifetime. With the advent of autonomous computing, the assumption that the called service is available and will respond in a timely fashion is called into question. In the real world, servers crash and network equipment goes up in smoke – we can no longer take for granted that communication will always be available, and that its quality will be good enough. In essence, this marks the end of synchronous RPC/RMI. The following code just won’t cut it in this brave new world:

localhost.service1 s1 = new localhost.service1();
orderReply = s1.HandleOrder(orderRequest);

If the service is unavailable, what will happen to our order request? Will it just get lost?
If the service takes a long time to respond, will our server tie up resources for the same amount of time? If this happens under peak load, might it cause our server to crash?

Performing the above code on a different thread won’t make any difference, autonomous services means the end of Request/Response as we know it.

“No Request/Response between services?!”, you ask incredulously.

The simple answer is “yes”, but there is another level of meaning to it. If you have two software entities that between them you just HAVE to have request/response communication, then they should be in the same service. This is where the real architectural guidance comes in.

In component-orientation and object-orientation, the division of the solution into the right number of parts, with each part having the right amount of responsibility was a kind of black magic passed from master to apprentice. Getting the boundaries right was paramount, but difficult. A number of litmus tests are used to catch the gross errors, and the rest is just gut. So too, the request/response test helps us catch gross errors in service boundary demarcation.

The interesting thing that happens after separating our services out this way is that we often end up with services that mirror the way the business side is structured. Voila, business-IT alignment with your hands closed and one eye tied behind your back! Well, it’s one step in the right direction anyway.

This leaves us with the original types of one-way communication (fire-and-forget, pub-sub, etc) and with one kind of two-way communication: duplex. Duplex is really just two one-way communications (A to B, then B to A) that are correlated. First, I send a message to you, mark it with an id number, and save that number. At some future point in time, you get the message, process it, and send a message back with its own id number. But, you’ll have to put my original id number on the message too, so that I’ll know that your message is a response to mine. At some even more distant point in the future, I get a message from you, look at it, and see that it is the long-awaited response to the request I sent way back when.

If I had to sum up the difference autonomous services bring to the styles of communication used between services, I’d say this: You get a message, look at it, and figure out what it means and what you should do. This isn’t an infrastructure issue. There application level timeouts to deal with (If I don’t get a response back in 3 days, then notify the supervisor), and long-running workflows to manage (next whitepaper ).

If there is one thing to pay attention to in this whole “autonomous services paradigm” it is that the focus has shifted from between services to within a single service. In parting, I want to let you know that systems can be, and are being, built this way. It works. It better than works. Systems created this way are more robust to failures (seeing as they’re designed for failures makes it less impressive) and easier to manage. Give it a try. You didn’t really think that SOA would fizzle away into a bunch of WS specs, did you?