XML Pipeline Definition Language

In February of 2002, Sun Microsystems submitted their XML Pipeline Definition Language to the W3C. See http://www.w3.org/TR/xml-pipeline/

I took the time to read the specification because I am interested in alternative ways to create composite web services. I found this spec hard to read - in a Sun kind-of-way, but here are some thoughts:
- XML PDL goes beyond web services, it is about processing xml documents in a pipeline manner, thus it may have significant relevance outside of the web service world.
- XML PDL uses a declarative approach to defining inputs and output. It makes the assumption that if I produce X and you consume X, then the producer will automatically feed the consumer. There is no need to write the actual web service call - it is implied. If multiple participants could produce X or consume X, it cries foul - and declares it an error. This is rather odd, but will work when you define a well scoped process that the pipeline works within.
- XML PDL is expressed in XML and can be implemented in your favorite language (C, C++, Java, etc.)

All in all, I gotta pass on this one as a real player in the web services world. Although, I do see the need to steal some of the concepts. I liked the concept of creating a 'pipeline scope' and performing implicit invocations. Now, this won't work in many environments, but I do see it being valuable in ad-hoc scripting environments, but with this said, you don't want to do ad-hoc scripts in an xml dialect IMHO. If XML PDL finds a home, it will likely be found behind the scenes in environments like web service platforms and web service scripting language implementations.

Web Service Vendors

Routing & Firewall
http://www.datapower.com
http://www.sarvega.com
http://www.metapa.com
http://www.xbridgesoft.com
http://www.f5.com
http://www.flamenconetworks.com


XML / SOAP Firewall / Encryption / Integrity
http://www.westbridgetech.com
http://www.reactivity.com/
http://www.vordel.com/
http://www.forumsystems.com/
http://www.quadrasis.com
http://www.akheron.com

Platform
http://www.capeclear.com/
http://www.systinet.com
http://www.themindelectric.com
Http://www.polarlake.com
http://www.iona.com
http://www.bea.com


Transformation Services
http://www.datajunction.com
http://www.iwaysoftware.com


Orchestration / Composition / Integration
http://www.momentumsoftware.com
http://www.collaxa.com
http://www.fivesight.com/
http://www.nimble.com/

Testing
http://www.empirix.com


Management
http://www.westglobal.com/
http://www.talkingblocks.com/
http://www.infravio.com
http://www.freshwatersoftware.com/
http://www.actional.com/
http://www.DigEv.com
http://www.amberpoint.com
http://www.swingtide.com
http://www.confluentsoftware.com

Web Service Networks
http://www.grandcentral.com
http://www.bangnetworks.com

SOAP Sniffer
http://www.westbridgetech.com/soapmonitor.html

Web Service Adoption

Over the last two weeks, I've had the opportunity to talk with 6 different CIO's while on sales calls. It had been a while since I went out and did the pitch, but what I found was very interesting. At my company, Momentum Software, we provide consulting services around application development (.net & j2ee), integration (EAI & web services) and business process management. My sales pitch was given mostly in my neck of the woods (2 in Dallas, 2 in Houston and 2 in Austin) and it crossed a variety of industries (state government, retail, insurance, manufacturing and energy). And here is what I found....

1. Two of the prospects currently had web services in production (limited functionality).
2. Two of them were in development on web service projects.
3. Two of them were still in planning stages, but had every intention of being there.

Actually, the people that were still in the planning stages were the people who had the most ambitious web service visions. They were asking me great questions about security, service composition, management of the service network, new roles (service architect), guidelines, etc.

One thing that was clear is that everyone believed it was the next major upgrade to their infrastructure and that it wasn't going to be cheap. I was really glad to hear that they realized that web services WILL take an investment and that it will be a while before they see the return. Frankly, I think they were glad to hear me reiterate these two realities - actually some of them requested that I return and reiterate the ROI message back to their CFO. It's a real nice return and a gradual investment. The companies that are calling us in are now not only asking for the web service roadmap but also turning the roadmap into a budget and an implementation plan. They all seem to realize that service oriented architectures is a major shift in thinking and getting outside help is smart. They want help selecting vendors, designing the service network and changing the organziation. All of them also wanted to be self-sustainable after a short duration as well, meaning, they wanted knowledge transfer.

2003 will be a good year for web service adoption - and it is good to see that many companies are stepping back and planning for the long haul.

KnowNow?

