2. Agenda:
What is Axis2
Key Features of Axis2 over Axis 1.x
Axis2 Data Bindings
Axis2 Architecture
Sample Axis2 Client with WS Header
Implementation of Axis2 Client
Web Services Intro (SOAP,WSDL,UDDI)
REST
3. Apache Axis2:
• Apache Axis2 is an open source Web Services /SOAP
engine.
• Apache Axis2 is the next generation Web services stack
which is built on a new architecture.
Axis2 1.0 was released in May 2006 and it has come a
long way since its Apache Axis and Apache SOAP
origins.
• Axis2 is more efficient, more modular, more scalable,
and more XML-oriented than the older version.
• It supports - SOAP, REST, WSDL 1.1 & 2.0
• Spring support- Axis2 has built-in support for Spring
services Framework
• Various transports support- Axis2 supports HTTP,
SMTP, TCP, and JMS.
4. Axis2 Key Features:
Speed - Axis2 has greater speed than Apache Axis 1 as it uses its own
object model and StAX (Streaming API for XML) parsing.
Low memory footprint - For greater flexibility, Axis2 was designed with
low memory footprint.
AXIOM - AXIOM is the lightweight object model of Axis2 used for
enhanced, superior performant and developer convenient message
processing service.
Hot Deployment - A new service can be added in Axis2 without having to
shut down the server. For doing this, users need to simply drop the required
Web service archive into the services directory in the repository. The
deployment model will automatically deploy the service.
Asynchronous Web services - Axis2 now supports asynchronous Web
services & asynchronous Web services invocation using non-blocking
clients and transports.
MEP Support - With its in-built support for basic Message Exchange
Patterns (MEPs), Axis2 is quite capable in message handling.
Flexibility - Axis2 is more flexible now as it enables developers to insert
extensions into the engine for custom header processing, system
management, and many more features.
5. Axis2 Key Features (cont.)
Stability - Axis2 is more stable than its previous versions as it defines a more
rigid set of interfaces that does not need to change frequently.
Component-Oriented Deployment - You can easily define reusable
networks of Handlers to implement common patterns of processing for your
applications, or to distribute to partners.
Transport Framework - We have a clean and simple abstraction for
integrating and using Transports (i.e., senders and listeners for SOAP over
various protocols such as SMTP, FTP, message-oriented middleware, etc),
and the core of the engine is completely transport-independent.
WSDL support - Axis2 supports WSDL allowing users to easily build stubs
to access remote services, and also to automatically export machine-readable
descriptions of your deployed services from Axis2.
Add-ons - Several Web services specifications have been incorporated
including WSS4J for security (Apache Rampart), Sandesha for reliable
messaging, Kandula which is an encapsulation of WS-Coordination, WS-
Atomic Transaction and WS-Business Activity.
Composition and Extensibility - Axis2 is supported with improved
composition and extensibility allow to add support for new WS-*
specifications in a simple and clean manner. They are however not hot
deployable as they change the overall behavior of the system.
5
10/7/2012
6. Data binding in Axis2 :
Axis2 is based on a completely new architecture and has been rewritten from scratch. That makes
Axis2 very flexible. For instance the data binding that is responsible for the serialization of Java objects
into XML is not limited to one technology.
Data Binding Description
ADB ADB (Axis Data Binding) – is Simple and light weight Framework but doesn't
compile/cover all XML Schema functions such as Complex Type Extensions and
Restrictions.
XML Beans Offers the most comprehensive XML Schema support
XML Beans claims that it supports the complete schema specification, and it is preferred
if full schema support is needed.
JAXB-RI JAXB2 support has been added in a similar manner to XML Beans and serves as another
option for the user
JiBX Allows the use of POJOs without any modifications. A mapping defines how the
POJOs are serialized to XML.
JiBX differs from the other data binding techniques supported by Axis2 in that it allows
you to use your own Java data objects (as opposed to Java data objects generated from a
schema definition)
6
10/7/2012
7. Axis2 Architecture/Overview:
Axis2 architecture separates the logic and the states.
Code that does the processing does not have a state inside
Axis2. This allows code to be executed freely by parallel
threads.
Axis2 architecture is modular. Therefore, Axis2
Framework is built up of core modules that collectively
make up the core architecture of Axis2. Non-core/other
modules are layered on top of these core modules.
8. Axis2 Architecture Overview:
The Axis2 architecture is implemented using seven independent modules:
1) Information model: This module manages the state of the SOAP engine.
This model defines a collection of classes for holding the state, and the engine
manages the life cycle of these information objects. The Information model has
two types of classes for holding the state. The Description classes hold data
that is static in nature and exists throughout the life of the Axis engine
instance, such as configuration of transports, services, and operations.
Context classes hold dynamic information of the service and operation that are
valid on the context of an invocation, such as the current request and response
SOAP message, From address, To address, and other elements.
8
9. Axis2 Architecture Overview:
2) XML Processing Model: Axis2 introduces a new object model
called AXIOM(AXIs Object Model) for processing SOAP messages.
AXIOM uses StAX (Streaming API for XML) to parse the XML.
StAX is a standard streaming pull parser.
Pull parsing is a recent trend in XML processing.
The previously popular XML processing frameworks such as SAX
and DOM were "push-based" which means the control of the parsing
was in the hands of the parser itself. This approach is fine and easy to
use, but it was not efficient in handling large XML documents since
a complete memory model will be generated in the memory.
Pull parsing inverts the control and hence the parser only proceeds at
the users command. The user can decide to store or discard events
generated from the parser.
AXIOM is very lightweight and does deferred building of the XML
infoset - in other words, an object is created only when it is
absolutely necessary.
Deferred building is the ability of AXIOM to partially build the object model
while the rest of the model is built based the user's needs. 9
10. Axis2 Architecture Overview (cont.)
3) SOAP processing model: Axis2 architecture defines two pipes (or Flows) called
InPipe (InFlow) and OutPipe (OutFlow) for handling request messages and response
messages on the server side. On the client side, the pipes are inverted -- in other words,
the SOAP request message flows through the OutPipe and the response message flows
through the InPipe.
A pipe or flow contains a series of handlers grouped into phases. The phases are
executed in a predefined order. In addition to the set of predefined phases and handlers,
users can configure user phases and associated handlers at the operation, service, or
global level. Handlers act as interceptors of the SOAP message and can process the
header or body of the SOAP message.
The InPipe is configured with the following phases:
TransportIn, PreDispatch, Dispatch, PostDispatch, PolicyDetermination, User phases,
Message validation
Passing through all the phases configured in the Inpipe, the request message reaches the
MessageReceiver, which then invokes the actual service implementation.
The OutPipe of the server has the following phases:
Message initialization, Policy determination, User phases, MessageOut
The user-configured phase comes in the User phases section of both these pipes. When
a fault occurs during the execution of these pipes, the faults goes through InFaultPipe
or OutFaultPipe pipes. InFaultPipe is invoked on the client side when the Fault message
is received; the OutFaultPipe is invoked on the server side when an invocation causes a
fault to be sent to the client. The user can add handlers to the predefined phases and 10
configure in what order the handlers should be run. 10/7/2012
11. Axis2 Architecture Overview (cont..)
When a SOAP message is being sent through the Client API, an Out Pipe activates. The Out Pipe
will invoke the handlers and end with a Transport Sender that sends the SOAP message to the
target endpoint.
The SOAP message is received by a Transport Receiver at the target endpoint, which reads the
SOAP message and starts the In Pipe. The In Pipe consists of handlers and ends with the
Message Receiver, which consumes the SOAP message 11
10/7/2012
12. Axis2 Architecture Overview (cont.)
Extensible messaging engine:Axis2 engine is a pure SOAP processor and doesn't depend
on any Java-specific specification. For example, JAX-WS will be implemented as a layer
on top of Axis2 and won't leak into the core.
Once a message is received by the engine through a transport, the engine calls the
preregistered set of interceptors called handlers. Handlers normally process the
information inside the SOAP headers, although they have no limitations on processing
other parts of the message as well. The message is then handed to a message receiver -
the ultimate recipient of the message. The message receiver also is responsible for
dealing with the message accordingly, and most of the time will hand this message to a
service implementation class for processing.
Piping model of Axis2:
The combination of the variable number of in and out pipes enables Axis2 to handle
any MEP. For example, one in pipe and one out pipe can be used to enable an in-out
interaction. One in pipe can be used to enable in-only interaction.
The inside of every Axis2 pipe is divided logically into areas called phases.
Phases are a logical set of handlers in a pipe.
These phases are named to represent what happens to a message during that phase. 12
10/7/2012
13. Axis2 Architecture (cont)
4)Deployment Model: The Deployment Model provides a concrete mechanism to
configure Axis2. This model has three entities that provide the configuration.
The axis2.xml file
This file holds the global configuration for the client and server, and provides the following
information:
The global parameters, Registered transport-in and transport-outs
User-defined phase names, Modules that are engaged globally (to all services)
Globally defined Message Receivers
Service Archive
The Service archive must have a META-INF/services.xml file and may contain the dependent
classes. Please see modules/kernel/resources/services.xsd in the source distribution for the
schema for services.xml. The services.xml file has the following information.
Service level parameters, Modules that are engaged at service level
Service Specific Message Receivers, Operations inside the service
Module Archive
Module archive must have a META-INF/module.xml file and dependent classes. The module.xml
file has Module parameters and the Operations defined in the module.
When the system starts up, Axis2 prompts the deployment model to create an Axis
Configuration. The deployment model first finds the axis2.xml file and builds the global
configuration. Then it checks for the module archives and then for the service archives. After
that, the corresponding services and modules are added to the Axis Configuration. The system
will build contexts on top of the Axis Configuration. After this, Axis2 is ready to send or receive
SOAP messages. Hot deployment is only allowed for services.
13
10/7/2012
14. Axis2 Architecture Overview (cont…)
5) WSDL and code generation: This module takes care of generating client stub and
server skeleton code from the WSDL file. The Axis2 code generator emits XML files
that are applied with the correct XML style sheets to generate code in the needed
language.
6) Client API: The Axis2 client API invokes operations following In-Only and In-
Out message patterns defined by WSDL 2.0. The client API supports both blocking
and non-blocking invocation of In-Out operations.
Axis2 can invoke a web service in two ways. The ServiceClient API is the easiest to
use but gives the user less control. The OperationClient API provides a great deal of
control during an invocation. Both APIs have built-in support for basic in-out and in-
only MEPs.
Axis2 now supports both blocking and nonblocking invocation models.
Nonblocking invocations are useful in designing user interfaces and when service
invocations take a lot of time.
7) Transports: This module contains handlers that interact with the transport layer.
There are two types of transport handlers, TransportListener (TransportReceiver )and
TransportSender.
The TransportListener receives the SOAP message from the transport layer and
passes it to the InPipe for processing. TransportSender sends the SOAP message
received from the OutPipe over the specified transport.
Axis2 provides handlers for HTTP, SMTP, and TCP. For HTTP transport, the
AxisServlet on the server side and a simple standalone HTTP server (provided by 14
Axis2) on the client side work as the TransportReceiver. 10/7/2012
16. Pluggable module architecture
Modules provide an extension mechanism to the server. Each module in Axis2
contains a set of related handlers. For example, a WS-Addressing module will contain
a set of handlers for WS-Addressing support for the Axis2 engine. An Axis2
administrator can add WS-Addressing support to an Axis2 engine by downloading a
WS-Addressing module and deploying it in the Axis2 engine. The module.xml file
contains rules to designate which pipe and phase the handlers should go in.
The module is useful because if you need support for a WS-*, the proper module can be
downloaded and deployed without worrying about where the handlers should go. Modules have
the .mar extension to denote module archive. Following are several modules supporting WS-*
specifications that have already been built:
Sandesha2 module: Provides WS-Reliable Messaging support
WS-Addressing module: Provides WS-Addressing support for Axis2
Rampart and Rahas modules: Provide WS-SX (security-related specifications) support
Kandula module: Provides WS-AT support
Savan module: Provides WS-Eventing support 16
10/7/2012
17. Axis2 Sample Client code:
public class ViewAppt_Axis2_Test_Client {
// define global constants
public static final String APP_ID="APP_ID";
public static final String IP_ADDR=“IP_ADDR";
public static final String SOURCE_ID="SOURCE_ID";
public static final String USER_NM="USER_NM";
public static final String PASSWORD="PASSWORD";
public static final String SUB_HEADER="SubHeader";
public static final String EMPTY_STR="";
public static void main(String[] args) throws OPVException {
// define endpoint URL
String endPointAddress = "http://tonemq2:17083/ViewAppointmentWSPort";
// create stub with endpoint URL
EnterpriseSchedulingServicesStub stub = EnterpriseSchedulingServicesStub (endPointAddress );
// set timeout to stub
stub._getServiceClient().getOptions().setTimeOutInMilliSeconds(5000);
// add header to stub
stub._getServiceClient().addHeader(getSubHeader());
// get the request Document object
ViewAppointmentsRequestDocument requestDoc = getDataWithRequestDocument();
17
10/7/2012
18. Axis2 Sample Client code (cont.)
// call the web service operation from stub and get the Response Document
ViewAppointmentsResponseDocument respDoc = stub.viewAppointment(requestDoc, null);
// get the Response object from ResponseDocument object
ViewAppointmentsResponse response= respDoc.getViewAppointmentsResponse();
// get the first Name of customer from response
if( null != response ) {
String firstName = response.getConfirmationInfoArray(0).getSchedulingInfoArray(0).
getPersonInfo(). getDemographicInfo().getName().getFirstName();
System.out.println("First Name:"+ firstName);
}
// print the response object
response.save(System.out);
}
18
10/7/2012
19. Adding Header in Axis2:
public static OMElement addHeader(){
// define constants
public static final String APP_ID ="APP_ID";
public static final String IP_ADDR =“IP_ADDR";
public static final String SOURCE_ID ="SOURCE_ID";
public static final String USER_NM ="USER_NM";
public static final String PASSWORD ="PASSWORD";
public static final String SUB_HEADER ="SubHeader";
public static final String EMPTY_STR ="";
// create OMFactory instance
OMFactory omFactory = OMAbstractFactory.getOMFactory();
// create OMElement for App Id
OMElement appId = omFactory.createOMElement( APP_ID, EMPTY_STR, EMPTY_STR);
// set value for App Id
appId.setText("ES");
// create OMElement for IP Address
OMElement ipAddr = omFactory.createOMElement(IP_ADDR, EMPTY_STR,EMPTY_STR);
// set value for IP Address
ipAddr.setText("10.10.0.12");
// create OMElement for Source Id
OMElement sourceId = omFactory.createOMElement(SOURCE_ID, EMPTY_STR,EMPTY_STR);
// set value for Source Id
sourceId.setText("Source001"); 19
10/7/2012
20. Adding Header in Axis2(cont.)
// create OMElement for Username
OMElement userName = omFactory.createOMElement (USER_NM, EMPTY_STR, EMPTY_STR);
// set value for username
userName.setText("walgreens");
// create OMElement for password
OMElement password = omFactory.createOMElement (PASSWORD, EMPTY_STR, EMPTY_STR);
// set value for password
password.setText("********");
// create OMElement for sub Header
OMElement subHeader = omFactory.createOMElement (SUB_HEADER, EMPTY_STR, EMPTY_STR);
// add elements to SubHeader object
subHeader.addChild(appId);
subHeader.addChild(ipAddr);
subHeader.addChild(sourceId);
subHeader.addChild(userName);
subHeader.addChild(password);
return subHeader;
}
20
10/7/2012
21. Adding WS Security Header in Axis2:
private OMElement addHeader() throws AxisFault {
// define schema namespace constants
private static final String SOAP_HEADER_SECURITY_NAMESPACE =
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
private static final String SOAP_HEADER_USER_TOKEN_NAMESPACE =
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
private static final String SOAP_HEADER_PASSWORD_TYPE_NAMESPACE =
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText";
// create OMFactory instance
OMFactory omFactory = OMAbstractFactory.getOMFactory();
// create OMElement for Security Header
OMElement omSecurityElement = omFactory.createOMElement(
new QName(SOAP_HEADER_SECURITY_NAMESPACE, “Security”, “wsse”));
// add mustUnderstand attribute to Security Header
omSecurityElement.addAttribute("mustUnderstand","1", null);
// create UsernameToken element
OMElement omUsertoken = omFactory.createOMElement(
new QName("", “wsse:UsernameToken));
// declare namepsace for UsernameToken element
21
omUsertoken.declareNamespace(SOAP_HEADER_USER_TOKEN_NAMESPACE,”wsu”); 10/7/2012
22. Adding WS Security Header in Axis2(cont.)
// create Username element
OMElement omUserName = omFactory.createOMElement (
new QName (“ ”, “wsse:Username”, wsse”));
omUserName.setText("6345/StgWag1");
// create password element
OMElement omPassword = omFactory.createOMElement (
new QName (“”, “wsse:password”, “wsse”));
omPassword.addAttribute( PASSWORD_TYPE,SOAP_HEADER_PASSWORD_TYPE_NAMESPACE, null );
//set the password value
omPassword.setText("*********");
// add the userName & Password elements to UsernameToken element
omUsertoken.addChild(omUserName);
omUsertoken.addChild(omPassword);
// add UsernameToken element to SecurityHeader element
omSecurityElement.addChild(omUsertoken);
return omSecurityElement; 22
} 10/7/2012
23. Get the RequestDocument with data:
// This method returns ReuestDocument object
private ViewAppointmentsRequestDocument getDataWithRequestDocument(){
// create RequestDocument object instance from Factory
ViewAppointmentsRequestDocument requestDocument =
ViewAppointmentsRequestDocument.Factory.newInstance();
// create Request object instance from Factory
ViewAppointmentsRequest request =
ViewAppointmentsRequest.Factory.newInstance();
// Create MessageInfo, SourceSystem, AppointmentInfo objects
MessageInfo messageInfo = MessageInfo.Factory.newInstance();
SourceSystem sourceSystem = SourceSystem.Factory.newInstance();
AppointmentInfo appointmentInfo = AppointmentInfo.Factory.newInstance();
// set confirmation Number to AppointmentInfo object
appointmentInfo.setConfirmationNumber("2F9VCYLQ");
// set Name to SourceSystem object
sourceSystem.setName("EC");
// set SourceSystem object to MessageInfo object
messageInfo.setSourceSystem(sourceSystem);
23
10/7/2012
24. Get the RequestDocument with Data (cont.)
// create PersonInfo, DemographicInfo objects
PersonInfo personInfo = PersonInfo.Factory.newInstance();
DemographicInfo demographicInfo =DemographicInfo.Factory.newInstance();
// set DateofBirth to DemographicInfo object
demographicInfo.setBirthDate(new GregorianCalendar().set(1980, 03,25) );
// set SourceSystem object to PersonInfo object
personInfo.setSourceSystem(sourceSystem);
// set DemographicInfo object to PersonInfo object
personInfo.setDemographicInfo(demographicInfo);
// set MessageInfo, PersonInfo, AppointmentInfo objects to Request object
request.setMessageInfo(messageInfo);
request.setPersonInfo(personInfo);
request.setAppointmentInfo(appointmentInfo);
// set Request Object to RequestDocument object
requestDocument.setViewAppointmentsRequest(request);
return requestDocument;
}
24
10/7/2012
25. Implementation in ecomm:
Down load Axis2 plug-ins for eclipse from Apache website and place them in plugins folder
of eclipse. Check plugins are loaded properly or not by following:
File New Other Axis2 Wizards, then you can see Axis2 Code Generator and Axis2
Service Archiver plugins.
25
10/7/2012
26. Implementation in ecomm:
Select the appropriate option , Our task is generate java source code from WSDL so first
option is right option for us.
26
10/7/2012
28. Implementation in ecomm:
Select Codegen option as custom and Databinding Name as xmlbeans and make sure
Generate client side code checkbox is selected.
Click Next and select output path it will generate the all axis2 client side classes.
28
10/7/2012
31. Using WSDL2Java command line task
in Axis2:
wsdl2java.bat -uri C:MyDevAxis2WorkspaceAxis2_POC_1WebContentwsdl
EnterpriseSchedulingServices.wsdl -p com.walgreens.opv.axis2.client.stubs
-d xmlbeans -s -o C:MyDevAxis2WorkspaceAxis2_POC_1
-p <package name> The target package name. If omitted, a default package (formed using the
target namespace of the WSDL) will be used.
-d <databinding> Specifies the Databinding framework. Valid values are xmlbeans, adb, jibx,
and none. Default is adb.
-s -- sync Generate code only for sync style . When this option is used the generated stubs will
have only the synchronous invocation methods.
-o <output Location> Output file location. This is where the files would be copied once the
code generation is done. If this option is omitted the generated files would be copied to the
working directory.
32. Lessons Learned from Axis2
1) From WSDL, not able to generate multiple port
operations but Axis 1.4 does.
2) Date issue in Calendar Object is resolved.
3) Does more schema/xml validation in request and
response, It avoids extra elements which are not
used.
33. MEP-Message Exchange Pattern
Message Exchange Patterns:
Messaging pattern is a network-oriented architectural pattern which describes
how two different parts of a message passing system connect and communicate
with each other.
Although all SOAP messages carry the same structure, the ways in which
they are used can be combined into a number of different "message
exchange patterns", . The two major message exchange patterns are:
In-Out: in this MEP, the client sends a SOAP message to the server, which
processes the message and sends a response back. This is probably the most
commonly used MEP, and is useful for tasks such as searching for
information or submitting information in situations in where
acknowledgment is important.
In-Only: In this MEP, the client sends a message to the server without
expecting a response. You may use this MEP for activities such as pinging a
server to wake it up, reporting logging information for which you do not
need an acknowledgment and so on.
33
10/7/2012
34. What is Web Service?
A Web Service is any service that
– is available over the web
– uses standardized XML messaging
– is OS and Programming language
independent
35. Web Services Architecture
There are two ways we can view Web Services
architecture
1. Web Service Roles
2. Web Service Protocol Stack
36. Web Service Roles
There are three major roles
Logically Centralized directory
of services
Service
Registry
2) Discover services 1) Register service
3) Invoke service
Service Service
Requestor Provider
Consumer of the Web Service Provider of the Web Service
37. Web Service Protocol Stack
Discovery UDDI
Responsible for centralizing services
Description WSDL
Responsible for describing the public
interface to a specific web service
XML Messaging XML-RPC, SOAP, XML
Responsible for encoding messages in
common XML format
Transport HTTP,SMTP,FTP,BEEP
Responsible for transporting messages
38. XML Messaging
There are two ways of XML Messaging
• XML- RPC
• SOAP
What is XML-RPC ?
is a simple protocol that uses XML messages to
perform RPC
Request are encoded in XML and send via HTTP
Response are encoded in XML and received via
HTTP
is a easiest way to get started with web services
41. What is SOAP?
Simple Object Access Protocol
SOAP is slightly more complicated than
the XML-RPC
SOAP extended XML-RPC
It uses XML namespaces and XML
Schemas.
42. SOAP Message
SOAP Message Envelope is like a
wrapper for content
Envelope
Header is a optional
element that could
Header contain control
information
Body element includes
Body requests and responses
Body element will
include a Fault element
in the event of an error
45. What is WSDL?
Web Services Description Language
Has 6 major elements
1. definitions – defines the name of the web service
2. types – describes all the data types that will be
transmitted
3. message – defines the name of the message that will
be transmitted
4. portType – defines the operations
5. binding – defines how the message will be
transmitted
6. service – defines where the service is located
46. Development plan for Service Requestor
1) Find web service via UDDI
2) Retrieve service description file
3) Create XML-RPC or SOAP client
4) Invoke remote service
47. Development plan for Service Provider
1) Create the core functionality
2) Create XML-RPC or SOAP service wrapper
3) Create service description file
4) Deploy service
5) Register new service via UDDI
48. REST Web Services:
REST stands for Representational State Transfer
REST is an architecture style for designing
networked applications.
RESTful applications use HTTP requests to post
data (create and/or update), read data (e.g., make
queries), and delete data. Thus, REST uses
HTTP for all four CRUD
(Create/Read/Update/Delete) operations.
REST is a lightweight alternative to mechanisms
like RPC and Web Services (SOAP, WSDL, et
al.).
48
10/7/2012
49. InPipe & OutPipe Phases:
Transport Phase - The handlers are in the phase that processes transport specific information
such as validating incoming messages by looking at various transport headers, adding data into
message contexts, etc.
Pre-Dispatch Phase- The main functionality of the handlers in this phase is to populate message
context to do the dispatching. For example, processing of addressing headers of the SOAP
message, if any, happens in this phase. Addressing handlers extract information and put them in
to the message context.
Dispatch Phase - The Dispatchers run in this phase and try to find the correct service and
operation this particular message is destined for.
The post condition of the dispatch phase (any phase can contain a post condition) checks whether
a service and an operation were found by the dispatchers. If not, the execution will halt and return
a "service not found' error.
User Defined Phases - Users can engage their custom handlers here.
Message Validation Phase - Once the user level execution has taken place, this phase validates whether SOAP
Message Processing has taken place correctly.
Message Processing Phase - The Business logic of the SOAP message is executed here. A
Message Receiver is registered with each Operation. This message receiver (associated to the
particular operation) will be executed as the last handler of this phase.
The Out Pipe is simpler because the service and the operation to dispatch are known by the time
the pipe is executed. The Out Pipe may be initiated by the
Message Receiver or the Client API implementation. Phases of the Out Pipe are described below:
Message Initialize Phase - First phase of the Out Pipe. Serves as the placeholder for the custom
handlers.
User Phases - Executes handlers in user-defined phases.
Transports Phase - Executes any transport handlers taken from the associated transport configuration. The last 49
handler would be a transport sender which will send the SOAP message to the target endpoint.
10/7/2012
50. WSDL 2.0
WSDL 1.2 was renamed WSDL 2.0 because of its substantial differences from WSDL
1.1. Some of these changes include:
Adding further semantics to the description language. This is one of the reasons for
making targetNamespace a required attribute of the definitions element in WSDL 2.0.
Removal of message constructs. These are specified using the XML schema type
system in the types element.
No support for operator overloading.
PortTypes renamed to interfaces. Support for interface inheritance is achieved by using
the extends attribute in the interface element.
Ports renamed to endpoints.
50
10/7/2012
51. SOAP 1.1 vs SAOP 1.2
SOAP 1.1 is based on XML 1.0. SOAP 1.2 is based on XML Information Set (XML Infoset).The
XML information set (infoset) provides a way to describe the XML document with XSD schema.
However, the infoset does not necessarily serialize the document with XML 1.0 serialization on
which SOAP 1.1 is based.. This new way to describe the XML document helps reveal other
serialization formats, such as a binary protocol format. You can use the binary protocol format to
compact the message into a compact format, where some of the verbose tagging information might
not be required.
In SOAP 1.2 , you can use the specification of a binding to an underlying protocol to determine
which XML serialization is used in the underlying protocol data units.
SOAP 1.2 provides the ability to officially define transport protocols, other than using HTTP, as
long as the vendor conforms to the binding framework that is defined in SOAP 1.2. While HTTP is
ubiquitous, it is not as reliable as other transports including TCP/IP and MQ.
SOAP 1.2 provides a more specific definition of the SOAP processing model that removes many of
the ambiguities that might lead to interoperability errors in the absence of the Web Services-
Interoperability (WS-I) profiles. The goal is to significantly reduce the chances of interoperability
issues between different vendors that use SOAP 1.2 implementations.
SOAP with Attachments API for Java (SAAJ) can also stand alone as a simple mechanism to issue
SOAP requests. A major change to the SAAJ specification is the ability to represent SOAP 1.1
messages and the additional SOAP 1.2 formatted messages. For example, SAAJ Version 1.3
introduces a new set of constants and methods that are more conducive to SOAP 1.2 (such as
getRole(), getRelay()) on SOAP header elements. There are also additional methods on the factories
for SAAJ to create appropriate SOAP 1.1 or SOAP 1.2 messages.
Java Architecture for XML Web Services (JAX-WS) introduces the ability to support both SOAP
1.1 and SOAP 1.2. Because JAX-RPC introduced a requirement to manipulate a SOAP message as
it traversed through the run time, there became a need to represent this message in its appropriate
SOAP context. 51
10/7/2012
52. Summary
Axis2
– Architecture of Axis2
– Features of Apache Axis2
– Implementation of Axis2
Web Service
– Roles in Web Services
– Web Services Protocol Stack
– Different ways of XML Messaging
– Development plan for Service Requestor and Provider
– REST
