Generating XML Schema in the Current Adapter Version

Key Word	Type	Description
[AssemblyName]	String	The name of an assembly. For example, Math.dll.
[Namespace]	String	The namespace which is used in an assembly.
[CustomTypeName]	String	The name of a complex custom type.
[ClassName]	String	The name of a class.
[FRAMEWORKTYPE]	String	The name of a .NET Framework type. To convert a C# built-in type to a .NET Framework type, a Built-In Types Table is available on the following webpage: http://msdn.microsoft.com/en-us/library/ya5y69ds.aspx. The .Net Framework type of a complex custom type has the following format: [Namespace].[CustomTypeName]
[Method signature]	String	The part of the method declaration. It is the combination of the method name and the parameter type list. In a parameter type list, the name of a .NET Framework type to present a C# type is used. [Method signature] sample: A complex custom type named CUSTOM is defined in a namespace NS. C# function: void setValue(CUSTOM obj, int input) [Method signature]: setValue(NS.CUSTOM, System.Int32)
[iWayURI]	String	In a request schema: [iWayURI]="urn:iwaysoftware: ibse:jul2003:" + METHODNAME. [iWayURI]="urn:iwaysoftware: ibse:jul2003:" + METHODNAME In a response schema: [iWayURI]=""urn:iwaysoftware: ibse:jul2003:" + METHODRESPONSEE
INOUTDATANAME	String	For a request schema, it is the name of an input parameter. For a response schema, it is equal to result.
NAMESPACECOMPLEXTYPE	String	The name of a custom type with the following namespace: [Namespace].[CustomTypeName]
TNSNAMESPACECOMPLEXTYPE	String	NAMESPACECOMPLEXTYPE with namespace prefixes tns. Format: tns:[Namespace].[CustomTypeName] For example: tns:Math.ComplexNumber
XSTYPE	String	The XML built-in data type with namespace prefix xs. For example: xs:int, xs:string and so on.
SUBELEMENTNAME	String	The name of a sub-element.
SUBCOMPLEXNAME	String	The name of a sub-element, which has a complex custom type.
METHODNAME	String	The name of a method.
METHODRESPONSE	String	It is equal to METHODNAME+"Response".
MATHODLOGICPATH	String	The logic path of a method. Format: /[AssemblyName]/[Namespace].[ClassName] /[Method signature] For example: /Server.dll/Server.TestServer/ GetVehicle(System.Int32)
PARAMETERNAME	String	The name of an input or output parameter.

In the current adapter version, XML request and response schemas can be generated.

An element is used to represent a method, and sub-elements under the sequence node of the element are used to represent input parameters in a request schema. Similar to earlier versions of the adapter, an element is still used to describe return data and type in a response schema.

Whether you are using the previous version of the adapter or the current version, a .NET built-in type data is described by one element node that contains the name and type attributes. The value of the name attribute is the name of the data, and the value of the type attribute is the name of XML built-in type with namespace prefix xs. Unlike the early version of the adapter, the current version of the adapter is also able to create schema for complex custom data types.

Complex Custom Type Representation Rules

To represent a complex custom data type, two rules are defined.

Rule A

For a complex custom type input or output, a type attribute to the element is applied and referred to the name of the complex custom type to be used, as shown in the following image.

Rule B

A complex custom type data may contain complex custom type sub-data. An element can be directly declared by naming the element for the complex custom type sub-data, as shown in the following image.

Namespace and Target Namespace

The xmlns:xs attribute is declared with the value http://www.w3.org/2001/XMLSchema in all XML request and response schemas. Each of the constructs that are defined by the XML schema language will need to be qualified with the xs prefix.

There are no namespace issues if a method only has .NET built-in type inputs or outputs. Namespace issues are only considered if a method has complex custom type inputs or outputs.

Consider the following example. MYDLL.dll is a .NET assembly that contains a class called MYCLASS that is defined in the MYNS namespace. MYCLASS has a function called FN with prototype A.CTYPE FN (A.CTYPE c1, B.CTYPE c2). In the function, A and B are different namespaces and both define a complex custom type named CTYPE. Even though CTYPE in A contains a member variable called CMEMBER that has a complex custom type ETYPE, and CTYPE in B also contains a member variable called CMEMBER that has a complex custom type ETYPE, CTYPE in A and CTYPE in B are different. This causes the name conflict in the request and response schemas if the data and types are not properly described.

The following image shows the structure of a XML request schema.

The following image shows the structure of an XML response schema.

In order to solve namespace problems in the XML request and response schemas for a method that supports complex custom type inputs or outputs, full names are used to represent custom types for input parameters or output data. The full name of a custom type has the following format:

[Namespace].[CustomTypeName]

The targetNamespace and xmlns:tns attributes in the request and response schemas are declared. All custom type(s) of input parameter(s) or returning data belong to the namespace [iwayURI] as defined by the targetNamespace attribute, and the prefix is tns as defined by the xmlns:tns attribute.

targetNamespace=[iwayURI]  (reference key table)
xmlns:tns      =[iwayURI]
xmlns:xs       ="http://www.w3.org/2001/XMLSchema"

Following the previously mentioned solutions and the Complex Custom Type Representation Rules, you can create elements to represent input or output data which have complex types, and describe the complex types by generating xs:complexType nodes.

As shown in the images that depict the structure of XML request and response schemas, the XML data are the parts of the request and response schemas of the MyDll.dll sample. The current release of the adapter generated ENODEs based on Rule_A and generated CNODEs based on Rule_B. An ENODE represents a parameter or return data and a CNODE describes the custom type of a parameter or return data. The sub data CMEMBER is also described by an xs:complexType node based on Rule_B.

Moreover, if a sub data has custom type members which can be made public, you can also follow Rule_B to describe them, and so on. How deep the complex type sub data can be extended depends on how the object of DataSet class infers schema from the data and loads the data.

The request and response schemas generated by this technique can handle multiple types with the same name from different DLLs or objects and support objects referencing variables of complex types with same names in the request and response schemas.

Formats of XML Request and Response Schemas

Formatting of XML request schemas can be based on the following scenarios:

Situation A. A method without input parameters.
Situation B. A method with simple .NET built-in type input parameters.
Situation C. A method with complex custom or mix (simple and complex) type input parameters.

Formatting of XML response schemas can be based on the following scenarios:

Situation A1. A method does not return a result.
Situation B1. A method returns a simple .NET built-in type data.
Situation C1. A method returns a complex custom type.
Situation D1. A method returns a data (simple type or complex custom type) and output simple type or complex custom type parameter(s).

The legacy version of the iWay .NET Technology Adapter only supports functions with some simple type inputs and outputs. The format of an XML request schema for the current adapter version is similar to the early version under Situation A and Situation B. The format of an XML response schema for the current adapter version has more information than the earlier version under Situation A1 and Situation B1. Only the current version of the adapter can support Situation C, Situation C1, and Situation D1.