ࡱ > ^ 8 $ [ Z 0 | M bjbj== W W l 6 6 6 6 6 6 6 & t t t t < u T & y ] ) h ? A A A A A A $ e E 6 e ! 6 6
! ! ! 6 p 6 ? ! ? ! b ! 2 P 6 y ,L& ^f t @ ' . T
0 U 4 ! J > 6 6 6 6 TOC \o \h \z HYPERLINK \l "_Toc536763909" Chapter 2 PAGEREF _Toc536763909 \h 4
HYPERLINK \l "_Toc536763910" Related Works PAGEREF _Toc536763910 \h 4
HYPERLINK \l "_Toc536763911" 2.1 XML and related technologies PAGEREF _Toc536763911 \h 4
HYPERLINK \l "_Toc536763912" 2.1.1 SGML and XML PAGEREF _Toc536763912 \h 5
HYPERLINK \l "_Toc536763913" 2.1.2 DOM PAGEREF _Toc536763913 \h 5
HYPERLINK \l "_Toc536763914" 2.1.3 XSLT PAGEREF _Toc536763914 \h 5
HYPERLINK \l "_Toc536763915" 2.1.4 DTD PAGEREF _Toc536763915 \h 5
HYPERLINK \l "_Toc536763916" 2.2 Web Services and Technologies PAGEREF _Toc536763916 \h 5
HYPERLINK \l "_Toc536763917" 2.2.1 SOA PAGEREF _Toc536763917 \h 5
HYPERLINK \l "_Toc536763918" 2.2.2 SOAP PAGEREF _Toc536763918 \h 5
HYPERLINK \l "_Toc536763919" 2.2.3 WSDL PAGEREF _Toc536763919 \h 5
HYPERLINK \l "_Toc536763920" 2.2.4 UDDI PAGEREF _Toc536763920 \h 5
HYPERLINK \l "_Toc536763921" 2.2.5 WSFL PAGEREF _Toc536763921 \h 5
HYPERLINK \l "_Toc536763922" Chapter 3 PAGEREF _Toc536763922 \h 6
HYPERLINK \l "_Toc536763923" System Architecture PAGEREF _Toc536763923 \h 6
HYPERLINK \l "_Toc536763924" 3.1 Use Cases PAGEREF _Toc536763924 \h 6
HYPERLINK \l "_Toc536763925" 3.2 System Overview PAGEREF _Toc536763925 \h 7
HYPERLINK \l "_Toc536763926" 3.3 System Interactions PAGEREF _Toc536763926 \h 9
HYPERLINK \l "_Toc536763927" 3.3.1 Invoking Web Service using SOAP PAGEREF _Toc536763927 \h 10
HYPERLINK \l "_Toc536763928" 3.3.2 Invoking Web Service utilizing the UDDI Registry PAGEREF _Toc536763928 \h 10
HYPERLINK \l "_Toc536763929" 3.3.3 Querying UDDI registry in a DNS manner PAGEREF _Toc536763929 \h 11
HYPERLINK \l "_Toc536763930" 3.3.4 Category Search and Service Selection based on User Profile PAGEREF _Toc536763930 \h 12
HYPERLINK \l "_Toc536763931" 3.4 Major Components PAGEREF _Toc536763931 \h 13
HYPERLINK \l "_Toc536763932" 3.4.1 Deployment Environment PAGEREF _Toc536763932 \h 13
HYPERLINK \l "_Toc536763933" 3.4.2 Web Service Flow Control System PAGEREF _Toc536763933 \h 16
HYPERLINK \l "_Toc536763934" 3.4.3 Rule Evaluation Unit PAGEREF _Toc536763934 \h 17
HYPERLINK \l "_Toc536763935" 3.4.3.1 Event Matcher and Rule Manipulator PAGEREF _Toc536763935 \h 18
HYPERLINK \l "_Toc536763936" 3.4.3.2 Condition Verifier PAGEREF _Toc536763936 \h 18
HYPERLINK \l "_Toc536763937" 3.4.4 Data Manipulator PAGEREF _Toc536763937 \h 20
HYPERLINK \l "_Toc536763938" 3.4.5 Task Enactment Engine PAGEREF _Toc536763938 \h 21
HYPERLINK \l "_Toc536763939" 3.4.5.1 SOAP Service PAGEREF _Toc536763939 \h 22
HYPERLINK \l "_Toc536763940" 3.4.5.2 Service utilizing the UDDI Registry PAGEREF _Toc536763940 \h 23
HYPERLINK \l "_Toc536763941" 3.5 Exception PAGEREF _Toc536763941 \h 25
HYPERLINK \l "_Toc536763942" 3.5.1 Script Level Exception Handling PAGEREF _Toc536763942 \h 25
HYPERLINK \l "_Toc536763943" 3.6 Services PAGEREF _Toc536763943 \h 26
HYPERLINK \l "_Toc536763944" 3.6.1 SOAP Service PAGEREF _Toc536763944 \h 27
HYPERLINK \l "_Toc536763945" 3.6.2 Service publishing in the UDDI Registry PAGEREF _Toc536763945 \h 28
HYPERLINK \l "_Toc536763946" Chapter 4 PAGEREF _Toc536763946 \h 29
HYPERLINK \l "_Toc536763947" Web Service ECA Language PAGEREF _Toc536763947 \h 29
HYPERLINK \l "_Toc536763948" 4.1 ECA Language PAGEREF _Toc536763948 \h 30
HYPERLINK \l "_Toc536763949" 4.1.1 Language Implementation PAGEREF _Toc536763949 \h 30
HYPERLINK \l "_Toc536763950" 4.1.2 Design Choices PAGEREF _Toc536763950 \h 31
HYPERLINK \l "_Toc536763951" 4.1.3 Rules Structures PAGEREF _Toc536763951 \h 31
HYPERLINK \l "_Toc536763952" 4.2 Events PAGEREF _Toc536763952 \h 32
HYPERLINK \l "_Toc536763953" 4.2.1 Invocation Event PAGEREF _Toc536763953 \h 34
HYPERLINK \l "_Toc536763954" 4.2.2 Result Event PAGEREF _Toc536763954 \h 34
HYPERLINK \l "_Toc536763955" 4.2.3 Registration Event PAGEREF _Toc536763955 \h 35
HYPERLINK \l "_Toc536763956" 4.2.4 Withdrawal Event PAGEREF _Toc536763956 \h 37
HYPERLINK \l "_Toc536763957" 4.2.5 Status Event PAGEREF _Toc536763957 \h 38
HYPERLINK \l "_Toc536763958" 4.2.6 Acknowledgement Event PAGEREF _Toc536763958 \h 38
HYPERLINK \l "_Toc536763959" 4.2.7 Termination Event PAGEREF _Toc536763959 \h 39
HYPERLINK \l "_Toc536763960" 4.2.8 Exception Event PAGEREF _Toc536763960 \h 40
HYPERLINK \l "_Toc536763961" 4.3 Conditions PAGEREF _Toc536763961 \h 40
HYPERLINK \l "_Toc536763962" 4.3.1 Data Condition PAGEREF _Toc536763962 \h 41
HYPERLINK \l "_Toc536763963" 4.3.2 Flow Order Condition PAGEREF _Toc536763963 \h 43
HYPERLINK \l "_Toc536763964" 4.4 Actions PAGEREF _Toc536763964 \h 44
HYPERLINK \l "_Toc536763965" 4.4.1 Service Invocation PAGEREF _Toc536763965 \h 45
HYPERLINK \l "_Toc536763966" 4.4.2 Service Registration Action PAGEREF _Toc536763966 \h 47
HYPERLINK \l "_Toc536763967" 4.4.3 Service Withdrawal Action PAGEREF _Toc536763967 \h 48
HYPERLINK \l "_Toc536763968" 4.4.4 Service Localization Action PAGEREF _Toc536763968 \h 49
HYPERLINK \l "_Toc536763969" 4.4.5 Service Selection Action PAGEREF _Toc536763969 \h 50
HYPERLINK \l "_Toc536763970" 4.4.6 Service Status Action PAGEREF _Toc536763970 \h 51
HYPERLINK \l "_Toc536763971" 4.4.7 Exception Handling Action PAGEREF _Toc536763971 \h 51
HYPERLINK \l "_Toc536763972" 4.4.8 Termination Action PAGEREF _Toc536763972 \h 52
HYPERLINK \l "_Toc536763973" Chapter 5 PAGEREF _Toc536763973 \h 53
HYPERLINK \l "_Toc536763974" Algorithms PAGEREF _Toc536763974 \h 53
HYPERLINK \l "_Toc536763975" 5.1 Resource Localization PAGEREF _Toc536763975 \h 54
HYPERLINK \l "_Toc536763976" 5.2 Service Localization in the Service Oriented Architecture PAGEREF _Toc536763976 \h 57
HYPERLINK \l "_Toc536763977" 5.2.1 Service Oriented Architecture PAGEREF _Toc536763977 \h 57
HYPERLINK \l "_Toc536763978" 5.2.2 Distributed directory of services PAGEREF _Toc536763978 \h 59
HYPERLINK \l "_Toc536763979" 5.2.3 Recursive Queries PAGEREF _Toc536763979 \h 59
HYPERLINK \l "_Toc536763980" 5.2.4 Iterative Queries PAGEREF _Toc536763980 \h 59
HYPERLINK \l "_Toc536763981" 5.3 Service Selection and Matching PAGEREF _Toc536763981 \h 61
HYPERLINK \l "_Toc536763982" 5.3.1 User Profile Matching PAGEREF _Toc536763982 \h 62
HYPERLINK \l "_Toc536763983" 5.3.2 Issues in Service Evaluation PAGEREF _Toc536763983 \h 69
HYPERLINK \l "_Toc536763984" 5.3.3 Publication of Service Characteristics PAGEREF _Toc536763984 \h 69
HYPERLINK \l "_Toc536763985" 5.3.4 Service Evaluation Program Deployment PAGEREF _Toc536763985 \h 70
Chapter 2
Related Works
2.1 XML and related technologies
Markup is the term applied to any set of codes or tags added to the contents of a document in order to indicate its meaning or presentation in a structural manner. Without markup, documents are limited to the mere presentation of content data. Since the data content is not self-defined in the document, any special meaning or process that may be applied to the data must be encoded outside of it.
Markup allows the inclusion of metadata in the document itself. However, this does not imply that the document will be semantically richer, or easier to work with. Proprietary markup mechanisms have been around for a long time, each adopting different conventions and meanings for the vocabularies they define, examples include GhostScript and Rich Text Format. However, these markup structures are totally proprietary to a particular application, there are not that many applications can use the same markup language.
2.1.1 SGML and XML
Standard Generalized Markup Language (SGML), a generalized markup metalanguage that allows people to create their own tags to describe their own data, was clearly a necessity, but it was too complicated for most purposes. This is why, in September 1998, a special W3C (the World Wide Web Consortium) group headed by Jon Bosak began working on a simplified version of SGML, which could capture most of its power, while avoiding the complications that make it unpopular until then. The result was the eXtensible Markup Language, XML.
XML's strongest point is its ability to do data interchange. Because different organizations (or even different parts of the same organization) rarely standardize on a single set of tools, it takes a significant amount of work for two groups to communicate. XML makes it easy to send structured data across the Web so that the meaning of the data does not get lost in translation. XML has significantly simplified business-to-business transactions on the web.
2.1.2 DOM
2.1.3 XSLT
2.1.4 DTD
2.2 Web Services and Technologies
2.2.1 SOA
2.2.2 SOAP
2.2.3 WSDL
2.2.4 UDDI
2.2.5 WSFL
Chapter 3
System Architecture
3.1 Use Cases
Before going into the technical and architectural discussion of the system, it is more beneficial to define the four primary user types for the whole system.
Service Providers are the internal or external parties who create the Web Service that can be invoked. These individuals should also hold the responsibilities to publish their services.
A System Administrator who manages the run-time environment of the system and also the local UDDI registry.
Service Integrator defines the business rules and encapsulates it in the form of rule script in the rule repository.
The client of the system is the person who sends a request to the system and receives the results by the Web Services.
Figure 3.1: Use Cases for the system
3.2 System Overview
In this section, we describe the overall architecture of the system and the manner in which individual system components interact. The system normally resides in the application service provider environment. This can be viewed as a domain which contains every components of the Service Oriented Architecture. In the application service provider environment, there can exist local services provided by the local service provider. An UDDI registry can also be useful to keep track or local or even remote services. The system connects to the remote service providers and UDDI registries through the Internet.
In the local domain, the system can be a run-alone application and also a Web Service deployed in a SOAP enabled web server. The later deployment is shown in Figure 3.2. As being defined in the SOAP standard, the request and the reply are encoded in XML. The underlying protocol being used in this case would be HTTP. The role of the Web server is to intercept events in HTTP request format and routes the Event to the ECA Rule Engine.
Figure 3.2: Deployment of the Rule Engine
The rule engine system is event-driven and only reacts to incoming events in the form of SOAP requests. Within the rule engines, there resides a set of rules. These rules define the exact behavior of the system. These rules contain three basic elements, events, conditions, and actions which are defined in XML.
When it is being deployed as a service, the system is connected with the outside world through the SOAP request dispatcher. When the dispatcher receives a SOAP event for the system, it routes the request to the System. This is considered an event. Other than job routing, the dispatcher also responsible for parameter passing.
In brief, the Event clause defines a triggering event which corresponds to an incoming SOAP message in our case. The Condition clause determines whether the action should be executed based on the data contents within the SOAP message. The Action clause defines the set of web services to be called when the rule is triggered. The web service description embedded within the action clause can be a complete SOAP description or some partial information. In the case of partial information, our system would query an UDDI registry and try to fill out all the information needed at run time.
The rule engine can then process the event, verify the rule and invokes a SOAP service if all the conditions are satisfied. On the other hand, the system also supports UDDI technology. Instead of specifying the full information of the intended service, the system can look up the service in the UDDI registry. All these are being handled by the execution core in the rule engine. Results are returned and data integrator is responsible for data transformation and integration.
Extensions in the current UDDI architecture has also been proposed and implemented in the system. Service selection does not only based on static characteristics such as name or category, dynamic nature also plays an important role in the service selection process. At run time, a user specification profile would be matched against service characteristics and only the most desired service would be invoked. Another extension is the publishing of remote UDDI registries in the local UDDI registry, the system is capable of recursive querying in such an environment.
In some situations, meta-service would be desired. By combining several existing services together usually can result in a more powerful, flexible service. Our system can fully taking advantages of using meta-service and easily integrate to the architecture. The system is SOAP enabled and seeing from outside, it is just another service. In other words, by fully utilizing the session control capability, the system can have two different sets of rule scripts loaded up at the same time.
The system can provide the just in time service integration and does not require recompiling any source programs. Once it is put into place, it learns the web services within the domain using the UDDI Registry. The System integration programmer only needs to write the script to represent the flow logic of the system and instead of letting the user to call these services separately, it becomes a one-stop invocation process.
3.3 System Interactions
We are going introduce the overall architecture briefly using some scenarios. The first one involves the less interacting parties, only the Service Requester, Rule Engine, and the Web Service. In the subsequent situations, other components in the Web Service Paradigm will come into place.
3.3.1 Invoking Web Service using SOAP
The first scenario is the base case in which all information is embedded in the script. Upon receiving a service event from the client, the system invokes the web service corresponding to the incoming event. When the service is executed and result being returned to the system as an event. The event causes another service to be invoked. When the final result being returned to the system corresponding to the termination event of the business process, the results are passed back to the client.
Figure 3.3: Message Sequence diagram of SOAP interaction
3.3.2 Invoking Web Service utilizing the UDDI Registry
The second scenario requires the utilization of the UDDI registry. In this case, full information is not included in the script reside in the rule repository. Some more general information such as the specific service name or even the service type is included in the rule. From the viewpoint of the client, the system behaves exactly the same, it just stands there and waits for request from client. Whenever a rule is triggered by an incoming event, the system first sends a request to the UDDI registry querying the registry on the service. The information being returned includes the location of the service and how to invoke it. The system can then use the information to invoke the service directly.
Figure 3.4: Message Sequence diagram for service invocation involving UDDI
3.3.3 Querying UDDI registry in a DNS manner
There is a trend where corporations begin to merge in order to save cost. In this case, it is not possible to merge all the existing infrastructures such as the local UDDI registry at once. Give another example, a local UDDI registry usually contains entries for the local services, and it cannot keep track of all the remote services in every external domain. In order to adapt to these situations, we proposed an extension to the existing UDDI architecture. Every UDDI registry is only responsible for the local services, but each registry contains entries for other remote registries as services.
When the client submits a request to the system, the system queries the UDDI registry for the requested service but this particular registry does not contain any information about this service. Instead, the UDDI registry returns a list of UDDI registries that might contain information about the requested service. After the system obtains the list of registries, it would query them one by one recursively and try to localize the details of that service. This implementation is very similar to what a Domain Name Server would do to keep track of the host names within a particular domain.
Figure 3.5: Message Sequence diagram for querying UDDI registry in a DNS manner
3.3.4 Category Search and Service Selection based on User Profile
In some cases, services are classified in categories. The exact fingerprint such as the service name is not even known. Our system can adapt to this scenario by doing a category search on a particular category of service. Please keep in mind that since we are searching a category of service, the results usually come back as a list of available services. We also make one step further to screen these services by incorporating the ideas of end point description language as well as a user profile. Each user is mapped to a set of attributes within the system. Such attributes usually describe the requirements of the user, such as the cost constraints, desired performance level, user privilege, etc.. If an UDDI query returns more than one matches, such information would be used to invoke a service evaluation service. This particular service would analyze the user profile data with the service endpoint description. The level of compatibility of both would be returned as a score. At run time, the service with the highest score would be invoked by the system.
Figure 3.6: Message Sequence diagram for service selection based on User Profile
3.4 Major Components
3.4.1 Deployment Environment
As we discussed earlier, the system uses a Web server to connect with its external environment. The SOAP dispatcher usually resides in the Web Server. When an SOAP request comes in, it dispatches the event accordingly. To integrate in this environment, our rule engine must register itself in the SOAP dispatcher. External events arrive as SOAP requests over HTTP are directed to the rule engine.
There are many SOAP implementations available. In our case, we are using the Apache SOAP version 2.2, this is a free tool which can be integrate with the Apache Tomcat Servlet Engine. At run time, the SOAP implementation is yet another Java Servlet running in the Servlet engine. Every SOAP request arrives as a HTTP Post request to the server, the SOAP Envelope is embedded in the body of the request.
The deployment of the Web Service to the server basically involves exporting the Java Class to a directory set up as the run-time classpath of the server. A deployment descriptor must also be sent to the server during deployment so that the SOAP request dispatcher stores the mapping and methods visible to the outside world. Figure 3.7 shows the deployment descriptor for the rule engine. The key information is the Java class name and which is eca.ruleEngine.ECARuleEngineClass and the method exposed to the external environment, which is incomeEvent.
org.apache.soap.server.DOMFaultListener
Figure 3.7: Deployment descriptor for the Rule Engine
Once the SOAP engine receives the descriptor, it stores the information in an internal data structure permanently and the ECA Rule Engine service is ready to get activated. The overall runtime structure is as illustrated in Figure 3.8 The web server lietens for HTTP request and when it got any Java Servlet request, it forwards the request to the Servlet Engine (Apache Tomcat in our case). The Servlet engine loads the requested servlet and dispatches the HTTP request to that instance of the Servlet class for processing. Since the Apache SOAP Engine is servlet based, the SOAP engine is being loaded by the Servlet Engine when the web server receives a request to the servlet in which the payloads of the request is an SOAP Envelope. A complete HTTP request to the rule engine is shown in Figure 3.9. The SOAP Engine does another class load up and in this case, it is the SOAP Service class, any implementation of Web Services or even our Rule Engine.
Figure 3.8: Deployment environment for the Rule Engine
POST /soap/servlet/rpcrouter HTTP/1.0
Host: tazdevil
Content-Type: text/xml; charset=utf-8
Content-Length: 666
SOAPAction: ""
Figure 3.9: HTTP Request to the Rule Engine
3.4.2 Web Service Flow Control System
The entire system is represented as a class diagram in Figure 3.10. Rules that control the integration of services may be written manually or they can be composed with tools. These scripts are stored in the script repository where they may be accessed by the rule engine. Once the rule engine has parsed the scripts containing the rules, it can then receive events from services and look for rules that should be triggered.
Figure 3.10: Class Diagram for the ECA Rule Engine
When rules are triggered, the rule engine passes a service request list to the task enactment engine. This list consists of all the services that were specified within the action component of the triggered rule. It uses the UDDI Registry to find the WSDL documents of the specified service. Upon receiving the documents, the task enactment engine parses the WSDL documents and invokes the service based on the definition.
Note that Figure 3.10 shows one ECA Rule Engine for simplicity. In fact, one instance of the Rule Engine can be viewed as a piece of Web Service from the outside.
When the system starts, all the classes are instantiated by the SOAP environment. At this time, the script in the rule repository is parsed and a DOM tree is built. We will discuss how the rule engine processes event and requests services in next section.
Each new event is forwarded by the SOAP enabled Web Server to the ECA Rule Engine class. The incoming event is represented an internal data structure for processing. This object holds the events name, type, and parameters that are all received as part of the SOAP request. An event satisfying a rule coarse usually results in triggering an action.
The main architecture of the Rule Engine contains four major components, Event Matcher, Condition Verifier, Data Manipulator. After a Service Request passes through all these blocks and identified as triggered, it would be passed to the Task Enactment engine for action invocation.
3.4.3 Rule Evaluation Unit
The basic building blocks in the rule engine are rules, this Rule Evaluation Unit block is responsible for accessing incoming event and marks the rule in the rule engine as a triggered event. For each rule, there are two main criteria to be satisfied, first the event(s) specified in the rule must be received, and second, the condition must be evaluated true. Two main modules, the event matcher and the condition evaluator handle these requirements.
Figure 3.11: Class Diagram for the Rule Evaluation Unit
3.4.3.1 Event Matcher and Rule Manipulator
When the system is initialized, a set of rules would be loaded to the system. Internally, this set of rules would be transformed into a DOM structure. In a nutshell, it is a tree structure storing all the information embedded in the script. Every rule usually contains three parts, event, condition and action. Internally, this data structure is being managed by the Rule Manipulator which provides an API for rule management. When an external event comes into the system, it is being matched against the event clause in the DOM structure. Whenever the Event Matcher finds a match for the event, it would signal the Condition Verifier to verify the condition.
3.4.3.2 Condition Verifier
The rule is then passed to the Condition Verifier and the condition clause in the rule would be evaluated. Generally, the Event Matcher only evaluates static information such as the event name. The Condition Verifier is responsible all the dynamic condition verifications. There are two aspects in this, data content checking and flow logic checking.
In data content verification, the Condition Verifier basically checks the data being passed in with the event. If we take checking the stock quote for an example, data checking can be a test to check whether the stock price is higher than a certain amount. If it is higher, system can initiate a sell order and if not, the stock would be held.
This check is implemented using the XSLT technology. XSLT can transform an XML document and has a full data manipulation capability. As a result, by conforming to the standard, the system does not need to implement its own data manipulation scheme. Furthermore, it is easier for the script writer since XSL is an open standard.
A condition clause defined in the ECA Script appears as in Figure 3.12. It always points to an XSL file and in the example, it is the CountListSize.xsl. The example shows that that a Bubble Sort service which only provides service if and only if the list contains less than 30,000 elements. The corresponding XSL file is illustrated in Figure 3.13.
Figure 3.12: Condition Definition in the ECA Script
truefalse
Figure 3.13: Condition Scheme in an XSL file
The Condition Verifier would fetch the file and uses this to transform the input data passed in with the event. Using the XSLT and the same core technology with the data integrator, the condition evaluator can produce results either true or false. Based on this result, the Condition Evaluator would decide whether the rule should be triggered and create a Service Request out of it.
The system also checks for flow logic. The system keeps a history list such as incoming event and triggered rule. As a result, a condition clause can specify an event if to safeguards the flow logic at run time. This kind of condition checking is best to arrange services to be called in a strict sequence and synchronization use.
Figure 3.14: Flow Order Condition definition in the rule script
3.4.4 Data Manipulator
In the flow engine, the system determines the control flow of the whole business process. In most of the cases, services provide data contents which need to be forwarded to the next service down the road. Given all the different paradigms of implementation, it is impossible to provide a super set of data that can be used for all the services. Some services might only take a subset of a modified set of data items in XML format. It is not hard to imagine that services from different domain might require the same data item with a slightly different name. For example, some stock quote system expect a parameter name as StockQuote but some might want Quote.
Changing the tag or the element name is a simple transformation. In other cases, some other forms of transformations have to be achieved. The complete set of requirements include structural changes of the whole XML documents, arithmetic computation and manipulation of numerical values, string manipulation functions, and transformation based on run time decision (if-else based on data contents).
Instead of implementing a full data transformation engine in the rule engine fulfilling all the above requirements, a more dynamic plug-and-play approach is being employed. The script would specify an external XSL file whenever data integration is needed. The Data Manipulator would invoke an XSL Transformer which takes the parameter as one input and the XSL file as another and carries out the transformation. The end result is therefore an XML document which would be put in the Service Request object and pass to the Task Enactment Engine.
3.4.5 Task Enactment Engine
The purpose of the task enactment engine is to take a request for a service and actually execute that service. The classification of service usually falls into two main categories, either it is a fully defined SOAP service or a service that needs to be looked up in the UDDI Registry and invoke when all the information is available. The Task Enactment Engine takes a service request and calls the invoke method for that object. The implementation of the Service Request is that Service Request is the base class with protected parameters such as the input parameters, each child class would implement the virtual method invoke and carry out any preparations, such as service look up, for that service. The class diagram is given in Figure 3.15. This approach gives a certain degree of extendibility in the architectural level. When there is a new kind of service to be supported in the system, a new class extending the Service Request class and the corresponding handling functions when the script is parsed.
Figure 3.15: Class Diagram of the Task Enactment Engine
3.4.5.1 SOAP Service
A SOAP service usually is a fully defined service with enough information that it can be invoked alone without requesting information from any external system. The system supports two different kinds of definitions in the script. The Script can either embed all the information or can include a WSDL document for the targeted service.
An example for the first case is shown in Figure 3.16. It shows an action definition for a Quick Sort service. All the information needs to invoke this service is fully specified, for example, the URL is specifying the SOAP server as well as the service id which identifies the service.
Figure 3.16: Action Definition in the ECA Script
A corresponding example for the second case is as Figure 3.17 and 3.18. The script specifies the service, method, and the WSDL file. This effectively separates the interface and implementation of the service and takes the object oriented approach. There is no particular advantages of one approach over another but rather depends heavily on the nature of the service.
Figure 3.18: Part of a WSDL document defining invocation mechanism
No matter the approach taken in defining the action in the script, this kind of definition is very easy to integrate because everything is known when the script is first written. However, the same feature does pose some limitations. Since every piece of information must be filled in at compose time, the Service Integrator must have knowledge of the services available for the whole domain. Some dynamic features, such as load balancing and choice of service based on quality cannot be handled easily.
3.4.5.2 Service utilizing the UDDI Registry
With the growth of UDDI registry, a more flexible approach can be achieved. UDDI registries are basically service repositories with a public interface to get queried and return search results. The registry usually classifies services into categories and serves WSDL documents when being queried. In other words, a client can send a query to a UDDI registry for a web service based on some criteria ranges from the service name to something more general such as the service category.
An example of search based on name is shown in Figure 3.19:
Figure 3.19: Action definition involving UDDI registry
The UDDI Service Request class would first query the UDDI registry and upon getting back the information, it fills up the SOAP request when the invoke method being called. In the current standards, an UDDI registry only contains information about the interface and the implementation of the Web Services. We envisioned that there would be significant extensions in this respect. A very obvious would be the end-point description language which gives information about the quality, and dynamic nature of the service. Coupled with a user profile domain model, the system can match the need of the user to the service at run-time. This ensures the system can find the most suitable service for each client.
In a category search such as the example listed in Figure 3.20. It usually produces a list of services matching satisfying the query. This is where the service end-point description comes into place, instead of selecting a service out of the pack randomly, a service evaluator is invoked. Basically, the service evaluator takes the user profile submitted by the system, and returns a score given each of the service end-point description. When the invoke of the UDDI Category Service Request is being called, only the service with the highest score would be invoked.
Figure 3.20: Action definition for a category search
Given all these advantages, this approach does contain some potential problems. Since the UDDI registry is the brain of the design, it would be the single point of failure except multiple UDDI registries are used. Although this design is flexible enough, the system must still have knowledge of at least one UDDI registry. It also increases the traffic and network delay by a factor of two. Fortunately, with the advance of computer hardware and locating a relatively close UDDI registry, the negative impacts of this should be able to be minimized.
3.5 Exception
Since services are generally at remote locations, it may happen that they may not execute or return a value (in the form of a new event). We have based our system on at-most-once call semantics which means that if a service does not return a value within a specified amount of time, we raise an exception.
3.5.1 Script Level Exception Handling
Exception can be caught whenever an action is carried out, instead of building a class handling all the exceptions or stopping the whole business process in the middle, there is an exception handling mechanism in the script level. In the action clause of the script, it can specify an Exception clause. This is just a simple tag which specifies the event the Task Enactment Engine would fire when an execution occurs at run time. It is up to the script writer whether this feature is utilized in the script.
Figure 3.22: Exception handling rule definition
This exception event takes the format of the normal event, in other words, an exception handling needs not to be a special event but rather an existing event definition. However, special attention should be paid to raise exception in the exception handling rule. Cycles can occur and the current implementation does not contain any detection against such situation. It is recommend that an exit exception handling rule be which put the system in a it is strongly recommends that an exception handling event should not use another exception event which may result in cycles.
3.6 Services
As we have mentioned, the action component in the rule is typically used for invoking distributed services. We have not said much about these services aside from the fact that they are programs or distributed objects and that the system, not the script writer, determines how to invoke them. In this section, we will take a closer look at services that can become make up the whole service web paradigm.
3.6.1 SOAP Service
A SOAP service is defined as a process that can be invoked using the SOAP over HTTP protocol. Parameters can be passed within the invocation SOAP envelope in XML format. Results are being passed back in the return SOAP envelope also in XML format. A typical service can be anything from a re-engineered legacy system module to a brand new software component that has been built specifically for our system. There are no limitations on what these services are implemented, they can be written in C/C++, Java or even Perl.
If using Java technology, in order to build a service, a SOAP service class is created which is a wrapper for the actual service that is to be invoked. This service class is being invoked by the SOAP service dispatcher in the Web Server and is responsible for parameter handling. The actual service may be business logic that is contained within this same class, but would more likely be an external call from this class. This class is then deployed in an SOAP service provider usually in the form of a Web Server. A simple deployment descriptor is being shown in Figure 3.23. The example provided is to deploy a service in the SOAP implementation of the Apache Web Server.
org.apache.soap.server.DOMFaultListener
Figure 3.23: Deployment descriptor for a Web Service in a SOAP platform
There are many tools that aid the whole deployment process. For example, the IBM Web Service Toolkit provides a GUI-based tool wsdlgen. This is a tool that takes either a Java class, EJB Jar files, or even a COM Dispatch Interface and creates the corresponding WSDL files and the deployment descriptor for that service.
Figure 3.24: Screen shot of the WSDL Generation tool
3.6.2 Service publishing in the UDDI Registry
All the services published in the UDDI Registry require service description document (WSDL). However, services do not needed to be SOAP-enabled, but rather SOAP is only one of the service binding methods. SOAP is the most popular binding method and widely used today. Our system focuses on invoking services using SOAP.
Service is ready to be published when the WSDL files are ready, in practice, there are two WSDL files, one refers to the interface and the other refers to the implementation. The interface document defines the input, output message format and how the exporting method utilizes theses messages. The implementation defines a binding method for that particular interface, for example, a SOAP binding usually gives the location (URL) of where the service can be invoked. These documents can be hand-written or using tool such as the WSDL Generator.
Chapter 4
Web Service ECA Language
In this chapter, we will discuss the heart of our system: the rule engine. In a nutshell, the rule engine reacts to incoming events issued either by external environment or by the rule engine itself. These events are transformed to service requests and usually result in more events being pushed back into the rule engine.
All the causes and effects of the events and the resulting actions are encapsulated in the form of rules. These rules are part of a scripting language based on the Event-Condition-Action paradigm and control the interactions between distributed services. The basic idea is simple: at the occurrence of an event, any number of rules may be triggered. If the condition clause is satisfied for that rule, then the actions contained within the rule are carried out.
Figure 4.1
We have named our scripting language Extensible Web Service Work Flow Language. This language is base on the Extensible Service Integration Language but with some major enhancements tailored for the Web Services Environment powered by the most up to date standards technologies. We will discuss in full details of the language which leads to the implementation of the rule engine.
4.1 ECA Language
Within the rule engine, the script is primarily a collection of ECA rules. The rule engine can have several of these scripts loaded at any time, so a script requires a name. The rule engine also keeps a session ID to each instance of the script. This information is not used directly as part of the rule invocation mechanism, but can be useful for referencing and managing scripts. Once a script is created, it is stored in the script repository and the rule engine retrieve and parse the scripts during initialization phase.
We have chosen Event-Condition-Action paradigm because we feel that it closely models the interaction of web services. Moreover, the concept of state transition and the invocation of services, given pre-conditions and triggering events, has solid theoretical support and has been investigated within the concept of Extended Finite State Machines, Petri-Nets and Logic specifications. (??? Contained in richards thesis)
4.1.1 Language Implementation
We have chosen to encode scripts in XML because text based XML document allows for scripts to be passed between servers using the HTTP protocol, and can be easily represented using the Document Object Model. Other advantages of using XML include efficient parsing of the script by an XML parser, portability and expressiveness of the scripts, and ease of use in language design and implementation.
Using XML to represent the ECA language allowed us to specify the grammar for the script by creating a DTD or an XML schema. XML parser such as Xerces (maintained by Apache) can be used to detect syntax and grammatical errors before they reach the rule engine. Within the rule engine, the XML Script is parsed and turned into a data structure known as the DOM tree. This structure can be managed handily by using the APIs provided by the parser.
Another advantage of using XML is that it provides ease of change as the language evolves. As we determine that more information or language features should added to the rule scripts, new attributes or tags can be added to the DTD and then included in the script.
Despite of all these overwhelming advantages, there are some limitations to the whole design. For example, the System Administrator is the person in charge of maintaining the system components such as the XML parser and XSL Transformer. This person must be extremely familiar with XML technologies and the API related to the parser being used. Since all these are standards maintained by outside parties, it definitely some learning time and efforts to keep up with these on-going changing standards. The Service Integrator in turn must know and adhere to the syntax and schematic of the rule script that defines the behavior of the rule engine.
4.1.2 Design Choices
Our language consists of a fair mix of attributes and elements. We have followed the general guidelines of XML for placing data contents within attributes and elements. In other words, elements are used to specify components of another element while attribute represents an aspect, or characteristic of an element.
4.1.3 Rules Structures
A rule is the most basic structure and the core building block of the work flow language. A rule consists of three main components, events, conditions and actions, which would be discussed in detail in the following sections. A basic overview between the three components is illustrated in figure 4.2. Within a rule, there can consist of a number of events, these events form an event expression which would either evaluated to be true or false at any given time. The same structure also applies to the condition clause in each rule. When the rule engine intercepts an event and if the event expression is evaluated to be true, the conditions would then be checked upon and evaluated. If the conditions turn out to be true, the actions listed in the rule would be executed.
Figure 4.2: Structure of the ECA Script
4.2 Events
The event component of a rule is a logic formula containing one or more expressions that are composed of individual events and the logical connectives, AND and OR, and is defined as
Figure 4.3: DTD for ECA Event
An event expression may itself contain expressions (for clarity, we refer to them here as sub-expressions, each of which may be composed of further sub-expressions). An expression containing an OR is satisfied if one of its subexpressions are satisfied. An expression containing AND is satisfied if and only if both of its subexpressions are satisfied. As expected, this definition applies recursively to each subexpression.
In this version of the language, we have only allowed binary operators to be used as connectives between sub-expressions. The grammar (DTD) can easily be changed to allow a sequence of sub-expressions separated by either AND or OR operators. It was easier to implement the rule engine using only binary operators, although with a little bit of work this can be changed. In any case, binary boolean operators are just as expressive, and there is no question as to operator precedence. For example, (a ^ b ^ c) can be written as (a ^ (b ^ c)).
The system recognizes a set of events and each event usually represents a function of the system. In this section, a detail discussion would be carried on every type of event in the system.
Figure 4.4: Event Classification
Invocation Event
This is the event to signal the system to invoke a Web Service. This event usually contains parameters such as the Transaction ID, Service Name, and the Input Parameters. The service name is used to identify the service intended to invoke, and the input parameters are the data items that need to pass to the service. The Transaction ID is used to aid the system to maintain session-control at run-time.
Parameter NameData TypeEvent TypeStringService NameStringInput ParametersString (XML Format)Transaction IDLong IntegerWSDL Document URL (optional)StringFigure 4.5: Parameter List for Invocation Event
A example of the invocation event is illustrate in Figure 4.6.
$input_parameters
Figure 4.6: Body of the Invocation Event
Result Event
This is the event where the service returns results to the system. The parameters being carried are the Transaction ID, Service Name, and the Result. This event usually responds to an Invocation Event and represents the successful completion of the remote service. The Transaction ID is once again used by the system to map the result to the appropriate instance of rule waiting for that event.
Parameter NameData TypeEvent TypeStringService NameStringResultString (XML Format)Transaction IDLong Integer
Figure 4.7: Parameter List for Result Event
An example of the result event is illustrated in Figure 4.8.
$result
Figure 4.8: Body of the Result Event
Registration Event
This is the event to signal the system to publish a Web Service in the UDDI Registry. This event can be classified into two cases based on the UDDI standards. For each Web Service listing, there exists two different description documents, the Interface and the Implementation.
The interface document contains information such as the Message Format, Port Type, and the Binding information. The Message part basically defines input and output message to the service for each method. The Port Type defines the methods exposed to the client and how the messages are utilized when the methods are being called. A combination of these two usually provide the complete details on the input and output parameters for each method provided by the service. The Binding part defines how the service can be bound, for example, through SOAP.
The implementation document contains information such as the Implementing Interface, and the Service Port. The interface part basically gives the location (URL) of the interface document which is being implemented by this document. The service port gives all the technical information to bind the service and how to invoke it. For SOAP, this definition usually contains the address (URL) of the service provider.
In order to register an interface, the Interface Registration Event gets fired. This event usually contains parameters such as the Interface Name, and the Web Service Interface Document.
Once the interface is published in the UDDI registry, the implementation can be published implementing this particular interface. Another event, the Implementation Registration Event is needed. For this event, the input parameters usually include the Service Name, and the Web Service Implementation Document.
Parameter NameData TypeEvent TypeStringInterface NameStringWeb Service Interface URLStringFigure 4.9: Parameter List for Interface Registration Event
An example of the interface registration event is illustrated in Figure 4.10.
Figure 4.10: Body of the Interface Registration Event
Parameter NameData TypeEvent TypeStringService NameStringWeb Service Implementation URLStringFigure 4.11: Parameter List for Implementation Registration Event
An example of the result event is illustrated in Figure 4.12.
Figure 4.12: Body of the Implementation Registration Event
Withdrawal Event
This is the event to tell the system to delete a services listing in the UDDI Registry. As in the case of Service Registration, there are the Implementation and Interface withdrawal.
Withdrawing an implementation is more common, this is needed when a service being undeployed, re-implemented, or migrated. In the later two cases, service registrations are needed in order for the modified service to be functional. The Implementation Withdrawal Event usually takes parameters such as the Service Name. This is enough since eventually, the UDDI registry can do a search on the name and delete the corresponding listing.
There are cases where an interface needs to be undeployed, this usually caused by a change in the input-output parameters of a method, or the number of methods being exposed. By issuing the Interface Withdrawal Event, the system can trigger a service withdrawal action. This event usually includes the Interface Name as the lone parameter. Please keep in mind that unlike un-publishing an implementation, removal an interface can have some unforeseen side-effects. There might exist some implementations referencing to this particular interface. By removing the interface listing, the implementation would become useless.
Parameter NameData TypeEvent TypeStringInterface NameStringFigure 4.13: Parameter List for Implementation Withdrawal Event
An example of the Interface Withdrawal event is illustrated in Figure 4.14.
Figure 4.14: Body of the Implementation Registration Event
Parameter NameData TypeEvent TypeStringService NameStringFigure 4.15: Parameter List for Implementation Withdrawal Event
An example of the Implementation Withdrawal event is illustrated in Figure 4.16.
Figure 4.16: Body of the Implementation Registration Event
Status Event
The status event is issued when a service request is issued without any reply after a certain period of time. This event has very similar parameter list as Invocation Event since it can be considered as a scale down Invocation Event. The input parameters include Service Name, and Transaction ID. Please note that not all the services provide a status querying interface, this event cannot be applied to all the services.
Parameter NameData TypeEvent TypeStringService NameStringTransaction IDLong IntegerFigure 4.17: Parameter List for Status Event
An example of the Status event is illustrated in Figure 4.18.
Figure 4.18: Body of the Status Event
Acknowledgement Event
This event is the reply when a service receives a status check. This is equivalent as a heartbeat notifying the system that the service is still running. The event usually passes in the following parameters, Service Name and Transaction ID. Once again, if the service does not support the status check, this event is not available.
Parameter NameData TypeEvent TypeStringService NameStringStatusStringTime to Complete (optional)Long IntegerFigure 4.19: Parameter List for Acknowledgement Event
An example of the Acknowledgement event is illustrated in Figure 4.20.
Figure 4.20: Body of the Acknowledgement Event
Termination Event
This event signals the system that the termination condition has been met. The system should release all the shared resources and return all the calculated results to the client. The lone parameter is the Result being passed back to the caller.
Parameter NameData TypeEvent TypeStringResultString (XML Format)Figure 4.21: Parameter List for Termination Event
An example of the Termination event is illustrated in Figure 4.22.
$result
Figure 4.22: Body of the Termination Event
Exception Event
This event is issued when an exception is caught. Exception handling can be defined in the script level where an exception handling rule can be defined explicitly. An exception event contains the service name the system tries to invoke but fails, an error status describing the problem, and the input parameters so that the system can reuse that again. The original transaction id is also included for transaction id handling purpose.
Parameter NameData TypeEvent TypeStringService NameStringError StatusStringInput ParametersString (XML Format)Transaction IDLong IntegerFigure 4.23: Parameter List for Exception Event
An example of the Exception event is illustrated in Figure 4.24.
$input_parameters
Figure 4.24: Body of the Exception Event
4.3 Conditions
Condition is the second component in the rule. Events usually signal the system to carry out specific tasks. However, in a highly dynamic and complex Web Service environment, there must exist some mechanism to verify the dynamic nature of the system to determine whether actions should be triggered. This is when the condition clause comes into place. Condition verification includes checking against data items passed in by an event as well as flow order checking to make sure events and actions happen in a pre-defined order. If the condition expression does not exist, or if it is satisfied, the action component of the rule would be executed. A Condition element is defined as
Figure 4.25: DTD for ECA Condition
The system recognizes two different categories of conditions and they are handled very differently at run time. Data verification needs a data verification engine to parse the parameter which is in XML format. Control Flow verification is done by comparing the occurrence of event or action in a history list kept by the system. The classification of the conditions is shown in Figure 4.26.
Figure 4.26: Condition Classification
4.3.1 Data Condition
Data Content condition usually falls into two categories, numerical checking and also the structural checking of the XML parameters. Numerical checking usually verifies a particular data is within range, equal to a value, or satisfies certain numerical conditions (even and odd). Structural checking can verify the hierarchy of the XML parameter, or even the number of occurrence of a particular element.
During the design of the script, there is a dilemma of whether we should include Data Manipulation Construct directly in our script and implement a full data parsing and verification function in the rule engine. By examining the existing related standards and technologies, we came out with a more flexible and convenient approach. We decided that the system should not define its own data manipulation language but rather makes use of the XSL Transformation Engine. The XSL originates as a data transformation language which defines how an XML document can be transformed to another XML document. There is a ready set of functions to do structural manipulation which can be utilized as structural checking using the built-in if-else and the case statement in XSL. Numerical checking can also be achieved since XSL also includes a set of arithmetic functions.
With the condition checking utilizing XSL technology, the Condition Verifier block in the Rule Engine passes the XML data contents and the specified XSL file to an XSL Transformation Engine. A boolean value would be returned to the system. As a result, the input and output parameter sets for the two Data Content Condition are the same, the input parameters include the Input Parameter (from the event), and the XSL File (defined in the script).
Parameter NameData TypeInput Parameters (from event)String (XML Format)XSL File (defined in script)String
Figure 4.27: Parameters used for Data Condition verification
An example of the condition definition and the corresponding XSL file are listed in Figure 4.28 and 4.29.
Figure 4.28: Data Condition definition in the rule script
truefalse
Figure 4.29: XSL file for condition checking (CountListSize.xsl)
4.3.2 Flow Order Condition
In cases where services have global effects, sequencing of events may be imposed. The system keeps a list of events received and actions completed in the current session. This list can be checked at run-time such that the triggering of a rule is strictly in the desired order. The check can range from checking whether an event or action has occurred or not. If the rule needs to get triggered after a particular reference point, then the reference event or action must appear in the history list. If not, it means that the reference event or action has not occurred and happen before is satisfied.
Once again, this condition checking returns either true or false and takes the same input parameters including Order Condition (before or after) and the Reference Point (either an event or action).
Parameter NameData TypeCondition TypeStringReference PointStringOrder ConditionString {before | after}History List (internal data structure)String []
Figure 4.30: Parameters used for Flow Order Condition verification
Figure 4.31: Flow Order Condition definition in the rule script
4.4 Actions
If the conditions, as we just described, hold after a rule is triggered, the final ECA rule component, the actions are executed. The action clause can be a remote method from a Web Service, query sent to an UDDI registry, service selection based on user profile, UDDI publication or withdrawal, and exception handling action. The Action is defined as:
Figure 4.32: DTD for ECA Action
Actions usually got invoked in response to an incoming event. As a result, the action classification is very similar to the classification of event. After all, it is the event that provides most of the parameters in an action call. The classification of action is illustrated in Figure 4.33.
Figure 4.33: Action Classification
4.4.1 Service Invocation
In the current implementation, the system supports only one invocation mechanism and it is the Simple Object Access Protocol (SOAP). This protocol is application layer protocol which can run over HTTP, or even email. The transport protocol is not significant in any case. The only thing where the two end points care are the delivery of the SOAP Envelope. Figure 4.34 describes the major components in a SOAP Envelope when it is used a Remote Procedure Call situation. A corresponding example is illustrated in Figure 4.35.
Parameter NameDescriptionMethod NameThe function being calledURNA identifier used to identify an application (service class) in the serverParametersData passed to the remote service
Figure 4.34: SOAP Envelope Components for RPC usage
$data_payload
Figure 4.35: SOAP Envelope example
If the call is over HTTP, the SOAP server URL must also be specified. Once the connection is established, the request SOAP envelope would be delivered. To define this piece of technical information, the ECA language can embed it or refer to a WSDL implementation document. Another key piece information that should be specified is the parameter manipulation scheme (if needed). This defines the input XSL file for the Data Manipulator at run time. In Figure 4.36, a brief description is given for each component in the Action clause, it is not very difficult to note the resemblance between this and the resulting SOAP envelope. This is not a coincidence since the task enactment engine actually assembles the SOAP envelope using all these information.
Parameter NameDescriptionMethod NameThe function being calledURNA identifier used to identify an application (service class) in the serverParameters (from event)Data passed to the remote serviceTransaction IDWSDL FileException EventReturn EventService URL (optional)URL for the SOAP server, does not need if WSDL is providedParameter Transformation (optional)Parameter transformation scheme
Figure 4.36: Parameters used by the rule engine to build the SOAP Envelope
Figure 4.38: WSDL Implementation referenced by the Action script
4.4.2 Service Registration Action
The service registration action is a more complex action since it includes a number of message exchanges between the service publisher and the UDDI registry. The messages include submitting the user id and password for an authorization token and a subsequent message submitting the received authorization token with the actual publishing information. During implementation, there are some packages which accomplish this through API calls just like the UDDI for Java provided from IBM. From the standpoint of Script Writer, the script only needs to include the Service Definition to be published, URL of the UDDI Registry, User ID and the Password for that particular registry. The Task Enactment Engine would transform these information using the API and carries out the required registration process.
Parameter NameDescriptionNameThe service or interface name being publishedWSDL Document URLThe URL for the implementation or interface documents being publishedUDDI Registry URL (optional)The URL for the UDDI Registry, if using the system default registry, does not need to define in scriptUDDI User ID (optional)UDDI Password (optional)Figure 4.39: Parameters used by the rule engine to do Service Registration
4.4.3 Service Withdrawal Action
The service withdrawal action is the process to un-publish a service from the UDDI registry. This carries a lot of resemblance of the service registration action and contains a subset of the parameters compare to its counterpart. The mechanisms are exactly the same except they use a slightly different API calls which completely shield the details from the script writer. The script only needs to specify the following information:
Parameter NameDescriptionNameThe service or interface name being un-publishedUDDI Registry URL (optional)The URL for the UDDI Registry, if using the system default registry, does not need to define in scriptUDDI User ID (optional)UDDI Password (optional)
Figure 4.40: Parameters used by the rule engine to do Service Withdrawal
4.4.4 Service Localization Action
The service localization action is the action to query the UDDI registry and returns information about a particular service. There are two querying patterns supported in the system, a search based on name and a search based on category. The mechanisms are exactly the same except they use a slightly different API calls. Behind the scene, the system and the UDDI registry also undergo a sequence of message exchanges as in the case of service registration. Since the system already provides an abstraction layer on top of the whole process, the script only needs to specify the following information:
Parameter NameDescriptionService NameThe service or interface name being publishedService CategoryQuery TypeUDDI Registry URL (optional)The URL for the UDDI Registry, if using the system default registry, does not need to define in scriptUDDI User ID (optional)UDDI Password (optional)Figure 4.41: Parameters used by the rule engine to do Service Registration
In the language, they are defined as follow:
This action returns the two WSDL documents (interface and implementation) which are stored during the service registration step. Once the system identify the service with the two service documents, it can generate a call to the service using the SOAP Invocation mechanism transparently.
Another querying approach is a bit different, the system queries the UDDI registry for services in a particular category and the system returns a list of services. The system uses the run-time service selection mechanism to pick a service based on the user profile. The definition in the scripting language is as follow:
4.4.5 Service Selection Action
As discussed in the previous section, a search for a category of service may return multiple results. It is up to the system to select the most appropriate service on be-half for the user. An extension is placed in the current UDDI architecture in order to accommodate this new idea. Matching a request from the user to the actual invocation of a service requires additional information from both sides. First, there must exist a user profile model specifying the user requirement. At run time, this would be mapped into a value and weight vector consisting evaluation criteria such as cost, distance, performance and even access privilege. On the other hand, an extra document is put at the server side which describe the services runtime characteristic. These characteristics can reflect current load of the service, cost.
When the system gets back a list of service description, it can then obtain the service characteristic description. With the idea of service description service, which is an external service which grades the compatibility of the users specification and the services offering. In Figure 4.42, it describes the information needed for service selection.
Parameter NameDescriptionService DescriptionThe service name and other technical detailsService CharacteristicThis is the service quality description which reflects dynamic characteristics of the serviceUser ProfileThe service quality the user desiredEvaluation Service DescriptionThe technical details on how to invoke the evaluation serviceFigure 4.42: Parameters used by the rule engine to do Service Selection
Please note that this action is different from the previous listed actions, this does not need to be explicitly defined in the script. This can be considered as one of the internal actions that are carried out automatically by the system.
4.4.6 Service Status Action
This is the heartbeat service in the system. If a service has been invoked for certain time and cannot receive any reply, the status service would can be queried. This function usually goes together with the service but with a slightly different interface. There is no need to pass any data except the transaction ID. In many situations, this action is completely optional and service does not support this at all.
Parameter NameDescriptionMethod NameThe function being calledURNA identifier used to identify an application (service class) in the serverTransaction IDService URL (optional)URL for the SOAP server, does not need if WSDL is providedFigure 4.43: Parameters used by the rule engine to query a services status
4.4.7 Exception Handling Action
When the system catches an exception and issues an exception event, the end result would be the triggering of the Exception Handling Action in the script. This is very similar to the exception handling routine in any computer programming language. From the system stand point, this action does not differentiate itself from others, but rather provide a path for the system to terminate gracefully in terms of logic flow. It can prevent deadlock in the system since it prevents it to get stuck in a state. Since it is the same as the usual service invocation, the parameter list is the same as the service invocation action.
4.4.8 Termination Action
When the system reaches the end of execution, it needs to release the resources it holds up and more important, it needs to return the results to the user. This is referred as the System Termination Action. If there are any events come in after the termination of the session, those events would be discarded by the system.
From the system standpoint, there is nothing to be returned except de-allocating all the data structures and set the system to the initial state waiting for another clients request. The result of the whole execution run which containing the end results of the executed services would be returned to the client.
Chapter 5
Algorithms
In Web Service Paradigm, there are many existing or developing standards governing the behaviors of each component. There are certain extensions that can be incorporated into the current standards. The two major enhancements proposed are publishing remote UDDI Registries as services and localize service in a DNS like manner, and another enhancement is service selection based on service quality characteristic and user profile approach.
In the first enhancement, the novelty of the approach is to apply a developed and successful resource localization algorithm and applying it to the Web Service platform. Several UDDI Registries form a distributed database for their own local Web Service while service requester can query the amalgamated registry in an organized fashion. This can also reduce the chance of single point failure and network traffic to a particular node. The second enhancement is the introduction of user profile and a service quality characteristic into the UDDI Registry technology. As services become more specialized and clients become more critical about the service quality, there need a mechanism to match the two parties using more fine grain. The novelty of this technique is that dynamic characteristic can be reflected in the service quality model and the matching algorithm is applied per customer and per invocation.
5.1 Resource Localization
When the resources are distributed across various places, it requires an algorithm to localize these useful resources. This problem has been encountered in the world of Internet. The Internet is made up of numerous of computers refer to hosts. Information is generally stored on these hosts and they are referred as hosts. One identifier for a host is its hostname, such as HYPERLINK "http://www.uwaterloo.ca" www.uwaterloo.ca, HYPERLINK "http://www.yahoo.com" www.yahoo.com, these identifiers are mnemonic and are therefore appreciated by humans. However, hostnames provide little, if any, information about the location within the Internet of the host. Furthermore, hostnames can consist of variable-length alpha-numeric characters, they would be difficult to process by routers. For these reasons, hosts are also identified by the IP address. An IP address consists of four bytes and has a rigid hierarchical structure.
Since people prefer the more mnemonic hostname identifier, while routers prefer fixed-length, hierarchically-structure IP addresses, the Internet needs a directory service that translates hostnames to IP addresses. This is the main task of the Internets Domain Name System (DNS). The DNS is (i) a distributed database implemented in a hierarchy of name servers and (ii) an application-layer protocol that allows hosts and name servers to communicate in order to provider the translation service. DNS is commonly employed by other application-layer protocols including HTTP, SMTP, and FTP to translate user-supplied hostnames to IP addresses. Most Internet services rely on DNS to work, and if DNS fails, web sites cannot be located and email delivery stalls.
Like HTTP, FTP, and SMTP, the DNS protocol is an application-layer protocol since (i) it runs between communicating end systems, and (ii) it relies on an underlying end-to-end transport protocol (i.e. UDP) to transfer DNS messages between communicating end systems. Unlike other applications such as the Web, file transfer, and email, the DNS is not an application with which a user directly interacts. Instead, the DNS provides a core Internet function namely, translating hostnames to their underlying IP addresses, for user applications and other software in the Internet.
There are many suggestions on the design of how DNS would work. If there is only one Internet Server that contains all the mappings in which all clients simply direct all queries to this server, and the name server responds directly to the querying clients. It suffers from the following design flaws:
A single point of failure: if the name server crashes, so does the entire Internet.
High traffic volumes: the only name server would have to handle all DNS queries.
Distinct centralized database: the single name server cannot be close to all querying clients.
Maintenance: the single name server would have to keep records for all Internet hosts. Not only would this centralized database be huge, but it would have to be updated frequently to account for every new host throughout the entire Internet.
In order to deal with the issue of scale, the DNS uses a large number of name servers, organized in a hierarchical fashion and distributed the world. In this scheme, no one name server has all of the mappings for all of the hosts in the Internet. Instead, the mappings are distributed across the name servers. There are three types of name server, local name server, root name server, and the authoritative name server.
Lets start with a simple example, suppose the host client.localdomain wants to get the IP address of target.remotedomain. The host client.localdomain first sends a query message to its local name server dns.localdomain and the local name server forwards the query message to a root name server. The root name server forwards the query message to the name server that is authoritative for all the hosts in the remote domain. This example assumed that all queries are recursive queries. When a host or name server A makes a recursive query to a name server B, then name server B obtains the requested mapping on behalf of A and then forwards the mapping back to A. This querying process is shown in Figure 5.1.
Figure 5.1: DNS messaging sequence for recursive query
There is another querying pattern in the DNS protocol which is refereed as iterative query. When a name server A makes an iterative query to name server B, if name server B does not have the requested mapping, it immediately sends a DNS reply to A that contains the IP address of the next name server in the chain, say, name server C. Name server A then sends a query directly to name server C. The querying pattern is illustrated in Figure 5.2.
Figure 5.2: DNS messaging sequence for iterative query
5.2 Service Localization in the Service Oriented Architecture
5.2.1 Service Oriented Architecture
Regardless of the implementation, SOA is comprised of three participants and three fundamental operations as in Figure 5.3.
INCLUDEPICTURE "http://www-106.ibm.com/developerworks/webservices/library/ws-arc1/Fig2.gif" \* MERGEFORMATINET
Figure 5.3: The SOA model
A service provider is a Network node that provides a service interface for a software asset that manages a specific set of tasks. A service provider node can represent the services of a business entity or it can simply represent the service interface for a reusable subsystem.
A service requestor is a Network node that discovers and invokes other software services to provide a business solution. Service requestor nodes will often represent a business application component that performs remote procedure calls to a distributed object, the service provider. In some cases, the provider node may reside locally within an intranet or in other cases it could reside remotely over the Internet. The conceptual nature of SOA leaves the networking, transport protocol, and security details to the specific implementation.
The third SOA participant is that of the service broker; it is a Network node that acts as a repository, yellow pages, or clearing house for software interfaces that are published by service providers. A business entity or an independent operator can represent a service broker.
These three SOA participants interact using three basic operations: publish, find, and bind. Service providers publish services to a service broker. Service requesters find required services using a service broker and bind to them.
In this architecture, the service providers are distributed across the Internet, each of them publishes the offered services in the service broker. This clearly shows some similarities between the SOA architecture and the DNS technology in the Internet. This is the point we propose a DNS adaptation to service localization in SOA.
The current trend of implementing a service broker is using the UDDI technology. UDDI requires service descriptions. There are several important aspects of a service description. First, it specifies the semantic characteristics of a service provider. Service brokers use the semantic characteristics to categorize the service provider as an aid to finding specific services. Second, the service description specifies the interface characteristics used to access the service. The interface characteristics include the operations available, the parameters, data-types, and the access protocols. The service requester uses this information to actually bind to the service provider and invoke its services.
The current UDDI technologies only specify the data-types and sequencing of messages an UDDI registry would take to publish, un-publish, and query a service and the corresponding service provider. There are no restrictions or specifications on whether a service can be publish in multiple registries and how a service requester should proceed if the registry finds no match for a particular service. If there exists only one UDDI registry in the Internet, it also suffers from the single design flaws as the one node name server approach, namely a single point of failure, high volume of traffic, and high degree of maintenance activities. Our proposed design tries to solve this problem by introducing a more structured distributed database of services avoiding major changes to the current UDDI standards and implementations.
5.2.2 Distributed directory of services
The UDDI can be enhanced in a way similar to the Domain Name Service. A collection of UDDI nodes can be distributed around the Internet each stores a set of services that are geographically related to each other. Information on other UDDI registries should also be stored in the directory itself. Whenever a request comes in and cannot locate a service, the UDDI registry can do one of the followings:
5.2.3 Recursive Queries
The UDDI registry tries to look up the service directory and if it cannot find a match, it tries all the other UDDI registries in its vicinity. The UDDI registry being called carries out the same process recursively. This method can keep the client as simple as possible because extra logic is only put into the UDDI registries and it always guarantee backward compatibility with any existing system because for each UDDI request, either a found or not-found reply would be receive. However, there may be some potential drawbacks with this approach. The most obvious one is that more logic must be tied into each UDDI registry to look up potential service, this might dramatically slow down the server.
Another potential problem is the loop in the UDDI query steps. Since all the registries are distributed, loop within the calling parties can be difficult to detect. Looping of calls can potentially increase the network traffic without bound. The simplest solution would be putting in a time-to-live or level-to-travel counter in the request and asking each registry to modify the flag accordingly.
5.2.4 Iterative Queries
Another approach is that whenever a UDDI registry cannot find any match, the reply including the original service-not-found information but also telling the client any other UDDI registries that might have the information. Upon the reception of the reply, the client can keep the old behavior of not doing anything or can query the list of UDDI registries one by one. Since a list is kept on the client side, loop can be detected by simply ignoring any further registries that exist in the list already. The traffic is always well under control since for one query, there is only one reply pending in the network somewhere. Another advantage is that the UDDI registry can be kept relatively similar to what it is today and extra logic is inserted on the client side if this feature is desirable. The messaging sequence of UDDI iterative query is illustrated in Figure 5.4.
Figure 5.4: Messaging sequence of UDDI iterative query
The algorithm involves first querying the local UDDI registry and if no matches can be found, find other UDDI registries and query these registries recursively. There are two basic requirements. First, the Web Service Integration system must aware at least one UDDI registry. Since this is almost the basic requirement for all Web Service Invocation client to function, so this assumption is almost always true. Second, each UDDI registry should list some other UDDI registries (in close proximity) as services. Although this is not very popular at this moment in time, it does not need to change any implementation for the UDDI registry.
The algorithm takes the input of a service description S and the address of an UDDI registry R and returns Invocation description.
Algorithm: FindService(R, S, L)
Purpose: Try to locate Service S in UDDI Registry R, if no matches can be found, try to do a DNS like query
Input: UDDI Registry Description R, Service S, current search level L initialized to 0 in the first call
Output: Invocation Description I for Service S
InvocationDescription I[] = QueryService (R, S)
If I is null
If L == D+1
Return null
UDDI_Desc UI[] = QueryService (R, UDDI Listing)
For each R in UI
I = FindService (UI[j], S, L+1)
If I is not null, return I
Else return I
Figure 5.5: Algorithm for UDDI iterative query in a DNS manner
The algorithm is implemented as a recursive function. The base case occurs when service S can be located in the current UDDI Registry or depth level D is encountered. If no such service is located, the function queries for remote UDDI Registry listings in the current registry. For each registry returned, the function applies the same search logic recursively.
5.3 Service Selection and Matching
It is clearly possible, and even a goal, to have many service providers with nearly identical service descriptions; that is, many service providers that offer specific semantic and interface characteristics, but perhaps differ in some details or in non-functional characteristics. Put another way, many service providers may implement the same service via the same interface and access mechanisms, but differ in cost, security, performance, etc. Aiming to support this kinds of features, there needs a service matching Algorithm based on dynamic service characteristics. The service characteristic specifies various non-functional characteristics such as security, transactional requirements, cost of using the service provider, and others. The modeling of the service selection is illustrated in Figure 5.6.
EMBED Visio.Drawing.6 Figure 5.6: Model for Service matching
5.3.1 User Profile Matching
In the service localization process, if there exists more than one Service Si..j {j > i} satisfying the Query q, the system must try to identify a service that is the most appropriate given some criteria. One of the most obvious choices for service matching is based on user preferences against the service quality. There are many qualities that each services can be characterized, for example, cost, performance, reliability, security, access privilege, etc. The basic idea is that when a client requests a service, the request first goes through the service matching process. The result is based on the user profile submitted and how closely each service matched against the user preferences. Only the service that is considered to be the closest matched would be invoked.
In general, the client profile specifies a list of characteristic vectors the client desires. Each vector contains the desired value and the weight of the importance of that quality. In other words, for each quality characteristic Ci, the user profile contains a v e c t o r <