 | |||
|
Wednesday September 5 2001 Sun and Web Services The Competition Heats Up Having missed the boat in the early stages of XML and SOAP development, Sun was shaping up to play the role of a follower, rather than a leader, in the nascent world of Web Services. However, as Java is establishing itself as the natural tool for serious server side development, and there are signs that J2EE standards are becoming more accepted, Sun may well have begun its fight back into the heart of Web Services activity. While it is quite clear that Sun Microsystems' initial entrance was not as smooth as they might have wished, there are signs that Java may not be out for the count quite yet in the Web Services arena. When Sun first introduced their SunONE strategy (http://www.sun.com/software/sunone/wp-arch/, February 2001), the company appeared to be making a strong move toward having an impact in the Web Services arena. This paper describes how the different parts of the J2EE platform could be used to assemble services, together with additional API for accessing Web Services. These include APIs for producing and consuming SOAP messages, accessing registries, and interrogating service description files. To date, this strategy has raised more questions than answers through the various holes that still remain. These are primarily the new APIs, which have suffered somewhat through the committee process on which they are based. While the fact that the Java Community Process (JCP) brings to bear the best knowledge in the market for designing the next generation of APIs, the need of each JCP member to achieve a solution that best serves their own means is causing problems, not only in the Web Services API but everywhere. This is most notable where contributory members have already made progress toward implementing tools and software for enabling the relevant technologies. Technology by Committee A contributory factor in the slow development of these APIs may also be the insistence of Sun to avoid common denominator APIs for the services mentioned above further exacerbating the problem above. Contributing members may be tempted to push the API in the direction their products are already moving, thus causing tension in the process. While avoiding common denominator solutions is obviously being done with good intent, it has severely hampered the development of APIs, and so has held back the development of software to use these APIs. By being required to design solutions that cater to all possibilities, Sun has been left behind through the complexity, and therefore time, that it takes to design simple interfaces for differing solutions that are not complementary. This is typical of the type of attitude that has placed Sun towards the back of the crowd for Web Services innovation. The weakness of this strategy is that they must wait until all the various solutions are fairly well established before providing tools for accessing those standards from within Java code. Research from Gartner Group indicated that only 20% of corporations that utilize Java as their primary development language are developing their applications in a distributed manner to support Web Services. This arguably makes Microsoft's stance more acceptable, since re-engineering the solution with good architecture has better long-term benefits. While automated conversions of J2EE applications that are designed to be distributed is a massive financial boon, attempting to do this with an application that is not suitable for conversion to a Web Service may result in more work long term, and a buggy solution. From Java to Web Services While Java is ideal for developing a distributed architecture with Enterprise JavaBean components that support applications, this ability has not been factored in across the board and many analysts say that more needs to be done to make EJBs easier to build, deploy, and purchase off-the-shelf. In addition, automatic exposure of EJBs as Web Services cannot be done naively while protecting investment and business resources. It is fair to say that existing code is designed for use by trusted parties. Code is often currently developed without an external (to the company) user in mind. As the majority of customers for business code are internal, checks can be put in place to ensure proper use of that code. This includes enforcing (distributed) transactions and workflow systems, features that are currently not supported in Web Services. What is missing, then, is a way of enforcing workflow where one of the participants is external to the immediate business. In an internal development project, testing can highlight problems and unexpected side effects. Where a participant is external, this is not an option. The main benefit of Web Services is loosely coupled design, discovery, and binding; requiring business partners to closely co-ordinate through projects defeats the point. It should be possible for the business to protect itself from attempts to misuse business resources, whether deliberately or not. In order to illustrate this point, let me make a somewhat trite example: in my application, the internal client is responsible for checking that there is sufficient capacity for ordering an item for manufacturing. As a result I have two EJBs, one checks capacity for a given list of part numbers, while the other schedules manufacturing jobs. You can immediately see the problem: there will definitely need to be some recoding in order to maintain the business integrity if these EJBs were to be automatically exposed. This example may be obvious, but it is typical of the types of assumptions that are built in to current applications. In addition, Gartner suggests that there is significant over spending by companies on J2EE servers for applications that do not use EJBs. This realization together with the pressure on IT spending is forcing companies to consider other options, such as pure JSP/Servlet solutions. This report suggests a slowing take up of application markets through to 2003. J2EE and Web Services Well that is the past, and this is now. We will look at the trends that indicate that this slow start may not hamper the Java language's involvement in Web Services for much longer. Louis Columbus, Senior Analyst, AMR Research: The J2EE platform clearly has the majority of the necessary components for developing Web Services as is obvious by reading the SunONE (http://www.sun.com/software/sunone/wp-arch/, February 2001) paper. Sun's solution for enabling Web Services development on the Java platform is a combination of existing J2EE technologies with a Web Services icing on top; that is, the group of APIs proposed; JAXR, JAXM, and JAXRPC. The difference between this approach, where companies are building on top of their existing infrastructure, and that of the .NET strategy are astounding and often discussed. While Microsoft has bet the bank on .NET and Web Services, this is something that may not be advisable for every company. A Variety of Platforms Until recently, this strength has been somewhat mitigated by the fact that there were several competing Java commerce platform vendors that did not comply, nor intend to comply, with the J2EE standard, Sun's platform for enterprise computing. In the main, companies have quoted their lack of faith in the technology, though the loss of existing code bases and the work to convert the rest must have been overwhelming. To some extent this was no doubt in part due to the proprietary, counter standards approach to application servers that has been the norm until recently. A report by Forrester (J2EE Dominoes Fall, Crushing Categories, August 15, 2001), however, indicates that customer pressure is encouraging the last of the proprietary application server vendors to move to J2EE application servers. The increasing commoditization of J2EE application servers will strengthen the protection on investment for companies who use Java for enterprise development. Furthermore, this will improve their flexibility to choose solutions for application hosting that are optimal for their most up to date needs. Secondly, Sun has indicated in the media that they are keen to make up for their loss of initiative over Web Services. In a news report to CNET (http://news.cnet.com/news/0-1004-200-6975650.html), Sun indicated that they intend making further progress toward impacting the Web Services market. These plans include a competitor to HailStorm, Microsoft's server for delivering content to multiple device types. In addition, with the assistance of IBM and HP they plan to release a number of services for accessing rented business service. Sun has also provided the first Java based implementations of an ebXML registry and repository on the market, plus the Web Services related APIs are close to delivering on their promises. Java-based Web Services In fact, IBM is one of the strongest indicators for a future in Java Web Services. They have always been a strong proponent of Web Services and were the first, and therefore most widely used, provider of tools for developing Web Services using Java. Other companies that have tools in place for implementing Web Services are IONA, Cape Clear, SilverStream, Shinka Tech, and BEA, and many more are fast on their heels. Fortunately, it appears that wide scale adoption of Web Services is expected around Fall 2002, with the majority of enterprises waiting to enter the market until they see widespread availability of tools. With this breathing space it is possible that Sun, and Java, will make a strong thrust in this market. Particularly encouraging is the high level of understanding that some companies are showing of the problems that remain to be solved. One example is Bind Systems, a platform developer for Web Services based collaborative business processes. Having already implemented technology for maintaining process and transaction integrity across multiple parties, Bind Systems have also implemented JAXM providers (at the current level of the standard). The platform is constructed of various components that take advantage of ebXML extensively, for its registries standard, Collaboration Business Process Specifications, and messaging service. Together with a workflow engine to address some of the glaring weaknesses of Web Services as they are now, this already provides a way for business to use Web Services in their systems now. It is my opinion that it is these types of companies that will push the widespread adoption of Java as a platform and language for implementing Web Services, in addition to the hopefully long lasting determination on Sun's part to make progress in this area. It will be important, however, for Sun to provide the tools and consistent, powerful, and timely APIs for creating Web Services with Java, as well as driving Java Web Services through clearly defined vision for the market. Additionally, Sun appears to have a new strategy for impacting the Java market, both to improve the performance, and possibly to reduce the latency between the definitions of API specifications and usable tools for developing applications with those APIs. This strategy is to release a product range of servers that will provide the components of a Web Services platform, much as Microsoft is doing. Finally, Sun will need to deliver on the promises for a number of toolkits, both generic and market are specific, for developing Web Services. The following diagram presents a likely timeline for this series of events.
Summary In summary, although Sun's vision for Web Services has been confused until now, there are signs that they are developing it. Java has most of the requirements already in place for creating Web Services and there is an extensive knowledge and skill base of Java programmers. The remaining pieces are beginning to emerge, namely the relevant APIs are near completion, and the toolkits for applications development have been promised in the near future. Java has built in distributed application support that is reasonably widely understood, even if it is not in widespread use. It also offers a greater protection on investment since Web Services "enabling" the language itself represents adding a fa硤e on top of existing functionality. Not mentioned until now is the strong application integration that Java has to offer as a language. This represents a very powerful advantage for enterprises with legacy systems. Finally, there are indications that current use of Web Services with Java is being done intelligently, with due learning from the disasters of over enthusiastic adoption of new technologies that we have seen in the last few years. This is all helped by the fact that the current climate means that widespread adoption of Web Services is a little further off. However, in their turn, Sun will need to:
With the combination of these factors, and strong support by Java developers, Java Web Services should certainly succeed in taking advantage of the strengths of the J2EE platform to provide scalable, portable, maintainable applications. Through their own actions, and those of the Java community, Sun should continue to grow in this market. Similar articles: Keep up to date with all the new articles and features on
Web Services Architect: |