I just noticed that KnowNow quit selling infrastructure products. What a shame. Now they feel that there is a market for turning your spreadsheet into an Internet accessible spreadsheet. Yea... it appears as though they have decided that they could make more money by wrapping DDE with a web service and passing the clipboard around the Internet. (I'm not even sure if DDE still exists :-) Hmmm... I wonder if this idea ever crossed Microsofts mind?

This is why I love competing against venture funded companies. If their products are ahead of their time, the vc's "encourage" them to go down some cheezy path where the window of opportunity is closer at hand. It's a classic way to turn a great company into... well... an enabler of "Live Spreadsheets"!!! Don't get me wrong, I have no idea why KnowNow went down this path, it just feels like I've seen this before.

If you aren't familiar with the previous KnowNow platform, here is a link to a nice demo.

WS-Cronies

WS-Cronies are all vendors other than the WS-Duopoly (IBM and Microsoft) that choose to release vendors under the WS-* nomenclature.

WS-Reliability

A couple days ago, Sun Microsystems, Fujitsu and some other non-influencers (dubbed the WS-Cronies) annexed the name, 'WS-Reliability' by putting out a specification with that title. The release of this specification by someone other than the WS-Duopoloy has two items of significance:
1. Sun finally realized that they could push their shit by annexing the WS-* prefix.
2. IBM and MS (hopefully) have realized that they need to put out a roadmap for some of the future required services (such as WS-Reliability). This roadmap may have to suggest some names that they intend on using...

As for the specification, it is exactly what you would expect: Reliability (message gets there at least once, not more than once and in order). From what I can tell, the fine folks at Sun wrote a Java utility to parse the OASIS ebMS specification and replace all instances of "ebMS" with "WS-Reliability". The document fails to acknowledge that specifications such as WS-Routing exist. Thus, the WS-Cronies version of the specification will act as a temporary placeholder until the WS-Duopoly choose to release their version.

Decoupling the Enterprise Data Model

ToDo:
service access to rdbms data
surrogate keys
GUIDS

Reverse Engineering Coupling Levels

An obvious extension to having a coupling rating system is having tools to automate the rating. Some of the newer web service management tools allow one to create an inventory of the services on the network. These tools are designed to help manage what you currently have rather than optimize your go-forward design. Design and architectural issues in web service infrastructure will first surface at the macro level.

In our recent architectures, 'ilities' emphasized responsiveness, availability, scalability and reliability. The 'ility' (non-functional requirement) of choice in the SOA will be Agility. The materials and the structure that we use to build our systems will have the opportunity to be nimble. Agility is not automatically granted in an SOA; it must be part of the plan.

Update the Coupling Rating System

When you ask a software person about coupling, they will usually tell you that it comes in two flavors: loose and tight. Other developers will tell you that it comes in 5 flavors (Data, Stamp, Control, Common and Content). Doug Kaye, will likely tell you that coupling is a continuum based on attributes. I believe they are all right - and that is part of my problem.

The art of coupling will likely rise to be the single most important design factor in the Service Oriented Enterprise. Unfortunately, the art of coupling (and cohesion) remains rather primitive. I think that we all would agree that Doug's recent effort to identify categories of coupling attributes was a great start. And by cruising other blogs, it is apparent that others have improved on some of his concepts.

As we approach a new year, it seems like an appropriate challenge to Doug (and friends) to create a coupling rating system. I'm aware that some of this exists in the academic settings (mostly on cohesion), but it is time to bring it to the masses. I'll gladly lend a hand and I'm sure that our Loosely Coupled community will chip in as well. And all good things take time - I propose that we iterate through it a few times, let it linger, demolish, rebuild and on January 1st of 2004 we publish a 1.0 of a new coupling rating system.

Well?

The SOAP Firewall - Level 3

It would appear as though many of the functions of a "transport firewall" would serve the purposes of a service oriented architecture, however an additional layer will likely be necessary. Let's assume that a transport firewall has two primary levels of protection:
1. Packet Filerting (TCP/UDP) Level (IP Source, Port, etc.)
2. Protocol Intrinsic Command Level (FTP-PUT, HTTP-GET)

First, we can assume that most firewalls will be able to identify SOAP messages (Protocol Intrinsic Commands), thus allowing those messages to pass through.
In addition, filtering based on SOAP contents will be needed. The SOAP firewall will be required to look at the ws-routing information and determine if the SOAP routing information is acceptable (valid source, valid destination, valid intermediary). The firewall may (or may not) use additional information (beyond IP address) to identify a valid trading partner. In this setting, the SOAP firewall is acting as a first line of defense (bastion).

Note: The SOAP Router will act as the bastion when the message contains bogus routing information.

Note: A level 4 SOAP firewall may determine if the service / operation is acceptable for the given trading partner.

Note: Scoped out of the SOAP firewall are individual service security devices; these will be placed close to the service (hash, authenticate, access control). In this setting, we end up with distributed security - macro at the firewall, micro at the service.

Guaranteed Hops, Guaranteed Routes

Guaranteed Hops
While travelling down a route, a SOAP message may use several different underlying "Guaranteed Hop Protocols", that is, protocols that either succeed or fail in moving a message from one node to another via a single hop. Examples of Guaranteed Hop Protocols include HTTP and SMTP. Now, neither of these protocols are considered reliable in that that they don't keep re-trying until the message is successfully transferred. Rather, the guarantee isn't to succeed, the guarantee is to to tell you which one happened (success or failure). Also note that the emphasis is on moving the message forward a single hop rather than the entire route. In Web Services, WS-Routing is used to faciliate moving the message the entire route, while Hop Protocols (usually guaranteed) are used to move from one node to another.

Guaranteed Routes
If I have a multi-hop route and all hops have the ability to provide a guaranteed hop, can the requesting client be granted a guaranteed route?
Answer: No. A SOAP router is a stateless device that does not predefine a message path or create a virtual circuit. Thus, the initiator is not aware of the level of guarantees or reliability of the SOAP routers in the path. Thus, the fact that all the routers in the path have the ability to provide guarantees does not give the initiator any guarantee. In addition, the WS-Routing specification clearly states that the return of a fault is optional in section 5.2:
If there is a reverse message path present in the faulty WS-Routing message then the WS-Routing fault SHOULD be returned to the initial WS-Routing sender. If the message path is not bidirectional then the fault message SHOULD be discarded.

The key here is the use of the IETF "SHOULD" - meaning, "No, the route is not guaranteed. However, if you and all the routers along the path implement faulting AND you specify a return path, a guarantee can be expected."

Side Note: I can't figure out why they didn't upgrade the SHOULD to a MUST... one reason might be on the lingering questions around non-guaranteed hop protocol bindings - as stated in section 7.2, "Editor Note The UDP binding described in this section is preliminary and is likely to change before requesting a well-known port from IANA."

Cross-Domain SOAP Routing

SOAP routing is essential to a service network. That is, a service engine should be able to drop a SOAP message on the grid and it should magically get to its destination. If a destination IP address is specified, why wouldn't it reach its destination? One reason is that the IP address is, "non-reachable". This is to say that something prevents the direct addressing of a given node on a network. Typically, this is the result of a firewall, proxy or NAT. In some cases, large internal networks may have been broken down into smaller domains to make them more managable or to control traffic. In other cases, devices like firewalls or present to secure networks. Either way, the problem of non-reachable nodes surfaces.

This is where a domain-based SOAP router enters the picture. The SOAP router takes on the responsibility of finding non-reachable nodes - enabling a SOAP message to reach its final destination even when the sender didn't know the actual address. In virtually every business to business web service interaction, we can expect that the participants will NOT know the physical address of where the other guys services are located. And why should they? A company should be able to move its servers around and not worry about having to update the trading partners on the new URI's or IP addresses. A cross-domain SOAP router enables a corporation to maintain an internal routing map for services, thus abstracting the 'service consumers' from the physical network.

The Differences Between Local and Remote Calls

Mr. Jini and friends knocked out a nice white paper in 1994 about the differences between local and remote invocations:
http://research.sun.com/techrep/1994/smli_tr-94-29.pdf

Web Service Presentations

I just ran across a good powerpoint:
http://www.almaden.ibm.com/u/mohan/WebServices_TES2002_Slides.pdf

WS-Duopoly

WS-Duopoly is an alias for the stronghold that IBM and Microsoft have on Web Service specifications.

Many view this "arrangement" as a good thing; Microsoft and IBM have been fast tracking web service standards in order to reinvigorate I.T. spending. Others view it as a duopoly trying to crush second tier players.

SOAP Router Homogeneity

After reading the ws-routing specification, it appears to me that people will interpret the composition of a SOAP Router in very different ways. The specification requires the implementations to conform to a minimal amount but also encourages alternative uses. Additional functionality that may be included in a SOAP Router that are beyond the ws-routing scope include: message filtering, message transformations, content based routing, load balancing, response-message caching and others. Actually, the inverse is more likely to happen: participants in an SOA will incorporate routing functionality (e.g. SOAP Load Balancers will incorporate routing functionality, etc.)

The 'good side' of this is that people will create new servers (like content based routers) that are single-purpose utilities and leverage the basic infrastructure of the ws-routing specification. The ability to drop routing functionality into the server facilitates the pipeline service pattern. This, in my humble opinion, is where the magic of a service oriented architecture is created.

There are a few potential downsides to not having an actual specification for a SOAP Router. One is that many of the functions that a router can perform are very dissimilar (domain routing vs. content routing). By keeping a server homogenous, you are able to more accurately predict the response to changes in the router settings (e.g. routing logic based on complicated algorithms, etc.) Also, from a marketplace perspective, it is hard to comparison shop for a 'SOAP Router' when the functionality can swing so drastically - although, one could argue that this is what slow down product commoditization.

Either way, when vendors begin releasing SOAP Routers, it may be worth asking, "So, what exactly does your router do?" And perhaps one day, the WS-I or another organization (the ws-duopoly) will create a SOAP Router Profile.

UDDI and the SOAP Router

WS-Routing describes a way where you can send a message from point A to point B with *minimal* concern for the path that was taken.

It has occurred to me that the entries in a public or private UDDI server *should* point to the SOAP router. Thus, UDDI is responsible for all the usual stuff (aggregating service descriptions, providing 'publish' and 'find' syntax, etc.) but it is not responsible for identify the actual address of the service provider, rather it is responsible for providing the address for a SOAP Router that is aware of one or more applicable service providers.

*minimal* - You still specify a 'from', 'to' and potentially a 'via' in the route description - thus, address based routing.

Message Correlation

So, I have been trying to figure out how asynchronous, reliable messaging in web services will occur at the wire level (not api). This seems like an easy enough task, however my small brain has been in overdrive trying to crack the nut.

Part of the problem seems to be the ambiguous use of the term 'message correlation' throughout the various specs. I'm now of the opinion that at least three levels of message correlation exist:

Correlation at the Business Process / Web Service Orchestration Level
Imagine a WSO engine is running a single orchestration script, however there are 50 instances of this 'process' in play. A WSO engine must be able to take an in-bound message and correlate it to the proper instance of the process. An example of this is described in the BPEL4WS script titled, "Message Correlation".

Correlation at the SOAP Router Level
In a service network, documents are passed across enterprises. Company A shouldn't care about the physical location of where Service X is running inside of Company B. This abstraction takes place in the SOAP router. It magically gets a SOAP document to the right place by using internal routing tables and acts as a proxy between domains. So, a service network will send a document from A to B and potentially use multiple go-betweens (aka, intermediaries, SOAP routers, etc.) as the transportation vehicle. Along the way (or at the end) a fault may occur. If this happens, the service network must be able to backtrack and send the fault code back to the originator. This means that it must tell each Router that, "I am message #968, please pass on that I failed." In this context, message correlation is used by an intermediary to *dynamically or statically* create a reverse path for the purpose of fault notification.

Correlation at the SOAP Server Level
If SOAP Server (A) sends SOAP Server (B) a message (M1) in an asynchronous fashion, it may want a response (M2) back (e.g. an answer to a request). When (B) sends (M2) (the response) to (A), (A) must be able to determine that (M2) correlates (is the response) to (M1). It appears as thought this type of message correlation also is taken care of by ws-routing (although I'm not sure). Unlike many network protocols, a service network must be able to send asynchronous, bi-directional & correlated, reliable messages without utilizing a virtual circuit. The downside of this is that it means that any initiator or receiver must be able to sniff the routing path to determine where to send the message back. This seems to violate the distincition between SOAP routing and SOAP serving, but it appears as though it is a necessary evil. Thus, the reverse message path in ws-routing not only sends fault information but also provides the necessary information for a SOAP server to send an 'application-level reply' back to the initiator.

* Note that SOAP 1.2 clearly states that 'message correlation' is out of scope for SOAP.

** One other item of interest is that "retransmission" information is NOT sent in the ws-routing information. In theory, you would need this to increase reliability. One could guess that this was intentionally left out and in the ws-* fashion, reliability will become its own spec (think ws-reliability or ws-sla).

WS-* Roadmaps

Overall, I have been impressed with the detail of the ws-* specifications. In general, they are detailed, consistent in terminology and provide some level of examples. However, the overarching document seems to be missing. This would be the specification that puts all of the specs into a single context. Now W3C has an architecture document that is coming together nicely, however it addresses the architecture at more of a conceptual level. The IBM/MS duo are in need of a ws-* roadmap. It would show how the pieces connect to each other, define the common glossary, spell out what is done today, identify what is out of scope, etc. Now, I know that 25 different people have all made best-effort stabs at these maps - but we need an official one from the source.

The ws-security team actually did a nice job of putting together their local roadmap.

What's in a SOAP Router?

SOAP Router =
Message correlation service +
Message forwarding (proxy, alternate path routing) +
Transport protocol swapping (tunneling) +
Router configuration (think telnet kind of stuff) +
Durable queues for store & forward +
Invoke service (when there is no "to" element) +
Activity logging +
Regular SOAP server stuff including security