Presentation on theme: "Axis2 WSDL- Code Generation. Contents Scope and Goals of the discussion. Anticipated runtime behavior. Proposed Architecture. Change request for."— Presentation transcript:
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).
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.