Java开发网 - Comparison of Microsoft and Java Frameworks

Java开发网

您没有登录

» Java开发网 » Architecture & Framework

打印话题 寄给朋友 订阅主题

作者

Comparison of Microsoft and Java Frameworks

SNIX

发贴: 43
积分: 30

于 2003-12-17 22:14

http://www.cswl.com/whiteppr/tech/web_services_framework.html

Comparison of Microsoft and Java Frameworks

Index

Introduction
Life Cycle Of Web Services
Web Services Framework
Web Services Development In .NET and JAVA
Developing Web Services In .NET
Developing Web Services In JAVA
Conclusion
Introduction
Web services use XML to provide a platform and language independent implementation of distributed application services and information. What this means is that applications and people can use the data and services of an application running on a remote computer regardless of differences in the technologies running on the remote and local machines. While it's perfectly feasible for a person to use a browser to take advantage of a web service running on a remote computer, the real potential of web services lies in its ability to allow applications to work with other applications without the need for any human intervention.

Unlike other technologies, such as Sun's Enterprise JavaBeans, and Microsoft's DCOM, web services are platform and language independent. Also, they do not rely on complex language translations like CORBA. Web services are independent because the messages sent between applications are in an XML-based protocol (called the Simple Object Access Protocol or SOAP). This allows applications written on one application server platform, such as ASP.NET, to be used by applications written in other platforms, such as ColdFusion or Java.

To understand web services, we need to look at the underlying technologies. This is presented in the next section. After that, we will look at the way it has been implemented using Microsoft and Java technologies and the tools involved.

Life Cycle of Web Services

Define a web service (in WSDL)
Implement the service
Produce deployment ready package
Deploy package
Publish the web service and binding information to a service registry

The Web Services architecture is based on three standards:

Simple Object Access Protocol (SOAP)
Web Services Description Language (WSDL)
Universal Description, Discovery, and Integration (UDDI)

XML and SOAP:
XML is a markup language, well formed, can best describe any kind of data in a platform- and language- independent fashion. SOAP is a protocol written in XML. SOAP protocol describes how messages are sent to and from web services. Currently SOAP (Specification v1.1) uses HTTP for its Transport. The Structure of SOAP message can be illustrated from the following diagram.

A SOAP message can be subdivided into three major parts

Envelop
Header
Body

The Envelope demarcates message boundaries. The header is optional and can contain one or more header blocks carrying the attributes of the message or defining the qualities of service for the message. Headers are intended to carry contexts or any application-defined information associated with the message, such as security tokens, transaction identifiers and message correlation mechanisms. The body is required and contains one or more body blocks comprising the message itself. The message would typically contain information about the operation to be invoked and arguments for the operation to be executed by the Web Service.

Thus SOAP transports an XML document across the Web and, potentially, across other types of networks to reach a Web Service implementation.

WSDL:
To understand about the services provided by a given service and to integrate with any of the existing application there is a need for standard. WSDL file defines the interfaces provided by the web services in the XML format.

A web services descriptor language (WSDL) file is an XML document that describes the arguments accepted by a specific web service as well as the methods and properties supported by that service. The WSDL specification provides the grammar and syntax rules for WSDL files. The Structure of WSDL file can be illustrated from the following diagram.

Types in a wsdl are the xml equivalent of Data types defined in a Service. Thus an abstract data type in a service is mapped to its XML representation in a WSDL. Parameter’s return values to an operation in web service are grouped to form Messages, thus we have a request message and a response message. Message contain set of variable names and it’s associated types with message name as Operation name suffixed with Request/Response.

Example of message

<wsdl:message name="addRequest">
<wsdl:part name="i" type="xsd:int"/>
<wsdl:part name="j" type="xsd:int"/>
<wsdl:part name="str" type="xsd:string"/>
</wsdl:message>

<wsdl:message name="addResponse">
<wsdl:part name="return" type="xsd:int"/>
</wsdl:message>

Thus here add is the operation and which takes i, j, str as input parameters and returns int. Operations define the what message goes in and what message comes out, thus a typical Operation is

<wsdl:operation name="add" parameterOrder="i j str">
<wsdl:input message="intf:addRequest"/>
<wsdl:output message="intf:addResponse"/>
</wsdl:operation>

A set of operations grouped together form a port type.

The Bindings describe message protocol with which the service can be reached. We can have multiple bindings for the same port type.

<wsdl:binding name="CalculateSoapBinding" type="intf:Calculate">
<wsdlsoap:binding style="rpc" transport= "http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="add">
<wsdlsoap:operation soapAction=""/>
<wsdl:input>
<wsdlsoap:body use="encoded" encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:Calculate"/>
</wsdl:input>
<wsdl:output>
<wsdlsoap:body use="encoded" encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/" namespace=" urn:Calculate"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>

