GSFL: a workflow architecture of a grid service (ZT, English document, here is saved here)

xiaoxiao2021-03-06 22

http://www.caip.rutgers.edu/~zhljenny/workflow_bib.htm

Author Blog:

Http://blog.9cbs.net/dbmining/ Thanks to the author, take the liberty to post saves

GSFL: a workflow architecture for grid services

Sriram Krishnan12, Patrick Wagstrom13, Gregor von laszewski1

1mathematics and Computer Science Division, Argonne National Laboratory, Argonne, IL 60439

2INDIANA University, Bloomington, IN, 47405

3illinois Institute of Technology, Chicago, IL, 60616

Summary: Open Grid Services (OGSA) Trying to use the concepts and techniques of mesh and web services to address the challenges of integrating services through distributed heterogeneous dynamic organization. The Web Services area has been aware of the potential of the web service has reached the limit unless there is a new mechanism to describe the various interactions between services and dynamically form the existing service to form new services. This is also the same in grid services. This paper analyzes the existing technology that handles web service workflows, and strives to apply them to grid services to meet their different needs of standard Web services. We discussed these special needs and introduced the Grid Service Streaming Language (GSFL) capable of resolving their grid service within the OSGA architecture.

Keywords: grid; igsa; igsi; grid services; web services; Workflow

1 Introduction

The network service method quickly promotes power in the industry. W3C [9] defines network services as software applications identified by URI [13]. The interface and bindings of the URI can be defined, described, and discovered by XML Artifacts. The latter uses an Internet protocol XML message to support direct interaction with other software applications. More comprehensive descriptive definitions can be found [20], which defines the network service as a platform, a component that performs a stand-alone software:

l You can describe the language description language;

l Release to a service registration office;

l can be detected by standard mechanisms;

l Use the declared API function to call, generally through the network;

l consists of other services.

The goal of web services is to achieve collaborative work. This requires the requester to access network services by using standard mechanisms. Ideally, any requester can interact with any documentation for network services without considering the language and environment they use. This makes a network service method attractive to modern enterprises and internal organizational computing systems.

Grid computing includes various resources in dynamic distributed virtual organization [18]. Grid technology is based, support sharing and coordination of different resources. At present, it [16] is being widely used in the field of scientific calculations. In addition to solving problems inherent in handling resources, such as algorithms and problem solving technology, resource management, security, instrumentation and technical performance analysis, network facilities, etc., and solve problems caused by network services, such as description, discovery, Communication, remote call, etc. Recently, with the development of the Open Grid Service System (OGSA) [17], these situations have caused attention from the grid.

OGSA is the result of Globus Toolkit development. Globus Toolkit has become a factual standard for grid computing. OSGA Using Network Service Description Language (WSDL) [14] implements self-description and discovery services. WSDL defines a standard interface set for a grid service output, which enables features such as discovery, service search, survival time management, notifications, and trust management. Despite this, and network service technology is similar, grid service potential will reach the limit unless there is a mechanism to dynamically form new services from existing service systems. For this purpose, we must not only describe the sequences of these services and their methods, but also need to seek a way to make such a system as a service output. In this article, we define the term "workflow" as a rule set, which defines interactions between service sets to make its components. This article describes the status quo of network service workflow language and how network services and grid service contact, pointing out the shortcomings of these languages in grid. In order to solve these problems, we also introduce the grid service streaming language (GSFL) and the research issues thereof and solutions.

2 technical overview

Recently, the streaming language field of network services has emerged. The main network service software suppliers have proposed various methods as standards. Due to the rapid development of this field, we cannot investigate all existing technologies and can only focus on some big projects.

2.1 Network Service Streaming Language (WSFL)

WSFL [21] is proposed by IBM, one of the methods of network service workflow. WSFL describes the composition of the network service using a flow model (FlowModel) and a unified model (GlobalModel). Flow mode defines a series of activities to perform the operation of composite network services and determine the order of the activity execution. It uses ControlLink and DataLink to define control and data streams between various activities. In most cases, the data will follow the control flow. However, WSFL is very flexible to handle cases that may be incorrect.

The Unified Model (GlobalModel) defines how the activity of the composite network service is how PlugLinks maps it to the operation of Individual Web Services. WSFL identifies the service in the workflow with Locator, supports the following bindings:

l Static, provide a reference for WSDL or WSFL definitions;

loCal, service execution is local;

l UDDI, use UDDI [2] API to detect the service execution;

l Mobility, the service provider will mention in the news generated by some activities;

