In a change from the usual Java One stories, a new article on WebServicesArchitect.com explores the current state of Java for Web Services as discussed at Java One. It covers security, identity and the Liberty Alliance, and Sun's ongoing relationship with Microsoft, and surprisingly also concludes that distributed transactions may turn out to be unnecessary.
- Posted by: Mark Waterhouse
- Posted on: April 04 2002 04:32 EST
Read the article.
- Java One on the State of Java-based Web Services by Rashid Jilani on April 04 2002 13:55 EST
- Java One on the State of Java-based Web Services by Quentin Cope on April 05 2002 06:53 EST
I don't understand what does people(intelligent developers) and so far our visionary analysts mean when they say one company is ahead of others in Web Services strategy. BTW I don't want to bash or support Microsoft or SUN. OK so lets talk about the Web Services, what is it... Runnig a language to WSDL compiler, calling a SOAP server and getting the quotes for a stock "getStcokQuote()". If that is Web Service, and it is exactly what is Web Service so far, then SUN and Microsoft is not even ahaed of me. I strongly beleive that big business companies who has some serious enterprise application expereince should lead the Web Services world. What the hack Microsoft/IBM/SUN knows about the enterprise applications and it's complexity, business processes etc etc. May be we all should start pondering about it.
At our company (one of the largest credit card companies in the world), we explored Web Services to determine if they are truly an option within a 6 month timeframe. The answer was a clear and resounding NO. There are just too many issues/barriers presently.
For example, other than supplying simple content (stock quotes), most companies need Web Services to perform secure business transactions between companies. Web Services are really intended for real-time calls, not batch oriented transactions. FTP'ing files between companies is mature technology and works much better. Making HTTPS based Web Service calls in batch programs will kill the performance of your batch program. So this leads to using Web Services for real-time calls.
What we found is that the security infrastructure to support this is just not there yet. Remember, both sides of the transaction must have the infrastructure in place, not just one side or the other. Most companies are not using strong authentication (digital certificates) yet. Also, in the financial industry, alot of systems are mainframe based. Try to tell a mainframe shop what they need to do to make SOAP calls to your J2EE Web Services and see what reaction you get. Mainframes are changing, but they do not have a serious investment in HTTPS, XML, and certificates.
We'll all get there, just not anytime soon. My guess is that we're 2-3 years away from what you could consider mainstream use. Microsoft and IBM have rushed out of the gate with respect to Web Services, but I don't see the ROI anytime soon.
Where Web Services will shine in the immediate future is integrating the heterogeneous applications within your own enterprise. This will be expedited by the 3rd party vendors such as SAP that will expose their business engines via Web Services and no longer require their proprietary API's. Security is much easier since the security space is limited to your own enterprise.
Lots of people analyze Sun and criticize them as being late to the Web Service market. Maybe so as compared to MS and IBM, but Sun will not pay any penalty for it. IMHO, they're "on track" with the real business world.
Just my 2 cents ...
I fully agree with Joe and cannot see Web services as a way to perform secure business transactions between companies anytime soon. In the inter-enterprise integration space, I see ebXML-based solutions coming up on the horizon. The technical ebXML infrastructure solves a lot of issues that Web services are currently struggling with, such as transactions, security, and quality of service.
ebXML infrastructure implementations are on the way. For example, even an open source implementation of the ebXML Registry and Repository specification is expected to become available this month. The Java API for XML Registries (JAXR) enables clients to discover and query various business registries. Currently, JAXR is a Proposed Final Draft. JAXR provides support for UDDI 2.0 and ebXML RegRep 2.0.
The ebXML Message service is a reliable, secure XML messaging service. It compensates for some of SOAP’s weaknesses, such as routing, reliability and security. My recent count shows 9 ebXML Message Service version 2-compliant implementations. However, at this time, most implementations provide only minimal support in terms of security. Four of them have recently passed the ebXML Messaging Interoperability Pilot.
Of course, ebXML will not replace Web services technology nor will it make Web services obsolete. I rather see them as complementary approaches. Web services provide for technical interoperability and, in my view, have their place in intra-enterprise integration where security is not a primary concern. In addition, Web services are a good choice for exposing security-insensitive, self-contained business services regardless of enterprise boundaries. In a B2B integration scenario, however, I would rather go down the ebXML road.
What the hack IBM knows about the enterprise applications
Do you mean "What the heck does IBM know about enterprise applications"?
They are an enterprise?
They use enterprise applications?
They write enterprise applications?
Their computers/software have run virtually all large enterprises for over 35 years?
They're the Worlds 9th largest company?
(Microsoft No. 72, I couldn't find Sun on the list)
They operate in over 120 countries?
They have been going for over 100 years?
Revenue (2001): $85.9 billion?
Net income (2001): $7.7 billion?
Total assets (2001): $88.3 billion?
Number of employees (2001): 319,876?
Biggest disappointment for me with Web Services at the moment is interoperability. It’s real easy to write web services in .NET but depending on your java tools you may well find it hard to consume them. Going the other way is not necessarily any easier either. Its all possible but you have to go out of you way to achieve it. Without interoperability being the default then Sun’s Phase 1 isn’t achievable and we needn’t worry about security. Perhaps that’s the web service security model…. Let’s all write services that no one else can use and in that way it will all be secure.
I had it in my mind that we were all going to just get along with each other for once. I guess I am old enough to have known a little better.
I must disagree with Quentin to some degree regarding interoperability of Web Services, since my experiences with the MGDP project (http://www.chaeron.com/gps.html) were very favourable in this regard.
We seamlessly integrated embedded Java processors to a J2EE server and the Microsoft .NET TerraServer using Web Services technologies (SOAP, XML, JAX-RPC) without much trouble. In fact, our development efforts helped to make the latest Sun Java Web Services Developer Pack (JWSDP) EA2 release substantially more useable and interoperable than the prior EA1 release. The EA2 JWSDP is able to take the Microsoft WSDL definition of the TerraServer web services interface and generate a complete set of Java stubs and SOAP/JAX_RPC plumbing to make it easy to interact with what is a rather complex .NET service.
At JavaOne, while everyone else was only talking about the promise of Web Services interoperability, we were demonstrating a live implementation from end to end, including invocations coming from a tiny embedded device.
Dieter's comments about ebXML currently being a better solution for the B2B space are spot on. I'm working on an ebXML implementation at GM, and my findings are consistent with his observations. There are now fairly complete ebXML stacks available from a number of vendors (eXcelon, Sybase) and many open source pieces (MHS and Reg/Rep in particular). The Business Process Management portion of ebXML is also now available, which is a key piece in doing inter-enterprise Web Services. In the pure WS world, there are no good Process Management/Work Flow/Transaction Flow standards or solutions with many candidates competing for the honour (WSCL, WSFL, XLANG, etc.). ebXML is not really ready for complete production roll-out inter-enterprise...but it is ready for reference implementations, pilots and getting over the learning curve. My gut feel tells me that mid '03 ebXML will be ready for limited production deployment. Mind you, for most large enterprises, it will be that long before they could implement regardless of the state of ebXML solutions.
IBM and Microsoft's perceived lead in Web Services is just marketing hype, piggybacking on the outrageous claims that Web Services is the key to nirvana. Sun's latest JWSDP closes the gap and maybe even leapfrogs the other two.
Other than small scale EAI and A2A integration efforts behind a corporate firewall, it's going to be a while before Web Services see the kind of wide deployment that has been predicted so promiscuously by the large vendors and media.