Understanding the Technology of the iWay .NET Adapter

In this section:

The iWay .NET Technology Adapter uses the classes in the Reflection namespace of the.NET class libraries. These classes enable loading an Assembly, and obtaining information from the loaded Assembly about the classes, methods, interfaces, and data types of the Assembly. This information from Reflection will be used to create XML schemas. At runtime, an instance of the .NET Common Language Runtime (CLR) will be instantiated to execute the selected method or methods in the Assembly.

Unlike static compiled code, dynamic code does not have access to all the field values stored in the Assembly, only the types and methods obtained from the Reflection API.

The Reflection API requires that the classes or methods be Serializable and that the member to be introspected be public. Private methods are always skipped and returned as private with no body.

Terminology Used With the iWay .NET Technology Adapter

The terms in this section are used with reference to the ECMA international and Microsoft documentation on the C# and Visual Basic languages, and to the Common language infrastructure. For more information on the languages and runtime of .NET, refer to these sources.

For a complete list of development sections of .NET, see the Microsoft .NET Framework 4.5 Development Guide and the Framework Design Guides for best practices.

For the adapter, it is a recommended practice that multiple application domains referencing the same types should not be loaded at the same time. The application domain boundary is at the Assembly level.

Do not use any class types that attempt to use Application environment variables. They will return the iway_home directory and not the expected Assembly. All Assembly environment variables function as documented.

The following objects are introspected dynamically:

The iWay .NET Technology Adapter supports only .NET Assemblies or .NET class libraries as target destination types. PE format executables are not acceptable as input and will return an error message.

Only classes and methods with accessibility domain of public will be available through the adapter. The adapter will accept default and overloaded constructors, provided the .NET runtime libraries are available.

Constant or other text defined in classes is usually not returned after introspection, so explicit variables that accept input must be defined. The .NET using clause, combined with a type variable, is often not returned, declare an explicit type instead.


Top of page

x
Session Support

If a class has a constructor, then calling the constructor will have a session ID in the return document. The adapter will attempt to construct and cache the object. Calling the object again with the session ID reuses the same object. Calling an object without a session ID or with an invalid session ID, causes the constructor to be called on the object again.

Cache and session behavior can be controlled on the Assembly or method level, as well as hiding Assemblies or methods.


Top of page

x
Constructor

A constructor is a special section of a non static class that creates an instance of the class. There are two types of constructors that can be used with the adapter, default and overloaded.

An default constructor has no parameters, and overloaded constructor has one or more parameters. Default:

class foo
{
foo(){
}
}
Overloaded
class foo
{
foo(string s){
s = new string(' ',5);
}
}

A static class must be declared explicitly as static:

static class sfoo
{
string getfooName() {
string s = "thefoo";
return s;
}
}

If a class has a constructor, then calling the constructor will return a session ID in the return document. The adapter will attempt to construct and cache the object. Calling the object again with the session ID reuses the same object. Calling an object without a session ID or with an invalid session ID, causes the constructor to be called on the object again.

Cache and session behavior can be controlled on the Assembly or method level, as well as hiding Assemblies or methods. For more information, see Controlling the Adapter Behavior Using a Properties File.


Top of page

x
Loading Assemblies Overview

In order to generate request and response schemas for a method of a target .NET assembly, you have to know what methods the .NET assembly can support and what kind of input and output data types are used for a method. Moreover, you also need to know related data types for custom data types. To implement the purpose, the working application domain has to load the target .NET assembly and its related assemblies (for example, base class assembly, derived class assemblies, and so on).

The following logic process is used to handle the AssemblyResolve event.

A target assembly may define multiple classes, a class may have multiple public methods, and two schemas are used to one method. In order to hold all schemas for a target assembly, you use an XML document.


Top of page

x
Parameters and Data Types

The iWay .NET Technology Adapter will return compatible data types for integration processing as best as possible. Some methods cannot be refactored for Java usage. If a parameter has a type of System.Object, then there is no good way of passing a .NET object from Java to .NET for invoking this method.

The adapter supports all Common Language Runtime (CLR) built in types and custom types, but not all types can be serialized.

When building a response schema, the adapter determines the response type from the .NET data type. If the .NET return type is a complex type that cannot be inferred, then the result will be anyType in the schema.


Top of page

x
Serialization

It is not possible to use the .NET XML serializers in an integration context. If a Datatable or DataSet object is used in a method, then it is the responsibility of the caller to serialize the results into a returnable type for Java (either as a structure, an array of strings, or an array). Microsoft has published an article describing a technique for writing a data table to a multi-dimensional array list that can serve as an example. For more information, see the Microsoft Developer Network (MSDN) topic Binary Serialization of ADO.NET Objects.

http://msdn.microsoft.com


Top of page

x
Method States

The state of all methods through the iWay .NET Technology Adapter is non persistent. The scope is method scope. It is possible to use a constructor and call a method in a repeated persistent state. If multiple methods are needed to be called in sequence, with each result passed to subsequent method calls, then consider using an iWay process flow or writing a .NET wrapper object, which will make all the method calls in one .NET method body.


Top of page

x
Calling COM Objects

The iWay .NET Technology Adapter works with .NET managed code only. If COM objects must be invoked from the adapter, then the technique of a Runtime Callable Wrapper (RCW) must be used to invoke a COM object and manage the lifecycle of the object. For more information on how to use it for a .NET to COM bridge, see the Microsoft Developer Network (MSDN) topic Runtime Callable Wrapper.

http://msdn.microsoft.com


iWay Software