A Monthly Article from our Speakers
Current Article of the month
.NET or J2EE - Choosing the Right Web Services Framework
The Web Services model is quickly becoming the preferred approach to creating, acquiring, and implementing business applications because of its rapid application development characteristics, low cost of entry, and consistency of information exchange.
Its XML text-based application interfaces are an evolution of proprietary and platform-dependent predecessors such as CORBA and COM IDL (Interface Definition Language). The business information exchanged in Web Services applications conforms to vertical transaction and data standards in finance, insurance, manufacturing, health, pharmaceuticals, and most other businesses. These standards are also expressed in XML, making them accessible to any system that understands text, and can connect to the Web.
Vendors are rushing to provide Web Services application frameworks software that takes advantage of this model, and are basing their offering on two application frameworks: Microsoft’s .NET and Sun’s J2EE. Although each offer a relatively easy and low cost startup, the exit cost – the price of switching from one to the other is very high, so business and IT management view the choice as strategic. In this article, we will compare these two frameworks, examine their interoperability characteristics, discuss critical factors in making the choice, and look at some open issues for .NET, J2EE, and the Web Services development approach as a whole.
What is a Web Service?
A Web Service is a self-contained modular application. The key to its power is enterprise and worldwide interoperability and reusability. It can be described, located, and invoked over standard network protocols, such as HTTP. Web Services enable new and existing application to be integrated using XML (Web Services are not, however, a replacement for Enterprise Application Integration (EAI)). Web Services interoperability is based on open XML standards and environments.
Web Services applications are designed using Service-Oriented Architecture (SOA). The most important SOA principle is loose coupling for dynamic integration of applications, objects and programs. To enable future applications to be built dynamically, the resources need to br publicly known, and advertised through a directory. To make the applications widely usable, interfaces can be personalized for each user.
This architecture defines three major roles (see figure 1 – Service-Oriented Architecture). The Service Provider creates and publishes the interfaces, and provides an actual implementation. This role could be played by and company, business, department, or other entity. The Service Broker registers and categorizes the services provided by various Services Providers, and offers services such search. The Service Requester is the actual consumer of Web Services. The Requester discovers Web Services by searching the repository (maintained by the Broker), and invokes services by communicating with the provider. This can take place on the Internet, between businesses, or on an intranet, within a business.
In general, there are two types of Web Services. User-centric services are designed to enhance a user’s experience by providing personalization, interface customization, and multiple language support. It is critical for this service to separate presentation, e.g. HTML, from content, e.g. XML An application-centric Web Service integrates enterprise and B2B applications. These services need to connect business processes while overcoming the constraints imposed by proprietary infrastructures, platforms, and operating systems.
To create, reuse, or integrate Web Services, we need a framework that supports XML, network-level interoperability, the Service-Oriented Architecture, and application- as well as user-centric services. This is the role of .NET and J2EE, provide guidelines for Web Services development, deployment, management, execution, and standards usage.
What is a Web Services Application Framework?
An application framework is a set of guidelines and specifications for platforms, tools and programming environments that address the design, integration, performance, security, and reliability of distributed and multi-tiered applications. This is a very comprehensive set of responsibilities, and one we have become familiar with in Java and COM application server software such as IBM’s WebSphere and Microsoft’s Transaction Server. Basic support for applications must include presentation services, server-side processing, session management, a framework for business logic, caching for application data, application logic, persistence, transactions, security, and logging services.
In a real-world enterprise environment, the framework is a scalable application development, deployment, and execution platform for web services. It needs to provide development and run-time services for transaction management, security, state management, application integration, administration, connections, messaging, and business process management. Because people need to connect to Web Services from anywhere and everywhere, the framework also needs to support various GUIs, including Web browsers and wireless devices. Application frameworks are implemented as tools and servers built on tope of application frameworks (see figure 2 – Application Frameworks). This programming model supports both application- and user-centric Web Services.
J2EE and .NET Differences
J2EE and .NET each provide an application framework for web services, but differ in design and support, implementation, pricing, portability, tools and servers, vendor backing, and maturity, and popularity
Design & Services
The .NET Framework has three major components. The .NET Platform consists of the tools and infrastructure provided to build .NET services and .NET device software. .NET Products and Services are provided by a set of .NET-based enterprise services that support the framework. These include BizTalk Server, SQL Server, Windows.NET, Visual Studio.NET, and Office.NET, Third-party vendors provide .NET Web Services built on the .NET platform (see figure 3 - .NET Web Services Support).
The J2EE Framework (see figure 4 – J2EE Web Services Support) addresses these requirements with a comprehensive set of standards, including Enteprise JavaBeans (EJB), J2EE Connector Architecture (JCA), Java Database Connectivity (JDBC), JavaServer Pages Standard Tag Library (JSTL), Servlets, the Java Transaction API (JTA), Java Messaging Services (JMS), Java Name and Directory Interface (JNDI), Java Remote Method Invocation (RMI), RMI/Inter-Orb Operability Protocol (RMI/IIOP), Java Authentication and Authorization Service, (JAAS), JavaMail, and the Java API for XML (JAXP).
The essential difference is that J2EE supports Web Services through Java APIs, while .NET Web Services are built into the platform.
J2EE Web Services are typically implemented with Enterprise Java Beans, although standard Java applications can also do the job. The choice depends on how the business processing and data logic layers are designed and built. .NET services are typically implemented in components managed by the .NET platform. This includes managed class and COM or COM+ components. .NET supports Managed C++, JScript.NET, VB.NET, and C#, a Web Services version of C++. The J2EE framework, of course, is limited to Java.
J2EE is expensive compared to .NET, but if a company already has a J2EE-based application server, such as Silverstream, WebLogic, or WebSphere, it makes sense to use it, as the incremental cost of J2EE web services is low in this case. .NET servers costs much less than J2EE servers.
J2EE Java code can be ported across multiple operating systems, but generally not between servers. The standard allows vendors, such as IBM and BEA Systems, to create J2EE-compliant application servers to support EJBs that use proprietary vendor features. These applications cannot be ported between application servers without modification. However, it is possible to move the entire application container (an instance of the application server itself) between platforms, and this can be a great advantage in a large multi-platform enterprise environment.
.NET is intended primarily for Windows operating systems. .NET applications, however, are not directly executed in native machine code. They are compiled to Microsoft Intermediate Language (MSIL). The MSIL is compiled to native code at run time by a just-in-time compiler, and runs in a virtual machine called the Common Language Runtime (CLR). This Java-like approach has so far been implemented only in Windows, although it is possible that it may be supported on other platforms in the future, as ECMA ratified C# and CLR as official industry standards in December 2001.
Tools, Servers and Vendor Backing
J2EE vendors like IBM, BEA Systems, Oracle, Hewlett-Packard, and Sun Microsystems have already begun to support web services creations, deployment, and execution. But the level of sophistication and standards support varies. Many vendors did not expect XML, the base technology for Web Services, to gain popularity so quickly, and were unprepared for the general market demand. J2EE vendors are also hampered by the overhead and conflict of creating industry standards for services as well as differentiating their offerings from competitors who adhere to the same standard. J2EE provides a framework for competing products, with no monopoly. This is a challenge, but not a new one.
Microsoft’s major Integrated Development Environment (IDE) is Visual Studio .NET, which is already ahead of its competition in supporting web services. Microsoft has moved forward to provide component-level support for web services with their suite of web service-enable servers, such as BizTalk. .NET is controlled by a single company, and while there is no question about Microsoft’s stability, quality, and commitment to web services, enterprises should explore and acknowledge the effects of making a long-term strategic commitment to a single vendor.
Maturity and Popularity
J2EE is a robust, scalable, and mature architecture that has been supporting enterprise applications for many years. Support for Web Services at this point is just another feature added to this flexible framework model. .NET inherits many features from the Windows DNA architecture. 79% of respondents to a ZDNet poll taken in December 2001 said they planned J2EE implementations, while 21% planned to use .NET. Three months later in February 2002, Microsoft released key development tools and servers, so the picture may change drastically in .NET’s favor. For instance .NET “My Services” provides a wider support of personalization and user preferences than J2EE.
Making the Right Decision
There are several major decision factors that come into play when choosing a .NET or J2EE strategy. This include the enterprise or business unit’s existing application framework and IT infrastructure, predicted Return on Investment (ROI), the IT and business strategy, current developer expertise, standards compliance, scalability and integration requirements, security, aggregation and personalization needs, and third-party support.
Existing Frameworks and IT Infrastructure
What is the existing framework? Many companies are moving forward to extend existing platforms. COM users, for instance, tend toward using .NET, while a WebSphere shop may choose to continue using J2EE. If, like most enterprises, your environment includes J2EE and Microsoft, consider a mixture, and make the decision on a project-by-project basis. Using standard Web Services XML standards, it is possible to integrate (or at least interface) .NET and J2EE applications by using standard WSDL (Web Services Definition Language) binding information and a private (intranet) UDDI directory.
Which framework can be easily supported in the existing IT infrastructure? Reduced support costs eventually leads to a lower Total Cost of Ownership (TCO), because TCO is the sum of implementation and maintenance costs over the application’s lifetime.
Existing Developer Expertise
This is probably one of the most important factors for any enterprise. If most or all developers are Microsoft experts, introducing J2EE is a difficult decision. On the other hand, J2EE developers tend to adapt well to creating .NET applications. The factors surrounding this decision point out the fact that correct usage is often more important than choosing the correct technology. In other words, using either framework well is a more critical success factor than choosing the “right” one.
Standards and Futures
Which products are evolving more rapidly and in line with standards? This is a difficult area to track and quantify because standards are still being defined. Many even conflict in the short term, such as WSIL (Web Services Interface Language) and UDDI. In fact 67% of the entries in public UDDI (Universal Description, Discovery and Integration) Web Services directories are either in error or describe implementations that do not exist, based on a SalCentral survey in January of this year.
In February 2002, Microsoft released Visual Studio.NET and a .NET-based enterprise server. With this move, Microsoft took a lead over all J2EE framework products, including BEA Systems’ WebLogic, and IBM’s WebSphere. This short-term lead may be reduced as J2EE vendors release new versions.
Robustness and Security
Which products are more robust and scaleable, and meet integration needs with the least complexity? J2EE is more robust and scalable, but is this important for a small-to-medium sized company, division or department? .NET is less complex to develop, deploy and maintain. This simplicity itself can increase robustness and scalability.
Which products have greater security? Both products are fine. .NET is role-based, however, and this may be an advantage given Web Services natural affinity with RBAC (Role Based Access Control).
Software Vendor Support
Most Application Server vendors have started to provide support for Web Services, and full support is inevitable soon. There is a high probability that an enterprise will be able to use its current EAI and B2B integration infrastructure to deploy web services, regardless of which framework is chosen.
Which products are more flexible in integrating third-party vendor services? Traditional logic is that an open architecture encourages third-party support. This would lead us to conclude that J2EE is superior in this are. After all, J2EE is an open architecture. But this is theoretical. The winner in this area depends on which services you need. All major packaged application providers have announced support for both frameworks. One lesson we have already learned in the component wars (COM versus J2EE) is that it is easier for a vendor to support one product (Microsoft’s) than it is to support many products based on one standard (J2EE). It remains to be seen whether this will hold true for .NET.
All major packaged application providers are racing to support and provide web services interfaces. This includes Enterprise Resource Planning (ERP), Supply Chain Management (SCM) and Customer Relationship Management (CRM). The current industry trend is to stay neutral by supporting both. SAP, for instance, has announced and implementation of Web Services for J2EE and .NET, using SAP’s own Web Application Server.
Both J2EE and .NET frameworks provide full support for multi-tiered web services applications, including design, development, deployment, execution, and monitoring. Because both technologies support web services well, framework war will continue for years. This competition will improve web services technology in terms of tools, standards, scalability, and cost.
It is not clear yet, however, how many important issues will be resolved in either camp. Although support for security, operational management, workflow, business rules, and transactional integrity is provided by vendors of J2EE and .NET frameworks, standards in this areas are not yet defined, or note yet complete. This will reduce interoperability overall, as vendors are being forced to create their own “proprietary” solutions.
One cost factor is very important. It may be very inexpensive to start using these frameworks, but be careful – the exit costs are extremely high. Developing a strategy and web services architecture now is prudent and risk-averse.