Web Services Collaboration Workflow System
University of Malta
+356 3290 2132
University of Malta
ABSTRACTIn this poster we present the design and implementation of a tool that enables users to define and invoke a Web Services workflow system. The tool allows users to search for Web Services needed and then combine the chosen Web services using a number of invocation rules and patterns. The tool empowers the user to define a specific workflow and ensure that the exact desired output from the combination of a number of Web Services has been achieved.
KeywordsWeb Services, Workflow, eCommerce, Semantic Web.
1. INTRODUCTIONThe concept of conducting business through the medium of the Internet is not a new concept. The first phase of eCommerce mainly dealt with businesses offering a Web-enabled front-end to their products and services. The next phase of eCommerce addressed the issue of business-to-business transactions and relationships . Web Services (WS) can be the main enablers of this eCommerce phase. WS will allow back-end interactions between computer systems, business applications and software components. The WS architecture relies on a number of protocols, namely, SOAP (Simple Object Access Protocol) , WSDL (WS Definition Language) , and UDDI (Universal Description Discovery Integration). Using these protocols a number of toolkits have been introduced by a large number of companies who offer support in all new versions of applications that allow users to expose their code as WS.
There exist several tools that allow simplified invocation of WS, however, the real value of WS lies in combining several services, thereby getting value from their amalgamation . The combination of services in a determined workflow is made easier through a tool we designed and developed.
2. WS Workflow ToolThe WS workflow tool allows the user to combine several WS to provide added value to businesses using the WS architecture. The tool uses all the protocols mentioned above. UDDI is used to discover services. WSDL is used to determine the technical interfacing of the WS chosen, and SOAP is employed when invoking the services. The tool we designed and implemented to define the workflow is made up of two components, which together offer the described functionality, namely, a WS Service Search Engine, and a Workflow Definition and Invocation Tool.
3. WS Search EngineThis allows a user to specify a few keywords that describe a service. The search engine then performs a search on available WS and returns the information (in the form of a WSDL document) to the user. In order to download the WS information, the tool needs to be able to connect to a UDDI registry specified by the user . After downloading the appropriate data structures from the UDDI registry, the information required is extracted. This includes the description of the WS (provided when the service is registered) and the WSDL document of the service. If the WSDL document does not exist, the tool checks if sufficient information exists to be able to obtain the document, if this is not possible, the WS is ignored. When the correct information exists, the WSDL document is extracted and its description stored in an appropriate data structure to enable quick searching through its description. The tool browses through the UDDI registry until all the WS have been downloaded. Periodic runs ensure that the local information is updated. As regards the search algorithms involved, the user will supply keywords that are probably included in the description of the WS required. Therefore, we implemented a search algorithm with multiple criteria to go through the local information and find the best matches. These include searching for ALL keywords, ANY keyword, exact phrase, case sensitive search etc. Once the correct matches are found, they are returned to the user, or stored in an appropriate data structure to be used later on.
4. Workflow Definition and Invocation ToolThis tool allows the user to include results returned from the search engine, and, with the help of a number of rules, designs the invocation pattern of the services chosen. The workflow designed can then be executed. The user is able to edit the workflow until the desired configuration is achieved, but initial parsing of the WSDL document has to be performed. Since the WS found by the search engine will be invoked, the necessary information is extracted from the document, namely, input and output details from the WS, its access point, and SOAP encoding types. The WSDL document plays an important role as all necessary information is extracted from it. The WS workflow rules of execution (sequential, parallel, if-then, And, Or, etc.) handle the invocation pattern. A purposely-constructed rule engine is employed to define a number of rules and the way that they fire. The chosen services have their invocation stubs automatically constructed to enable the successful SOAP communication when triggering the flow of events. This will then be coupled with the rule engine so that each client stub is executed at the appropriate time.
CONCLUSIONThe workflow design interface complements the above-mentioned tasks as it includes both the search engine and the design tool. The search yields a number of WS that are dragged onto a design panel. A variety of components allow the user to specify the rules of invocation thereby designing the workflow - invocation follows. The outcome will be then be conveyed to the user to confirm or edit the configuration of the workflow.
- Stef Joosten et.al. An empirical study about the practice of workflow management, WA-12 report, 1994.
- Simple Object Access Protocel, http://www.w3c.org/TR/SOAP
- Web Services Definition Language, http://www.w3.org/TR/wsdl
- Universal Description Discovery Integration, http://www.uddi.org/
- Dan Gisol "Web services architect, Part 1: An introduction to dynamic e-business, http://www-106.ibm.com/developerworks/library/ws-arc1/ , April 2001.
- Zoran Zaev et al. "Professional XML Web services", Wroxx Press Ltd, 2001.