Solving the Service Composition Puzzle

2008 IEEE International Conference on Services Computing

Solving the Service Composition Puzzle Yuan-Chi Chang, Pietro Mazzoleni, George A. Mihaila, David Cohn IBM Thomas J. Watson Research Center Yorktown Heights, New York

Abstract

ership organizations dictate what and where an integration intermediary may be set up and managed, which in turn lead to different composition patterns. An IT architecture must be conscious of such relations to effectively deliver the benefits of composed services. In practice, we observed the choice of composition patterns have been largely ad hoc and lacked formal justification based on impact and cost analysis. Furthermore, the lasting impact of such design decisions can be costly to correct. The multi-factored design dimensions, as well as costs associated with developing, operating and evolving the services, demand much on the experience of the composition architect. The contribution of this paper lies in the framework and methodology of bringing design formalism into the architecture. The rest of the paper is organized as follows. We first review related literature in Section 2. Section 3 analyzes different business situations requiring service composition. Section 4 defines and describes six patterns of composition. Section 5 reviews some of the factor which impact the application of these patterns. Section 6 outlines the advisory tool we built to analyze the impact of the composition patterns in a real case scenario. Section 7 concludes the paper and points to future research directions.

We observed and grouped common service composition techniques into six patterns with distinct characteristics of their integration intermediary. No pattern is better than others in all business and IT situations. Therefore our analysis suggests a formal methodology in impact and cost analysis to justify the choice of composition patterns in service design. Our contribution leads to an advisory tool consisting of questionnaire, semantic reasoning and assessment map to assist IT architects in making a decision of lasting impact. Through solving the service composition puzzle, we hope further values of service oriented architecture may be demonstrated at a fraction of total ownership cost.

1

Introduction The whole is greater than the sum of its parts.

Service composition connects existing component services to deliver new functionality which none of its constituents can provide. The appeal of service composition resides in reuse and low cost integration, which effectively puts additional burden on the medium of integration. This paper investigates patterns of service composition from the viewpoint of integration intermediary, which may be human, browser widget, storage, program, workflow engine or event broker. We noticed when a decision was made to apply one pattern over the others, it is uncommon to appreciate and document the full impact of the decision for fair evaluation. Our study explores the impact dimensions in agility, scalability, interoperability, monitoring and robustness. Our analysis leads to a design advising tool to rationalize design tradeoffs in the short term and longer run. While service composition is often referred in the context of web services or service oriented architecture, it can be materialized in many ways, including connecting atomic applications within and between organizational boundaries. Thus our study scope encompasses the broader definition of service composition. Business relations among the own-

978-0-7695-3283-7/08 $25.00 © 2008 IEEE DOI 10.1109/SCC.2008.61

2

Related Work

Service-oriented computing is gaining momentum, and the ability to correctly and efficiently assemble solutions by composing existing services is essential to its success. It is understandable then that service composition has received considerable attention in recent years both from the academic and the industrial research communities. Services can be designed and implemented using a variety of tools and programming languages. Anybody can implement a service, but it is not obvious how to design services for composition. Oftentimes, the composed service’s processing logic is tightly coupled with context handling, presentation, database access, etc. To this end, modeldriven methodologies that decouple these aspects have been proposed [19, 27].

387

Several service composition specification languages are in use today. Among the most prevalent service composition approaches we note BPEL, OWL-S, Web Components, algebraic process composition, Petri nets and finite state machines. A good survey and comparison of these approaches can be found in [15]. Furthermore, a taxonomy of service composition approaches based on how and when the composition and execution takes place is provided in [4]. Service composition patterns are also extensively discussed in [3] and are the subject of at least two forthcoming books [20, 7]. When designing an application by composing services, a system architect first needs to specify the application in terms of modules with a well defined behavior and interfaces and then to identify services that can be used to supply the functionality of each module. If no perfect match can be found, frameworks like OSCA [17] provide a principled way to analyze how well services match the requirements of each module. Once suitable services are found, selecting among a potentially large set of candidates can be done using semi-automated tools [22] that filter inappropriate services and check validity of services. Moreover, the service bindings can be dynamically changed in order to adapt to intermittent availability of services [13]. While identifying and qualifying services for use in composite applications is relatively well studied, the problem of selecting a composition pattern that matches the IT and business requirements received relatively less attention.

