Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0...

25
1 Axis2 - Overview Aim of this presentation is to give an overview of Axis2 and it’s architecture.

Transcript of Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0...

Page 1: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

1

Axis2 - Overview

Aim of this presentation is to give an overview of Axis2 and it’s architecture.

Page 2: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

2

Agenda

� ����������������

� �������������

� ��

� ��� �

� ����

� ��������

� ���������

� �����������������

� ��������� ������!�������!������

� �����������

This is the agenda

Page 3: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

3

Overall Architecture of Axis2

This is the overall architecture of current Axis2. The subsequent sections explain each and every component in detail.

Page 4: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

4

Introduction to the terminology

� ��"��#� $���%�����"�����������������#������������������

� ��"��#�& $���%�����"�����������������#���������������������

Before going into the details, here is a quick intro to the terminology.

Inflow is the sequence of events that happens when a message is received up to its consumption.

Outflow is the sequence of events that happens when a message needs to be sent out. This out bound message may well be a reply to one of the inbound ones.

Page 5: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

5

Core

� ������������"����"����#���

� '�����(��#�)

� ����������*�

� +�����

� �����

The Core section of Axis2 is discussed here.

Core compromises of the following components.

1. Handlers (Phases)

2. Engine

Slides that follow explains each of these core components in detail

Page 6: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

6

Core (cont…)

� $��������������"�����������������������"����#�

This image will be helpful in visualizing the relationship of the core components

Page 7: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

7

Core :: Message Context

� ��������"������ ��������������������"�������,

� ����������������������������������������������

Page 8: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

8

Core:: Handler Framework

� '�����������-*������������.� ��#����#�)��#����������������*�� '����������!�*�������������"��#�����������"��#

� /�!������������� $������0�1��!�����������

� ��������������������������������� �������������������

� '��������������������� ������������������������"����������������������

Here is an excerpt from one of our recent Axis2 articles about handlers and phases.

Axis first introduced the concepts of the Handlers that provide extensions or filtering to the Web Service stack. The handlers are configurable callbacks that can be registered before consuming or sending the Message. With the existing Axis 1.x handler framework order of the handlers can only be specified at the service deployment time. This requires the exact order of the handlers to be known at the deployment time, and as a result the task of deciding the order of the handlers needs to be carried out by the Web Service developer.

However most of the Handlers (e.g. Security, Reliable Messaging, and Transaction etc) are developed by separate Web Service stack projects. Unfortunately the Service developers are not expected to understand the complex requirements that govern the ordering of the handlers.

Axis2 boldly takes the next step by introducing the “Phase rules” that enables the developers of each handler to specify the “partial order” of the handlers. This is achieved by introducing two concepts, the “Phases” and the “Phase rules”. Phases are labels given to the specific area of the execution handler ordering and the phase rules are Rules that specify location of the each handler relative to particular phases. When the execution takes place Axis2 engine will make sure that the Handler will be placed in such a way that the all the phase rules are met. For example say the Reliable Messaging (RM) project wrote a RM handler. Since this handler is supposed to run with the other handlers and going to be used in different situations, there is no way that the developers of the RM handler can specify the absolute location the RM handler should run. As a result the burden is shifted to the Service developer who is not required to be aware about the behavior of the RM handler. However the developer of the RM handler knows some rules about how it should run. For example a simple rule governing the RM handler would be that it should run after the security handler but before the transaction handler. RM Handler developer may very well decide to document this fact to assist the service developer. Phase rules go one step further by letting the RM Handler developer instruct Axis directly about the placement of handlers, rather than just documenting the fact, ensuring a smooth operation.

Page 9: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

9

Core:: Handler Framework (cont..)

� �������������

� +���

� +�����������

� ��������������������������������

� ���

� ����������

� ����)��������"��#������������

� ��������

� (������������

Receiver is the component that theoretically receives the message. In reality however the actual component that receives the message is the transport receiver (such as the Servlet or the socket server) and the Receiver Is half way up the execution chain.

Receiver has a receive() method that is called by the engine.

Sender is the component that sends the messages out. Unlike the receiver, sender creates the relevant transportSender and send the message

Page 10: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

10

Core :: Registry

� 2��"����������

� ���������#�)��������+�����

� ���"�����!����������������������,

Page 11: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

11

Core :: Engine

� $��-�������.

� �������3

� ��������)�������������������*�

Engine is the component that calls each and every handler, receivers, senders and so forth. It is the “driver” of the process.

Note however that the actual driving thread will be created from another entity, most probably a transport receiver.

Engine is a stateless component that can be re-used. The message context holds the state information

Page 12: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

12

How the Axis2 core works

� �*������*��4��������������������������&����������"��#

Page 13: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

13

AXIOM

� $��� �����"��������������

� $�������!������������

