Very very short history of web services follows,
RPC was there for a very long time and it brought forth
CORBA: allowed distributed software components to collaborate with a language and platform-neutral RPC specification.
RMI: java's version of RPC
DCOM: microsoft version, allowed native Windows programs to interact.
Then came XML,
In 1998, XML-RPC was advocated by Microsoft as a truly open technology leveraging the web infrastructure.
XML-RPC is essentially a remote procedure call protocol which uses XML format to encode its calls,
and HTTP as a transport mechanism.
XML-RPC evolved into a more elaborate SOAP specification.
Then came a need to standardize the service interface and a specification came into being known as WSDL and
UDDI became the standard for registering and finding web services on the Web.
Differences between JAX-RPC and JAX-WS
Short version follows, longer version here:
First came JAX-RPC 1.0, after a few months of use, the Java Community Process (JCP) folks who wrote that specification realized that it needed a few tweaks, so out came JAX-RPC 1.1. After a year or so of using that specification, the JCP folks wanted to build a better version: JAX-RPC 2.0.
A primary goal was to align with industry direction, but the industry was not merely doing RPC web services, they were also doing message-oriented web services. So "RPC" was removed from the name and replaced with "WS" (which stands for web Services, of course).
Thus the successor to JAX-RPC 1.1 is JAX-WS 2.0 - the Java API for XML-based web services.
| JAX-RPC | JAX-WS | |
| SOAP | SOAP 1.1 | SOAP 1.1, SOAP 1.2 |
| XML-HTTP binding | No | Yes |
| WS-I's Basic Profile (BP) | BP 1.0 | BP 1.1 |
| Java/J2ee/Web services | 1.4/1.4/1.2 | 1.5/1.5/1.3 |
| Data mapping model | Not based on standard, own mechanism | JAXB |
| Interface mapping model | Adds new functionality | |
| Dynamic models | Only client could be dynamic | Both client and server could be dynamic |
| Async | No | Yes |
| MTOM | No | Yes |
| Handler model (SAAJ) | SAAJ 1.2 | SAAJ 1.3 |
Migrate from JAX-RPC to JAX-WS in Websphere: here
Webservices development approaches
You can follow two general approaches to web service development:
In the top-down approach, a web service is based on the web service interface and XML types, defined in WSDL and XML Schema Definition (XSD) files. You first design the implementation of the web service by creating a WSDL file using the WSDL editor. You can then use the Web Service wizard to create the web service and skeleton Java classes to which you can add the required code. You then modify the skeleton implementation to interface with the business logic. The top-down approach provides more control over the web service interface and the XML types used. Use this approach for developing new web services.
In the bottom-up approach, a web service is created based on the existing business logic in JavaBeans or EJB. A WSDL file is generated to describe the resulting web service interface. The bottom-up pattern is often used for exposing existing function as a web service. It might be faster, and no XSD or WSDL design skills are needed. However, if complex objects (for example, Java collection types) are used, the resulting WSDL might be difficult to understand and less interoperable.
JAX-WS programming model
Technologies and standards involved:
Java API for XML Web Services (JAX-WS) 2.2
JAX-WS is the primary API for web services and is a follow-on to the Java API for XML-based Remote Procedure Call (JAX-RPC).
Java Architecture for XML Binding (JAXB) 2.0
JAXB is an XML to Java binding technology that supports transformation between schema and Java objects and between XML instance documents and Java object instances. JAXB consists of a runtime application programming interface (API) and accompanying tools that simplify access to XML documents.
JAXB provides the xjc schema compiler tool, the schemagen schema generator tool, and a runtime framework. You can use the xjc schema compiler tool to start with an XML schema definition (XSD) to create a set of JavaBeans that map to the elements and types defined in the XSD schema. You can also start with a set of JavaBeans and use the schemagen schema generator tool to create the XML schema.
JAXB is a standalone technology and can be used anywhere where you need java to work with xml.
More about architecture and samples:
http://docs.oracle.com/javaee/5/tutorial/doc/bnazg.html
Tutorials:
http://www.vogella.com/tutorials/JAXB/article.html
SOAP 1.2
SOAP was an acronym for Simple Object Access Protocol. Now that meaning is widened. SOAP is just another XML markup language accompanied by rules that dictate its use. SOAP has a clear purpose: exchanging data over networks. Specifically, it concerns itself with encapsulating and encoding XML data and defining the rules for transmitting and receiving that data. In a nutshell, SOAP is a network application protocol.
A SOAP XML document instance, which is called a SOAP message (also called SOAP envelope) is usually carried as the payload of some other network protocol. Most common being HTTP. SOAP messages can also be carried by e-mail using SMTP (Simple Mail Transfer Protocol) and by other network protocols, such as FTP (File Transfer Protocol) and raw TCP/IP (Transmission Control Protocol/Internet Protocol). At this time, however, the WS-I Basic Profile 1.0 sanctions the use of SOAP only over HTTP.
Advantages of SOAP:
1. The SOAP message format is defined by an XML schema, which exploits XML namespaces to make SOAP very extensible.
2. Another advantage of SOAP is its explicit definition of an HTTP binding, a standard method for HTTP tunneling. HTTP tunneling is the process of hiding another protocol inside HTTP messages in order to pass through a firewall unimpeded. Firewalls will usually allow HTTP traffic through port 80, but will restrict or prohibit the use of other protocols and ports.
Basic Structure of SOAP
A SOAP message may include several different XML elements in the Header and Body elements, and to avoid name collisions each of these elements should be identified by a unique namespace. Namespace xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" defines the namespace of the standard SOAP elements—Envelope, Header, and Body.
<soap:envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:header>
<!-- Header blocks go here -->
</soap:header>
<soap:body>
<!-- Application data goes here -->
</soap:body>
</soap:envelope>
More info about structure and rules in Richard Monson-Haefe's book J2EE Web services.
SOAP Messaging modes
A messaging mode is defined by its messaging style(RPC or Document) and its encoding (SOAP encoded or Literal) style.
This gives you four style/use models:
- RPC/encoded
- RPC/literal
- Document/encoded
- Document/literal
SOAP encoding is not supported by WS-Iconformant Web services because it causes significant interoperability problems. So this leaves out RPC/encoded and Document/encoded.
Document/literal has the advantage over RPC/literal that:
- Everything that appears in the soap:body is defined by the schema, so you can easily validate this message.
- Document/literal is WS-I compliant
More about these and their differences
http://www.ibm.com/developerworks/library/ws-whichwsdl/
SOAP with Attachments API for Java (SAAJ) 1.3
SAAJ describes the standard way to send XML documents as SOAP documents over the Internet from the Java platform. It supports SOAP 1.2.
Why SAAJ?
As an XML-based messaging protocol, SOAP messages require considerable processing power and memory. All parts of a SOAP message must conform to XML rules for allowed characters and character sequences so binary data can not be included directly. Furthermore, SOAP implementations typically parse the entire SOAP message before deciding what to do with the contents, so large data fields could easily exceed available memory. For all these reasons it was recognized that SOAP requires some mechanism for carrying large payloads and binary data as an attachment rather than inside the SOAP message envelope. -Wikipedia
Differences between SOAP versions: here
Overview and tutorial: Oracle Docs
SAAJ could be used with servlets to communicate SOAP messages (instead of using JAX-WS). A sample here.
SAAJ is not used nowadays. Instead JAX-WS + MTOM takes care of most of the needs.
Streaming API for XML (StAX) 1.0
StAX is a streaming Java-based, event-driven, pull-parsing API for reading and writing XML documents. StAX enables you to create bidirectional XML parsers that are fast, relatively easy to program, and have a light memory footprint.
StAX is also a seperate API that works well with JAX-WS.
http://www.vogella.com/tutorials/JavaXML/article.html
http://docs.oracle.com/javase/tutorial/jaxp/stax/using.html
Web Services Metadata for the Java Platform
The Web Services Metadata specification defines Java annotations that make it easier to develop web services. This specification and JAX-WS together provide a comprehensive set of annotations for Java web service and web service client implementations.
Java API for XML Registries (JAXR) 1.0
JAXR provides client access to XML registry and repository servers.
Tutorial: http://www.javaworld.com/article/2074341/soa/discover-and-publish-web-services-with-jaxr.html
Java API for XML Web Services Addressing (JAX-WSA) 1.0
JAX-WSA is an API and framework for supporting transport-neutral addressing of web services.
SOAP Message Transmission Optimization Mechanism (MTOM)
MTOM enables SOAP bindings to optimize the transmission or wire format of a SOAP message by selectively encoding portions of the message, while still presenting an XML infoset to the SOAP application. We will see MTOM in detail later.
Web Services Reliable Messaging (WS-RM)
WS-RM is a protocol that allows messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures.
Web Services for Java EE
Web Services for Java EE defines the programming and deployment model for web services in Java EE servers. It includes details of the client and server programming models, handlers (a similar concept to servlet filters), deployment descriptors, container requirements, and security that vendors need to implement.
The following examples uses Websphere Application server and RAD for application development.
WAS uses a modified version of Apache Axis 2.
Also RAD provides interfaces for generating wsdl (for bottom-up approach) or java code (for top-down approach) by internally using wsgen and wsimport command-line tools.
wsgen and wsimport
JAX-WS provides the wsgen and wsimport command-line tools to generate portable artifacts for JAX-WS web services. When creating JAX-WS web services, you can start with either a WSDL file or an implementation bean class.
If you start with an implementation bean class, use the wsgen command-line tool to generate all the web services provider artifacts, including a WSDL file if requested.
If you start with a WSDL file, use the wsimport command-line tool to generate all the web services artifacts for either the server or the client.
How JAX-WS runtime fits into J2EE?
http://java.boot.by/scdjws5-guide/ch04s06.html
No comments:
Post a Comment