Technology Thoughts

Against the usage of "logical" and "phisical"

2007-02-11T11:38:00.000-08:00

Once upon a time, the terms "logical" and "physical" meant something absolute, at least in specific contexts inside IT. In databases, the physical layer was the actual files and other containers of data, while the logical one was the fields and records immediately on top of them. In networks, the physical layer was the actual wire, and logical referred to the protocol governing the actual bits sent over it.

But nowadays, when there are so many layers in any IT system, the terms physical and logical have lost these absolute position and have only a relative meaning. Logical means just "less detailed", (i.e. abstracting some details out), and physical means just "more detailed" (i.e. with more concrete details). Nowadays, something termed as logical (or physical) in a context is just the physical (or logical) layer of another context.

Thus, when any of these is used without a reference (e.g. "the logical layer" or "a physical diagram"), in many cases the communication is difficulted because the person saying them may have one idea of what they mean, while the others may well have a different one. Then, misunderstanding comes and also time wasted realizing it and trying to sort it out.

Because of this I advocate to either using them only in a relative way (e.g. "this is a logical view of this"), or even better not to use them at all, and using instead other clearer terms.

soapUI: a very good tool for invoking and testing web services

2006-11-28T03:51:00.000-08:00

Today I have known of a very good open source tool to work with SOAP web services: soapUI. It isa kind of small IDE which allows to define web services out of its WSDL, generate sample requests,send them to the services (including attachments), perform functional or load testing, WS-I validations,and other operations from other tools it integrates with, like TCPMon, Axis, GSoap or .Net, likegenerating stubs and deployment descriptors.

I would have liked to know it before, but it is better late than never. More information: http://www.soapui.org/.

BEA microService Architecture (mSA)

2006-11-15T08:58:00.000-08:00

When I saw the announcement of the future SOA 360 product initiative from BEA I focused on the Workspace 360 idea, which sounds nice (I think the SOA killer application will be something allowing Excel-capable users to compose applications and services). But I overlooked the microService Architecture (mSA). And it looks very interesting, too.

For start, it seems to be a SOA not based on a central ESB, as popular in software vendors and as it was now with BEA. It looks more like Jini, but based in OSGi. It is a federation of containers of small services, which discover and communicate between them dynamically. It seems to follow the view of SOA as a galaxy of free services, instead of having them orbiting around a central broker. They talk about "infrastructure services" providing composite service capabilities, but this does not look like a central ESB anyway.

The services are Java or bound with Java, but I guess they will be able to interoperate with others at least by WS-* . mSA seems mostly protocol-agnostic, so it should support both WS-* and other (I do not see the point of being more abstract than WS-*, but OK, many people does).

I am curious to see which will be the method to discover services, and how will they handle the actual communication. We'll see.

The different levels of Service-Oriented Architectures

2006-11-07T01:59:00.000-08:00

Yesterday I sent a message to the Service-Orientated-Architecture group of which I am still fond of, so I think it is worth to be published also here.

Key to any SOA is the Service Model - i.e. which services exist, what for, and which interfaces do they have. Indeed this is what most often is called "architectural design", which is key to the success of any information system, assigning responsabilities to parts of the system.

But to really have a running system these services must be deployed into something, which completes the architecture. And also SOA is more than the services; it is also the infrastructure surrounding them.

Without a defined architectural framework there is no real interoperability, which is the basis of the reuse, agility et al touted for SOAs. To make services work you need of some infrastructure for things like discovery, communications (both synchronous and otherwise), management, etc. I.e. the gap originally addressed by SOAP, WSDL and UDDI and being now incrementally filled by WS-*. For SOAs not based on web services, similar things must exist first in order to lay the ground for reuse in practice.

I think there are three levels of architectural detail in any SOA:

The basic one shared by every SOA, i.e.: there are services (implementing the business/domain functionality without user interface) and applications (without business/domain functionality at all, but with user interface).

I think there is a general agreement at least about these basics, although there may be still discussions on whether applications and services can invoke other services, or this is allowed only to ESBs (which would then be the third element of the basic architecture, of course). Or whether there is a need of a directory (e.g. UDDI) in order to consumers to locate services.

The level addressed by the assorted Reference Architectures used nowadays by different software vendors, involving elements like "legacy services", "service buses" or "registries". There is some degree of convergence here but no consensus yet, at all.

The concrete architecture of a particular running SOA which details what and which are these legacy services, buses or whatever, if any.

To have a running SOA you must first make a decision about the three levels, and this is architecture, because Service Models do not execute.

IBM has abandoned UDDI

2006-11-02T09:50:00.000-08:00