l Any, the service provider is not limited in the flow model.

WSFL also supports the lifecycle operation of the flow mode of the composite network service. It supports such as Spawn, Call, SUSPEND, RESUME, ENQUIRE, and TERMINATE. The advantage of WSFL is the ability to logical consistency with WSDL and define network services. Network services are often composed of other network services.

IBM announced the WSFL1.0 version in May 2001. But there is no much improvement there. Although it seems that some working groups are also committed to launch feasible WSFL [15], there is no popular application.

2.2 xlang: Web Services for Business Process Design

Microsoft's proposed XLANG [27] is a language for transforming business process patterns to autonomous proxy. The unit of action in WSDL is an operation, which is capable of being applied to stateless services (Stateless Service, such as stack references) or on a useful stateful service (STATEFUL Service, the start and end of the process). There is a third model, and the business process may be an autonomous agent such as a supply chain. In this chain, the input and output messages occur in a specific order as the service process. Self-connection and synchronization based on π-calculus (π-Calculus) theory.

XLANG defines the following operation sets as a standard WSDL operation to assist this model:

l Delays such that a thread delays a certain period or until other conditions.

l RAISE, a method of triggeting a particular action.

l Process, combined condition and iterative schematic control combined action.

l Correlation provides a method of declaring longer running sessions.

l Transaction Support defines the rollback process, which occurs when the execution fails.

l Contracts Create a block service, using the port between the port.

Like many technologies, Xlang is also developing. Currently, it lacks the way the service is dynamically added to the business process and lacks a mechanism to output these services as part of the workflow. This will be implemented in its future versions. Despite this, since the announcement in May 2001, the introduction of XLANG is still very small.

2.3 Web Services Conversation Language (WSCL)

WSCL [28] is a session language architecture proposed by Hewlett-Packard, which establishes a model for the interaction and operation of an interface. It makes up for the gap between interface definition language. The interface definition language does not describe any Choreography and more complex processes or streaming languages. The flow language describes complex unified multiparties sessions and processes. The main composition of the WSCL specification is as follows:

l File type description, involving the type of file that can be accepted and propagated, using XML Schemas definition [3];

l Interaction Description, establish a model for the session action between the two participants;

l Conversion description, explain the order relationship between interactions;

l Session Description lists all interactions and conversions of constituent sessions.

The session is the public interface supported by the service. Script is introduced into WSCL in the possible order of the operation, for services. However, WSCL does not resolve the recursive problem of web services, and this is precisely our target for grid services.

2.4 Other related work

The Web Services Choreography Interface (WSCI) [11] is proposed by Sun, Intalio, SAP and BEA, and it is desirable to achieve integration of application level than XLANG cohesiveness. However, WSCI is proposed in June 2002, which is very new when writing this article. Business Process Modeling Language (BPML) [10] is a meta-language that models business processes. BPML provides a virtual execution model for collaborative transactional business processes, based on a concept called transaction finite state machine. Dagman [6] is a Condor [5] yuan scheduler, dependent management. Although the Dagman does not process the network service workflow, the input and output and execution are the incoming assembly method of the input and output and execution is the content of the network service. The Xcat Application Factories [19] solves the workflow problem with components based on the General Component System (CCA) [12] architecture. XcAT allows components to communicate with each other, making it possible to establish applications, which is impossible in the standard network service model. 3 demand for workflow

After analyzing and analyzing grid case cases, we have established a set of demand for grid workflow norms. This part we will show these needs and existing network service technologies unable to handle all requirements, and provide some useless techniques for use.

As the network service technology is hoped, the grid workflow specification should allow special activities to be applied to personal services as the output of workflow activities, and should also enable output activities to trigger other activity chains. The technology currently like WSFL can effectively solve this problem. Therefore, we strive to introduce these features of WSFL into the grid service stream language. Further, the activity output in this manner should also be described in the same manner as the service itself. In this sense, the specification should be sufficient to describe the workflow, such as the specification should automatically generate WSDL for workflow entities (later referred to as workflow coordinators). Workflow coordinators must use a method of dynamic output as a variety of workflow activities. In this way, customers can use the same tools that handle personal services to access them. This is an important requirement for the recursive ingredients of the service.

