Why Apache Axis2: The Future of Web...

Colorado Software Summit: October 22 – 27, 2006

Paul Fremantle – Why Apache Axis2 : The Future of Web Services Page 1

© Copyright 2006, WSO2, Inc.

Why Apache Axis2: The Future of Web Services

Paul Fremantle

WSO2 Inc.




About Me ...

Apache Software Foundation - Member

Apache Web Services - PMC Member

Apache Axis2, Axiom – Committer, Release

Manager.

Apache Synapse - Committer

Member of W3C Working Group for WS-

Addressing, WSDL 2.0

Working with WSO2 on Apache Axis2,

Apache Axiom, Apache Synapse and WSO2

Tungsten.




AgendaIntroduction and Motivation

The “big picture”

Key Features of Apache Axis2

High Performance XML Processing Model

Extensible Messaging Engine

Pluggable Module Architecture

Improved Deployment Model

New Client API

Optional Pluggable Data Binding

REST Support

Other Improvements

Summary and Conclusion




A Quick Look At SOAP StacksFirst Generation :: Apache SOAP

First Apache driven SOAP stack

SOAP carries RPC requests & responses in XML form

Apache SOAP

Based on DOM

Slower and memory intensive




A Quick Look …Second Generation :: Apache AXIS

Based on SAX

Introduced the handler architecture for

SOAP stacks

Faster and better than Apache SOAP

Wide Industry Acceptance

Integrated to major application servers like WebSphere and JBoss

Highly Interoperable




Motivations for Apache Axis2

Limitations of handler architecture

Inherent request/response nature

Need for more document centric

interactions

Need for more asynchrony

Need to support new specifications like

WSDL 2.0 and various QoS protocols

WS-A, WS-RM, WS-SX




Motivations for Apache Axis2

• Performance

– Parsers, Optimizing based on use

• Ease of use

– Deployment of new capabilities, service

deployment




Axis2 Architecture - The “big picture”

A x i o m

S T A X

C o r e

E n g i n e Transp

orts

R e p o s i t o r y

R e p o s i t o r y

S e r v i c e s

M o d u l e s

C l i e n t A P I S e r v e r A P I

> > > P h a s e s > > >




Key Features of Axis2

New XML Infoset Representation

Deferred building

StAX integrated

Extensible Messaging Engine

Pluggable Module Architecture


New Client API

Optional Pluggable Data Binding

REST Support




New XML Info-set Representation





Known as AXIOM (Axis Object Model)

Yet another XML object model?

API is more like a simplified DOM

Fundamental Difference ?

Objects are made “on demand” using a pull model

Allows direct access to the underlying pull stream with

or without building the tree

Support for storing binary values

Support for multiple implementations




Axiom Streaming<soap:Envelope>

<soap:Header>

<myNS:Security soap:mustUnderstand=“true”>

</myNS:Security>

</soap:Header>

<soap:Body>

<doSomethingCool>

... MEGABYTES OF DATA HERE ...

</doSomethingCool>

</soap:Body>

</soap:Envelope>

Build object model to here

h = envelope.getHeader(securityQName)

...and then you can do

body = envelope.getBody();

reader = body.getXMLStreamReader();

while (reader.hasNext()) {

...

}





API also provides a StAX parser

interface at any element

Allows the event based navigation of the OM tree.




New XML Infoset Representation

A X I O M

A X I O M

P u l l s t r e a m

P u l l s t r e a mP u s h s t r e a m

P u s h s t r e a m

A P I

R e a d

( t r e e )

A P IW r i t e

( t r e e )

S T A X O M B u i l d e r .

g e t D o c u m e n t E l e m e n t ( )

O M E l e m e n t . g e t C h i l d r e n ( ) e t c

O M F a c t o r y . c r e a t e O M E l e m e n t ( )

O M E l e m e n t . s e r i a l i z e ( )

O M E l e m e n t .

g e t X M L S t r e a m R e a d e r ( )

S A X O M B u i l d e r .

g e t D o c u m e n t E l e m e n t ( )





