GSFL: Workflow architecture for grid services (1)
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
GSFL
Some problems in the engine execution.
