WS-* Bloat, what is actually being used

Below is a list of WS/XML Specifications that I have implemented with customers that are in production or in pilot mode. The first generation specifications (XML Schema, XSLT/XPath, SOAP, WSDL) are used widely. The second/third generation specifications would be BPEL and the WS-* standards.

• SOAP
• WSDL
• XML Schema - Pretty much the standard for data definition and more powerful than DTDs (nothing new here).
• XSLT/XPath - Standard for data transformation (haven't used XQuery yet).
• BPEL - Standard for Orchestration Web Services
• WS-RM - only have used it at one client but it provides reliability as advertised.
• WS-Security - not used in production but have several customers moving to it for up-coming releases.
• WS-Addressing - examining this and other specifications for a routing road map. Not currently used in production work that I have performed.

So as you can see there are still a lot of missing specifications that are floating in the WS-* ether as well as UDDI (an unpopular specification in project based SOA). The above is based on a sampling of 200+ customers that I have worked with from 2002.

JMS Queues versus JMS Topics

Today I was working with a customer on demonstrating integration of a JMS Topic into their ESB. For years now I have spent all my JMS Integration work specifically using JMS Queues. For this integration, however, the customer was utilizing a topic. Based on my research the following rule of thumb appears to delineate when one is used over the other:

• Topics are utilized when the information is time senstive (i.e. stock quote).
• Topics are utilized to broadcast of information to a wide audience (or subscribers).
• Queues are utilized when performing transactions.

There may be several other reasons to use one over the other, but this applied to this specific customer and helped address its usage.

Personal Services show the way

Although this is not directly related to my main discussion about SOA/Web Services, I noticed a trend in the past 3 days that impacted me and shows the power of what SOA/Web Services/Internet technologies are bringing and will bring .

So on Friday I checked my gmail account and noticed that LinkedIn (http://www.linkedin.com/) had notified me of several contacts who were interested in touching base and joining my personal network. One was a fomer colleague and another was a former friend from college. Within a couple of hours I had caught up on 6 years with my colleague and 15 years with my college buddy. The part that is interesting is all I needed to do was post my LinkedIn profile (my personal WSDL). This included my destination (email address) and content. LinkedIn hosts some general operations and away you go.

So a single personal service in a short time frame brought me information relevant to me and simplified my networking life dramatically. Just imagine all the phone calls, mixers, conferences etc that you would have had to attend. Who's got the time!

Personal Integration is here and helping me and many others.

Transport or Message Level Security?

This is a question that has been posed to me at a lot of state government pilots over the past few years with regard to encryption/privacy of messages. The following is the simple rule of thumb that I have used based on the best practices ( http://www.ws-i.org ) and discussions with security/web service professionals.

• If securing two points (a client and a service for instance) and the assumption is that security is not required once it is received on either end, then transport level security is sufficient (HTTPS, SFTP etc.)
• If it is unknown how many systems/intermediaries will be touching the message then message level security should be utilized (WS-Security / XML-Encryption).

An interesting point by the security gurus is that transport level security has the potential of being at various strengths (i.e. 128 bit). As a message travels between more than one point, there is the potential for the privacy of the message to vary. This is not the case with message level security as the strength is specified within the SOAP Headers of the message and thus remains constant. This is an important consideration as a lot of state agencies begin integrating across departments/agencies which in turn may be across networks.

One simple reason for using ESB in a SOA

Well here is a real world example of why an ESB is a nice piece of infrastructure when things fail. I am working with a company which had a failed transaction. An ESB is being used to broker communications across multiple applications. The failed transaction had originally been created by one of those applications and placed on a JMS Queue for processing. Because there is an ESB, the destination service is not only available over JMS but also HTTP (the default transport for the waiting BPEL Service) or other transports that you can choose from.

We simply resolved this issue by loading the SOAP request into a SOAP Client in Eclipse and doing an HTTP Post to the service.

There are many other reasons to using an ESB but just the flexibility in supporting multiple transports can help out in a pinch.

Simple SOA Client

Several months ago I needed to demonstrate a workflow task in a BPEL Service. Searching the web, I came across an old colleague. In his spare time he founded http://www.magoosoft.com/. Using it reminded me of an email client like Outlook Express. It supports multiple protocols and more importantly renders the SOAP message as a HTML Form. So for the scenario that I was working on, it was simply defined by importing the WSDL for the BPEL Service to define the call back and messages. Once defined a few properties were specified and my magoo client would receive messages, allow me to view and then respond back to the waiting BPEL Service. All the work was done within a day and demonstrated a human workflow component for SOA Pilot.

SOA for the masses?

Most of the blogs I have read don't seem to talk about the developers viewpoint ("the masses") of actually implementing an enterprise SOA using ESB or other technologies. Maybe I have missed some good independent literature out there.

Currently I am working with a variety of clients that are large and small using third party ESB, MOM or Open Source. In my travels I have run into the good and bad of SOA and when done right, the benefits it can provide.

As I navigate my customers problems and learn/implement the WS-* standards, I'll post what I find. Maybe this will help you or at a minimum draw some debate.