Thus in the above xml snippet of wsdl file Calculate is the port type and the transport protocol is http. The Service element contains the actual network end point where the service is running.

<wsdl:service name="CalculateService">
<wsdl:port name="Calculate" binding="intf:CalculateSoapBinding">
<wsdlsoap:address location="http://localhost:8100/Calculate.jws"/>
</wsdl:port>
</wsdl:service>

Thus in the above snippet the endpoint is http://localhost:8100/Calculate.jws, hard coded in the wsdl which makes it non-reusable. For a given service there are tools, which can generate wsdl files. As the name implies, these files are used to describe the web service to potential consumers of the web service. Typically for a Web Service client developer the wsdl file can be an input to generate Static stubs.

UDDI:
To get more market for the developed web service, it has to be registered to a public domain. UDDI server is like a domain name server where the services are registered.

Universal Discovery, Description and Integration (UDDI) is the means by which potential users of web services can locate and choose the web service that best meets their needs. UDDIs can be thought of as the marketplace for web services. They are the web sites where web service creators can offer and market their services and where users can locate the web service that meets their needs. UDDIs provide information on the organizations providing web services, categorized lists of services registered with the UDDI.org web site and specific information on each service listed on UDDI.org.

Currently, there are three main public UDDI services on the web, but this number may change in the future. These include xMethods, the IBM UDDI and the Microsoft UDDI. There are numerous private UDDIs that are not publicized on the web as well.

Web Services Framework
Web services can be made available using the following Frameworks.

Microsoft .NET framework:
Includes the Common Language Runtime (CLR) and the unified class library. The CLR is a standard foundation for building a range of new applications, where as unified class library provides different application services. Among the technologies in library are ASP.NET, which is next generation of Active Server Pages. ASP.NET is the recommended technology for implementing Web services based on the .NET Framework. ASP.NET web services process services requests using SOAP over HTTP as well as HTTP GET or POST. ASP.NET Web services automatically generate WSDL and Disco (precursor of WS-inspection) files for Web services. The .NET framework development kit also provides tools to generate proxy classes that client applications can use to access Web services.

In addition to the features provided by the .NET Framework, Visual Studio .NET provides tools to help you build, deploy, and consume Web services.

Fig: web service in .NET framework

Java framework:
Web service in java is achieved by introducing an extra layer (SOAP Layer) in the existing Web Container. The SOAP layer accepts SOAP request with the transport as HTTP. The request is then processed and further delegated to existing java class or the EJBs/JMS, based on the deployment descriptors. Thus the java class or EJBs are enabled as Web service. The deployment descriptor contains information like

Service Name
The class or EJBs to invoke
The methods to expose as web service

You can also define simple web service with a java class with extension as .jws (java web service). A jws functionally behaves like a jsp file but looks like a java class and is placed into a web container during deployment. Since a jws file is itself a web service file you need not write a separate deployment descriptor to deploy it.

The following diagram clearly illustrates the way java provides support for Web Services.

Web Services Development in .NET and JAVA

Developing Web Services in .NET

Creating Web Services
Any file with the extension .ASMX can be published as web service in the web server. It can be done using the following steps

Use object oriented skill to develop web service classes
The web service class is the normal class having the OOPS advantages. It is as similar that of any class.
Specify the class is a web service
While defining the class extend it from WebService class

public class CalsoftWebService inherits WebService.
Also there should be a tag
<WebService(Namespace:="http://tempuri.org/");>_
For extending you need to include System.Web.Services in your code
Exposing methods as web services
We may want to expose some of the web service class methods alone for the end user, not the critical business methods, as web service is available for HTTP access. The methods with the qualifier "WebMethod" alone get exposed to the web service client. The description tag describes about the web service method functionality to the user and the session data storage is handled by simply setting the attribute "EnableSession".

[WebMethod(Description="This......",EnableSession=false)]
public CalsoftInfo GetCompanyDetails(string Code)
The ASMX file
If we compile this code it creates the ASMX file, which has reference to this class:

<%@ WebService Language="vb" Codebehind="CalsoftWebService.asmx.vb"
class="CalsoftWebService"%>

This will also store the. ASMX file to the (IIS)-controlled directory for getting through the browser. For example, CalsoftWebService.ASMX file is stored to the virtual directory \Calsoft\WebServices\ of wwwroot of IIS.
The VB class will also be compiled into a DLL that will under the wwwroot directory under the project name.

When we browse the page in browser with the URL http://localhost/Calsoft/WebServices/CalsoftWebService.asmx, .NET framework renders the page with the

Request parameter type, response type
Text box for getting the input parameter to the web service methods
Invoke button to submit the client request to the web service.

This is a test client to check if the invocation is working or not.

