[Xpipe-developers] More web-services, choreography and tools

[Tony R. <ton...@pr...>]

One of the other interesting things about XPipes as web-services is that
they become a tantalisingly easy way to expose existing functionality as
web-services through a common interface. For example, if the web-service
'front-end' to a pipe is a job-oriented web-service i.e. every pipe has a
common interface where a job is just passed in, then an executable
xcomponent i.e. one that calls a system program can be a web-service.
	This is interesting in that if you look at what the SOAP stack vendors are
doing, they're inquisitive rather than declarative in their approach. They
go to great pains to provide studio like tools to interrogate your existing
CORBA, Java etc code and wrap it in a web-services interface.
	The XPipe approach to web-services on the other hand is somewhat more
explicit - you specify that a certain pipe contains a certain XComponent
which is a call to a certain program or CORBA object or Java object or
whatever. At first glance, the web-services vendors approach would seem to
be easier. However, the XPipe approach is easier to understand I believe.
	The other thing is the choreography of web-services. This is an interesting
one which is all about order of calls to web-services. Systems like WSCI
define what web-services should be called and when. A job based XPipe
web-service contains a raft of pieces of the puzzle in a particular order.
Therefore the tools vendors for web-services approach is somewhat external
to the web-service itself. On the other hand, given that XPipes are great at
putting together a whole raft of sequential processes and then possibly
exposing them as a web-service, they make a great and I think obvious
web-services payload processor. And indeed, your *legacy* code and programs
fit it like a glove.
	Therefore XPipe is a particularly strong complement to the web-services
stack and tools vendors. What's the feeling of the masses?