Are Semantic Web Services the next step?

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

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

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


2. 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?

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