One of the original proposers of UDDI, has in fact abandoned it. I have read in IBM people blogs that UDDI will be superseded. In the some 5 papers I have seen about its upcoming Websphere Registry and Repository, I have seen no mention of it. And this later paper about "Web service standards for Service Registry and Repository" confirms this: they mention UDDI, but only as some kind of legacy technology than, if cannot be superseded, has to be kept along with the Service Registry and Repository.

I do not know what happened to UDDI. Since the start, very few people used it. I agree in that it has several clumsy things and several other things that have yet to be added to it, but I think it deserved better destiny.

Now that I come to it, while UDDI was for service registries, WebDAV was for document repositories and it has come to a similar fate. Few people use it and many loath it.

At any rate, some standard way of accessing a registry and repository is badly needed in SOAs, and I reckon also for a service WWW. So something will come up, I guess. We'll see.

The legacy ESB

2006-10-31T09:19:00.000-08:00

3-5 years in the future from now on, many companies who thought that they bought a SOA by buying an ESB will be faced with the issue of buying some new infrastructure, maybe a new ESB, packed with new features. But they won't want to replace their old one, full of cranky old orchestrations who nobody in the corporation does any more how were done and that nobody want to touch because they just work...

Then the company will realize that they will have a legacy ESB. And if they buy something new, it will run just as fine, being integrated in the new infrastructure. Hopefully they will learn, then, that the ESB is not the center of a SOA at all, but just another provider of services, just as so many other things in a SOA.

The typical three-tier SOA (legacy-orchestration-frontend) is not a reference Service-Oriented Architecture; it is just a way of building integration services / applications.

SOA and reuse

2006-10-06T02:09:00.000-07:00

There seems to be a debate about the true extent of reuse in SOAs. E.g. David Chappel, Joe McKendrick, or Theo Beack have blogged about it.

I think that inside an organization reuse is perfectly possible, because in many cases there is only a single context. E.g. inside of a company there should be room for only one logic for a Purchase_Order_service.

The problem for reuse is across a large market of organizations, or for larger organizations with different context. E.g. to be able to buy a "generic" Purchase_Order_service and adapt it for your context.

Theo Beack says that "the context should be elevated to the process layer and NOT encapsulated within the service". But I think this would result in services doing tasks of very limited usefulness, since the actually valuable business logic would be inside business processes, which would create the context by linking services. One can envision these business processes being traded across companies (the context changing thanks to using different services), but I think there is not yet a framework for this. But one for services is emerging, so it may be better to use it.

I think that the key to reuse may be to factor out funcionality as much as possible: create many small services doing concrete things, and relying themselves on other small services. Then all these small services can have a particular implementation inside a particular context. E.g. Purchase_Order_service would rely on Product, Customer, Invoicing etc services which would be specific for the context of an organization. Interface-oriented design is key to this.

This would make services to depend on other services, resulting in more thigt-coupled services, but in exchange they would deliver much more business value than isolated services.

About the SCA and SDO

2006-10-04T03:40:00.000-07:00

During some months now, many software vendors lead by IBM have been involved in the SCA initiative (well it is actually Open SOA, whose two main pillars are SCA - Service Component Architecture and SDO - Service Data Objects).

As far as I understand it, the intention of SCA is to create a standard environment (APIs, models, containers) in which services of a SOA can run and interoperate, no matter which implementation or platform they have, or even which type of components they use, since it aims to integrate Java objects, EJBs, C++, or whatever. This is, it is sort of a standard, vendor-neutral middleware for creating services; the specification of a SOA platform which every vendor can then implement.

For its part, SDO aims to create a standard way for service implementations to access any kind of data, from RDMBS to XDBMS through web services.

So all in all to me it seems much like J2EE: allow both to create distributed components and access data. Of course, not limited to Java or even to a single networking protocol, but for every platform.

When I first saw the creation of the initiative I thought that this was just a rebranding of proprietary IBM technologies (things called SCA and SDO had been available at IBM for some time before that). Well it seems something like that, only that hopefully it will be truly open. Although I can guess that IBM, being the inventor, will have much advantage in its implementations on the rest of the consortium. But who knows.

At any rate, I still do not see the point of SCA. For me, the platform that allows for interoperability of every kind of software component in any implementation or platform is web services. SCA should allow to have interoperable services other than web services, but I think that WS-* is enough and that there is no need of any more.

But we will see, since the success of these initiatives rely on the end upon who supports them (e.g. it does not matter you like CORBA more than SOAP, since SOAP is supported by every vendor), and Open SOA has an impressive list of them (BEA, Oracle, TIBCO, Sun and several others). However, they happen to be only Java vendors: Microsoft is not there. And if SCA will not properly supported in Microsoft platforms, it means that it will not be interoperable enough, as WS-* is.

