|
Wednesday April 3 2002 The State of Java Web Services Taking the temperature at JavaOne This year's JavaOne conference, the premier Java conference run by Sun Microsystems each year in San Francisco CA, was a quiet affair, but a more interesting and mature one than last year from a Web Services point of view. Firstly, it appears that the Web Services phenomenon has caught up with even the most junior of programmers; there was certainly enough material aimed at this level, suggesting that systems architects designing Web Services into their architectures should not cause the implementation programmer too many headaches. A media session at the opening of the conference gave a broad overview of the politics of Web Services and Java. The session began with some scene setting, presumably to establish a common base of understanding on Web Services amongst the participants. Web Services, the session told us, are not necessarily in XML and do not have to use SOAP, they just describe opening up your internal processes. Integration between (sometimes proprietary) products is not Web Services (although perhaps it is a type of Web Service). Java is loosely coupled in a relatively small space (the Java platform), Web Services opens up this up to many more systems. There are, though, issues with Web Services that need resolving: Transactions, Security, and Identity. This is primarily because they have not been addressed in current specifications in favor of getting the specifications out in a timely manner. In particular, security issues must be addressed. Sharing data and business processes across the internet and other insecure networks means being sure of the identity of the party you are speaking with, being able to prove it to ensure contractual obligations are met or can be enforced, and securing the data that is being exchanged from tampering, eavesdropping, and interception, to name a few. Sun believes that the map for Web Services is split into three phases; Phase 1 is using Web Services within the enterprise for integration between disparate systems, both software and hardware, we should see this happen from now and over the next 18 months. Phase 2 is the implementation of Web Services for integration between enterprises; partner to partner, supply chain management, customer relationship management, etc. That should commence in 18 months. Finally in around three years, we should see loosely federated, secure, end-user systems with fully integrated security models available - mainly because the standards are not in place for this to happen and there are many questions to be answered before we can see whether this part of the Web Services vision will resolve. Perhaps key among these is distributed transactions being handled by standards driven technologies. SOAP Native in Java In response to the accusation that Sun is falling behind (for example SOAP is not native in JDK1.4 while Microsoft Corp already has a development suite for Web Services, James Gosling replied that Native support in Java is meaningless. It is merely not bundled in with the JDK (or to say this another way, it is not required). The premise here is that Java allows the plug-in of Java APIs for new technologies. SOAP not being "native" in Java is just some dust kicking since ApacheSOAP is the de facto SOAP engine for exposing Web Services, whether implemented in Java primarily, or merely exposed through a thin Java fa硤e. This means that it is perfectly possible to create Web Services in Java right now. It is an interesting trend that my personal experience so far has consisted of contact with engineers that want to open Mainframe applications up, where Java is a very sensible choice since it offers platform independence. In all these cases, the engineers have been beginners in Java. As a further aside, SOAP becomes mandatory in the Java SDK 1.5 edition, and can be downloaded separately until then with the Java Web Services Developer Pack that Sun have recently rolled out. Microsoft Corp vs. Sun As usual there was some discussion of what Sun was doing with Web Services versus Microsoft's .NET. It was interesting to note that from all the senior Sun staff, the message this year is far more about working together, and yes that includes Microsoft. True interoperability is only going to be achieved if Sun and Microsoft work together. This is quite aside from the law suit that is currently in progress over Microsoft's involvement with the Java language. While the percentage of corporate spin is yet to be determined, it does make sense that in order to cooperate with developers and systems that work on Microsoft technologies, Sun will have to work with Microsoft to achieve this. One way in which this could be done is through the Web Services Interoperability Organization, of which Sun is not yet a member. Here, Sun indicated that they were not invited to join, hence their notable omission from the list of contributors; they appear, however, to be very interested in becoming Board level members. Sun's "falling behind" Microsoft in offering mature solutions for Web Services development and deployment is also undoubtedly to do with the slow moving standardization of Web Services. Sun has consistently chosen to wait for standards to be ratified before creating supporting Java APIs. While this has undoubtedly harmed their standing with early adopters, it does mean that implementing Web Services with Java is guaranteed to be standards compliant. Security of Web Services This presents a problem though: how do I (as an enterprise) begin developing Web Services now? Enterprises are difficult ships to steer and so must start considering now how Web Services will affect their system soon. Answers such as "use CORBA" (James Gosling) hardly help since the problem with CORBA has always been its heavy weight nature, which has deterred many, although has nevertheless contributed to its security. Alternatively, Bill Roth (Group Marketing Manager, SunONE) offers probably the only alternative for Enterprises that must have secure systems - implement the standards yourself. Unless you are happy to depend on the hope that nothing bad will happen, a somewhat short sighted strategy and unlikely to go down well with most enterprises, then you will need to provide for the scalability and security of your systems, both in terms of identification, non repudiation, etc, and in securing the data itself. In enterprises, which typically have much larger resources for systems development (granted that they may be somewhat stretched), this may be the only option. Unfortunately, no Application Server provider chimed up at this point or at any time in the conference that they already provide these types of services, though this may be because of the strong standards bias that Sun has to software implementation. It may be that some Application Server vendors provide non-standard ways of securing applications that use Web Services interfaces to bind to other systems. Passport and the Liberty Alliance When the subject of identity was broached, Sun indicated that they have invited Microsoft to join the Liberty Alliance. The difficulty that many have with trusting Microsoft to administer identity raises the issue of the security of data. Microsoft is known for their strong business practices, which leads to a perception that there may be issues with ownership of the data collected and handing over so much information may not be desirable. This data primarily includes such information as how many times a given user has been authenticated by an organization, where the user has come from, where they consequently went, and so on. In a panel discussion, the subject of privacy was also raised. Microsoft indicates that it is able to support identity with only 13 fields. Sun considers this is unlikely to fully implement all of the functionality associated with identity, and specifically federation: the collaboration of business partners to allow the handover of identity. Imagine that Air Miles wishes to pass a customer over from their Web site to a hotel company that awards air miles for staying at its hotels. This talk was a little vague, but the upshot is that Microsoft is not prepared to join the Liberty Alliance at this time. To date there has not been any talk of collaborating between the two groups so that Passport and Liberty Alliance work together. It should be noted that this may be partly because of the lack of concrete details on Liberty specifications, but may also be more fundamentally to do with the fact that Microsoft proposes that it be responsible for maintaining identity on the internet, while the Liberty Alliance merely proposes to standardize the way that identity is established, leaving each company to implement the standard and maintain private stores. This second system would then allow collaborating companies to hand off identities (pass them between each other) guaranteeing a person's identity but without revealing personal information about them. Someone pointed out, though, that this competition between Passport and Liberty is much like comparing Visa and Amex - they are competing ways of paying for things, and many retailers accept both (many customers use both as well, for those that only accept one). Looking at the situation in this light, it matters little that Microsoft don't want to join the Liberty Alliance - if both approaches are shown to be successful, the only difference it will make is a bit of extra code behind the sites that want to use identity, and a choice for the consumer. Distributed Transactions Finally, an addendum: one consistent message that has come through is that Distributed Transactions may turn out to be unnecessary. Preliminary investigation has turned up that in 90% (I suspect this is a figure grabbed out of the air) of Web Services scenarios, distributed transactions can be avoided. The traditional Two Phase commit that is now very well understood should provide sufficient functionality for most peoples needs. Implementing two-phase commit transactions across Web Services agents represents a significant undertaking. This model would still allow for chaining of transactions so that you have end-to-end data integrity but then introduces the problem of supporting very long running transactions (months instead of days). Conclusion Implementing Web Services in Java is for the SME (small to medium sized enterprise) rather than the SMB (small to medium sized business) space, which Microsoft more naturally competes in. It requires more work, but allows far more flexibility, arguably better security, and is much more suitable for complex systems that must work with legacy systems, rather than duplicating or replacing them. As usual, Microsoft has provided easy to use development environments that minimize flexibility but maximize productivity (so long as the problem to be solved is catered for in their development suite). It is perhaps this fact that appears to have reconciled Sun to working with Microsoft, as Enterprises will not be able to control the systems they integrate with (in third party and very loosely federated services). |