Home
 > Research and Reports > TEC Blog > Liberty Alliance vs. WS-I; J2EE vs. .NET; Overwhelmed .YE...

Liberty Alliance vs. WS-I; J2EE vs. .NET; Overwhelmed .YET? Part 2: Comparison, Challenges, & Recommendations

Written By: Predrag Jakovljevic
Published On: March 21 2002

Event Summary

February appeared to be the month in which Web Services earned notable legitimacy. Recently, IBM and Microsoft, the two largest proponents of Web Services, and a slew of other prominent IT companies and enterprises (Accenture, BEA Systems, Hewlett-Packard, Fujitsu, Intel, Oracle, and SAP to name some) have joined to form the Web Services Interoperability Organization (WS-I, www.ws-i.com). The organization's goal is to work with other standards groups like, inter alia, the World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASIS) to make sure standards from one version of Web services development tools will be compatible with the next.

The group will initially concentrate on the following interoperability issues:

  • To profile Web service standards
  • To build industry-specific Implementation Scenarios
  • To build Test Suites and Supporting Materials

Noticeably absent from the members' list was Sun Microsystems that seemingly has plans on its own. Its recent introduction of a counterpart organization, named the Liberty Alliance, was an attempt to gain leadership in the area of identity, authentication and authorization open standards through an alliance that will oppose Microsoft's counterpart "Passport" authentication (single sign-on) efforts.

Another crucial event pertinent to the adoption of Web services should be Microsoft's recent launch of the software development kit, which it claims will begin to deliver some of the promises of its long touted, but yet to be fully clarified .NET strategy.

This is Part 2 of a two-part event note continues the discussion of the Market Impact of recent announcements concerning the standardization of Web Services.
 
Part 1 began the discussion with recent events and their Market Impact.

Comparisons

Somewhat surprisingly, with the blitz of all the recent hoopla surrounding Web services in its .NET strategy, Microsoft seems to have caught its archrivals asleep. The protracted lack of a clear message and a more vocal embracement of Web services by Sun Microsystems is puzzling given that Sun was one of thought leaders in the advent of the 'software as services' notion. Sun and Oracle have long advocated a vision of services on the Web replacing traditional applications. With this vision came the introduction of e.g., network appliances, devices connected over the Internet, mobile Java code, content stores and even application service provider (ASP) discussions. Much of this, among other capabilities, is now present within the Microsoft .NET strategy, forcing Sun to play a game of catch-up by only recently debuting the Sun Open Net Environment (Sun ONE) counterpart to VS.NET.

The battle for the dominance in Web services has so far largely been a war of words without the clear winner yet (and not any time soon), as many underlying standards have emerged only recently. Still, the bitter enemies, agree on the future of Web services, and have been building similar technology frameworks for developers. Both camps also rely on the same set of established standards such as XML, Universal Description, Discovery, and Integration (UDDI), Web Services Description Language (WDSL), and SOAP.

Also, to spoil the possible users' early enchantment, there are significant differences when it comes to the vendor's support for OS platforms and languages. While Microsoft works only on its Windows OS but offers support for over 20 programming languages as a consolation prize, Sun encourages development on multiple OS (e.g., Windows, Unix, Linux, mainframe), but using a single language, Java. Based on the above perplexing facts, and given that neither product has fully matured, enterprises will consequently have to delve into both methods for some time to come.

Despite its head start in offering the framework to build Web services, Microsoft's task of luring developers' community into its camp, especially enterprise application developers, remains an uphill battle since many large organizations have made significant investment and progress with Java. Java remains a platform of choice for typical diverse e-business solutions environments, as the various Java platforms have reached an indisputable level of maturity and acceptance. Java is still likely the fastest-growing language and platform for building new applications and will likely continue to be used by large global corporations, as seen in SAP's recent endorsement (see SAP Opens The 'Miss Congeniality' Contest).

The only non-J2EE application server product of merit belongs to Microsoft, while all others have committed to the Java juggernaut. As mentioned in Part 1, Visual Studio.NET may give Microsoft a tool to compete on level footing with the Java community. Although Microsoft touts the advantage of delivering a toolkit to link MS Office applications to Web Services and .NET, that might not be enough to convert Java-files. On the other hand, .NET's steep learning curve for traditional VB developers (with only a limited object oriented experience), may be used by Java proponents to convert any disgruntled Microsoft developers. To that end, by targeting Java novices, BEA might be hitting a current market hotspot with the need for tools that have an easy entry point into Java development.

