Technology Thoughts

Thursday, December 22, 2005

(This was originally published in Bloglines on December 22, 2005)

(This is a comment to the post Ajax: Where should my business logic sit?)

Of course, any software engineering theory dictates that any AJAX should have no trace of business logic, but that this one must be limited to the server. Any good developer will tell you that one should put all of your logic in server-side web services, and handle only the presentation issues on the AJAX client side.

Also of course, the ability of creating business logic in a simple development environment like Javascript will lead in practice to the existence of a large number of applications with all of its business logic in the client side part. Just have a look at the number of applications existing now that have input validations only in the client side, and have the server side open to any client side mischief.

This is one of the problems I see in all the fuzz around AJAX. In my view, Javascript is not a good, stable, reliable environment for running professional applications. In my experience, any average development team devoted to Javascript will end up creating an unmanageable mess. It is not that it is not possible to do it in the right way: it is just that the average team won't. One just has to look to all the problems JSP has created to see this (if instead of just copying Microsoft's ASP with JSP Sun would have come up with a decent component-oriented framework for creating web views -which was perfectly feasible at the time-, web development would be a lot more easier now. Then, Java trailed MS again in this, with JSF).

I think that currently there is much more hype in AJAX than practical stuff. Although all the frenzy is also good, since it draws the attention and it is a first step. A first step towards a good computing platform to deploy client-side applications to the web: what Java applets should have been and are not because of several different reasons. Something with the robustness of Java (or .Net), the appeal and speed of Flash, and the convenience and universal availability of Javascript.

Some day there will be such a platform, well beyond AJAX. However, it will be also thanks to AJAX.

Friday, December 16, 2005

Will the ESB kill the UDDI star?

(This was originally published at Bloglines on Fri, Dec 16 2005)

I do not like the Enterprise Service Bus (ESB) concept. I think a Service Oriented Architecture (SOA) should be composed of a myriad of services, all of them peers (i.e. no one is higher than the other), which would contact themselves freely. And for this contact to happen, better not to use hardwrired addresses but a registry of services, i.e. UDDI.I do not like the Enterprise Service Bus (ESB) concept. I think a Service Oriented Architecture (SOA) should be composed of a myriad of services, all of them peers (i.e. no one is higher than the other), which would contact themselves freely. And for this contact to happen, better not to use hardwrired addresses but a registry of services, i.e. UDDI.

And I am not the only one to see SOAs this way, but then the ESB concept is being increasingly popular. For me, an ESB is just an Enterprise Applications Integration (EAI) product that is based in standards around the SOA world, instead of using just proprietarty mechanisms as in the pre-SOA times - no less, no more. It is intended to be the centerpiece of the SOA, the master of all interactions. All messages should go through it, all services should contact it to talk with other services. It would be the King of what I think should be a Republic of services. For start, the own concept of "Bus" is against any "liberal" SOA.

Without an ESB, if an element of the SOA needs to send something to someone, it would require that a particular known interface is implemented by some component, which is registered in the UDDI, as implementing this interface (which in turn is also defined in the UDDI). The element searches in the UDDI for that other component, calls it, and that's all. The element depends only of a set of well known interfaces, that may be implemented by any valid means of creating a service, including a service scripting engine (see later).

With an ESB, the element hands the message to the ESB, and it will take care of handling it. The element still depends on an interface, but now it is not explicitly defined since the ESB will be programmed to implement it. With the ESB every element depends on the ESB; without it, every element depends on a set of interfaces. The ESB becomes a new repository of business logic, without it, the logic is where it is now: in the services. A new repository with its new rules, means of administrating it, means of developing it, etc.

If all elements contact the ESB for any interaction with a service, then there is very little point in having a UDDI registry: as far as all services are registered in the ESB, there is no need for it. Of course the ESB could rely upon a external UDDI server for the registration but, since it will be the only element of the SOA accessing it, it seems little useful. So the UDDI is dead. Well, at least for SOAs internal to an organisation - for SOAs reaching outside an organisation, the ESB model scales to a "SOA of ESBs", having the ESB of each organisation contacting the other ESB. These ESBs should be registered somewhere, so I guess UDDI still makes sense for extranets.

I guess the ESB model is easier to understand, but I do not see the point of it at all. And it is not that I do not see the usefulness of what a ESB does. It could perform the following tasks:

  1. Simple transformation of messages, for adapting two services using different interfaces

  2. Allow to create simple services

  3. Allow simple routing of messages

  4. Allow asynchronous communications (queuing of messages, retrying, etc)

  5. Allow publish/subscribe communications

Tasks 1 to 3 conform what I call service scripting, i.e. they are tasks that could be performed by a regular service of the SOA made by any usual technique (e.g. .Net) , but that are simple enough to be done by a configurable product instead. It is just the same as the Unix scripts: its job could be performed by a regular command written in C, but it is simple enough to be carried out by simpler means.

Taks 4 and 5 are middleware / infrastructure tasks that I will refer to as asynchronous interactions, that are of use in most SOAs, since both should be needed in most real life situations.

For start, I do not see the point of having such different two groups of tasks performed by a single, big component. For asynchronous interactions it makes sense to have a single component in the SOA performing them, but by no means it should be the center of anything, since in most cases not all interactions should be asynchronous.

But for service scripting there is no reason at all to have a single component performing it. Service scripting is just a means of creating another web service, and thus it would be a hidden facility of the SOA: when one contacts a service, it does not matter whether it has been created through scripting, through regular development, through semantic computing, or whatever. And there is no point on limiting to have a single scripting engine, where different ones may have different advantages.

But I am afraid that there is more people out there liking the ESBs than not. With all the buzz about SOAs, people wonder about "how could I implement a SOA?" And then there come the ESB vendor with the solution: "buy me this and you will have a SOA." Then the customer starts using the ESB and putting its business logic into it, i.e. on the hands of the vendor, who will be much happy for that. Well, the less happier the more standard is the way to define, deploy and administer that logic.

There is much more movement around ESBs than around UDDI. There are JBI, SCA, a couple of open-source ESBs. And, for UDDI v3, there is very little. These days I have tried to create stubs to access a UDDI repository out of the WSDLs with Apache Axis, and the result has been really poor (the stubs do not even compile, and some of them generate wrong responses). And even I had to manually modify the original UDDI WSDLs following the instructions by OASIS . I do not see UDDI being trendy out there any more.

Well, I guess a SOA centered in an ESB is better than no SOA at all. After all, the main benefit of SOAs is to distribute the business logic into a set of reusable services. They would be more reusable if they would not rely on the ESB, but if the ESB is standard enough, the services will be reusable anyway.

Farewell, service republic, here it comes the ESB king to rule you.

Weblog Commenting and Trackback by