|
|
|
|
|
|
|
|
|
|
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Start by identifying the differences :
.NET is coupled tightly with the operating systems on which it runs (all of them are Windows systems), and includes a full range of features and functionality, including the database, desktop interface, browser, and everything in between.
J2EE provides a more abstracted and loosely integrated environment than .NET, but it's one that runs on virtually any hardware and operating system platform.
.NET integrates Web services more tightly with other Microsoft products. J2EE developers must, by definition, employ a broader approach to integrate with other comparable technologies, often from different vendors. .NET is available on Windows only, which requires the hardware to be Intel-based.
J2EE is available on multiple platforms, including a broader range of hardware.
Microsoft takes the .NET architecture a step, basing a large part of it on XML and Web services. This means you need to recode your existing Microsoft applications to move them to .NET.
The J2EE community, which relies upon a large vendor community consensus-process to define and incorporate new technologies, views Web services more as an evolution of application servers rather than a technology requiring any fundamental architectural change.
The leading Java vendors, including Sun, IBM, Oracle, BEA, and IONA, are part of an organization called the Java Community Process (JCP). Sun chairs the JCP, which chooses how J2EE defines standard features, APIs, and protocols for Java-based application servers, including Enterprise JavaBeans (EJBs), servlets, Java Server Pages (JSPs), and Remote Method Invocation (RMI).
For J2EE, adding Web services support means adding more APIs to an already long list of APIs that integrate applications servers with other, external technologies.
The .NET environment treats Web services as an integral part of the major pieces of .NET, which includes the .NET Framework, Visual Studio .NET (VS.NET), and ASP.NET. .NET hosts Web services as client and server technologies equally.
J2EE hosts EJBs within a server container, which can't host Web services. Therefore, a Web service that connects to an EJB, always requires a separate Java class "proxy" or wrapper. (This isn't necessary within the .NET environment.) The additional development step complicates design and development activities. For .NET, deciding to expose a server object as a Web service is one of several options supported natively within the VS.NET framework.
For J2EE application servers, deciding to expose a server object as a Web service involves an additional, completely separate development and deployment step.
Supporting standards is a more significant undertaking for the J2EE application server vendor community because there's a double requirement of sorts. The internal APIs that manipulate XML, SOAP, WSDL, and UDDI must be standardized, in addition to providing support for those base standards. Within .NET, objects send and receive SOAP messages using .NET-specific APIs.
Within J2EE application servers, vendors are moving toward adopting the Java API for XML-Based RPC (JAX-RPC), a standard API for sending and receiving SOAP messages. The goal is to standardize the APIs developers use, as well as the formats and protocols for communication transports, configuration parameters, and data interchange formats. Application servers that conform to J2EE reassure customers that their investments in application development are protected by, at least, the potential to port to another application server product (hopefully at minimal cost), and assures them that their application server products work well with external standards.
In practice, customers don't often port applications from one application server to another after they've chosen one and deployed upon it successfully. However, customers tend to insist on J2EE conformance, just in case.
The opposite issue plagues .NET. Despite its technical advantages, and some open source and porting initiatives, it remains a Windows-only implementation. This means customers must choose between .NET and J2EE based on the whole environment�not just the application server or its equivalent in .NET�and not simply on the basis of which environment has superior Web services support. Many end up seeking solutions that join .NET- and J2EE-based applications to get the full power of application development and deployment on Windows and Unix platforms. But such applications often become "lowest common denominator" solutions, because aside from the commonality around Web services, many differences remain in both platforms.
Developers can use WSDL as a service description and SOAP/HTTP as a communication protocol to bridge .NET and J2EE. However, integrated security, transactions, and reliable messaging constructs (such as conversations or sessions) aren't available. Web services standards themselves are lacking in features compared to .NET and J2EE.
Therefore, you can use Web services for basic interoperability, but not for building applications with a combination of .NET and J2EE components yet�at least, not without sacrificing significant functionality.
And as always , specifications are open to interpretation.
.NET and J2EE implementations of SOAP and WSDL tend to vary somewhat.
These core Web services specifications contain optional parts that not all vendors support. The WS-Interop organization, (Microsoft and IBM ) focuses on this problem, defining and certifying a common interpretation of the core Web services specifications.
The different approaches to delivering Web Services?
Web services are implemented using a Java class that's responsible for receiving the HTTP/SOAP message, parsing the XML, and mapping the message to another Java class or Bean that provides the implementation of the service .Developers can place the implementation of the service within the Servlet engine, or within the EJB container. When you place the implementation of the Web service within the EJB container, as either a session Bean or an entity Bean, the container must be accessed using the RMI or RMI/IIOP protocol rather than the HTTP protocol.
In other words, J2EE requires you to create a protocol bridge or gateway class to accept a Web services invocation over HTTP and call an EJB using RMI or RMI/IIOP, adding additional complexity to the design, development, and deployment tasks. Application server containers don't support HTTP as a native communication protocol currently, while .NET servers do. Adding this capability is a primary theme for J2EE 1.4.
The .NET environment provides a single, generic mechanism for supporting Web services in multiple languages. The common language runtime (CLR) hosts objects or components developed in multiple languages using the same infrastructure, which is basically the .NET Framework (see Figure 2). So far, VS.NET for C#, Visual Basic, and J# offer native support for Web services, and support for C++ Web services is provided through the Active Template Library (ATL). And now that Microsoft has opened up Visual Studio for additional ports, you can get third-party support for additional languages. ASP.NET, the recommended approach for creating Web services, and ADO.NET, the recommended approach for accessing data resources, also create objects that are hosted by the CLR, providing a consistent, seamless architecture.
.NET provides a binary and XML version of its communication protocol. For J2EE, the binary protocol is RMI or RMI/IIOP, and the XML protocol isn't supported currently. However, you should note the .NET XML protocol doesn't support many of the features available in the binary protocol, .NET remoting. It includes features such as full type fidelity, references to server-side objects, and control over the lifetime of those objects. If your application needs these object lifetime services, you should implement both client and server applications using .NET remoting (see the Go Online box for additional information on .NET remoting).
Assess How the .NET Architecture Measures Up
Therefore developers can use VS.NET to develop a Web service using any one of the supported languages, and choose either the HTTP or binary communication channel. However, developing and deploying Web services with J2EE remains a two-stage process in which Web services and EJBs communicate using different protocols.
Living Up to the Promise
=================================
I think it's fair to say that Microsoft initiated, and continues to lead, the Web services movement, and that the leading platform implementation of Web services is found within the .NET initiative. Although .NET represents more than just Web services, these servers are perhaps the most significant part of the initiative.
Web services offer the promise of universal interoperability and reusable components for rapid application assembly. But these promises can't be fulfilled in a vacuum�both .NET and J2EE need to provide equivalent, or at least compatible, implementations of Web services technologies. The real difficulty for Microsoft will be to continue to find a way to promote the standards that need to be widely adopted and, at the same time, stay ahead as the J2EE community closes the gap. As long as Microsoft and the Java vendors remain at war, businesses will suffer when they have to deal with both environments in different ways, with different skill sets, and using different hardware platforms.
The difference will be settled by the rate of adoption, and the rate at which Web services provide value�in other words, if Web services take off big-time, the Microsoft bet will pay off. If Web services prove to be a significant force for industry change, Windows developers will find the additional effort to migrate and convert existing applications worthwhile. If not, they might look seriously at migrating to alternatives within the J2EE environment, where the changes are more incremental (read the sidebar, "Understanding the Past and Future Direction of Web Services").
You can expect the next release of J2EE, J2EE 1.4, to standardize many of the features required for Web services support that individual vendors have developed using proprietary architectures and APIs. The speed at which the Java community can advance its ideas and specifications for Web services collectively will be critical to maintaining parity with Microsoft, who often advances ideas on its own.
Some J2EE vendors are closing the gap with .NET already by providing development environments that focus more on Web services, such as IONA's XMLBus, IBM's Web Services Toolkit, and BEA's WebLogic Workship.
Significant work is already underway within the Java Community Process (JCP) for Web services security and transactions (see Resources). These additional technologies will provide the basis for secure, reliable, robust, and complex business applications for J2EE-hosted Web services. Similarly, Microsoft is promoting its Global XML Architecture (GXA), which offers additional Web services features such as security, message routing, and process flow.
The fact that Sun, Microsoft, and IBM are all cooperating on WS-Security at Organization for the Advancement of Structured Information Standards (OASIS) is a good sign, but this is only one of many specifications in the Web services arena (see Resources). Microsoft should avoid requiring its software to be at each end of the communication, as it does with .NET remoting, because that's antagonistic to the Web's origins as a free, open, and completely standard place.
Microsoft has reinvented its distributed computing development and deployment platform around XML and Web services. Therefore, the .NET platform is less mature than most Java-based application servers, where vendors have tended to view Web services support more as an add-on to a proven technology. However, Microsoft seems to have done the right thing by taking the plunge.
Is the Microsoft .Net "embrace and extend" approach is superior to the J2EE "redesign and rework" approach when it comes to Web services ?
Web services are sufficiently different from the features and functions that motivated J2EE and Windows DNA originally ?
Originally posted by HS Thomas:
I need to find a few WebServices that I could use on a web site.
For simple ones like map directions and payments,how do I choose ?
regards
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by HS Thomas:
Thanks , Balaji. Which site do you mean ?
I'd like to put some web services on a Web site that needs to handle payments among other things.I don't want to write these myself but would rather use components.
I'd like to use Open Source software as much as possible.As a user of the component how much of the above should I worry about.
By the way, I wouldn't take the implied superiorities in the article too seriously as it was printed in the "dotnetmag" section...
The author of the article is Eric Newcomer who wrote "Understanding Web Services" , so hopefully he knows what he is talking about. He is also one of the authors of the acclaimed Principles of Transaction Processing.
I kind of would go with what he says.
The only problem I'd have with the article is that it was written in Aug 2002. Which may still hold for projects starting now but maybe not in 3 years time (?)!
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
|
Grow your own food... or this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|