The visual specification package comprises a set of forms or screens where the developer introduces information about the integration. Figure 16 shows the classes that implement the visual specification package from Figure 15.
The first screen showed by the visual tool is produced by the PrincipalForm class, allowing the developer to open or create an integration project. After that, the visual tool shows the LoginForm where an enterprise is selected; the project name, user name, and password are entered here. If authentication is successful, the visual tool shows the SpecificationForm screen,
where the user can select the generic Web service corresponding to the e-service and the remote operation for this Web service. The last screen is the GenerationForm where it is possible to select the programming language for the client of the remote operation. This form also allows one to compile and deploy the generated Web service and compile both the wrapper and the client. For instance, in the case of the Java programming language, the GenerationForm uses Apache Axis tools to generate proxy classes (stubs and locators) from a WSDL document. Another screen related to the PrincipalForm is the ConfigurationForm where the set of generic Web services are con- figured using the visual tool.
As Figure 17 depicts, the process to specify the complete integration consists of three steps beginning with a log-in screen, followed by the Web service and operation selection, and final- izing with the code generation form. The log-in step uses some additional features that the visual tool provides like a Web services deployed in the hub platform to retrieve a list of enterprises that belong to the hub platform and to authenticate the user or developer who wants to integrate the enterprise. The operation selection step involves access to the XML configuration file (webser- Figure 15. Main packages of the visual tool
Figure 16. Visual specification classes
Figure 17. Visual specification flow
User / Developer
Login Select remote
operation Code generation
•Web Service •Wrapper •Client
vices.xml) that declares where the generic Web services are deployed. Then, the screen shows a tree of the generic Web services from which the user can select a Web service and an operation through visual selection.
The following XML code is an example of the webservices.xml file, which contains the declara- tion of a set of URI to WSDL documents. The WSDL documents in Box 1 are definitions for the generic Web services mentioned before.
The last step, code generation, involves a code generation functionality to produce the neces- sary code, based on the specified operation in
the operation selection step. The code generator component is explained in the next sections.
Data mapping
The data mapping classes implement the func- tionality to map information using XML directive files. These classes define operations that both visual specification and code generation classes use to achieve the complete process of code gen- eration for integration. Figure 18 shows the class diagram for the data mapping package.
<webservicesbean>
<webservices name=“eSupplyWeb”>
<description>Web service for e-supply hub integration</description> <WSDL>http://10.17.56.89:8080/axis/services/eSupplyWeb?wsdl</WSDL> </webservices>
<webservices name=“eMarketingWeb”>
<description>Web service for e-marketing hub integration</description> <WSDL>http://10.17.56.89:8080/axis/services/eMarketingWeb?wsdl</WSDL> </webservices>
<webservices name=“eBrokerageWeb”>
<description>Web service for e-brokerage hub integration</description> <WSDL>http://10.17.56.89:8080/axis/services/eBrokerageWeb?wsdl</WSDL> </webservices>
</webservicesbean>
Box 1.
At the top of the class diagram is the Projec- tHandler class that allows retrieving and saving a project (directive files). Once the project is loaded or created, it is possible to manipulate its two attributes: the IntegrationInfo and Connection- Info classes. The IntegrationInfo class includes information for the integration process like the operation and Web service. The ConnectionInfo class contains the enterprise, user name, and password for authentication. In order to load the generic Web services stored in the webservices. xml file, the ServiceHandler class implements mechanisms to retrieve information from this file. The WSDLParser class reads information from each WSDL document (specified in the webservices.xml file) such as the set of opera- tions, and their types and parameters. Then, the ServiceHandler class stores this information in a list of WebService classes.
The directive files in the visual tool are seen as project files because it is possible to open the XML files and recover or save directives. For a directive representing access to a remote param- eter through a Web service interface, the following information is required.
• Project name
• Information for authentication and connec- tion
Enterprise to integrate User name
Password
• Information for integration
Language for client and wrapper E-service to integrate
• WSDL of the generic Web service by in- cluding the URI where the Web service is located; is composed by
Transport protocol (HTTP, FTP [file transfer protocol], file, etc.)
Host name or IP (Internet protocol) address
Port
Relative context of the WSDL (i.e., /axis/services/eSupplyWeb?wsdl) • Operation to execute
Type of data returned by the operation invocation
Required parameters for the opera- tion
Name
Type
Taking as example a service to retrieve work orders, the directive file for integration through Web services is as shown in Box 2.
This directive specifies an operation named getWorkOrders, modifying the date parameter releaseDate. The operation returns a vector param- eter getWorkOrdersReturn. In this case, the opera- tion accesses a Web service that resides within an application server implementing HTTP at the IP address 10.17.56.89 through port 8080 in the /axis/ services/eSupplyWeb context inside the applica- tion server. The complete URL (uniform resource locator) specification is http://10.17.56.89:8080/ axis/services/eSupplyWeb?WSDL.
These previous examples may give a general idea of the tasks that should be performed by a visual specification and integration tool using directive description files as input, and the output that should be produced for service level integra- tion. In order to deal with the heterogeneity of data types, WSDL documents are commonly deployed with general types that the visual tool converts to specific types. Within the application systems, parameters can be of the following data types. • String: Data that represent a succession
of ASCII (American Standard Code for Information Interchange) codes
• String[ ]: Data that represent an array of
string types
• Integer: Represents an integer quantity
• Double: Represents a floating point value
<project name=“project1”> <connectionInfo> <enterprise>ipacsa</enterprise> <username>webservice</username> <password>webservice</password> </connectionInfo> <integrationInfo> <language>net</language> <serviceInfo name=“eSupply”> <WSDL>http:// 10.17.56.89:8080/axis/services/eSupplyWeb?wsdl</WSDL> </serviceInfo> <operation name=“getWorkOrders”> <return-name>getWorkOrdersReturn</return-name> <returnType>vector</returnType>
<inParameters name=“releaseDate” type=“date”/> </operation>
</integrationInfo> </project>
Box 2.
• Vector: An array of data objects
Directives represent the basic information necessary to execute operations and their param- eters. For every access operation, it is necessary to define a set of directives to identify the parameters involved and the way in which the operation will be executed (Web service). In this way, directives are a very flexible mechanism easy to adapt when changes to parameter access are necessary.
code generator
The package of the code generation represents a submodel for code generation facilities.
Figure 19 depicts an interface named Generator that defines general methods for all subclasses. There exist two subclasses of the Generator class:
WServiceGenerator and ClientGenerator. The first one defines methods for the generation of a Web service adaptation and a subclass named WServiceGeneratorJava that implements the generation functionality for a Web service in the Java language, including its deployment. The ClientGenerator subclass defines methods for the generation of clients. There exist three subclasses of ClientGenerator. The ClientGeneratorJava subclass implements functions for the wrapper and client generation in Java. Both ClientGen- eratorCSharp and ClientGenerationVBasic imple- ment functions for wrappers and clients in C# and Visual Basic languages, respectively.
The code generator component uses configu- ration wizards’ techniques (Jiménez, 2003) to generate code based on specifications introduced through visual screens and stored in XML direc-