The ESB and the SOA

2006-10-03T04:55:00.000-07:00

(I am replacing this post, because the original one was too obscure and not even me really understood it after some time of having written it. So I hope the new version transmits better which I think has to be the role of an ESB in a SOA.)

ESBs are, for one thing, a fuzzy category of middleware products with a large variety of capabilities. From these capabilities, I think there are two that ESBs are well suited to perform:

Managed communications, including support for different protocols, asynchronous and publish/subscribe communications, and reliable communications (in general, anything that is not supported by the communication stacks available in the consumers or the services).

Orchestration, which includes message routing, transformation, aggregation and creation of composite services.

These capabilities are needed in many SOAs, and I think ESBs are a good way to implement them.

ESB products usually perform other capabilities like monitoring, security, logging or endpoint management. These other capabilities are useful only if the ESB mediates in every consumer-service interaction, because otherwise you need also of additional mechanisms different than the ESB.

This is the other meaning of the word ESB: an architectural pattern in which the SOA has three main type of elements: services, service consumers, and the ESB, which is an element independent from the other two and which is the neccessary mediator in any interaction between the other two. To me, to call a product an ESB it must allow to implement this pattern, and this is why I do not see the IONA middleware, which is agent-based and not an independent element, as an ESB.

I think the ESB pattern makes sense in some kind of SOAs (more on that later), but I consider that saying that every SOA has to follow this pattern is plainly wrong. A Service-Oriented Architecture is a way to structure an IT system so that as most logic as possible is implemented in services which can be freely consumed by any other element of the SOA, as long as it knows the service description (mainly, its interface). This vision does not need a intermediate element like an ESB to make these interaction possible, and thus requiring it is just misleading.

As I said, to use an ESB to implement the latter capabilities requires not only the ESB product but also to follow the ESB pattern, but not every SOA has to implement this pattern. If your architecture follows the ESB pattern you can well use the ESB to implement these, but your architecture may not follow that pattern, and thus an ESB would not be useful to implement these capabilities and you will have to use other solution to implement them. However, for the two first capabilities (communications and orchestration), an ESB may be useful in any kind of SOA.

So I am not against the ESB product per se, but more against the ESB pattern being mandatory. I think the ESB pattern makes sense in some cases, but it is not the only way of doing SOAs. Indeed, for many SOAs it is a wrong pattern.

The ESB pattern is actually an integration pattern. The more diverse sources to integrate you have, and the simpler they are, the more useful is the ESB pattern. The extreme ESB pattern requires very basic services which are fully decoupled, i.e. which are never consumers of other service. Then, you integrate them using the ESB, and after that you can have other consumers leveraging the integrated set. Of course, this happens to be the same as the EAI pattern, in which you have existing systems you want to integrate. This is not casual, because ESB products are actually an evolution of EAIs.

But, while an EAI is a solution for integration and only for integration, SOAs are more than this. For example, if you do not have existing systems to integrate (e.g. a new distributed system is created from scratch), an EAI product would be useless. But a SOA would still make full sense, because SOA is just a way to structure functionality inside of a IT system by means of services.

This is a common mistake: many people think that the main value, even the only value of SOA is integration. This is wrong. SOA is more than that. Of course services are a good way to expose the functionality of systems to be integrated, but this is not the only usefulness of services. Besides integration, services are useful as a mean to split functionality in bits and then reuse it.

These people sees Service-Oriented Architecture as an integration architecture, and this is why they see that the only way to create a SOA is by means of the ESB pattern. But this is one flavor of SOA, not all of SOA.

Thus, I see ESBs as a good means to implement managed communications and orchestration when you need them, which is often. This is, if the interaction between consumer A and service B needs managed communications, it is OK to put an ESB in the middle. If you have three services C, D and E and they are often used jointly in a coordinated way, it is perfectly good to use an ESB to create service F which would orchestrate them. If you have service G with an interface but you have consumer H which expects another interface, is is fine to use an ESB to implement H's interface and transform it into G's interface. And so on. Of course you can use also other methods than ESB for that, but ESBs are just fine.

But if you want to log all the messages going through your SOA, or enforce security polices for consumers and services, or monitor activity, or be able to change the location of your services without broking the SOA, an ESB is useful only if you follow the ESB pattern, which may well not suite your SOA. If you have an integration-intensive SOA it may be the best option to follow, but otherwise it is better you look for other ways of implementing these, because it could be negative to force your SOA to follow the ESB pattern.

