To study rule-based dynamic composition models for grid applications.
Design and implementation of a prototype rule based framework that enable integration, interaction and controlled management of grid applications and there components.
An application can be thought of as a “composition “ of components or commands. It is created with some objective in mind, which is fixed for its lifetime. The composition consists of a plan specifying a sequence of conditions and actions. The actions that can change the state of environment (input /output) or can change the state of the application itself to achieve the final objective. In the case of dynamic composition of grid applications the objective is changing with time. We do not know apriori what might be objective of the application at later point of time. Thus we require the ability to dynamically select the components and compose the plan at runtime. This can also be viewed as transforming a given composition to new one according to the change in objective. Enabling dynamic, runtime compositions for autonomic grid applications can be done automatically or interactively by our rule based system. By dynamic we mean that new components and interactions can be added later in the lifecycle of autonomic applications.
Some of the key challenges and questions encountered in enabling runtime, dynamic compositions are
1. How to specify the changes in the objective to create dynamic compositions? Static composition could be described in some existing languages i.e. Petri nets or workflow definition language (WFDL) but to specify changes in the composition we require more flexible approach.
2. In a dynamic composition would need to modify the application at runtime. Not only that it also require interaction with other applications. Thus we require extensions in the existing middleware to support such collaborations. The middleware should also support the monitoring and steering capabilities for these “composed” applications, which are created on the fly.
3. How to guarantee consistency of environment after submitting “change in plan”. Are we corrupting the interacting applications? Is there any flaw in our “change”, which might result in deadlock?
4. In this new scenario we also require middleware support in providing resource management, access control and security. The middleware should contain the engines that support specifying rules and policies dynamically. The engines should be able to access the interacting applications at runtime to hook different components as specified by “evolved composition plan”.
5. The middleware should also enable the composer to monitor the changes step by step for new composition plan.
i. WSFL and WSDL
Web Services Flow Language (WSFL), which is under development by IBM, is one of the approaches to Web services. WSFL is an XML language for the description of Web Services compositions. It has two major distinctions within its model, a global model and a flow model. The global model is used to describe how Web services interact with one another and what interfaces are exported to the outside world. The flow model describes the actual choreography of the system that is needed to achieve the end goal. One of the greatest strong points for WSFL is that it is logically consistent with WSDL and compliments it well.
WSFL supports lifecycle operations for the flow model of the composite Web services. It supports operations such as spawn, call (blocking spawn), suspend, resume, enquire and terminate. It supports the different bindings like Static, Local, UDDI, Mobility and Customize.
ii. BPML and WSCI
The Business Process Modeling Language (BPML) and Web Services Choreography Interface (WSCI) are a set of complementary XML languages that are designed to allow for complete definition of a business process model. BPML is a metalanguage for modeling business processes. BPML provides an abstracted execution model for collaborative and transactional business processes based on the concept of a transactional finite-state machine. The WSCI is aimed at application to application integration on a tighter level than that proposed by XLANG. With WSCI it is possible to model private implementations of methods and services via BPML and show the public methods via WSCI.
iii. XLANG
XLANG (Microsoft) make it possible to formally specify business processes as stateful long running interactions. It specifies message exchange behavior among the participating web services for automation and composition of new business processes. It provides an extension service element to WSDL that describes how the process will work as part of a business flow. XLANG also is able to use WSDL documents to provide basic access to components for implementation of a business process
iv. JSFL
Jini Services flow Language (JSFL), is an XML based notation for describing composite jobs made up of interacting services. It extends the WSFL and permits more general data mappings than WSFL.
i. GSFL and GSDL
The Grid Services Flow Language is an XML-based language that allows the specification of workflow descriptions for Grid services in the OGSA framework. It has been defined by using XML schemas.
ii. XCAT Application Factories
The XCAT Application Factories address workflow issues for Grid-based components within the Common Component Architecture (CCA) framework. XCAT allows components to be connected to each other dynamically, making it possible to build complex applications from simple components.
i. WSCL
Web Services Conversation Language is a conversation language framework under development by the Hewlett-Packard Company, for modeling the sequencing of the interactions or operations of one interface. It fills the gap between mere interface definition languages that do not specify any choreography and more complex process or flow languages that describe complex global multi-party conversations and processes. WSCL does not, however, address the recursive composition of Web services
.
It integrated the coordination with composition. Associative broadcast is used to target messages to processes in specific states, which are in turn used to form composition. It enables coordination over dynamic sets, is fault tolerant and preserves anonymity. It enables fully distributed and symmetric coordination among the participating processes. The only limitation is that associative naming and binding is used as a compilation process to select an initial set of binding among the components prior to runtime.
It is the automation of a complex process, in whole or part, during which resources, information, tasks and data a passed from one participant to another for action, according to a set of rules.
Coordination among a set of heterogeneous, asynchronous, and distributed activities according to a given specification.
It is a mechanism that defines, creates and manages the execution of workflow through the use of software, running on one or more workflow engines, which is able to interpret the process definition, interact with workflow participants and, where required, invoke the use of tools and applications.
Allow people to specify and manage working processes, which are distributed in time and across different domains and actors.