3

likely to extend and connect enterprise service buses but a shared orchestration server is still possible through a chosen set of exposed services. More often, partner services are directly invoked through hard coded programs, which are written specifically to comply with the contract. In a marketplace environment, where the market owner defines and referees rules that participants must follow, service composition is further restricted to the programming and data model of the marketplace. Predefined data objects and APIs for interoperability among services are commonly used in a marketplace setting [21, 24]. A recent example is the announcement of the integration of web based CRM applications with web based productivity suite to synchronize data objects including client contacts and appointments [5]. On a hosting platform, where its owner provides a selfcontained environment that includes data, programs and tools, a composite service stays within the environment throughout its lifecycle. Quite often the main composition mechanism is through browser-based widgets that are lightweight and flexible [8, 9, 14, 26]. Finally, when no business relationship or trust can be established, service composition is resorted to the impromptu model. Services are assembled to fulfill a short term need since there is no guarantee of long term availability. The composition approach in this model is often ad hoc and difficult to provision robustness and agility. Since service composition must work within the boundaries of business situation, we examined six composition patterns in the next sections to illustrate the choices and tradeoff a designer faces. It will soon be clear that choosing one or more patterns can conversely affect the delivery and efficiency of business situation.

Business Situations and Composition Scenarios

Service composition takes place not just within a single organization but also across organizations. The business situation often defines the constraints bounding composition technologies. Our work was partly stemmed from designing a business venture to build a community of service providers, composers and consumers. The venture was explored from tightly connected to loosely coupled business relations among the participants in the community. In considering the spectrum of business situations, we examined enterprise-like, partnership, marketplace, hosting and impromptu models. In an enterprise-like environment, where internal control enforces governance and standards, service composition takes an open and approachable form. For example, it is feasible to set up an enterprise service bus [11, 23] or a shared master data. Some may even argue service composition is a natural evolution of enterprise application integration (EAI) developed in the 90’s. In a partnership environment, where contractual binding defines some governance and standards among the partners, service composition takes a more guarded form. It is less

4 4.1

Composition Patterns Motivating Example

To better describe the six patterns of service composition, we will use a simple example, accompanied with design sketches, to illustrate the different patterns. In this hypothetical scenario, there are two commonly used business services. The first retrieves the list of products orders. We name the service WS1 and as a part of its functions, the GetOrders method returns the list of orders. An order contains a product code, a customer name and the recipient address. The second business service ships a product based on an order. We name the service WS2 and as a part of its functions, the ShipOrder method accepts a product code, a customer name and the recipient address to issue a shipping slip. The method returns a tracking ID for the shipment. Previously these two services were run and managed independently. As illustrated in 1, each service might have

388

?

WS1

Storage1

composition. Similar to Type G, composition by widgets might require human interactions to route connection messages. The difference is, while in the previous case the behavior of the composed business process is completely manage by humans, in Type W it is fully or partially embedded as part of the user interface. As depicted in Figure 2-b, UI1 could be extended with a widget allowing the human operator to select (via a checkbox) the list of orders he wants to process. When completed, the user pushes a button which copies the selected orders to UI2 shipping form widget and then submits the ShipOrder request.

UI2

UI1

WS2

Storage2

Figure 1. Composition Example

4.4

Composition by Direct Invocation

its own graphical user interface, called UI1 and UI2 respectively, and storage space (in the form of file system or database), represented in the Figure as Storage1 and Storage2. To streamline operations, it is desirable for WS1 to pass the order information to WS2. In the scenario,what are the ways to compose a new service by connecting WS1 and WS2? In the rest of the section, we present six different patterns which can be used to answer to such question.

We define composition by direct invocation, or Type D, as a method to connect services by developing a custom application that calls the services and handles the data and control flow explicitly. In our hypothetical scenario, Type D composition (presented in Figure 2-c) involves implementing an application that first calls GetOrders method and then iterates through the returned orders and invokes ShipOrder method for each of them.