The bottom line: I see perfectly sound to use an ESB to implement managed communications and orchestration in any kind of SOA. But for other capabilities like monitoring or security, unless the ESB pattern suites your SOA I would rather recommend using other kind of solution, like agent-based middleware or just SOA communication libraries. The more integration needs you have, the more useful is an ESB to implement your SOA.

I think the ESB frenzy is temporary and that eventually everybody will see things this way. But there has been people saying similar things since 2004, and still the ESB is commonly presented as the king of the SOA. However, the implementation of larger and more complex SOAs, and the growing importance of governance and registries and its usage at runtime, may displace the focus from the ESB and change this perception.

I am not alone in my view of ESBs

2006-09-28T11:42:00.000-07:00

... or at least this is what I think. Today I have subscribed to the blog of IONA CTO Eric Newcomer, and I have found a post about "The ESB question" that makes me believe so: IONA sells a distributed agent infrastructure instead of a big clunky ESB.

This makes me very happy, because every time I discuss with people about ESBs I end up with the feeling that I am the only one thinking that, while ESBs perform some useful features, the current concept of putting the ESB as the heart of the SOA is wrong.

From some weeks I have had a pending task of writing a series of posts dissecting and detailing this opinion. I hope some day I will. But besides I will also collect these kind of opinions close to mine, even if it serves only to raise my morale a little.

So I am keeping a list of articles that argue against, or at least put into doubt, the assumption that an ESB lies in the hearth of every SOA: http://del.icio.us/jcamara/ESB!%3DSOA

Windows XP taskbar not showing up

2006-08-11T01:10:00.000-07:00

This is a practical post to document a Windows XP problem a friend of mine has had. I did not found the solution in Google and thus it should be useful to put it somewhere.

This friend called me because when logging into Windows XP, just the wallpaper was shown: no taskbar or icons appeared. I told her to run "explorer.exe" from the task manager, but the taskbar just flashed in and out. One thing however: before executing anything from the task manager, an error dialog telling something about some Google file missing was shown.

We opened regedit and looked for Google and found the UninstallString of Google desktop and ran it. Apparently the deinstallation succeeded and the error dialog disappeared, but the taskbar still won't show up.

I end up going to my friend's home and trying deinstalling more things ("XP Styles", an antivirus), deactivating shell extensions, running Ad-Aware, using Process Explorer and FileMon and RegMon, restoring XP to an older saved state, and nothing worked.

Just before resorting to repariring the XP, I thought of looking back to the original Google desktop problem. I intended to delete any traces of the Google desktop directory and reinstalling it again, but in these directories I already found "GoogleDesktopSetup.exe". I ran it, rebooted (or maybe just logged out and in again), and there was the taskbar.

So Google desktop broke somehow (have no idea of how) and after that Explorer did not start properly, even though Google desktop seemed to have been deinstalled, and the problem was not fixed until Google desktop was installed again. A pity that a so well-famed company as Google causes that kind of problems. I hate when something fails without saying anything about it.

Hope this helps somebody

Are Semantic Web Services the next step?

2006-01-20T03:10:00.000-08:00

(Originally published at TheBlog on January 20, 2006)

(This is a reply to the article Is it time for SOA developers to start thinking about semantics?).

I have some experience with SOA and web services, and also have looked a little into the world of semantic web services. And to summarize my position: I am very much skeptic about the latter.

SOA is a new wave of traditional computing that works or, at least, is clearly viable. "Traditional" means that it relies in humans programming machines mainly using procedural approaches like Java or activity/flow diagrams. Non-IT, Domain users are increasingly able to do so.

Semantic Web Services (SWS) is the new incarnation of symbolic Artificial Intelligence agents. They have been there since several decades ago. Each time a new computing wave appears, the symbolic AI people come in saying "hey this is good but it would be superb if you put semantics on top of it". The high level approach is always the same: use declarative programming not to tell the computer how to do something, but what it has to do.

The underlying technology is irrelevant to this; it is just the same whether they are using dumb terminals, client-server, web applications, or a SOA. It is so irrelevant that the SWS world is a bold new one. You have to start learning tons of things about ontologies, description logics, planning and many other things that, while may be useful in many respects, are usually very far away from the actual, day to day needs of real Domain users of computers. And, you know, resources, experience and tools about it are far, far less aboundant and with far less quality than with standard computing. And once you spent months learning v(or trying to learn) it, then you try to apply it to the real computing, and you find that the world happens to be much more complex than theoricists think it is. (In particular, you find that declarative programming is in general more complex than procedural one, to which does not help the much worse tools and support).