Publishing Web Service in .NET
To create awareness of our service to others, it has to be published with Universal Description, Discovery, and Integration (UDDI). It provides the advertisement for the web service. For enabling UDDI, we have to create the discovery file with the extension. DISCO. This is typically automatically generated.

The WSDL file is the Web Service Description Language file that is automatically generated by the .NET framework, which can be simply accessed by the web service URL and giving wsdl as a parameter. This provides the basic description about the web service. To access the wsdl, we need to use the same URL in the following manner
http://localhost/Calsoft/WebServices/CalsoftWebService.asmx?wsdl

The disco file that has the information about target WSDL file (which in turn has the information about the web service). This will be published or registered to any of the public UDDI server with the proper business information.

Consuming web services in .NET

Fig: Consuming web service

Visual Studio.NET allows us to create the clients easily with the following steps.

Use web references for the WSDL file
Use System.WebServiceClients namespace
With this approach a proxy of the webservice class is created in the client system. Create object of the web service class and consume the web methods with proper exception handling, like a normal invocation. In the background the proxy will invoke the web service and reply to the requests.

Tools for web services in .NET
The tools provided by Microsoft for these are:

Web Service Development Kit (WSDK)
Soap toolkit
Office XP web service toolkit
WSDL verification tool
WSDL browser tool
Microsoft Visual Studio.NET
WebServiceUtil
UDDI SDK

Important tools

MSXML parsers: It is the default parser available with the Microsoft product. It contains a class XMLDOM, which is enriched with methods, properties, and fields.

XML Schema Toolkit for XML binding: At design time, the XML Schema Definition Tool allows you to either generate a set of C# or Visual Basic classes from an XML Schema or generate an XML Schema from a set of classes (DLL or EXE). At run time, the XmlSerializer class allows you to serialize graphs of objects to XML and deserialize graphs objects from XML.

XML Messaging XMI,XSD: XML Messaging Interface (XMI). The XMI describes the data structures of elements and attributes that make up the services and the XML commands used to retrieve and modify user data stored in the services, including support for advanced queries and data synchronization and caching. XML Schema Definition (XSD) describes the data structures of these documents.

Registry tools (.NET UDDI Server, UDDI SDK, VS.NET): Initially, Microsoft had the discovery of Web Services with DISCO in the form of a discovery (DISCO) file. A published DISCO file is an XML document that contains links to other resources that describe the Web Service. In addition to providing a .NET UDDI server, the UDDI SDK provides support for Visual Studio .NET and depends on the .NET framework. Products such as Microsoft Office XP offer support for service discovery through UDDI.

Developing Web Services in JAVA

Web Services can be categorized in two types

RPC Oriented
Synchronous communication
Tightly Coupled: client must find recipients, and know the method arguments
No persistence
Message Oriented
Point-to-point SOAP communication
JAXM Provider (like a "messaging server")

Creating Web services
Java Web services can be created in the following scenarios

Create a web service for a given wsdl: There are tools, which can generate a dummy implementation of the service for a given wsdl.
Create a service and generate the wsdl for the service
JWS file
A JWS file is the simplest type of web service backend and is a good choice when you have the source code for a service class and the service does not require custom data type mappings. A JWS file is a Java source file with the .jws extension, which you can dynamically deploy as a web service. It is automatically compiled much like a JSP is. You can dynamically deploy a Java class as a web service by placing the source file in a web-accessible web application directory (not WEB-INF or META-INF) and changing the file extension to .jws. The JWS file is automatically compiled to class and converts SOAP calls into Java method calls. JWS is a good choice for simple web services, but you cannot use custom data type mappings for Java to and from XML. The WSDL will get automatically generated when we say
http://< location of service for jws >?wsdl

Java class file
A Java class is a good choice for a web service backend when you do not have the source code for the service class or the service class takes operation (method) parameters that are not basic data types. To deploy a Java class, you must create an RPC-style service element that specifies a provider value of java:RPC in the web application's server-config.wsdd file; for example:

<service name="SampleJavaClassService" provider="java:RPC">
<parameter name="methodName" value="*"/>
<parameter name="className" value="SampleJavaClass"/>
</service>
Stateless session bean
Stateless session bean is a good choice for a web service backend when you want to provide container-managed transactions or the session bean acts as a facade to an entity bean.

To deploy a stateless session bean, you must create a service element that specifies a provider value of java:EJB in the web application's server-config.wsdd file; for example:

<service name="SampleLoanEjbService" provider="java:EJB">
<parameter name="allowedMethods" value="calculate"/>
<parameter name="jndiPassword" value="Password"/>
<parameter name="homeInterfaceName"
value= "ejbeans.SampleLoanHome"/>
<parameter name="jndiUser" value="User"/>
</service>
There are tools, which can generate wsdl for a given bean or a java class

