converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 19:||Line 19:|
|Line 38:||Line 38:|
|Line 43:||Line 43:|
|Line 47:||Line 47:|
|Line 68:||Line 68:|
|Line 76:||Line 76:|
|Line 86:||Line 86:|
|Line 90:||Line 90:|
|Line 96:||Line 96:|
|Line 102:||Line 102:|
|Line 111:||Line 111:|
- WSDL 2.0 support
- Direct or indirect WSDL 1.1 support (need to parse the existing WSDL at the Axis test suite)
- Direct or indirect support for the JAX-RPC mapping file.
- Well define Object Model for the WSDL and XSD schema extensions
- Work with the encoding Module and code generate the Deserializer (and Serializer) for complex types
- Code generate client and server side artifacts
- Code generation for the available extensions in the engine
- WOM Implementation
- WOM building from WSDL 1.1
- WSDL Service Desc on top of WOM
Proposed package structure
org.apache.wsdl.wom :WOM Interface package. org.apache.wsdl.wom.impl :Concrete Implementations of the WOM. org.apache.wsdl.wom.wsdltowom :WOM Builders org.apache.axis.wsdl.servicedesc :Axis Service Desc Wrapper on WOM.
WSDL Module for Axis 2 should support the functionality provided by the existing Axis 1.1 modules that do the WSDL processing. Further it has the requirement of supporting the latest WSDL specification at the time of this writing, WSDL 2.0. Support for WSDL2WS and WS2WSDL for both WSDL 1.1 and 2.0 specifications. ('Here WS is used with java or C++ in mind.)' Architect an Object model that can accommodate both WSDL 1.1 and WSDL 2.0 compliant documents. Decoupling the WSDL Object Model (WOM) from the code generation or other Emitting functionality. Provide a mechanism for the WSDL 1.1 users to upgrade their WSDL version to 2.0. Decouple the WSDL generation module to allow extensibility in WSDL generation. WSDL Parsing will be done using external schema parser.
Architecture & Design
The following diagram identifies the sub modules in the WSDL module and tries to demonstrate their interaction.
Figure 1: WSDL Module for Axis 2
The above architecture consists of six major sub-modules which will be eventually be integrated to build the WSDL module. The WSDL module will be capable of providing the necessary WSDL processing capabilities that has been stated under the requirements of this document whilst they fall into to the scope defined in this document.
WSDL Object Model (WOM) The WOM has been introduced to this architecture with the intension of decoupling the Object representation from other sub modules especially code generation and WSDL writing. WSDL Object Model will be the runtime representation of the WSDL file in memory. Since already there are two WSDL versions which are different the WOM will be designed in such a way that it will be capable of representing both the versions at the same time while preserving the reversibility (regeneration of original WSDL from WOM) as much as possible. WOM can be generated from a WSDL file or from code and/or interface segments provided by the user.
WOM Builder The WOM Builder sub module will basically take a WSDL file as an input and will build the WOM. The schema parsing will be part of this module and the there will be an interface that will facilitate external schema parsers (e.g.: xml-beans, JAX- ME) rather than writing a schema implementation of its own. Logic of converging towards a common WOM from two different WSDL versions will be encapsulated in this module.
WSDL Writer - The WSDL Writer will be emitting the WSDL documents of different versions based on the WOM that has been previously created by either of the two mechanisms. This will be basically achieved by registering the necessary writer that will serialize the WOM. http://wiki.apache.org/ws/FrontPage/Architecture/WSDL/WSDLWriter
Language Registry The Language Registry will have the language specific information required by the Code parser and the Code Generation Module.
Code Generation Module The Code Generation Module will be basically emitting code required for the web service by looking at the WOM that has already been built by either of the two methods. The Code Generation Module will try to build a semantic model of the code to be generated in a language independent manner. Then it will have the language specific code writer that will generate the required code of a given programming language with the help of the Language Registry.
Code Parse The Code parser will be basically building a WOM based on sufficient information available to it by means of different inputs. The inputs can be interfaces and/or implementation classes and may be some type mapping classes, etc. These input code can be of different languages but should be of a single programming language given a single run.
Service Desc implementation on WOM
The Service Dec functionality (i.e. the operation identification , ++) is proposed to be built on top of the Current WOM(WSDL Object Model) implementation. The WOM is based on the WSDL Component model proposed by the WSDL 2.0, though generic for both WSDL 1.1 and 2.0.
Under this proposal the Deployment module will build a WOM at the Deployment time and the WOM will get populated with the other necessary deployment information. Thus eventually the service object that will be deployed in the Engine Registry will be of the type org.apache.wsdl.wom.WSDLService.
The WOM components extend a common base class org.apache.wsdl.wom.Component and following is Class diagram of it in this Context.
As the class diagram tries to illustrate there is a property bag associated with the org.apache.wsdl.wom.Component and it will be to this property bag that the additional information that Deployment module will inject to after its WSDD parsing in the deployment time. For example the WSDLService Components property bag will have the service specific handlers as a property, etc.
Enging and Deployment interaction
The WSDL Object Model is expected to provide the service Desc functionality eventually. It should be made clear that this functionality will not be burnt to the WSDL Object Model (WOM). Rather the WOM would facilitate an generic association properties to a given WSDL Component. This is achieved through the ComponentImpl Class illustrated above.
The ComponentImpl Class has a HashMap and all the WDLComponents in the WOM inherit from this Class thus they will also inherit the capability of adding Component Property value key pairs. This functionality is capable of theoretically meeting the demands of the Service Desc.
But the Engine API of the Service Desc would expect much cleaner interface. So what has been proposed is an Adapter Classes that will work on top of WOMs WSDLComponent classes and will give a better interface to the engine. A example would be the proposed AXISWSDLService class shown below which extends the WSDLService class.
Overall picture is that the Deployment will Build a WOM and with the WSDLService of the WOM it will build a AXISWSDLService and populate it with the Axis specific deployment information and will deploy it in the Engine Registry. Engine will pick it up at the runtime.
- Object model for the WSDL2.0
- Parsers to parse WSDL2.0 and WSDL1.1 to the object model.
- Parser to accept a java class and some options and generate WSDL2.0 object model.
- WSDL Object Model to WSDL file writer
- Code Generation Module
Object model for the WSDL2.0
This subcomponent set up a standard runtime representation for WSDL file in side the Axis. Both WSDL 2.0 and WSDL 1.1 files are parsed and stored in this Object Model.
- Q1) What is over schema Object Model JAXME?
WSDL2.0 and WSDL1.1 Parser
Possibility of using IBM WSDL2 or working with WSDL2 to write a WSDL parser should be considered.
Java Class Parser
This is more or less the parsing part of the Java2WSDL. Most of the code should be able to reuse.
WSDL Object Model to WSDL file writer
Good way to implement this would be to add the serialize() method to each and every component of the WSDL Object model we discusses earlier.
Code Generation Module
The Code generation Module should work on the WSDL Object Model. There should be a mapping layer that can be plug in to the generation code that would do the language specific mapping. The code generation framework should be extensible so that the behavior of the generated code should be able changed programmatically with out changing the source code of the core module.
Generation of server side and client side artifacts
extension points for the extension writers