Axis2 WSDL- Code Generation

Contents  Scope and Goals of the discussion.  Anticipated runtime behavior.  Proposed Architecture.  Change request for other Axis Modules.

Code-generation  Scope: Client stub and server skeleton generation to support invocation of service and to engage add on services (RM, security, etc). The Data binding is considered orthogonal to this discussion.  Design Goals. Generate artifacts that will engage add on service, if specified. Leave room for extensibility based on policy.  Wish List. Provide for programming language extensibility.

Anticipated runtime behavior.  Client side  Server side

Client side Runtime.  Two levels of configuration Default/Initial configuration (static and may be based on a generated client.xml) Invocation properties (Dynamic)

Client side Runtime.

Server side runtime.  All the modules be available in the inflow.  Run the dispatch phase as early as possible for service discovery.  Engage the modules in the runtime.

Server side runtime.

Code generation tool

Input Configuration files.  Promote the use of WSDL extensions and policy to build the Input configuration (while providing for other inputs as well).  Configuration Builder will build to the Configuration from different descriptors.

Client Side/Server side Code Generation  Required runtime configuration will be generated as deployment descriptors (service.xml, client.xml)  Emitters will be used which are Program language dependent Emitter is aware of the add on service implementations available.

Add on services  Add on services will be incorporated in the form of the form of Modules and handlers and be burnt into the wsdd file.  Add on services may get switched on at the runtime.  A add on service implementation modules be made available in aar-drop directory.  Download the module-x.mar if required for the add on services (Dr Sanjiva’s idea).

Deployment Interaction

Other Aspects  Sync Async behavior will be burnt into the stub in the client side(?) and server side will be based on a particular Receiver(?).  MEP support at client side??

Change Request  Client API should changed call.setInvocationProperties();  Engine should be a policy driver.

Comments ??????