Web Services provide a standardized way to call remote services via HTTP communication. Stardust allows you to use Web Services as an application type for applications invoked by arbitrary activities in a process. Data can be passed to and retrieved from Web Services as parameters via the access point concept.
Web Service Call with Primitive data-types
Following model is used to implement an example of web service application (WebServicesAppExample.xpdl):
The user enters the degree Celsius.
Within the activity Celsius To Farenheit, the assigned web service application Celsius To Farenheit App transforms the degree Celsius into degree Farenheit by calling the remote services Converter.wsdl (here: localhost:8080/<project name>/services/Converter?wsdl).
Finally, the computed degree Farenheit is displayed.
The integration of a Web Service Application into a model is described in detail in the corresponding article in the Stardust documentation.
Web Service Call with Structured Data-Types (SDTs)
For most real world situations, the above example is too simplistic. Often Web Service are used to integrate difference technology platforms, e.g. .NET and Java. In such cases, and ideally all Web Services development, good service-oriented design principles should be followed to ensure compliance with WS-Interoperability.
The following examples provides:
- SDTWebServiceExample.xpdl - Process Model with Structured Data imported from CorporateAction_RIMS.xsd and Holding_RIMS.xsd, calls RimsServiceSOAP.wsdl
- RIMSService - Deployable service implementation generated from well designed RimsServices.wsdl
- RimsServicesSOAP-soapui-project.xml - soapUI project for testing calls to RIMSService independently of Stardust
'WSDL first' design is essential to avoid many problems associated with Web Services Integration. Generating WSDL from code is considered a poor approach to Web Service integration.
In this example, XSD's from two sources are used in a WSDL document. For Stardust to relate data elements in a Web Service to data elements in a process, they must share the same namespace and structure. To ensure namespaces match in Web Service processes it is good practice to design XSD in an external editor, taking care to specify cardinality and use elements and types, then import the XSD into the process. If XSD changes, the XSD must be imported again, and the Web Service updated to refer to the correct XSD.
RimsServiceSOAP.wsdl is designed in Eclipse (File>New>Other>WSDL). Once the design is checked, the implementation is auto-generated by selecting the XPDL within Eclipse and using the Web Services builder (File>New>Other>WebService) (by default the dialog correctly chooses top down design)
Note namespaces must match correctly and message elements should point to an external schema located locally or remotely. Where a remote schema is used (i.e. some URL on the web) then this remote location must always be available - pragmatically, the schema should be deployed locally since network availability is not usually guaranteed.
<wsdl:definitions name="RimsService" targetNamespace="http://www.example.org/RimsService/" xmlns:tns="http://www.example.org/RimsService/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:corr=http://www.infinity.com/CorporateAction/RIMS xmlns:holr="http://www.infinity.com/Holding/RIMS" > <wsdl:types> <xsd:schema targetNamespace="http://www.example.org/RimsService/"> <xsd:import namespace=http://www.infinity.com/CorporateAction/RIMS schemaLocation="CorporateAction_RIMS.xsd"/> <xsd:import namespace=http://www.infinity.com/Holding/RIMS schemaLocation="Holding_RIMS.xsd"/> </xsd:schema> </wsdl:types> <wsdl:message name="GetHoldingsRequest"> <wsdl:part element="corr:CorporateAction" name="CorporateAction"/> </wsdl:message> <wsdl:message name="GetHoldingsResponse"> <wsdl:part element="holr:Holdings" name="Holdings"/> </wsdl:message>
The following model is SDTWebServiceExample.xpdl.
Download, unzip import and deploy the service contained in RIMSService.zip . Once Tomcat has started you can test availability using soapUI (RimsServiceSOAP-soapui-project.xml), and once this proves connectivity deploy and run SDTWebServiceExample.xpdl .