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)
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).