4.2

4.5

Composition on the Glass

We define composition by information sharing, or Type I, as a method to connect services by a shared access to persistent storage space which holds service invocation information. The shared access may be a logical view, through data federation techniques, over a disparate set of physical storage. Or alternatively, the services do access the same medium. Different from Type D, in which orders are transient objects manipulated by the service and then destroyed, Type I persists the processed orders for tracking and reporting purposes. Figure 2-d illustrates this pattern by emphasizing that it is the persistent storage, such as file system and database, of the two services that interacts to create a information sharing layer. In order to implement this composition pattern for our example scenario, one would need to develop two service adapters: the first adapter retrieves the orders from Storage1 and stores them in the persistent store and the second adapter to get the new order from the persistent store and to place them in Storage2.

We define composition on the glass, or Type G, as a method to connect services by presenting their user interfaces on screen and have a human operator serve as an intermediary to route connection messages. Figure 2-a illustrates this pattern with UI1 and UI2 displayed together without a link between the two. In our hypothetical scenario, a human operator logs on to UI1 to display new orders and then logs on to UI2 to manually enter the orders for shipping. The manual entry may involve additional steps in checking the validity of the order information, verifying the correctness of address, and looking up shipping guidelines in accordance to the ordered product. The human operator may also translate and transform the data as needed to satisfy UI2 requirements. Perhaps less recognized than it should be, Type G is prevalent in use today and often serves the need to interact with legacy applications.

4.3

Composition by Information Sharing

Composition by Widgets

We define composition by widgets, or Type W, as a method to connect services through programmatic interactions between their on screen representations, such as forms, maps and buttons. Pluggable user interface components are managed, displayed, interacted using webdevelopment techniques (e.g. Ajax) which facilitate service

4.6

Composition by Orchestration

We define composition by orchestration, or Type O, as a method to connect services by a workflow specification which defines both communications among services as well

389

Ship Order WS2 WS

G eW t SO1r d e r WS

S hW i pS O2 r d e r WS

G eW t SO r1d e r WS

Ship Order UI2 UI

Get Order U I 1U I

Workflow Engine

Workflow Engine

m P rPor oggrraa m

BPEL (a) Glass

(c) Direct Get Order Storage1 Storage

S hUi pI 2 O r d e r UI

G eUt I O rder 1 UI

(e) Orchestration

j a v a sA c rj iap x t,Ajax

ShS i pt oO rder rage2 Storage

G eWt SO1r d e r WS

(d) Information

S hWi pS 2O r d e r WS

PPuubb / S Suubb

a ggee SSt toorr a

(b) Widget

BPEL

(f) Event

Figure 2. The six composition patterns the behavior of the composed process. As depicted in Figure 2-e, a workflow engine recognizes the specification, correlates it to the executable services, and handles those messages appropriately. In order to implement this composition pattern for our example scenario, one would have to define the composed process such that for each output (i.e. pending order) retrieved by invoking GetOrders method, a request to ShipOrder method is generated. The output of WS1 will be redirected to WS2. As part of the process, additional functions such as data transformation or monitoring can be defined.

4.7

design decisions of a service composer. During the design, it is common to question and evaluate options to achieve scalability, robustness, interoperability, agility, monitoring, etc. This section discusses a few representative characteristics and rates the composition patterns from easy to hard qualitatively. The list of impacts, graphically presented in Figure 3 is by no means exhaustive and should be considered in weighing other business requirements. While in practice, service composition designers often implicitly choose one pattern over another, this impact analysis help clarifying the tradeoff to rationalize the design.

5.1

Composition by Events

In the context of service composition, a transaction is a logical unit of work involving one complete end-to-end execution of the implemented business process. Thus, transaction throughput is defined as the number of such executions of the composed application in a given unit of time. Assuming that one of the business requirements of the composed application is the ability to support a high transaction throughput, let us analyze how this requirement can be met by each of the service composition patterns. The first obvious observation we can make is that it is harder to support high transactions using the composition patterns that involve a human operator (Type G and W) than by deploying a fully automated solution. If a G or a W pattern must be used, the only way to scale the composed application to high throughputs is by employing many operators, which could be very expensive. At the other end of the spectrum, the most efficient runtime can be engineered by using Type D since there are no additional levels of indirection or human intervention. The remaining composition patterns incur comparable amounts of overhead, either from

