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.