Architecture for Services Orchestration using BDI Agent
V. Prasanna Venkatesan and V.Portchelvi
December 2007
Summary: As companies try to extract value using service-oriented architectures, service orchestration—the ability to compose new business services by building on existing ones—will emerge as the major barrier to success. One reason for this is that tackling service orchestration using traditional programming and design techniques does not solve the problem of complexity. Goal-directed orchestration is an emerging way to build processes in a loosely coupled manner without having to hard-code every possible execution or exception path. Goal-directed orchestration (GDO) relies on a set of goals, plans, and rules to design complex processes. It is the ultimate in loosely coupled process modeling. The aim of this paper is to propose an architecture that shows how to model processes using goals, plans, and rules. The proposed architecture provides an agent-based solution in which a goal-directed BDI (Belief Desire Intention )agent enables the service provider s to automatically create, deploy and maintain the required services with reduced time-to-market and total-cost-of ownership. It allows business and IT to speak the same language and dramatically reduce the effort needed to model, understand, and implement complex processes.
Contents
Introduction
Services Orchestration Challenges
Problem Definition
Goal-based AI Technologies
Proposed Architecture
Case Study Loan e-Market Application
Conclusions
References
Introduction
Traditional applications are designed with the idea that customers will buy most, if not all, of their applications from single vendor. However, Fortune 2000 end user companies do not purchase most or all of their applications from a single vendor. Research indicates that these firms tend to purchase a mixture of back-office applications from multiple vendors and then worry about application integration afterward. Most of the companies have been attempting to solve their application integration problems using traditional approaches: enterprise application integration (EAI) and portal technology. These are effective in creating a single point of access or view of the applications and data sources across the enterprise, but they do not provide application integration at the business process level. Service-oriented architecture (SOA) is an architectural approach that thrives on turning enterprise computer assets into well-defined services. It provides process integration through the use of services. Composition and integration of old and new business components into new real-time applications is a natural fit with SOA environments.
Most businesses adopting SOA have focused on building standardized services interfaces to existing components and exposing more granular functionality from existing applications. This provides a large base of business services that can be reused across the enterprise and potentially by suppliers and partners. But such a library of interoperable business services is of limited value unless one can orchestrate them to deliver new business functionality and services the whole value proposition for SOA rests on its ability to rapidly create composite services to meet changing business needs. Therefore, service orchestration [1][2]—the method by which new functionality and composite services are built from existing ones—is key to any SOA initiative. This paper discusses the various challenges faced in orchestrating the services; it also identifies a challenge that is under research, which is defined as a problem, and a goal-directed approach to solve it. Various goal-based artificial intelligence (AI) technologies are surveyed and analyzed. This paper elaborates on the proposed architecture, along with a loan e-market application as a case study. Finally, the paper concludes with the characteristics of the goal-directed approach and the work to be done.
Services Orchestration Challenges
This section gives a literature survey of the recent works that address the orchestration issues. The concepts of SOA, Web services, and Web services orchestration (WSO) were conceived from a technical perspective. The key goal of Web services is application integration. This integration was originally limited to enterprise application integration (EAI), but soon after the potential to use Web services for business-to-business application integration was realized. To use Web services in a business-to-business environment, the need to integrate Web services into business processes arose. WSO [3] was developed to facilitate this. "Web services orchestration is about providing an open, standards-based approach for connecting together Web services to create higher-level business processes.
Because Web services orchestration is a challenging task, various issues related to WSO are identified and listed. Certain approaches for tackling those issues are identified from the literature. In "Service-OrientedArchitecture: Implementation Challenges" [4], a business process management (BPM) approach is used to orchestrate the services. In "Orchestrating Composite Web Services under Data Flow Constraints" [5], decentralized orchestration is proposed. In "Weaving Aspects into Web Service Orchestrations -Proceedings of the IEEE International Conference on Web Services (ICWS'05)" [6], Services can be dynamically adapted with new features and hot-fixed to meet unfoeseen post -deployment requirements. Business processes can be enriched with additional features such as debugging, execution monitoring, r an application specific GUI. Adapting a process can only be performed by stopping it, which is unacceptable especially for long-running processes. Steering a process is impossible. How to dynamically compose business processes based on business rules? Dynamic aspects are used on processes themselves to tackle the problem of ht-fixes to long running processes.
In "Business Rules Integration in BPEL – A Service-Oriented Approach" [8], service orchestration is viewed as a conversation and agents are used to handle conversation failure. In "Business Rules Integration in BPEL – A Service-Oriented Approach" [8], two approaches, namely tightly coupled and loosely coupled, suggest the integration of business rules into process-oriented Web services composition.
Problem Definition
Exposed Challenge
The conventional way of orchestrating services is to specify the business processes that determine the flow of control and data among them [1]. Usually, these processes are coded in a general purpose programming language such as C# or Java, a business process language such as BPEL, or by using a variety of other business process management (BPM) or workflow tools. In a tightly coupled world, these languages and tools are just fine.
However, the loose coupling and increased granularity of SOA can greatly complicate service composition. SOA provides far more components to select from and far more components to orchestrate. Orchestration itself is complex, because business value depends on the ease with which business processes can be orchestrated to individual customers and business conditions. Different business units must be able to create and change their own services, independently of others. Moreover, today's highly connected business environment requires continuous adaptation and process change.
These demands pose severe challenges for service orchestration if the promise of SOA—business level adaptability, faster time to market and lower total cost of ownership—is to be realized. Conventional programming and business process languages are not up to the task. The key problem—whether using Java, BPEL or visual drag-and-drop BPM tools—is that the processes and services are all tightly coupled. Because every possible flow must be directly specified, building business processes that can handle diversity and individualization rapidly leads to spaghetti code. The handling of exceptions, failures, and unanticipated events must be explicitly coded, leading to more spaghetti. The process linkages need to be searched, examined, and rewired whenever there is a significant business change.
These limitations take process specification and development well away from the business side, increase development costs, and make business change difficult, expensive, and error prone. In short, most of the promised benefits of a loosely coupled SOA get lost in the tight coupling of business processes and tightly linked control and data flows. To overcome these challenges, businesses need a new paradigm for Web services orchestration.
Proposed Approach
Goal-directed orchestration (GDO) [1][6] —GDO takes as starting point three concepts fundamental to the business side: business goals (objectives or desired outcomes), business context (current situation), and business events (dynamics). It then uses these concepts to specify the business processes. Using GDO, a library of business processes can be created, each independent of any others, and each containing the full semantics for their use: the goals (objectives) they achieve or the event to which they respond; the business context or circumstances in which they are appropriate; and the sub-goals that, in turn, need to be achieved for the process to be successful. To make the GDO approach work, one needs a GDO [1] framework, consisting of both a development environment and a run-time environment.
And the magic sauce is simply a matter of changing the ways of seeing. It is required to extend the loose coupling and semantic encapsulation of the SOA to the business processes themselves and define these processes in the way it is done in the real world in terms of the goals needed to achieve instead of by sequences of tasks and actions.
Goal-based AI Technologies
A major concern throughout the development of technologies for automated problem solving within artificial intelligence (AI) is the provision of more sophisticated support for the client side. End users should be able to formulate system usage requests on the knowledge level, such as specifying objectives to be achieved by stating the desire on a human understandable level and abstracting from technical details on service or resource consumption. Therefore, the concept of goals has been introduced for request formulation as a declarative objective description that abstracts from concrete service invocation. Applying this notion within IT system design yields a goal-driven architecture: a system takes a goal as input and automatically determines and executes suitable resources for resolving the goal. Because the term "goal-driven architecture" [9] is quite vague and undefined in literature. The idea of goal-driven architecture is explained using an example Virtual Travel Agency use case scenario.
A client C wants to book a one-week holiday by using an advanced IT system S that provides computational facilities for automated travel and tourism-related booking. C has some further constraints on the holiday package to be booked; for example, the destination should offer a beach and allow swimming in an ocean, but it is preferable to not be in a country where travel warnings are given by the government; he also wants to book a scuba diving package, and the accommodation should be located in the center of a city or village. The system S should allow C to specify his objective, along with the constraints, while S should be able to automatically detect, arrange, and utilize available computational facilities for solving the objective—similar to the service offered by a real-world travel agency.
The main merit of such systems is that they bridge the gap between the human and the machine-level problem solving. Obviously, sophisticated goal models that allow specifying user objectives and carry all information needed for automated goal resolution are the central requirement for realizing goal-driven technology.
As outlined earlier, goal-driven architectures attend to the grand aim of AI of creating intelligent systems that automatically perform tasks in a similar way that humans do. Although a commonly accepted framework for goal-driven architectures does not exist.
Survey of Approaches and Techniques
Because the central requirement for realizing goal-driven technology is to have a goal model that allows specifying user objectives and that carries all information needed for automated goal resolution, various goal resolution approaches [10] are analyzed. The following three techniques for automated goal resolution are identified:
- SOAR.
- BDI agents.
- AI planning.
The decision cycle of SOAR along with sub-goaling applies forward chaining to be able to subsequently choose the operators for reaching the goal state from the initial state. The central characteristic of automated goal resolution within the belief, desire, intention (BDI) framework is interleaved action and planning, meaning that the agent observes the world, determines intentions and executes, and then repeats this process until the final desire is solved. As the third goal resolution technique, AI planning techniques automatically create the goal resolution plan by matchmaking and forward-chaining or backward chaining. Each of these techniques allows resolving the specific type of goals.
Summary of the Findings
Because systems in service-oriented environments are highly dynamic, the existing AI planning approach is not exactly suitable because of the previously mentioned drawbacks. On the other hand, the other goal-based AI approach goal-directed agent is found suitable to overcome the drawbacks of an existing AI planning approach.
Goal-directed agent theory finds its origins in BDI (belief, desire, intention) model from research conducted at Stanford University for NASA. BDI agents differ from traditional AI planning models with the concept of intentionality. This rationale allows the search space to be pruned and for action to be taken, thus allowing efficient real-time behavior. However, it is the flexibility of BDI architecture that makes it appropriate for an agent that must display human-like behavior.
The world is complex and in general cannot be planned for because something unexpected will always arise. The goal-directedness of BDI agents enables them to deal with unexpected events gracefully, instead of just falling in a heap.
Goal-Directed Agents
Goal-directed agents [11] adapt real-time as they select the next plan, based on the most current information that is available for the situation.
Figure 1. Goal-directed agent model
When a plan fails, an agent tries alternative plans that fit the same goal, based on updated agent data, until the current goal is successfully completed. If there are no more plans available, an agent declares the goal unsuccessful and forces failure of the plan that was called by the particular goal. By doing this, the agent automatically backs up to the goal that triggered the plan, trying other plans that fit the current situation. As a result, software agents build a successful completion path in real time, even when unplanned exceptions occur. Figure 1 illustrates the model of goal-directed agents. Goal-directed agents may use three key components to reason effectively:
- Beliefs—to capture knowledge about the environment in which they operate.
- Desires—to specify what it is that an agent is trying to achieve.
- Intentions—to capture decisions about how to behave now and in the future.
Proposed Architecture
This section outlines how a goal-directed model is used to propose architecture for the previously mentioned problem. The architecture depicts the system S that allows the client C to specify his objective along with constraints, while S should be able to automatically detect, arrange, and utilize available computational facilities for solving the objective.
Figure 2. Goal-directed model
Figure 2 illustrates a goal-directed model used to design an application. This model initially has high-level plans. These high-level plans are to achieve a sequence of goals. Each goal is achieved by a set of plans. If a goal can be achieved in different ways, it is further decomposed and separate plans are developed to achieve the goal. More plans can be added to the application at any time. The set of plans that are developed to achieve a goal is a service that is defined by the goal it fulfils.
Figure 3. Application development
Goal-directed agents act as intelligent mechanisms to determine the goal resolution plan during system runtime. A goal-directed approach significantly lowers application development and execution complexity. Application design involves defining a library of plans, each with the goal it fulfills and the rule governing its use. The actual application is then dynamically assembled at run time, based on the situation that is encountered, as shown in Figure 3. The architecture explicitly represents each goal with the set of plans designed to achieve that goal.
The proposed GDO system based on the goal-directed model automatically creates and executes the service requested by the user. The GDO system discovers the relevant services from the available services and creates the control flow between them. The user needs to only specify the service he or she wants, and the system converts this information into formal specifications required for service creation. The system can then generate a flow, and with some inputs, deploy the flow on to a run-time infrastructure. This should lead to a quicker service creation, and thus faster time-to-market for new services.
Case Study Loan e-Market Application
Scientific innovations are useless if they have no reflection on the economic activity and the society. For this reason, existing scientific efforts and present economical activity are gathered. As an example for this, the concept of a loan e-market is used for study. A loan e-market, which acts a common contact point for loans, is taken as a case study. This loan e-market is an intermediary between loan seekers and loan lending institutions. It uses a new consumer-to-business approach through tie-ups with banks and financial institutions. The loan e-market site provides a portal user interface to the user to input the required parameters. This user interface connects to the most important business processes, such as Expert on Demand, Loan Comparator, Loan Calculator, and Instant Loan Offer, to satisfy the various goals of the user. The development of one such business process, Loan Comparator [12], as shown in Figure 4, is detailed here.
This process gathers data from different financial institutions by finding and aggregating the services. Each bank provider, using its own formulae, calculates the data. The results after being ranked will be passed to the portal to be presented to the user. The comparator process is a composite process designed to integrate the different applications run by the lending organizations. Much of this service/application development is currently done in an ad-hoc manner, without standard frameworks or libraries, thus resulting in poor reuse of software assets. When a new service is needed, the desired capability is informally specified. An application developer must then create this capability using applications available in-house or from known vendors. This process is essentially manual. In the existing traditional environment, applications exist as silos or there is a custom-built integration between them with very few service reuse options across the applications.
Therefore, service providers need tools and standards-based run-time platforms to quickly develop and deploy interesting applications for their clients. This would assist in their transition toward "on demand," responsive businesses. This manual process can be optimized by the service-oriented technology. The SOA enables an enterprise to use the resources optimally, because it helps to create an application by assembling discrete application components. These are reusable components, which could be orchestrated to build different applications for diverse business processes.
The proposed agent-based solution goal-directed orchestration approach results in such SOA-based development approach. The proposed approach builds the required composite application functionality by assembling the reusable services. As a result, the new applications can be developed quickly and offer quick services to the customer. This agent-based solution is for automation of this process integration.
Figure 4. Loan Comparator process
Conclusions
GDO uses the language of the business to define the processes needed for orchestrating services. It models the business in terms of goals, events, the processes to achieve and respond to them, the data these processes need, and the context in which those processes are appropriate. In short, it greatly simplifies specification of the processes needed to orchestrate services and build new functionality and new composite services. GDO will remove the roadblock of service orchestration, allowing SOAs to realize their potential, giving business faster time-to-market times, greater ROI, and demonstrable value from SOA initiatives. At present, implementation of the architecture is being done and its further characteristics are being studied. Our aim is to work on this architecture and to prove that it significantly orchestrates the business processes according to customers' needs dynamically in a lesser time and in a smarter way.
References
[1] Service Orchestration: The Next Big Challenge by Michael Georgeff-Published in BI Report in June 2006. Printed from DMReview.com
[2] Web Services Orchestration and Choreography Chris Peltz Hewlett Packard Company, published by IEEE, 2003.
[3] Web Services Orchestration - a review of emerging technologies, tools, and Standards -Chris Peltz Hewlett Packard, Co. January 2003 ©2002-2003 Hewlett-Packard Company
[4] Service-OrientedArchitecture: Implementation Challenges Easwaran G. Nadhan Principal, EDS April 2004
[5] Orchestrating Composite Web Services under Data Flow Constraints -Girish Chafle Sunil Chandra Vijay Mann Mangala Gowri Nanda, IBM India Research Laboratory
[6] Weaving Aspects into Web Service Orchestrations -Proceedings of the IEEE International Conference on Web Services (ICWS'05)
[7] GODO: Goal driven orchestration for Semantic Web Services- Juan Miguel Gomez, Mariano Rico, Francisco Garcia, Christopher Bussler, DERI, Ireland.
[8] Business Rules Integration in BPEL – A Service-Oriented Approach - Florian Rosenberg and Schahram Dustdar Vienna University of Technology
[9] DIP Data, Information and Process Integration with Semantic Web Services, Deliverable WP3: Service Ontologies and Service Description D3.10 Goal Description Ontology, Michael Stollberg (UIBK), Martin Hepp (UIBK), July 10, 2006
[10] Cognitive Architectures in a Rational Analysis J. Anderson. In K. van Lehn, editor, Architectures for Intelligence, pages 1{24. Lawrence Erlbaum Associates, Hillsdale, N.J. (USA), 1991.
[11] Augmenting BDI Agents with Deliberative Planning Techniques, A. Walczak, L. Braubach, A. Pokahr, W. Lamersdorf, Distributed Systems and Information Systems, Department of Informatics, University of Hamburg, D-22527 Hamburg, Germany
[12] DIP Data, Information and Process Integration with Semantic Web Services, Analysis Report on eBanking Business Needs, Mónica Losada Richard Benjamins, 30 June 2004
Không có nhận xét nào:
Đăng nhận xét