We define composition by events, or Type E, as a method to connect services by publishing and receiving event messages to predefined topics on a pub/sub server, which serves as an intermediary to asynchronously deliver connection messages. Figure 2-f illustrates this pattern with WS1 and WS2 loosely connected by a pub/sub platform, which may span multiple pub/sub servers. In our hypothetical scenario, WS2 first registers and subscribes to a topic or named logical channel called ‘ToBeProcessedOrders’. When WS1 publishes an event message containing the order information to the ‘ToBeProcessedOrders’ topic, the pub/sub platform notifies WS2 to receive the published order and to invoke ShipOrder.

5

Scalability - Transaction Throughput

Impact Analysis

The specificity and capability of the service composition intermediaries leads to unique characteristics that influence

390

D

O,E,I

easy

G,W

O

hard

easy

a) Transaction Throughtput

O easy

E,I

W,D,G hard

b) Process Monitoring

W,E

hard

c) Exception Handling

G,O

G,W

G,I,D

E,I

easy

O,I

E,D

easy

hard

e) Data mediation

W,D hard

d) Process Evolution

Figure 3. Impact analysis characteristics the additional levels of indirection caused by the orchestration engine (for Type O), or the event publishing infrastructure (for Type E), or the database management engine (for Type I). This justifies placing these patterns in a cluster in the medium range for transaction throughput as reported in Figure 3-a.

for Type I and E technologies already exist which separate the specification of the KPIs from the process to be monitored, in case of Type W and D, the business logic of the monitoring needs to be hard-coded along with the process.

5.2

Exception handling is a part of the service specification construct designed to address the occurrence of conditions that lead to deviations from the normal execution flow. A composite service is more critical on exception handling than a standalone service due to compounded risk on multiple service components, including connection disruptions, illegal data inputs, individual service outages, etc. In special cases, the lack of service invocation over an extended period of time may be treated as an exception also, which may mean the upstream service chain is broken. For a service composition design point of view, exception handling is hard to test and validate and thus may require several iterations of runtime testing and design revisions. Among the six types of service composition, Type O with its explicit workflow specification, is the easiest to add and change exception handling. For example, the “faultHandler” construct in BPEL enables programmers to deal with different exceptions in catch-and-handle fashion. Compared to Type O, Types W and E are a little harder to incorporate exception handling. Type W requires in fact changes to the scripts running at the browser, where we have seen many Web sites checking mandatory fields before submission. Type E can create new message topics to accommodate unforeseen exceptions. As depicted in Figure 3-c, we place Types G, I, and D on the hard side to address exceptions. Contrary to popular notion, Type G requires new instructions and training for the human operator to react to irregularity of composed service. While there is an inherent flexibility in Type G, exception

5.3

Monitoring - Process Monitoring

Process monitoring is a key element of any composed service, especially within industry. In case of service composition, Key Performance Indicators (KPIs) represent technical and business metrics for both the to-be-composed services (e.g. number of new orders received each month) and the composed ones (e.g. the average time between receiving and shipping an order). Managing KPIs might a very complex task as it requires a deep understanding of the process as well as the business objectives (e.g. customer satisfaction, minimize delays) to be monitored. Among the six types of composition described in Section 4, Type O is the most feasible to implement monitoring as many SOA vendors, including IBM, offer today a welldefined “Model-To-Monitor” [2] approach to monitor processes. In a nutshell, metrics are specified along with the abstract model of the process to be monitored. At runtime, the workflow engine recognizes such metrics and generates the corresponding values. On the other hand, we recognize Type G to be the composition type more difficult (where possible) to monitor. Such because the business logic of the process is entirely left to humans. It is therefore not possible to compute metrics without relying on some technology (e.g database triggers) which is outside of such composition type. The complexity of implementing process monitor solution for the other composition types can be placed in the middle of the previous two (Figure 3-b). However, while