As we observed and [19] pointed out, existing network services define their workflow, the workflow engine must intervene in each step of the application sequence (Figure 1). This is because the current workflow technology is designed for business communication, and only the medium data transmission level can be reached through network services. As a result, the workflow engine is not because of the real bottleneck. However, exchange of large amounts of data is often events in grid-based services. Using the Center Workflow Engine Forwarding data between servers is not wise. The workflow specification should be able to communicate between the server (Figure 2). As mentioned earlier, in order to meet the special needs of the grid, OGSA has expanded WSDL, using NOTIFICATIONSOURCES and NOTIFICATIONSINKS to resolve communication between Grid Services, which allows for asynchronous messaging between each other. This requires GSFL to provide a mechanism to connect NOTIFICATIONSOURES and NOTIFICATIONSINKs to avoid the workflow engine involve every step. In addition, OGSA uses Registries and Factories to find and create grid services, respectively, which is GSFL should have.

(figure 2)

The specific grid service in the workflow cannot be performed, which may be due to the data required for the service that is performed in advance to run a few week or the service that is later executed. The grid service stream specification should be able to meet this special needs. In addition, instantiation should also be solved in each method or a personal grid service on the workflow instance. Since the grid service is instantiated based on each workflow instance, some activities of the workflow output may not be able to run due to a single grid service or not yet instantiated. Therefore, WSCL recommends to add specific semantics to the order of output activities.

In the next section, we describe the grid service flow language and how to resolve the needs listed. 4 GSFL review

The grid service streaming language is based on XML, supports the workflow description specification for grid services under the OGSA architecture. It uses XML Schemas definitions. Figure 3 shows a simplified architecture. Here are some important features, which will then expand:

l Service Providers, service providers, participating in workflow;

l Activity Model, Activity Model, describing important activities in workflows;

l Composition Model, a combination model, describing the interaction between personal services;

l Lifecycle Model, lifecycle model, describe the life cycle of various activities and services participating in workflow.

4.1 Service Provider (Service Providers)

All servers involved in workflow must be declared in Service Providers. The GSFL document identifies the service provider by a unique name, which is part of the definition. Definitions also include the type of service provider, as the Grid service type of WSDL specification. The server provider can find it in a series of ways by looking for components. The service can look up via a static URL. The URL can point out the service running. You can also create Factories, which is the handle in the GSFL document. You can also find the service using Registries.

4.2 Activity Model (ACTIVITY MODEL)

Activity Model lists all the operations of the personal service provider. The provider plays a variety of roles in the workflow. Activity Model contains a list of events, and each activity has names and sources. The name is used to identify, the source is a reference to the network service, and the operation is defined by the endpointType. EndPointType includes the name of the operation, the port type, port name, and service name of the specific operation.

4.3 Combination Model (Composition Model)

Composition Model describes how different grid servers make up new grid servers. It describes the control flow and data streams between service operations, as well as peer-to-peer communication. It includes the following sections:

4.3.1 Output Model (Export Model)

Export Model includes a list of activities output by a workflow process. Any customer can call these workflow instances using standard mechanisms. Since the workflow instance can be seen as a standard grid service, it can also be recursively used for another workflow process. For each output, the control flow and data stream are represented by ControlModel and DataModel, respectively.

ControlModel describes the activity sequences that are called when the output activity is called by the customer. Each ControlModel element has attribute controlin, which involves the first activity that will be executed when the output activity is called. At the same time, each ControlModel also contains a sequence of ControlLink as part of the output activity. It is a priority list that needs to be successfully called.