The WS-I consortium may be in a position to bridge the gap Microsoft and Sun have long created (see Sun's Java Won't Be In Microsoft's .NET Complicate Your Integration? You .BET), by emphasizing interoperability, guidance rather than legislation, and a desire to help educate the market and thereby raise the awareness and adoption of Web services. The presence of high-profile players like IBM, SAP, Oracle, BEA and Microsoft, some of which have been playing with both rivaling camps, may help the consortium reach the decision on what Web services will and will not be.

However, whether the other standards groups (e.g., W3C, OASIS, OAG) will comply with WS-I's recommendations remains to be seen. Also, with deployments expected to stay within the firewall for a foreseeable future, it is still unclear whether interoperability or security is the main issue in Web services adoption. As admitted by the WS-I ring leaders, IBM and Microsoft, there is still much effort outstanding for message extensibility, binary attachments, routing, correlation, guaranteed message exchange, signatures, encryption, transactions, process flow, inspection and discovery. Many other issues, such as proper security, privacy, payment collection, and the accountability to fix any glitches remain undefined and a moving target.

For the consortium to be more than yet another nice try on standard adoption, both Microsoft and Sun should join their respective counterpart organizations. Otherwise, the threat of eventual market apathy and even more separation into trenches remains great. While interoperability seems to currently be the motivation for bigger players to suspend hostilities and focus on standards adoption, the desire for domination will tempt them to weave dependencies on their products into their strategies.

Challenges

It is very likely that owing to the standards immaturity and disparity, in the immediate future, XML remote procedure calls (RPCs) and other Web services initiatives will mainly see adoption between applications inside an enterprise firewall, rather than between enterprises assembling applications from services components supplied by a variety of outside vendors. One of the major challenges for the success of Web Services in general is to provide an environment in which enterprises can leverage an available Web Service to fulfill a specific business need. The key success factor will be that these users need to be insulated from the technical details and underlying technology and platforms.

At their core, Web services are all about business-process management, as the concept of Web services refers to the ability of combining portions of software applications (using a set of technology standards) to create new applications and business processes. While the ability to accomplish that combination is relatively easy, it becomes much more difficult, when companies try to leverage that capability for creating new business processes. If Web Services offers the technical flexibility to better map software functionality to business needs, then business users must have an intuitive, easy-to-use tool for Web Services that becomes part of their regular workspace. However, as tools for the easy creation of Web services have been flooding the market lately, enterprises should try to utilize prudent and structured adoption or face infrastructure overload.

Furthermore, Web Services may motivate vendors to more tightly couple integration with development early in the life cycle of software applications. Microsoft seems to have realized this through the ability of BizTalk Server to utilize Visual Studio.NET objects and combine them in a process-oriented manner with other application components. BEA's WebLogic Platform, IBM's WebSphere, Oracle 9iAS, SAP's WAS, and others have been delivered along the same lines. Instead of having to wade through the complexity of integration only after applications have been implemented and are up and running, enterprises can begin executing on integration strategy concurrently with development and deployment. This might be one of the promises of Web Services first to be realized in reality.

User Recommendations

Although the widespread acceptance of Web services inter-enterprise implementations will not happen any time soon, the major players' involvement in leveraging these should prompt large global enterprises to start learning the new protocols, standards and technologies in order to grasp the potential underlying business advantage. They should try to grasp how developers will leverage Web Services, what their ongoing needs are, and what intricacies may arise from the u

While Web services may make integration easier through some imposed interoperability, they will not eliminate the need for application integration via adapters, connectors or so. They are not any kind of panacea. While they may provide new business opportunities and create some dynamism and efficiency , they are not going to transform businesses on their own, given that they are only a piece of new technology.

Likewise with a public and private marketplaces comparison, Web Services seem to have more potential within a trusted environment of business partners. Organizations evaluating Web Services may benefit from following WS-I activity, while those that have leveraged Web Services may benefit from joining it so as to share the experiences with their peers and to make sure that the consortium focuses on their business issues. However, as the consortium cannot impose much authority on vendors and as it is not performing compliance testing at this stage, you should question vendors directly on compliance to the standards.

Before customers make any attempt at choosing products or suites of products for enterprise application integration (EAI), middleware, Web application servers or other software solutions that require seamless interoperability, they must be sure they understand the difference in the approaches used by J2EE and .NET. While one of the main goals of Web services was to make the platform choice less important, that reality is still a long way off. Despite your platform preference and the roster of programmers with certain skill sets, it is therefore prudent to gather as much as possible information from both camps, as both will have their pros et contras.

Although competition typically results in both camps keeping each other on their toe tips to be more creative, it does not help you now. Question vendors closely on which approach they have (or will be) taking in their current and future releases, and why. Once the choice is made, it will be difficult although not quite impossible to switch or abridge. Since application integration efforts are costly, complex and time-consuming, the decision may come back to haunt you if you do not choose wisely. Users must recognize that making a choice for an application server should encompass the entire stack (portal, personalization, directory, etc.).

As for Microsoft followers, they should be pleased with Microsoft's partial execution of its Web Services strategy by delivering a production-ready .NET. Microsoft remains a good choice for Windows environments with an abundance of PC desktop-oriented activities, and that are involved in next-generation platform (e.g., .NET and Web Services) development/deployment. Microsoft might not be such good a choice for complex organizations that need solutions for complex computing problems (a high-volume backbone ERP system that uses publish-and-subscribe message-oriented middleware (MOM) and multi-vendor integration projects (hardware, software, services)), solutions where security is of high concern, and projects where cross-platform is a matter of course, and where most application developments are done in Java.

In general, the market should watch out for the honesty and the longevity of the IBM/Microsoft WS-I relationship. Also, beware of any vendor that is inclined to create much dependence on its technology, as it leads to unjustifiable price increases, and a declining openness in the future.

This concludes Part 2 of a two-part event note continuing the discussion of the Market Impact of recent announcements concerning the standardization of Web Services.
 
Part 1 began the discussion with recent events and their Market Impact.

 
comments powered by Disqus

Recent Searches
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others

©2014 Technology Evaluation Centers Inc. All rights reserved.