[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Feedback on Web Services (RE: Web Services stuff - fyi)
Comments inline. > From: Amit Bhatiani [mailto:amit@i...] > Sent: Monday, June 04, 2001 6:32 PM > To: Michael Brennan; 'Edd Dumbill'; xml-dev@l... > 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.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|