Axismora WSDL2Ws spsecification

Contents

1.Functionality

2.Architecture

1.Functionality

The tool should be able to generate different types of Wrapper.

1.1 Types of classes

The Tool Should starts with a WSDL document and generate following classes.

• Web service class describe by the WSDL document such that application developer fill the logic in the methods (WSDL operations).
• Wrapper class that used to deploy the Service in the LSF Axis engine. (Please refer the Wrapper Specification for more information).
• Parameter classes for each custom type in the WSDL document together with desirealize and seriealize logics (Please refer the Wrapper Specification for more information).
• Server side stubs for invoke the web service (This part is not implemented yet).

1.2 Programming Languages

The tool should able to generate classes for

• Java
• C++
• C

The tool should be extensible to support other programming languages if required.

1.3 Encoding Style

The tool should be support SOAP1.2 encoding style and extensible to support other encoding styles as well.

1.4 Style of the Service

The tool should able to generate classes for following styles

• RPC
• Document
• Messaging

1.5 Supports for making simple custom types

Tool generate Wrapper for custom types in following conditions.

• Generate the method signatures of the types (serialize(), desirealize()) so that developer can write serialize desirialize code in most efficient way.
• Generate the complete wrapper for WSDL types like struts.
• Genarate the complete wrappers for Array of any simple or WSDL types like struts.

1.6 Supported schema type

2.Architecture

2.1 Outline

The tool takes a top down approach. It starts with a wsdl document and generates all the classes necessary to deploy the web service. It generates.

• Skelton (wrapper class)
• Service (Class to be published)
• Wrapper classes for complex types
• Server side stubs

For more information about the generated classes please refer to the architecture documentation.

The blue arrows means the execution will go for one of the objects and black arrows mean tool will go to all the objects.

The factories have used to have right kind of instances at each occasion. The path and how the execution is done depend on the options. e.g. if the targetEngine is client all generators except generator creates server wrapper will be called or else server all generators except generator creates client stub will be called. MSG-WSG and DOC-WSG will call the generators even they are not shown.

2.2 Mediator WsContext

The WSDL file and the user options are processed by the WSDLWs. The WSDL create a class called wsContext(WebServiceContext) which is the runtime representation of the processed data. This wsContext passes to the generators. The generators extract the information form the wsContext create the files.The wsContext act as a mediator and create a loosely coupled system.

• ServiceInfo information about service
• WrapperInfo information about wrapper options
• TypeMap information about custom types

2.3 Generator

Generator generate a class depend on the options, It contains a class called SourceWriter and the concrete implementation of the SourceWriter decides what will Genarator generate. The SourceWriter factory create a correct type of generator depend on the options.

2.4 Flow of Execution

• WSDL file and user options are processed by the WSDL2Ws and WSContext object is created.
• WebServiceGenaratorFactory will create WebServiceGenarator depend on the service style, then the WebServiceGenarator will create right set of Generators to create the set of files.
• Each generator will invoke SourceWriter capable of writing each type of file.
• Rest of the logic is developer to decide (He have all needed info as WsContext).

2.5 Class Diagram

Above class diagram shows the class structure of the tool. The extensibility has been the major concern of the design.

2.5 Sequence Diagram

To really work on this please go through the example3 description at userguide.