391

Robustness - Exception Handling

handling rules still need to be documented and followed. Types I and D are both difficult to change iteratively, since both embed logic in programs or storage.

5.4

formed at runtime by the workflow engine. Similarly, when the composition is provided by a shared information space Type I, data mediation can be handled by the database (for example, through views). Data mediation is harder to implement in the case of Type E, because custom data adapters need to be placed between services. Finally, Type D requires custom data mediation code to be inserted in the implementation of the service invocation code.

Agility - Business Process Evolution

Business processes are, by nature, not static but in constant evolution to reflect the changes of the business they represent. Different types of evolution exist. Process evolution can impact the structure of the data (e.g. support for two last names when shipping to Spain), the list of composed services (e.g. include custom clearance service) or business rules (e.g. custom clearance service is needed only for shipments worthy more than 1000 US Dollars). Not all evolutions have the same business impact or happen with the same frequency. Not only, while some evolutions might be foreseen by the user at the time the composed service is created, others might become needed only afterwards. As depicted in Figure 3-d, the easiest composition type to implement process evolutions is Type G. As the business logic is totally managed by humans, no (or very minor) IT changes are needed. On the other hand, G implies users to be trained to understand how to realize the new process. On the other extreme, the most complex composition type for managing process evolutions is Type D as the programmer needs to hard-code the changes directly as part of the process. Similarly to what described for Process Monitoring, the other composition types can be placed in the middle of the two above. Only Type O is probably easier as BPEL and related technologies are mature enough to support processes changes. However, as in case of Types W, I and E, , in Type O some specific IT knowledge are needed to implement such changes.

5.5

6

Cost-Based Design Decision Tool

To choose from among the six design patterns, the architect must consider a number of functional, nonfunctional, and infrastructure factors. In this section, we briefly describe the tool we built that allows architects to rationalize their design decisions through cost analysis, impact analysis, or a combination of both. Our tool is composed of three main elements: a design questionnaire for collecting estimates related to each of the six patterns, a semantic reasoner for performing the analysis, and an assessment map visualizer for visualizing the results. It should be recognized that there is no “hard” evaluation criterion applicable to composition design since there are both qualitative and quantitative factors in consideration. The design tool makes recommendation with explicit presentation of design tradeoffs to rationalize the architecture chosen. The questionnaire contains questions about the business and IT characteristics of the services being composed. The questionnaire also includes questions about the underlying IT infrastructure and the experience of the users composing and using the services. Because the number of questions may be very large, we used IBM’s Conversational Application Builder technology, originally proposed in [16].1 In a nutshell, we created a knowledge base that allows our decision tool to reason and dynamically filter out paths through the questionnaire that do not lead to valid results. For example, if the architect is interested only in composition by orchestration, then our design tool will not ask about the services graphical user interfaces (GUI) unless no other interfaces are available. The reasoner uses the design information from the questionnaire to determine the cost of each composition type. Logic programming rules are used to encode relationships among costs, impacts, and service composition types. We used Smodels[18], an implementation of stable model semantics [10] and well-founded semantics [25] for normal logic programs. Smodels was selected because it can process large numbers of rules in linear time. Nonetheless, our tool can be easily adapted to work with other reasoners. Figure 4 shows some simplified rules that determine the cost of creating a widget-based GUI for the service to be

Interoperability - Data Mediation

In the context of service composition, data mediation refers to the process of transforming the output data from one service to match the input data format required in order to invoke another service. The ability to perform data mediation is especially critical in the context of service evolution, when the service input/output interfaces change over time. Clearly, the highest flexibility for data mediation is provided (see Figure 3-e) by human operators (Types G and W), who have an innate capacity to adapt to differences in data requirements. For example, if one service outputs full addresses, and the invoked service requires street, number, city, state and zip a human operator will have little or no trouble recognizing the address parts. In the case of Type O, data mediation can be relatively easily configured outside the services’ code and is per-

1 This technology will soon be //alphaworks.ibm.com/tech/cab.

392

available

from

http:

A1: A2: A3: R1: R2: R3:

