Introduction of Apache Axis2 &

Implementation

- Sreeni Inturi Walgreens –Ecomm Dept

inturis@gmail.com

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

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.

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.

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.

10/7/2012

5

Data binding in Axis2 :

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)

10/7/2012

6

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.

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.

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.

10/7/2012

8

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.

10/7/2012

9

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 configure in what order the handlers should be run.

10/7/2012

10

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

10/7/2012

11

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. 10/7/2012

12

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.

10/7/2012

13

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 Axis2) on the client side work as the TransportReceiver.

10/7/2012

14

SOAP Message process in Axis2:

10/7/2012

15

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

10/7/2012

16

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();

10/7/2012

17

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);

}

10/7/2012

18

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"); 10/7/2012

19

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;

}

10/7/2012

20

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

omUsertoken.declareNamespace(SOAP_HEADER_USER_TOKEN_NAMESPACE,”wsu”);

10/7/2012

21

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;

} 10/7/2012

22

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);

10/7/2012

23

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;

}

10/7/2012

24

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.

10/7/2012

25

Implementation in ecomm: Select the appropriate option , Our task is generate java source code from WSDL so first option is right option for us.

10/7/2012

26

Implementation in ecomm: Browse and specify the correct WSDL location path.

10/7/2012

27

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.

10/7/2012

28

Ant build script: <project name="build" default="makejars" basedir=".">

<property name="lib.dir" value="../lib" />

<property name="build.classes.dir" value="../classes"/>

<property name="wsdl.dir" value="../WebContent/wsdl"/>

<property name="wsdl.filename" value="EnterpriseSchedulingServices.wsdl"/>

<property name="src.generated.dir" value="../"/>

<property name="app.lib.dir" location="../../../APP-INF/lib"/>

<property name="axis.lib.dir" location="C:\Axis2_Info\Axis2_160\axis2-1.6.0\lib"/>

<property name="project.name" value=“Axis2_POC_ViewAppointment"/>

<target name="init"> <mkdir dir="${build.classes.dir}"/> <mkdir dir="${lib.dir}"/> </target>

<target name="clean"><delete dir="${lib.dir}"/><delete dir="${build.classes.dir}"/> </target>

<path id="axis.classpath"><fileset dir="${axis.lib.dir}">

<include name="**/*.jar" /></fileset></path>

<target name="import-wsdl" depends="clean,init">

<java classname="org.apache.axis2.wsdl.WSDL2Java">

<arg value="-uri" /><arg file="${wsdl.dir}/${wsdl.filename}" />

<arg value="-o" /><arg file="${src.generated.dir}" /><arg value="-d"/>

<arg value="xmlbeans"/> <arg value="-ap" /> <classpath refid="axis.classpath" />

</java>

</target>

10/7/2012

29

Ant build script (cont): <target name="import-wsdl-new" depends="clean,init">

<java classname="org.apache.axis2.wsdl.WSDL2Java">

<arg value="-uri" /> <arg file="${wsdl.dir}/${wsdl.filename}" /> <arg value="-o" />

<arg file="${src.generated.dir}" />

<arg value="-d"/> <arg value="xmlbeans"/>

<arg value="-sn"/>

<arg value="EnterpriseSchedulingServices"/>

<arg value="-pn" />

<arg value="CreateAppointmentWSPort" />

<classpath refid="axis.classpath" />

</java>

</target>

<target name="compile" depends="import-wsdl-new">

<javac srcdir="${src.generated.dir}" destdir="${build.classes.dir}"

classpathref="axis.classpath"

debuglevel="lines,vars,source" debug="true" includeAntRuntime="false"/>

</target>

<target name="makejars" depends="compile" >

<jar destfile="${lib.dir}/${project.name}.jar"><fileset dir="${build.classes.dir}"/></jar>

<delete dir="${build.classes.dir}"/>

</target>

</project> 10/7/2012

30

Using WSDL2Java command line task

in Axis2:

wsdl2java.bat -uri C:\MyDevAxis2Workspace\Axis2_POC_1\WebContent\wsdl\

EnterpriseSchedulingServices.wsdl -p com.walgreens.opv.axis2.client.stubs

-d xmlbeans -s -o C:\MyDevAxis2Workspace\Axis2_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.

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.

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.

10/7/2012

33

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

Web Services Architecture

There are two ways we can view Web Services

architecture

1. Web Service Roles

2. Web Service Protocol Stack

Web Service Roles

There are three major roles

Service

Registry

Service

Requestor

Service

Provider

2) Discover services

3) Invoke service

Provider of the Web Service Consumer of the Web Service

Logically Centralized directory

of services

1) Register service

Web Service Protocol Stack

Discovery UDDI

Description WSDL

XML Messaging XML-RPC, SOAP, XML

Transport HTTP,SMTP,FTP,BEEP

Responsible for centralizing services

Responsible for transporting messages

Responsible for describing the public

interface to a specific web service

Responsible for encoding messages in

common XML format

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

Sample XML-RPC Request

<methodCall>

<methodName>

com.wag.pharmacy.sayHello

</methodName>

<params>

<param>

<value>Java</value>

</param>

</params>

</methodCall>

Sample XML-RPC Response

<methodResponse>

<params>

<param>

<value>

<string>Hello Java</string>

</value>

</param>

</params>

</ methodResponse >

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.

SOAP Message

Envelope is like a wrapper for content

Header is a optional element that could contain control information

Body element includes requests and responses

Body element will include a Fault element in the event of an error

SOAP Message

Envelope

Header

Body

Sample SOAP Request

<SOAP-ENV:Envelope

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<SOAP-ENV:Body>

<ns1:sayHello

xmlns:ns1="http://walgreens.com/">

<name xsi:type="xsd:string">Java</name>

</ns1:sayHello>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Sample SOAP Response

<SOAP-ENV:Envelope

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<SOAP-ENV:Body>

<ns1:sayHelloReponse

xmlns:ns1="http://walgreens.com/">

<result xsi:type="xsd:string">Hello Java</result> </ns1:sayHelloResponse>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

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

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

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

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.).

10/7/2012

48

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 handler would be a transport sender which will send the SOAP message to the target endpoint.

10/7/2012

49

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.

10/7/2012

50

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.

10/7/2012

51

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

Resources

Axis2 Architecture - http://axis.apache.org/axis2/java/core/docs/Axis2ArchitectureGuide.html

Web Services & Java home - http://java.sun.com/j2ee/webservices/index.html

Java Web Services tutorial - http://java.sun.com/xml/docs.html#tutorials

SOAP 1.1 - http://www.w3.org/TR/SOAP

WSDL 1.1 - http://www.w3.org/TR/wsdl

Thank you !!!