Faster and Easier Deployment

Service Archive files (.aar files)

A collection of resources needed for a

service

Includes

Service implementation

Handlers (optional)

Service descriptor (services.xml)




Improved Deployment Model (Continued)

Hot Deployment

“Drop in” deployment

Uploaded through

File system

Axis2 web application




Message Receivers

The link between Axis2 and your service application

Either a simple “POJO” MR

Calls a Java object

Or code-generated from WSDL

Part of the WSDL2Java




WSDL2Java

Takes a WSDL

Generates either client or server components

Or both!

Plus an Ant build script

Plus the Services.xml

Java2WSDL

Takes a Java class and generates WSDL for you

Used when dealing with Java clients

Tools




Skeletons

Generates a custom Message Receiver

Plus a “skeleton”

You fill in the code




Pluggable Data Binding

How to provide data binding support ?

Use a well established framework

Avoid reinventing the wheel!

Flexible

Adds more functionalitye.g. XMLBeans supports the complete XML Schema

Features an API that can bind to another data binding framework




Pluggable Data Binding (Continued)

We have Axis data binding (ADB) framework by default.

Sufficient and proven to support simple data binding needs

Currently supported frameworks

XMLBeans, JaxMe, JiBX, ADB, none




New Client API

Supports both blocking and non-blocking

invocations models

Concept of callbacks for the client for non-blocking case

Can handle both transport dependent and

transport independent asynchrony.

Based on the “MEP Client”

Default support to IN only and IN-OUT MEPs

Can be extended to support custom MEPs




New Client API

ServiceClient

• simplest API

• less control

OperationClient

• more control




Stubs

WSDL2Java generates Stubs

New option to support unwrapping

Makes it even easier

Two options

1+n classes (n = number of top level schema elements)

1 (+n inner classes)




The Messaging Engine -

Message Exchange Patterns

Describes the exchange pattern of SOAP messages per given operation.

E.g.

In – Out

In only

In – In – Out !

WSDL 2.0 defines 8 standard MEPs.




The Messaging Engine - Phases

Concept of Phases

A phase is a particular stage in

execution.

e.g. pre-dispatch, Transport

Each Phase contains a group of Handlers

Handlers are linked to rules that say

where the handler should go




The Messaging Engine - Phases (Continued)

Standard Phases

Transport phase

Pre-dispatch phase

Dispatch phase

User Defined phases (If any)




Phase Rules

For dynamic handler chain

Writing phase rules

Phase Name

PhaseFirst

PhaseLast

Before

After

Before and After




Phase Rules - Example

<inflow><handler

name="SampleHandler" class="org.apache.axis2.SampleHandler">

<order phase="userphase1" />

</handler>

</inflow>




Service Dispatch

• Dispatch