service(ws1). interfaceOf(ws1,html). service(ws2). interfaceOf(ws2,widget). service(ws3). interfaceOf(ws3,widget). service(ws4). interfaceOf(ws4,html). numService(4). costInterface(high) :- interfaceOf(X,none), compType(widget), service(X). costInterface(medium) :- interfaceOf(X,html), compType(widget), not interfaceOf(X,none), service(X). costInterface(low) :- N {interfaceOf(X,widget): service(X)} N, compType(widget), numService(N). Figure 4. Interface building cost rules in case of W process monitoring

composed via Type W (widget) pattern. The table contains facts and rules. Facts are the answers to questions on the questionnaire. Rows A1 and A2 contain facts that specify the names of the services being composed and their interfaces (chosen from “none,” “html,” and “widgets”); row A3 defines the number of services. Our example has three rules. The rule in row R1 specifies that the cost of creating a widget-based GUI for the services is high if at least one of the services being composed has no GUI. In this rule, compType(widget) specifies the service composition type to which the rule applies. The variable X represents all services defined in the model (i.e., all services X such that service(X)). Similarly, the rule in row R2 specifies that the cost of creating a widget-based GUI for the services is medium if all the services have some GUI (i.e., not costInterface(X,none)) but there exists at least one service exposing static html. Finally, the rule in row R3 specifies that the cost is low if there are N services that all expose widgetbased interfaces, where N is the number such that numService(N). After this process is executed for all composition types and all impact axes, a design assessment map is produced as shown in Figure 5. On the map, costs are first normalized to fit concentric rings, each describing an impact axis. The centroid marks zero cost and the outer rings reflect higher costs. The assessment map provides a global view of the tradeoffs among the impact axes. The architect can further drill down on the estimates of development, production, and evolution factors. By looking at Figure 5, architects will realize that it costs too much to gain high throughput via Type W composition. A further drill down could suggest replacing the throughput bottleneck with Type D (direct invocation) composition. The final architecture thus might become a widget-based composition with some steps implemented by direct invocation.

7

service Interface

transaction throughput

failure recovery

composition complexity

exception handling

process evolution

structural variation

Figure 5. Design assessment example of Type W where the cost increases outwards from the centroid

their impact on various business requirements. The end goal was to assist a composer in selecting among several composition alternatives based on expected fitness to given non-functional requirements, such as scalability, monitoring ability, robustness, agility and interoperability. Of critical importance in this selection process is the expected cost of implementing and operating a solution using each composition pattern. To this end, we proposed a cost estimation methodology that takes into account elements of the IT environment, such as maturity of the infrastructure, the associated skill set and the overall strategy of an organization as well as the target level that needs to be attained on each nonfunctional requirement. To assist in exploring the feasible alternatives and trade-offs, we developed a recommender system which encodes all the constraints and the cost model as a set of logic programming rules which, when evaluated, generate the set of all feasible solutions together with their costs and a detailed break-down of the work involved. In our analysis we were clearly not exhaustive, both in the space of composition patterns and techniques as well

Conclusion

In this paper, we focused on application design using services. Thus, we started exploring the space of service composition patterns used by practitioners today, and discussed

393

as in the set of IT and business requirements. A recent article provided an updated view on SOA and pointed out many research challenges [6]. The most prominent omission in our study is the pattern of composition by choreography [1]. While we did not find sufficient evidence of its large-scale adoption in the industry, we believe this approach has good potential, due to its declarative nature. Another important aspect is the design of services for composition. What makes the problem different from traditional software development is the fact that use cases and business requirements are typically less well understood at the design phase. In order to be used in practice, the techniques highlighted here need to be extended and adapted to the concrete situation at hand. In order to better generalize to arbitrary composition patterns, a unified composition specification logic would be needed. A composition specified in a platform independent logic would then be automatically translated into concrete composition patterns. As part of our current research, we are investigating ways to automatically generate the rules of our recommender system from high-level specifications, such as UML profiles for services. Another direction for future research is facilitating the evolution of an already deployed composed application, in order to better suit changing requirements. For example, an application might have been assembled using composition by the glass if the initial transaction volumes were low, and now needs to be scaled up to higher volumes. Ideally, one should be able to change the architecture of a composition as needed, without changing the implementation of the constituent services themselves.