DataModel describes the data stream generated when the output activity is called. This data stream may not be necessary to reflect the control flow between various activities. Each DATAMODEL element contains a attribute DatAinto ("Data IN" in Figure 3). This attribute illustrates activities that will receive input data as an output activity. DataoutFrom properties ("Data out" in the figure assigned source activity of data, which are returned to the caller.

The GSFL file provides sufficient information for DataModel and ControlModel, which is not only dynamically set up WSDL for output activities, but also supports dynamic calls. We explain in Section 5.

4.3.2 Notification Model NOTIFICATION Model solves the problem of every step of the workflow engine to intervene in the event. As mentioned earlier, OGSA services communicate with NOTIFICASOURES and NotificationSinks. NOTIFICATION Model provides a two-way link mechanism from Sources to Sinks, which is a unique topic that requires NOTIFICATION LINKS. At present, the server can transmit a large number of data without having to pass the workflow engine. Users can also use control models and data models to transfer control messages and small data between each other, but is also recommended to use Notification Messages when transmitting large amounts of data.

Figure 4 shows a simple example of the Composition Model. Two services A and B form a workflow. This Notification Model consists of separate Notification Link A! B, which represents links from A to B. The output model consists of a pair of output activities, one of which is described in detail in the figure. It is performed by the operational q of the service A operations P and R and Services B. The control model consists of control links P! Q and Q! R. The operation P is the controlin of the output activity. The data model consists only of a separate data link P! Q. This may not be called because the operation R does not need to call the data. This is an example of a data link is not just like controlling the link. Operation P as DataInto, Q as DataoutFrom. Therefore, the call to the output activity will trigger the above operation set accompanying the control and data stream.

4.4 Lifecycle Model (Lifecycle Model)

Lifecycle Model handles the order in which services and activities are executed. Service Life Cycle Model ServiceLifeCycleModel contains a list of priority chains that describe the service execution order. Therefore, not all services need to be initialized at the beginning, and can start after the previous service stops execution.

The lifecycle model uses the SCOPE attribute of the workflow, which can be a session or application. Session indicates that there is no state between the call to the workflow engine. All calls are legal. For each call, the service uses ServiceLifeCycleModel to instantiate, and these services are active when calling.

Application indicates that the call status will be saved in the service flow engine. For each workflow instance, the service only uses ServiceLifeCycleModel. Since services that implement these activities may not be active, the call to the workflow engine is not all valid. So, we add ActivityLifecycleModel to describe the order they call. In other words, some activities can only be called when certain activities have been successfully called, such as the Checkout operation of the online shopping system must be called after one or more Buy operations. Follow the ActivityLifecycleModel to ensure that all services are active when calling in appropriate order.

We believe that using the above designs, we can solve the needs of the grid service workflow. Now, to discuss some problems in the execution of the GSFL engine.

5 Executive details

We choose OGSI Technology Preview [22] as the basis for the development of GSFL prototypes. This is current grid service specification [29] using Apache Tomcat [23] and Apache Axis [24] based on Java-based applications. Tomcat is a servlet container for java servlet [26] and JavaServer Pages [25] technology in office-related applications. AXIS is an application of Simple Object Access Protocol (SOAP) [1] in W3C. In the following section, we give some important parts of GSFL applications.

5.1 Analysis of GSFL

We analyze GSFL Schema with CASTOR [4] and generate Java bindings. CASTOR is a Java open resource data binding architecture that generates Java class and is displayed in XML Schema. It also provides a method to configure the XML document with the corresponding Java object, and vice versa. Use CaStor to automatically generate Java bindings for our XML Schema to avoid writing code. This greatly reduces the time of developing code. Although CASTOR can map GSFL Schema into Java classes, it is unable to understand the semantics associated with component, such as Castor does not know that there is enough information in GSFL Schema with sufficient information (Namespace and location) to import another GSFL document. It can only use the appropriate acquisition and installation method to map the type of Import to the Java class with the Namespace and Location fields. Therefore, we have to add packages generated by Castor to resolve this issue. But this is much better than you write code.

5.2 Automatically generate WSDL

In addition to using CASTOR, we can also use WSDLAJ [8] to handle personal service WSDL documents. WSDLAJ is a toolkit that can be created, showing, and operating WSDL documents.

As we introduced in Section 4., the GSFL document contains sufficient information about the output activity. Since WSDL can participate in workflow, it is easy to find Types and Messages themselves for input and output information. Other information from WSDLs such as Operations, Ports, etc. can easily get from GSFL itself. The key to automatically generating WSDL for workflow is to provide sufficient information from GSFL Schema.

5.3 GSFL Coordinator (CORDINATOR)

The core of GSFL Workflow is GSFL Coordinator service. This service creates virtual ports and servers that map internal processes to workflows. These ports are virtual because they are not physically in GSFL Coordinator. Despite this, customers can call methods through these ports because they are mapped to a collection of Coordinator.

Figure 5 shows a commonly used control flow. A customer who wants to perform GSFL workflow first begins with a GSFL instance (through standard OGSA Method). The coordinator is then sent to GSFL representing the workflow. On the GSFL document receipt, the coordinator instance dynamically generates a WSDL document, including all new output operations. Then WSDL can be used by customers who can perform workflow and dynamic output operations. When a customer calls an operation of a GSFL Coordinator output, requests to the OGSA WebApp via a servlet container. OGSA WebApp sends GSFLPROVIDER / IntercePter calls using the mapping config.wsdd on the server, which is an extension of the standard OGSA RPCuriprovider class. The OGSA RPCuriprovider class is responsible for assigning the introduced request to the correct service instance based on the requested URL. Since operation is not physically existing on GSFL Coordinator, if this standard provider has been used, the call will fail. However, the custom provider can interrupt this call and sends a universal configuration function in the coordinator. Based on the information provided by the GSFL document, the coordinator handles the request to map the operation to a call set. These calls are actually performed by the service participating in workflow.

The provider can distinguish whether the call is active or executed in a static port. One of the static operations of interest is generatewsdl. Including dynamic ports, it automatically generates WSDL (5.2) to the coordinator

6 gsfl example

Considering the following scenarios, in order to achieve a common goal, the grid service needs to communicate with each other. The description of the concept is defined in Section 4, which is stronger than XML in readability. Figure 6 depicts interactions between personal services. 6.1 service provider

The service provider consists of a work queue service, a resource management service, and an execution service set. The work queue service is responsible for the work to be queued for the user; the resource management service is responsible for the various resource pre-store information on the grid and only decisive to the target resource for the implementation; the execution service set is running on each manager Execution of the work and report resource information to the resource management service.

6.2 Activity Model

Activity model consists of a queue operation of a work queue service, an outgoue operation, a getResource operation, and executeJOB operation. Queue operations are responsible for queuing for work requests, work demand information to be provided in a suitable format; out of queue operations work from the queue, depending on the queue rules; the acquisition resource operation in the resource management service uses the queue work information to do specific work The best resources; execution work operations in the implementation of the service are responsible for the implementation of work

6.3 Combined model

The output model in the combination model consists of an output operation Execute. It consists of a model consistent with a control and data model. Operations of these two models include Dequeue, GetResource, and Execute-Job. Therefore, when the customer calls the Execute operation on the workflow instance, the workflow engine gets the next job from the work queue service and then passes the work information to the resource management service via the getResource call. GetResource Calls Returns the target resource to continue working. Using this call on the information and the ExecuteJob operation, it works on the original resource.

In addition, each execution service sends Soft-State resource information to the resource management service by using asynchronous cycle. This is how the resource management service has a method of having every resource information. It is based on this information to determine the best target resources. NOTIFICATION LINKS set consists of Notification Model, which connects the execution service to the resource management service.

6.4 Life Cycle Model

In this example, we require all services to be active at the same time, so we don't need to use all the features provided by the lifecycle model.

Therefore, in order to create more complicated and need to serve more than each personal service, we find that you can work with GSFL to make your personal service (Job Queue Service, Resource Manager Service, and Execution Services).

7 future work

Grid service streaming languages may also have vast space in applications and enhancements. This is also a development work, which will continue to improve according to the needs of the grid. In the future, it will contain the characteristics of processing processing, similar to the XLAN, and the task sorting function in the enhanced workflow, which may be used to cycle and select the structure; automatically integrate the graphical workflow editor.

8 conclusions

We describe the grid service streaming language (GSFL), a workflow architecture based on grid service. We overview existing technologies for processing network service workflows and studies their applications in grid services. Existing network service technology provides some good features that can be utilized, although some needs are not solved, such as peer-to-peer service interactions and use lifecycle management in the service. We have designed GSFL to handle these issues, but also integrate the characteristics of existing network service technology.

references:

[1] Condor: high throughput computing. Http://www.cs.wisc.edu/condor/22.

[2] Dagman (Directed Acyclic Graph Manager). Http://www.cs.wisc.edu/condor/dagman/, 2002. [3] Assaf Arkin. Business Process Modelling Language. Http://www.bpmi.org / bmpi-downloads / bpml-spec-

1.0.zip, June 2002.

[4] Assaf Arkin, Sid Askary, Scott Fordin, Wolfgang Jekeli, Kohsuke Kawaguchi, David Orchard, Stefano Pogliani,

Karsten Riemer, Susan Strount, Pal Takacsi-Nagy, Ivana Trickovic, And Sinisa Zimek. Web Services Choreography

Interface. Http://wwws.sun.com/software/xml/developers/wsci/index.html, June 2002. Version 1.0.

[5] R. Armstrong, D. Gannon, A. Geist, K. Keahey, S. Kohn, L. MCInnes, S. Parker, And B. Smolinski. Toward A

Common Component Architecture for High-Performance Parallel Computing. In Proceedings of High Performance

Distributed Computing, Pages 115-124, Redondo Beach, California, 1999. CCA forum,.

[6] T. Berners-Lee, R. Fielding, And L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax.

Http://www.ietf.org/rfc/rfc2396.txt, August 1998.

[7] Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah Mendelsohn, Henrik Frystyk Nielsen,

Satish Thatte, And Dave Winer. Simple Object Access Protocol (SOAP) 1.1. Http://www.w3.org/tr/soap, may

2000.

[8] Roberto chinnici, Martin Gudgin, Jean-Jacques Moreau, And Sanjiva Weerawarana. Web Services Description

Language Version 1.2. Http://www.w3.org/tr/2002/wd-wsdl12-20020709/, July 2002. W3C Working Draft 9.

[9] Erik Christensen, Francisco Curbera, Greg Meredith, And Sanjiva Weerawarana. Web Services Description Language.

http://www.w3.org/tr/wsdl, march 2001. revision 1.1 - March 15, 2002.

[10] Francisco Curbera, Yaron Goland, Yohannes Klein, Frank Leymann, Dieter Roller, And Sanjiva Weerawarana.

Business Process Execution Language for Web Services. Http://www.ibm.com/developerWorks/library/ws-bpel/.Version 1.0 - July 31, 2002.

[11] Distributed Systems Department Pervasive Collaborative Computing Environment Project (PCCE), LBL. PCCE

Quarterly reports. Http://www-itg.lbl.gov/collaboratories/quarterly-reports.html, April 2002.

[12] David C. Fallside. Xml Schema Part 0: Primer. Http://www.w3.org/tr/xmlschema-0/, may 2001.

[13] I. Foster and C. Kesselman, Editors. The Grid: BluePrint for a Future Computing Infrastructure. Morgan

Kaufmann Publishers, July 1998.

[14] Ian Foster, Carl Kesselman, Jeffrey Nick, And Steven Tuecke. The Physiology of The Grid: An Open Grid Services

Architecture for Distributed Systems Integration. Http://www.globus.org/research/papers/ogsa.pdf, January 2002.

[15] Ian Foster, Carl Kesselman, And Steve Tuecke. The Anatomy of The Grid: Enabling Scalable Virtual Organizations.

International Journal of Supercomputing Applications, 15 (3), 2002.

[16] Dennis Gannon, Rachana Ananthakrishnan, Sriram Krishnan, Madhusudhan Govindaraju, Lavanya

Ramakrishnan, And Aleksander Slominski. Grid Web Services and Application Factories.

http://www.extreme.indiana.edu/xcat/appfactory.pdf, June 2002.

[17] The globus project. Http://www.globus.org/, June 2002.

[18] Steve Graham, Simeon Simeonov, Toufic Boubez, Doug Davis, Glen Daniels, Yuichi Nakamura, And Ryo

NEYAMA. Building Web Services with Java. Sams, 2002.

[19] IBM. The Web Services Description Language for Java Toolkit (WSDL4J). Http: // www-

124.ibm.com/developerWorks/Projects/wsdl4j, July 2002.

[20] Frank Leymann.Web Services Flow Language. Http://www-4.ibm.com/software/solutions/webservices/pdf/wsfl.pdf,

May 2001.

[21] OGSI Technology Preview Release. Http://www.globus.org/ogsa/releases/techpreview/, June 2002. [22] Apache Jakarta Project. Apache Tomcat. Http://jakarta.apache.org/tomcat/ JUNE 2002.

[23] Apache Xml Project. Apache axis. Http://xml.apache.org/axis/june 2002.

[24] Sun Microsystems Inc. Java Server Pages. Http://java.sun.com/products/jsp, 2002.

[25] Sun Microsystems Inc. Java Servlet Technology. Http://java.sun.com/products/servlet/index.html, 2002.

[26] Satish Thatte. Xlang: Web Services for Business Process Design.

Http://www.gotdotnet.com/team/xml WSSPECS / XLANG-C / Default.htm, 2001.

[27] The Hewlett-Packard Company. Web Services Conversation Language (WSCL) 1.0.

http://www.w3.org/tr/wscl10/, March 2002.

[28] Steven Tuecke, Karl Czajkowski, Ian Foster, Jeffrey Frey, Steve Graham, And Carl Kesselman. Grid Service

Specification (Draft 2). Http://www.gridforum.org/ogsi-wg/drafts/gs spec draft02 2002-06-13.pdf, June 2002.

[29] UDDI TECHNICAL White Paper. Http://www-3.ibm.com/services/uddi/pubs/iru uddi technical white paper.pdf,

September 2000. Universal Description, Discovery and Integration Is for Discovering Web Services.

[30] keith Visco and assaf arkin. Castor. Http://castor.exolab.org/, 2002.

[31] World Wide Web Consortium. Http://www.w3.org/, June 2002.