For until now, the result of these semantic attemps is always the same: much promises, and very little deliverance. In the meanwhile, the rest of the computer industry goes on doing useful things and creating new waves, and the symbolic AI people remain entrenched in their ivory tower, attending to events and figthing themselves. For, did I talked about a single world of semantic web services? Sorry! Telling people behind OWL-S (mainly from US) that they are just the same as people behind WSMO (mainly europeans) I think is an outrage to them. If you attend a presentation of one of them, they will tell you that "the other approach" is just flawed and is in the process of fading away. Last time I attended one, I asked the speaker about the unifying initiative of SWSI and he did not know about it. And OWL-S and WSMO are not even the only initiatives, existing several minor other ones.

I am fully convinced about that, some day, computers will be really able of intelligent thinking. But I am also quite convinced that this will not come from the hands of symbolic AI, but from less clear machines in the track of neural networks (i.e. non-symbolic AI). But until then, what has worked and what I think will continue working, is mostly traditional, procedural computing.

However, I grant that the current initatives behind the Semantic Web have a new flavor, with much more people behind it than in other incarnations. Maybe this, along with the superior power of todays computers and the availability of the WWW will make a difference. But from what I have seen, I remain skeptical.

SOA: A platform to rule them all (and in the network bind them)

2006-01-16T03:07:00.000-08:00

(Originally published at TheBlog on January 16, 2006)

What is an SOA?

Let's start with the basics. Service Orientation is a way of building software systems in which the implementation of the features to be done is splitted into discrete collaborative units called services, which depend on each other only through well defined procedural interfaces which define the operations offered and the data they interchange, and that are usually scattered around a network. A Service Oriented Architecture (SOA) is the artifact that makes the system run with the principles of applying Service Orientation, and thus is the result of it. Both concepts are tightly associated and I will freely use one or the other.

Service Orientation and SOAs are useful paradigms for building systems, because having services as loosely-coupled computing units may provide many benefits like componentization (and associated isolation, maintenability and others), reuse, flexibility and interoperability, among others.

To compare them with something more known, let's take Object Orientation (OO). This is another paradigm for building software with similar goals; only, instead of focusing in services, it does in objects and classes of objects, which have several different properties than these. Object Orientation is more complex than Service Orientation and allows to design and create not only the architecture(1) level of systems, but is also useful for lowel levels, like the internal implementation of components. For example, typically in an SOA, each individual service would be internally built using OO principles, not SOA ones.