[5] [6]

[7] [8] [9] [10]

[11] [12]

[13]

[14] [15]

[16]

[17]

Acknowledgment

[18] [19]

A special thanks to our colleagues Erik Mueller and Doug Riecken for their valuable inputs and for sharing with us their experience with semantic engine. We are thankful for the comments from anonymous reviewers to improve the quality of the paper.

[20] [21] [22]

References [23] [1] WS choreography working group. http://www.w3.org/2002/ws/chor/. [2] M. K. G. Ackerman and Others. Patterns: SOA Foundation - Business Process Management Scenario. IBM RedBooks, August 2006. [3] J. Adams, S. Koushik, G. Vasudeva, and G. Galambos. Patterns for e-business. A Strategy for Reuse. IBM Press, August 2001. [4] V. Agarwal, G. Chafle, S. Mittal, and B. Srivastava. Understanding approaches for web service composition and execu-

[24] [25]

[26] [27]

394

tion. In Proceedings of the 1st Bangalore annual Compute conference, January 2008. P. announcement. Website:. http://www. salesforce.com/googleapps/. J. Erickson and K. Siau. Web services, service-oriented computing, and service-oriented architecture: Separating hype from reality. Journal of Database Management, 19(3):42–54, 2008. T. Erl. SOA Design Patterns. Prentice Hall/PearsonPTR, forthcoming - 2008. Facebook. Website:. http://www.facebook.com. G. Gadgets. Website:. http://code.google.com/ apis/gadgets. M. Gelfond and V. Lifschitz. The stable model semantics for logic programming. In R. A. Kowalski and K. Bowen, editors, Proceedings of the Fifth International Conference on Logic Programming, pages 1070–1080, Cambridge, Massachusetts, 1988. The MIT Press. IBM. Ibm service oriented architecture (soa). Website:. http://www.ibm.com/soa. IEEE. 2007 IEEE International Conference on Web Services (ICWS 2007), July 9-13, 2007, Salt Lake City, Utah, USA. IEEE Computer Society, 2007. I. Jureta, S. Faulkner, Y. Achbany, and M. Saerens. Dynamic web service composition within a service-oriented architecture. In ICWS [12], pages 304–311. Microsoft. Website:. http://www.popfly.com. N. Milanovic and M. Malek. Current solutions for web service composition. IEEE Internet Computing, 8(6):51–59, 2004. L. Morgenstern, E. T. Mueller, D. Riecken, M. Singh, and L. Gong. Enhanced semantic networks: Hybrid knowledge structures for reasoning. IBM technical Report - RC23436, 2004. K. G. N. C. Narendra, K. Ponnalagu and A. P. Sheth. Variation oriented service composition and adaptation (OSCA): A work in progress. In IEEE International Conference on Services Computing (SCC 2007), 2007. I. Niemela and P. Simons. Smodels — an implementation of the stable model and well-founded semantics for normal lp. G. N. Prezerakos, N. D. Tselikas, and G. Cortese. Modeldriven composition of context-aware web services using contextUML and aspects. In ICWS [12], pages 320–329. A. Rotem-Gal-Oz. SOA Patterns. Manning Publications Co., forthcoming - 2008. Salesforce. Website:. http://www.salesforce.com. J. Schaffner, H. Meyer, and M. Weske. A formal model for mixed initiative service composition. In IEEE SCC, pages 443–450. IEEE Computer Society, 2007. J. Spohrer and D. Riecken. Communication of ACM: Special issue on Service Science. ACM Press,New York, NY, USA - July 2006. Strikeiron. Website:. http://www.strikeiron.com. A. van Gelder, K. Ross, and J. S. Schlipf. The well-founded semantics for general logic programs. Journal of the ACM, 38(3):620–650, 1991. Yahoo. Website:. http://pipes.yahoo.com. Y. Yamato and H. Sunaga. Context-aware service composition and component change-over using semantic web techniques. In ICWS [12], pages 687–694.