Consuming Web Servics:
You can create either proxy or dynamic clients that invoke web service operations. A proxy client calls methods on a local proxy generated from the WSDL file for a specific web service. The proxy object handles interaction with the remote web service. You use the tools provided by the vendors to convert a WSDL file to generate proxies. A dynamic client is a JSP or Java class that invokes operations by directly calling the client API.

Publishing Web Services:
After Creating the Web Service you can publish your Service in either in your own private UDDI or a Public UDDI. The following are Operations on registry

To submit and store shared information
To identify, name, describe, classify, relate, group, and associate shared information
To query, discover and retrieve shared information
Toolkits for Developing Web Services:

Web Services Pack (Sun Microsystems)
Idoox WASP Tools (Idoox)
EBYZ Toolkit (ebyz)
Web Services Studio (Iopsis)
Web Services Toolkit (IBM Alphaworks)
GLUE Platform (The MindElectric)
CapeConnect (Capeclear)
XMLBus (IONA)
There are Tools, which can generate a WSDL file for a given Java Class file (Web Service) and back to Java classes for a given WSDL file. The clients that we write using the generated stubs from the WSDL file will communicate with the Web Service using SOAP. The Technologies which java uses to support web services are briefed below

Java Architecture for XML Parsers (JAXP) defines Pluggable Framework for Parsers and Transformers, parsers include Simple Api for XML (SAX) and Document Object Model (DOM), Transformers include transforming XML documents using XSL /XSLT.

Java Architecture for XML Binding (JAX Black Eye

defines a mapping between Java classes and XML Documents.

Java Architecture for XML Messaging (JAXM) defines the way Java support for sending and receiving SOAP Messages (synchronous/asynchronous) reliably on multiple transports (HTTP/SMTP, etc).

Java Architecture for XML-RPC (JAX-RPC) defines API for web services and client using Remote Procedure Calls.

Java Architecture for Registry (JAXR) defines the Interfaces to registries of XML business data such as Universal Description, Discovery Integration (UDDI).

Thus the SOAP Server / Layer is a combination of the above-mentioned technologies where SOAP Messages can be (JAXM / JAX-RPC), these messages are parsed using JAXP and converted into appropriate java objects using JAXB. Tools, which convert a Java class files to a WSDL file and vice versa also use JAXP and JAXB. Web services are supported in a J2EE 1.3 or J2EE 1.4 using the above technologies. The following is a list of J2EE servers, which support Web Services.

Macromedia JRun 4
Bea Weblogic 7
Oracle 9i As
IBM Websphere 4
Sybase EAServer
Sun [ONE] Application Server
Borland Enterprise Server
Tomcat with axis engine and jboss server
Comparison of Web services in .NET & J2EE

J2EE .NET
Already existing Java classes and java beans/EJBs can be exposed as webservices without any change to their code. & J2EE Existing classes need changes to become a webservice. Alternatively they need to be written from scratch.
Application server tiers still communicate using RMI or RMI/IIOP Tiers communicates using COM plumbing, or through remoting mechanism
Support for web service is another tier in the already existing Java framework Re-architecture of Distributed Computing Environment has led to Web services in Microsoft.
Philosophy
Language-centric framework, platform independent Platform-centric framework, language independent
Proven enterprise application platform, can be built over existing business Major changes required to existing components
Business
Open Standard Process (JCP) Based on open standard
Multi vendor solution Moving towards multi vendor by compact environment
Multi platform Single platform

The technological differences between J2EE and .NET are listed below

Technology
J2EE .NET
Migration Java Programming Language C#, others translated to MSIL (Microsoft Intermediate Language)
Existing System Integration Portable Client and server side wrappers for MTS COM, COM+ is provided. SOAP toolkit used convert other components to .NET components.
Web Services Connectors Host Integration Server, BizTalk

Data Services Servlets, JSP System. Web Services, ASP.NET
Messaging JDBC & JNDI ADO.NET & Directory Services
Remote Objects JMS, Java Mail System. Messaging, CDO
XML Support RMI, CORBA & EJB DCOM, System.Runtime.Remoting

Conclusion
There is a development environment shift from client centric applications towards server centric services as it encourages automated business integration, and a platform neutral, and language neutral new era of distributed applications. Having a clearer idea of the technology as well as the frameworks provided by Sun and Microsoft will help make better decisions while choosing products, technologies and designing applications. Calsoft has the necessary infrastructure and expertise in providing web service-based solutions for client needs.

Download this document
MS Word Format [16.8 k Zipped]

Want to learn more? Contact CSWL for Additional information.

话题树型展开

人气	标题	作者	字数	发贴时间
3679	Comparison of Microsoft and Java Frameworks	SNIX	23224	2003-12-17 22:14

已读帖子

新的帖子

被删除的帖子