(Note 1: I won't try to define here what "the architecture of a system" is, but just assume a hopefully common, fuzzy conception related to the macrostructure of an IT system.)

While one of the most praised benefits of Object Orientation is software reuse, I think that all of us are aware now of its limitations regarding this. For start, just applying the Object Orientation paradigm does not help much in making your newly developed software modules really reusable, since this depends also on the actual technology you have used to build it. If you have used Java, then you have a chance to be able to reuse them in a Java environment, but very little to do so in a .Net, C++ or Ruby one; even though all of them are Object Oriented. And even if you stick to the same development language, for example Java, it usually is not enough. If you have used e.g. Hibernate for accessing the database or Swing for your user interface, you will have problems if it happens that the environment in which you want to reuse them uses JDO over an XML database or is a web application. So it is not only the language, but also all of the surrounding framework.

Just the same as Object Orientation principles are not enough to achieve reusability, but also the actual pieces of technology used matters a lot, the same happens with Service Orientation and SOAs. If you stick only to Service Orientation, your code will not be reusable. For example, you may build a component for an SOA using Jini - but then you will able to deploy it only in an SOA based on Jini.

Now I come to my first point: it is useless to talk about SOAs in abstract. One must settle to the actual technology used in order to achieve the true benefits of an SOA. So I will choose such a technology right now and forget about other alternatives.

Which SOA are we talking about?

From these "true benefits" of SOAs, for me the most outstanding one is interoperability. For start, it is a required factor for achieving the holy grail of software reuse, since only if a component you create is interoperable with others may it be reused.

And indeed interoperability is the feature we most miss now: we may have componentization, isolation, maintainability and many other good things - what we do not have is a real way to create software using a technology, that is able to properly interact with software created with most other technologies. And it is not a technical problem. I mean, most technologies are interoperable in theory - but in practice almost all of them miss the proper industry support in order for this to be true. And most people are interested in the in practice part, not in the theoretical one.

For example, Java does not interoperate specially well with other non-Java platforms, except through web services or CORBA. The extent of CORBA support may be discussed, but as long as Microsoft does not embrace it it is not interoperable enough in practice. DCOM is just the complementary to DCOM. And .Net is the complimentary to Java.

The truth nowadays is that XML web services over SOAP and HTTP and described by WSDL are the only realistic option to interoperate with any platform. This is, if you are to build a product that you pretend to have the maximum interoperation with other platforms, there is not other choice that SOAP web services. I do not care about whether it is inefficient, bad or even a total crap. I do not care whether REST is better than SOAP, whether SSDL is superior to WSDL, or whether RELAX outperforms XML Schema in every aspect - the main differentiator of all them against its alternative technologies is that they are supported by every relevant actor in the IT landscape. Microsoft, IBM, Sun and all the other players support WSDL + SOAP + HTTP, and this means that you can indeed interoperate with any other platform in the world (2). And this is interoperability in practice.

By the way, this is the very same value of XML: regardless of whether it is good or bad, what makes it so useful is that it is supported by every player.

(Note 2: I agree in that interoperability of web services is still more a goal than a reality, but today you are much more interoperable if you use web services, than if you use any other technology. And I trust in that they will eventually become fully interoperable.)

I said that for SOAs to really provide interoperability the actual technology to be used must be fixed, but until now I have only talked about WSDL/SOAP/HTTP web services. And as you may well know, SOAs are not only web services. Which is the difference between a bunch of web services and an SOA?

What differentiates a set of web services from an SOA?

More or less, the difference is the same as between the Java programming language and a full Java development/runtime environment with all of the J2EE libraries; and, if you want, additional ones like Spring, Struts, etc. This is, a common framework that provides facilities to the bunch services which is still contained inside the SOA.

For start, when one of these services needs to call any other service, first has to locate it, i.e. find out which is the URL to where the XML message must be sent. If you do not have an SOA, you have to use ad-hoc mechanisms for this, like for example hard-wired URLs taken from WSDLs or ad-hoc configuration files. Such ad-hoc mechanisms are an ovbious obstacle for reuse, since your software depends on them, which means that any environment in which you aim to deploy them muse use these mechanisms too, and none of the two examples given above are a good option for this (e.g. imagine having thousands of services, each one of which requires of a custom, ad-hoc configuration for calling each other). In short, there must be some mechanism for components to discover each other.

To solve this problem there are at least two solutions: use an ESB, or use a UDDI server. In theory they are not exclusive, but I think that in practice they are, since both technologies take a central room in an SOA. The ESB is the communication channel of every communication inside the SOA, while the UDDI must be used at least once before each communication is stablished, but does not intervene during the own communication. You can read here more about my opinion on ESBs versus UDDI.

Having a UDDI server in place, each service must look up into it which is the endpoint to be called at least once before invoking each different interface it depends upon. Depending on the degree of dynamism of the environment this may be at deploy time or at run time. This provides something similar to what in other environments is called dynamic or late binding, since the actual code to be called behind an interface is decided at run time. And this brings dynamism, since you may replace the implementation of any given interface by another one without touching any line of code, and as long as this interface is enforced the SOA keeps working fine.

I keep talking about interfaces, since I think the proper way of building collaborative, loosely coupled services is to make them depend from each other only through well-defined interfaces. These interfaces end up being represented in WSDL 1 as portTypes, bindings and ports, among which the most useful thing to make a service depend upon I think is the binding. This is, when you create a component that invokes some other N services, you should make it depend on N SOAP bindings. When the WSDLs are registered in the UDDI, if you follow the OASIS recommendation about how to do it, then your component may easily look up the binding in the UDDI, and them which are the services which implement them in order to call them.

Note that there may be more than one service found, but this may be a good thing. For example, if you want to find out which vendor sells the cheapest shoes, assumming every vendor implements a given SOAP binding, you may find out all of the provider endpoints in the UDDI, call them one after each other and compare them.

As you can see, I am relying all of the time in having well defined interfaces, and as all of us know, this is something that may be difficult to have, since even for an internal integration we will found a large number of different interfaces. But the own flexibility SOA comes to the rescue, since it allows to build adaptors for each interface and register them as stubs, so that you still can rely on having a given interface. I do not want to ellaborate much about this; maybe I will do a separate post, since this one is already long enough.

By the way, I have focused on UDDI, and maybe you are an ESB fan. For the ESB flavor of SOAs, the thing is very similar. Your nice component still should depend on interfaces, but it does not look up in the UDDI to see who implements them - it just calls the ESB, and it will take care of implementing your interface and deliver your message to the proper place. In the end is just the same, only you lose options: instead of writing the adaptation layer in whichever way you want, you typically will use the ESB. I do not like this because the ESB will become just a trash can of business logic, and we have places enough already where we put business logic to have yet another more. Besides, you usually put your business logic in the hands of some proprietary product, which uses new paradigms and technology to make your system work. With a non-ESB SOA, you are free to implement your services in any way.

As you see, the UDDI approach does not preclude the ESB one: if you stick to UDDI, you always may register your ESB inside it as providing your interface if you want. But if you focus on ESBs, then you lose other options like UDDI. Thus, I like to have ESBs only as an option, and not as the center of a SOA as, unsurprisingly, ESB vendors depict. (For the start, this is what the "Bus" term implies - a common communication facility that everybody uses. If you have not yet guessed out, I do not like ESBs.)

Until now I have drawn some conclusions:

SOAs based on WSDL + SOAP + HTTP are the base of unparallelled software reuse

You also need to have some mechanism for discovery to achieve this

But besides discovery there are, of course, still more things one needs before one may claim you have an SOA and not only a bunch of services. Things like security (most critically, authentication and authorization), transactions, asynchronous messaging, publish/subscribe, stateful services, non-functional properties of contracts (e.g. policies), etc. This is all what the large number of WS-* standards aim to settle. For example, if there would be a universally accepted WS-Transaction standard, one could create a component that would access several services like Accounting, Customer and Invoicing, do useful business operations on top of them, in a single transaction. How nice.

I have heard about many of these WS-* standards but do not know well any of them, so that it is pointless I talk about them. I only should say that they are needed in order to achieve true reuse of SOA components.

And only if one has all of these standards in place one will have an SOA. This means that nowadays having a real SOA is impossible, since most of these standards are not mature, agreed or even standrdas but just mere specifications made by a number of vendors, some time with more intention to sell their own products than to create useful standards (e.g. the recent initiative for SCA, SDO and others seems to be quite product-oriented).

But the point is that, the more actual standards does your wannabe SOA support, the more it resembles a true SOA. And what do you achieve when you have a true SOA? A platform on which to deploy arbitrary software components developed by arbitrary vendors. If you are a software vendor, what you gain when you target your software for SOAs is a platform that every one of your potential customers will eventually have, and on top of which you can deploy (i.e. sell) your products and services.

It is like in the hottest dreams of Bill Gates: if every computer in the world would use Windows, then every piece of software in the world would run in it, and would probably offer DCOM interfaces over which every software would be able to interoperate with the other. The IT systems would be much easier to operate and maintain - and Microsoft would be incredibly powerful.

Stop dreaming, Bill - because this dream is possible, although not by means of Windows, but by means of SOA. SOA is the platform. This is the basis of the so much praised Web 2.0 : A world of discrete services, offering well defined interfaces, with no central "bus" inside it, with a nice distributed directory system to find each other and infrastructure services for security, transactions and so on.

But Web 2.0 is the view of a "world-wide SOA", while I am more interesting in the view of lots of SOAs operating inside organizations (i.e. Internet vs intranets). Once most organizations in the world with own IT systems are using an SOA, most pieces of business logic which is available as a service may be reused in most organizations. Most components performing useful functions may find other services fulfilling its needs, in most organizations. The SOA is the ultimate technological platform. And it is non-proprietary, it is not owned by anybody; neither by a pack of greedy executives, nor by a bunch of untidy developers, but shared and developed by them all.

Beyond technology

Once this universal platform is available in most organizations, business logic becomes reusable. One can buy a component that calculates the payroll (note that it is possible to buy either the software, or the on demand service). This component will depend on a series of interfaces to be offered by my organization to access e.g. the employee database, and I must create these interfaces before being able to use the component.

Thus, if this vision becomes a reality (which I firmly believe), it well may cause that organizations start converging into using the same business interfaces. For example, if there is a excellent payroll component that becomes popular and many organizations end up using, it is likely that the interfaces it uses would also become popular and used by all of these organizations. Which may end up standardizing the business interfaces and languages used in organizations, which would make life really easy for CIOs (so easy that even they may stop existing).

Well this is too futuristic and, while I firmly believe that SOA will become the ultimate platform, I am not so sure about this business uniformization. But who knows...

Which will be the face of Web 2.0?

2006-01-11T02:57:00.000-08:00

(Originally published at TheBlog on January 11th, 2006)

Actually I do not like much the name of "Web 2.0" (and even less the mystification of "Web 3.0"), but it seems the only currently available.

(Me, being a Capt. Picard fan, would rather prefer something like "WebNG", but this is hopeless).

This post is to reply to the article Web 2.01, a rich internet application example from TheServerSide.com. I posted my reply there, but what do I have a tech blog for, if not for dumping these kind of things?

It is puzzling that, in the article, Java is considered as more powerful in the desktop than in the server, since reality is otherwise. Thus, either reality is wrong, or the article is in this respect.

The client-side (the "face") of Web 1.0 was the HTML browser, and in fact this was a very large percent of its success. Reviewing the alternatives for the face of Web 2.0 given in the article:

Java has, up to now, been an utterly failure when coming to client-side applications, and it will remain to be so, despite the swift SWT, as long as 90% of the workstations of the world do not come with a JVM preinstalled - namely, until Windows does not come with a JVM again. And since MS has bet its future on .Net, it will be hardly so.
One of the main points of the web, HTML, XML, web services, SOA and so on is that it must be platform agnostic, which is a sine qua non requisite for making it ubiquitous. Web 1.0 is mainly platform agnostic and Web 2.0 will also be, even more. Arguabily, .Net will never be platform agnostic, and even if there are properly emulations in non-Windows systems (including Nokia phones), lots of people will never consider it as an universal platform for running client-side applications. Thus, I'd rule out .Net too.
Flash is indeed a fine thing, powerful and appealing. Only, since it is proprietary, I find it difficult for it to be the "face" of Web 2.0 . Also, usually you need to pay to create Flash content (yeah, I know OpenLaszlo, but the vast majority of Flash out there is built with the Flash designer, plus a little with Flex). These two things would have to change for Flash to become this face, but also it would have to prove to be, or evolve into, a platform solid enough for professional application development. Also, given the intertia (i.e. effort, expertise, tools, etc), I find it very difficult to switch away from [X]HTML.
AJAX is mainly a frenzy that will pass (along with all of its usually unnamed varieties like just JAX, JSON and the resurrected RADs for web applications). But Javascript + DHTML will stay as a popular method to create RiAs because it fulfills the main requisites that any Web x.x client platform must have.

I think that the features that made the HTML browser a success were that it is:

Ubiquitous (which implies platform-agnostic)
Easy and free to create content for it (many early web sites were started just by "view source" and copy+paste on a notepad)

And for the Web 2.0 client-side platform the requisites should be also these, plus the ability to include control and presentation logic in the client side for which is very easy to discover and access web services, and I guess that a lot of more nice things. Hopefully domain logic will remain in the server, although sadly in many projects this rule will be broken.

Given the existing intertia, I would rule out that this platform would be anything else than a web browser. I am sure sure it will be an enhanced browser, but a browser anyway, and not custom, independent applications. These applications will exist, but running inside the browser. The "platform" for Web 2.0 applications will be that enhanced browser as client, running light applications quickly downloaded on demand (I hope this alone is enough to rule out applets) which access arbitrary web services, along with facilities for discovery, security, transactions, and several others. Maybe this backend could be called some "world wide SOA", but I am not sure that it is the right term.

Now, from between the two camps of dynamic typed (scripting) languages vs strongly typed languages, I rather fall in the second side, and thus I do not consider Javascript as a proper platform for creating professional, robust applications. Of course it is not that it is impossible to create them, only that the average real life development team of the average real life project will create just a mess if trying to implement a large project with Javascript. I have seen messes enough just from trying to use much Javascript in regular, server-side Java web applications, and I usually flee from it.

But indeed my guess is that Javascript+DHTML, being already a popular tool, fulfilling many requisites for success, and fully embraced both by Microsoft and all-the-rest, will be the tool of choice for creating client side applications. It will evolve so that it is able to easily discover services, connect everywhere without posing a security risk, in general to easily use all the features of that "world wide SOA"; and hopefully something will be made in order for it to become a more suitable tool for creating professional, complex applications (e.g. maybe it will be optionally brought closer to Java or .Net). Also, more powerful user interface capabilities will be provided to HTML (e.g. see The future of HTML, Part 1: WHATWG ). Maybe some sort of "compiled Javascript" will appear, to improve network performance and helping to write proprietary interfaces. Dunno. I actually would like it to be a more powerful platform closer to Java/.Net, but just imagine the fuss to make Microsoft and all-the-rest to agree on it: near to impossible.

Up to here, my thoughts about Web 2.0 . The conclusion I draw from all this is that the article, more than showing a Web 2.0 example, is illustrating just an example of a web services client. The second title sounds far less compelling, but I think it is closer to reality.

2005-12-22T02:51:00.000-08:00

(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.

Will the ESB kill the UDDI star?

2005-12-16T02:41:00.000-08:00

(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:

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

Allow to create simple services

Allow simple routing of messages

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

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.