• Service and operation can be located via• URL (http case : http://myEngine:5678/axis2/services/sushi/foo)

• Transport Information (http case : SOAPAction)

• WS-Addressing Headers

• SOAP Body QName




Pluggable Modules

Extensions for the server

Meant to provide a specific

functionality

e.g. Security, Reliability, etc.

Consists of

Handlers

Special Module class

A Descriptor (module.xml)




Module Descriptor

<module>

<inflow> <handler name="AddressingInHandler"

class="org.apache.axis2.handlers.addressing.AddressingInHandler">

<order phase="PreDispatch"/> </handler>

</inflow>

<outflow>

<handler name="AddressingOutHandler" class="org.apache.axis2.handlers.addressing.AddressingOutHandler">

<order phase="MessageOut"/>

</handler> </outflow>

</module>




Pluggable Modules (Continued)

Archived to make a single bundle

Known as a “.mar” file

Concept of Engaging

Engaging a module means activating it

Can be done

Per System

Per Service

Per Operation




The Messaging Engine – Detailed

Components View

Resolver

Modules

Engine

Contexts




Pluggable Modules - Example

The WS-Addressing module

Contains

Addressing-in handler

Placed in the pre-dispatch phase – in pipe

Addressing-out handler

Placed in the message-out – out pipe




Context Hierarchy

Descriptions keep static informationinformation extracted from deployment descriptors

Contexts keep runtime information

This Information needs to be in various scopes




Context Hierarchy

Contexts in Axis are somewhat like scopes in a programming languageMessageContext

OperationContext

ServiceContext

ServiceGroupContext

ConfigurationContext

A handler can ask for a property from the MessageContext, and get the value from the “closest” scope in which it is set







Inside Message Context




Axis2 XML

Defines parameters

Any configuration of the engine

Transports

Which transport listeners (ins) and senders (outs) are configured

Global modules – usually just addressing

Phases and PhaseOrder

Default MessageReceivers




MTOM Support

Two ways to transfer binary data

In-line in the XML

base64 – 4/3x original size

hex – 2x original size

Reference

pointer to outside the XML

MTOM allows best of both worlds

Appears as if it is in-line even when it’s pointed to

Same programming model




MTOM - Example

<soap:Envelope

xmlns:soap='http://www.w3.org/2003/05/soap-envelope'

xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>

<soap:Body>

<m:data xmlns:m='http://example.org/stuff'>

<m:photo xmlmime:contentType='image/png'>

<xop:Include

xmlns:xop='http://www.w3.org/2004/08/xop/include'

href='cid:http://example.org/me.png'/>

</m:photo>

</m:data>

</soap:Body>

</soap:Envelope>

--MIME_boundary

Content-Type: image/png

Content-Transfer-Encoding: binary

Content-ID: <http://example.org/me.png>

// binary octets for png




MTOM - Example

OMElement data = factory.createOMElement("binaryData", xNs);

// Creating the Data Handler

FileDataSource dataSource = new FileDataSource("c:\test.data");DataHandler dataHandler = new DataHandler(dataSource);

//create an OMText node

//optimised = true means by reference// use optimised for large data, inline for small

OMText textData = factory.createText(dataHandler, true);

data.addChild(textData);

Explicitly need to enable MTOM support in axis2.xml




REST Support in Axis

Services deployed in Axis2 can be

invoked in REST manner

A system wide switch to enable REST

By default, two different endpoints for REST and SOAP messages

Selection of messages depending on WSDL 2.0 REST binding rules.

All REST messages will be treated

similarly to SOAP messages inside the

system




More Features

Other transports

SMTP / POP based transport

TCP based transport

JMS based transport

Can easily switch between different

transports

Service Groups




More Features

JMX Management Console (Google

SoC project)

WSS4J support

Successfully completed interoperability

with Indigo using Axis2 with WS-

Security, MTOM and WS-Addressing




More Features

Sandesha2

WS-Reliable Messaging implementation

on Axis2

DOOM – W3C DOM over OM

implementation

WS – Policy Support




More Features

Support for other languages

Ability to write implementations in

various JVM languages

Groovy

Client stub generation for languages other than Java

Tested on IKVM based C# and VB.Net

code !

E4X Support




Features Under Development

Management capabilities via JMX

Clustering Support

Binary Serialization / De-Serialization

Jabber Transport




Interoperability

Interoperable with WCF (Indigo) in

basic scenarios including WS-Security,

WS-RM and WS-Addressing.

Interoperable with IBM, JBoss, Sun

with WS-Addressing




Existing Products

• WSO2 Tungsten

• Fully integrated and fully featured Web services server built on top of Axis2

• Available under Apache license

• http://www.wso2.com/products/tungsten




Releases

M1, M2, 0.90, 0.91, 0.92, 0.93, 0.94

and 0.95 already released

1.0 released on 4th May, 2006

1.1 coming soon!




Join us ...

Use Apache Axis2 and give us feed

back

Let us know your specific

requirements

Join [email protected] or

[email protected]

(remember to prefix subject with

[Axis2] )




Questions ?

Visit us at

http://ws.apache.org/axis2/




Thank you

Date post:	08-Jul-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

Why Apache Axis2: The Future of Web...

Documents