� (�������""��!�������

Here is an except from one of our recent articles on AXIOM. Note that AXIOM is termed OM in certain instances for convenience.The main challenge any web service based middleware faces is to avoid keeping the complete SOAP message in the memory. The entire object model being in memory is not a disadvantage in terms of ease of programming. It makes the programmatically manipulation of the XML objects much easier. However in terms of memory there is a penalty since the object model requires a considerable amount of memory which accounts to at least the size of the XML document being processed.A first generation SOAP Engine, Apache SOAP uses a DOM based Object model internally to represent the XML document. The problem arises due to these XML handling techniques forcing the entire XML object model to build at once. At the second generation Apache Axis shifted to SAX, to avoid keeping the complete information in the memory. But SAX has a major constraint. It is built around a “push” technique and once the parsing of the XML document is started it can not be stopped. To jump over this hurdle, Apache Axis had to record the SAX events. In effect, the XML message is kept in the memory in the form of SAX events and forced Apache Axis to have yet another memory intensive programming model. The disadvantage of these memory intensive programming models becomes evident when large XML files need to be manipulated. For midsized XML documents the performance is acceptable but when larger XML documents are processed memory requirements become much higher. Few concurrent requests with large XML documents eventually cause the SOAP engine to crash!Axis2 avoids keeping the complete SOAP message in the memory by introducing a new object model for representing the SOAP Envelope. This new object model is termed AXIOM (or simply OM for convenience) and it takes a dramatically new approach. From outside, AXIOM shows an Object model just like DOM. However internally it generates the objects only when needed. This “on demand building” feature gives AXIOM the edge needed to overcome the memory barrier that Axis 1 failed to pass.One interesting fact that surfaces when digging deeper into AXIOM is that it is based on Pull parsing. AXIOM is capable of generating the pull events from the Object Model that is built and if the object Model happens to be half built AXIOM is capable of shifting to the underlying pull parser to generate pull events directly from the stream.

For example consider a SOAP message which has 3 header elements in the SOAP Header and 100 child elements in the SOAP body. If the user asks for the third child element in the SOAP Header, the Object model is built tillthe third element, At that point, if the user asks for the pull events for the SOAP envelope, the pull events will be generated from the Object Model only till the third element and the other events are taken directly from the under lying XML pull parser. Since in the SOAP message processing it is usual to process the SOAP Headers through the convenient API (DOM like) and process the SOAP body though the streaming API, above capabilities allows Axis2 to make a notable difference in performance. The heart of AXIOM is the XML Pull parser since it is the only parsing model that supports the pausing of the parsing process. AXIOM selected the standard pull parsing API, the Streaming API for XML (StAX). This wedding with StAX has not gone wrong .AXIOM has proved itself to be very easy to manipulate and it utilizes only a fraction of the memory used by a conventional object model. Combined with the speed of the streaming pull parser, AXIOM pushes Axis2 leaps ahead of its predecessors in terms of efficiency and speed.

Page 14: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

14

AXIOM :: SOAP Implementation

� ����������� ��!���������

� $�������������

� 5���������������6,6

� � ���!����!������!�����������

Axiom has a tightly bound SOAP object implementation. It is compliant with the SOAP 1.1 specification and built directly by a StAX parser

Page 15: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

15

WSDL

� $������������������������

� 7#� !8��������

� � �9����� !8�������:

WSDL handling is a must for the SOAP engine. Axis introduces WOM, WSDL Object Model to represent the WSDL document. WOM has a builder for WSDL 1.1 based on wsdl4j.

WOM is based on WSDL 2.0

Page 16: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

16

Deployment

� $���#�������"����

� '�����������

Deployment is a highly improved area in Axis2.

Axis2 deployement features

1. A new Archive format for the services

2. Hot deployment

Page 17: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

17

Deployment :: Service Archive

� �*��������� ,�� "��,

� ��8��"���#��������������������������������������������

� ����!�������������������#!��������������������"��������,

� ���������������������������������,*��

Axis archive is actually a jar file with special files in the meta-inf directory. This special file is called the service.xml and included everything about the service that Axis needs to know.

This archive (which we call the Axis Archive or “aar” file) can be just dropped into the special repository folder where it would be picked up automatically by Axis or uploaded through the Axis web app upload page.

Page 18: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

18

Client API

� (��������"�������������;������������������������

� �������������

� ��&��������

� ��&���������9����������������������:

� ��& ���

Client API is also a great improvement over the earlier one. Client API has support for both synchronous and asynchronous invocations of the service. It also includes better support for the MEP’s (Message Exchange Patterns) described in the WSDL 2.0 specification.

Note however that support for out bound MEP’s is yet to come.

Page 19: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

19

What is yet to come?

� ���������!������

� �$ ���������"����� �

� ������!�������!������

� ����������������

Although what Axis2 has right now is impressive, there are more things to come. The most important changes to come are

1. Message based core

2. MTOM support for AXIOM

3. Pluggable Data binding support

4. Multiple transports (SMTP)

Page 20: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

20

MTOM Support

� �$ ���������"����� �

� �������������"�7#� !8���& �<��!

� �����;�� ���#��!����

MTOM support for AXIOM has been tried with a model that introduces a new object to the OM Tree, the OM blob.

MTOM support also includes a MIME/XOP aware builder

Page 21: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

21

Message based core

� $�����������������!������������������

� �������������� �����������+��� =

Messaging has been the most important topic of all for next phase of Axis2. Srinathhas been working on a proposal and a toy-implementation for a complete messaging based core and this will be the main discussion for the day.

Page 22: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

22

Transport

� ��$�;� ��������

The concern with transports is that HTTP should not be the automatic choice. Hence a SMTP/POP based transport has been written but there are lot to discuss and clarify

Page 23: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

23

Data binding

� ������!�����������;������!�������������

� ���<���

� >��<

� �����

Data binding is planned to be done by using an existing framework such as XMLBeans, JAXB or castor. Dasarath has been looking into this and we already have a working prototype for WSDL2java for doc/lit . However there are things to be clarified in moving ahead

Page 24: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

24

Questions ?

Page 25: Axis2 - Overviewpeople.apache.org/~ajith/summit/material/Axis2-Overview-notes.pdf · 2.0 specification. Note however that support for out bound MEP’s is yet to come. 19 What is

25

Thank you