Axis2, Middleware for Next Generation Web Services

Srinath Perera

Next 20 Minutes

• Why Axis2?• What does it have? • Architecture• Core Concepts

– XML processing – Extensibility– Messaging

• Conclusion

Why Axis2?

• Web Services has changed, so are the values and expectations from WS Middleware– Better support for Messaging, Asynchronous

interactions– Performance, Need for better XML

processing– Better support for WS-* specifications – New specs, and changes to specs

(Better or for worse)

What does it have?• Better XML processing model• Powerful messaging support• Seamless integration with WS-*

implementations – WS-Addressing, WS-Security, WS-RM ….

• Archive based Deployment • Close integration with Policy• HTTP, TCP, SMTP and JMS transports• REST, MTOM, WS-Policy …• Pluggable data Binding• WSDL based Code Generation

Architecture 10,000 foot view

XML processing Model

• Major decider of performance • Expectations

– Better performance, Streaming access to the Soap Message

– Move back and forth– Easy accesses to the Soap Message, in

other words Tree like (DOM like) representation

How to tackle XML Processing?• Use of XML streaming API• Virtual XML elements, that provide

familiar interface to user• Underline implementation based on

differed/lazy parsing (Data is read as late as possible)

• Switching back to the pull parser• Use cases

– Streaming at data binding– Pass result to another Web Service

(Workflows)

Extensibility• Support for security, reliability,

transactions, addressing ….• Axis1 approach, Handler architecture

Need bit more than Handlers

• Simpler deployment • Automatic configuration e.g. Security• What if two or more Handlers co-

exists? E.g. Security and Reliable Messaging

• Operation Injection - e.g. RM, WS-RF, WS-Sec Conversation

• Managing Handlers automatically and transparently based on Policy

Axis2 Modules for extensibility

• Module = Handler(s), + ordering rules + Initialization logic + Operations

• Archive based deployment, just copy it to Axis2 repository.

• Available modules vs Engaged modules• WS-Policy based engagement and

automatic configuration• Possibility of automatically adapting

services with (dynamic/static) policy negotiation

Messaging• Messaging System addresses three issues

– Complex message groupings and correlation– Blocking-Non Blocking behavior of Client /Server

API– Synchronous and Asynchronous behavior of

transports

• Supports for following cases– Request response, non-blocking synchronous – Request response, non-blocking asynchronous – Request response, blocking synchronous– Request response, blocking asynchronous – One way

Messaging in Axis2• Two Pipes, IN and OUT• Composing pipes at the Client (MEP clients)

and Server (Message Receiver) to yield different MEPS

Messaging (Continued)

• Three Properties (non-blocking, MEP, Sync-Async) are Handled in Operation Clients and Message receivers

• Switch between the different modes by simply setting client API parameters

• If you are a Geek, you may even add new Operation clients/ Message Receivers – e.g. Pub-Sub use case

Architecture (Revisited)

Summery

• We discussed rationale for Axis2, and brief looked at the architecture

• We discuss three main topics, XML Processing, Extending SOAP Processing Model and Messaging

• For more information– Official Site http://ws.apache.org/axis2/– http://www.wso2.net/projects/axis2/java– Mailing List

http://ws.apache.org/axis2/mail-lists.html