RE: Feedback on Web Services (RE: Web Services stuff - fyi)

[Michael Brennan <Michael_Brennan@allegis.com>]

Comments inline.

> From: Amit Bhatiani [mailto:amit@invertica.com]
> Sent: Monday, June 04, 2001 6:32 PM
> To: Michael Brennan; 'Edd Dumbill'; xml-dev@lists.xml.org
> Subject: RE: Feedback on Web Services (RE: Web Services stuff - fyi)
> [...]
> 2. Has anyone implemented a UDDI registry that contains 
> something more than toy entries?

UDDI is still pretty new. I'm not aware of anything other than "toy
entries", and I think it will take some time before you see real-world
enterprises really leveraging UDDI. There is a good deal of real-world use
of SOAP without UDDI, though -- and there will continue to be. And UDDI
will, I believe, continue to build momentum and start seeing some real-world
use this year.

> 3. Has anyone thought about stateful XML-based services?'

Some people are doing that today with SOAP. We support that currently by
using HTTP cookies -- the same way other HTTP applications do. I'd like to
see us move to using SOAP headers for session identifiers so that we are not
relying upon the transport layer for that. The degree of statefulness we are
supporting for that, though, is fairly minimal; just a user ID, associated
authorizations, and some cached metadata. We do this for design reasons. For
integrations, we try to minimize round trips over the network, so we don't
encourage many fine-grained interactions that rely upon statefulness on the
server.

> 4. Has anyone thought about transaction semantic across XML based
> connections over HTTP?

Yes, and some are doing work on that. I think Idoox SOAP
(http://www.idoox.com/) is adding support for J2EE transactions. Many think
this is generally a bad idea, though. There is too much latency and too
little reliability over the web. You can end up with very long running
transactions, which could be retaining locks on data and thus constraining
scalability and reliability of the system as a whole. There are many issues
surrounding distributed transactions over the internet. It's usually better
to keep the transactions separate (if possible) and take some compensating
action if one action fails.

> 5. What do "Web Services" mean for EAI type solutions?

XML-based APIs have become the dominant form of EAI type solutions. Web
Services just formalize this and provide some rich metadata standards to
support more sophisticated uses. We have already been doing EAI over the
internet using XML/HTTP for some time. Customers of ours integrate our
hosted solution with their internal systems this way. We are currently
implementing a fully SOAP-based EAI solution with a partner of one of our
customers.

It's fairly common for staff within enterprise IT departments to have to
integrate 2 or more enterprise apps on a shoestring budget. In the past,
these were usually done with shell scripts or batch files that transmit
simple comma-delimited files via FTP or email. Today, these shoestring EAI
implementations can use one of the popular SOAP or XML-RPC toolkits and
achieve a considerably more robust, secure (if done properly), and adaptable
solution at no greater cost.

Those with budget and more sophisticated demands can leverage web services,
as well, as their approach to EAI. 

> 6. What do "Web Services" mean for message brokers (like MQSi)?

Most talk of Web Services focuses on XML over HTTP, but other transport
mechanisms can be used, as well. Many of the available SOAP toolkits support
other transports, including POP and SMTP, and message brokers such as
MQSeries and MSMQ. IBM is planning on supporting MQSeries as a SOAP
transport as an alternative to HTTP. Message brokers can serve as
routers/dispatchers for web services; instead of the message being sent
directly to a service via a web server, you can have a message broker
receiving messages and dispatching them accordingly within the internal
network -- possibly transforming the message along the way. SOAP added a
custom HTTP header "SOAPAction" to facilitate routing and dispatching of
SOAP messages without having to go through the overhead of parsing the XML
payload. I believe all of the leading message brokers now support XML over
HTTP, so they should all be able to fit into the web services world quite
nicely. I would think that message brokers should be able to make good use
of some of the metadata standards such as WSDL and XML Schema, as well.