Manners Externalize Service Semantics for Automated Service Composition Ali Arsanjani IBM Global Services, Maharishi University of Management Francisco Curbera IBM Research Nirmal Mukhi IBM Research ABSTRACT Architectural mismatch can be alleviated through the ubiquity of the protocols for service composition (syntax); yet the semantics remain elusive. We suggest the use of manners for explicit service semantics representation in a re-configurable architectural style. We describe the base requirements for automated component and services composition and show how automated assembly of components and services can be accomplished through a dynamically re-configurable (DyRec) architectural style. We show how this vision of dynamic reconfiguration is naturally supported by the Web services framework, because it derives from some of the core requirements of the Service Oriented Architectures (SOA) style embodied by Web services. Further, we discuss how such a DyRec architectural style can be implemented using grammar-oriented object design (GOOD) and describe a project that led to a tool called the Business Compiler, to accomplish dynamic composition and collaboration. Keywords Manners, service composition, service-oriented architecture, component-based software engineering, Grammar-oriented object design, context-aware components, on-demand computing, dynamically reconfigurable software architecture. 1. INTRODUCTION Business agility is achieved through a business model that supports rapid response to changes inside and outside an organization. Such business models require the support of a software enterprise architecture that absorbs and allows dynamic alterations and enhancements to applications. Cost-effective and timely alternations are typically feasible when they do not rely on intrusive changes; as such changes typically introduce architectural entropy and side-effects to the application and runtime architecture of the applications, making the architecture more brittle with every unanticipated change. We propose that a dynamically re-configurable architectural style is required to realize these rapid changes in business needs and quality of service (QoS) to support an enterprise’s systems and applications. We will show how the web services set of standards is already defining a framework in which dynamic reconfiguration is enabled as a first class characteristic of network applications. In this dynamic environment, an automated assembly-oriented paradigm, one of dynamic composition, is needed to augment current component-based software engineering practice. The elusiveness of dynamic composition arises from the fact that manual composition has not yet been realized on the orders of magnitude of productivity that were envisioned [13]. Part of the problem has been the lack of ubiquitous standards in additional to the lack of general availability of commercial components to meet the wide spectrum of functional and extra-functional requirements. 2. Service-oriented Architecture This dynamic composition paradigm is already emerging in response to a shift in the way enterprises conduct their business. Vertically integrated enterprises are being replaced by networked ones which rely on other businesses to provide them with services. As a consequence, IT infrastructures in which every application used is managed by a single enterprise are being replaced by networks of applications owned and managed by many business partners. Basic enablers of this transformation are a pervasive networking infrastructure and a set of standard protocols. The Service Oriented Computing (SOC) paradigm aims at recognizing this new computing environment and enabling a fully automated integration of diverse software applications and processes. We summarize the assumptions of the SOC model as follows: 1. Services are software applications that must be able to operate in a natively cross-organizational setting. Applications may access services owned by different, autonomous enterprises, and which may be deployed across the Web using heterogeneous system environments. 2. Service interaction fundamentally relies on a set of open standards that provide universal interoperability at the middleware level. Industry-specific, business level interoperability and semantics will gradually be Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Conference ’00, Month 1-2, 2000, City, State. Copyright 2004 IEEE. developed. In other words, the technical barriers to cross-enterprise interaction have disappeared. 3. The interaction between services is naturally conversational, or peer-to-peer, and loosely coupled. Loosely-coupled services combine traditional decoupled messaging-style interactions (data-exchange) with the explicit application contracts of tighter-coupled (interface-driven) object-oriented interaction styles. 4. Services declaratively define their functionality and Quality-of-Service (QoS) requirements and capabilities in a standard, machine readable format, enabling dynamic (runtime) and automated service discovery and use. In particular, no out-of-band or implicit assumptions about service implementations (including their local middleware use and execution environment) are acceptable, since they would compromise interoperability. 5. Service composition is at the core of the application development task. Applications are created by combining the basic building blocks provided by other services according to certain a business logic. Service compositions may themselves become services, following a model of recursive service composition. Particularly relevant to this paper is the component oriented aspect of the SOC model. Because of the lack of centralized control, the encapsulation of function in service components becomes unavoidable; at the same time, the interoperability requirement demands not only standardized access protocols, but also standard service (component) description languages able to represent service capabilities and behavoior in a machine readable format. We claim that this characteristics naturally make SOC a component oriented paradigm. SOC, realized in the Web services framework, presents a new face to the CBSE effort. In this paradigm a service provider publishes a service which may later be found by a service consumer attempting to find a service. When a match is found, the service description is used to directly bind and later invoke the service. However, the ability to find a service is seldom sufficient to support a business process’ use-case goal; rather an orchestration of services is often required to accomplish anything of value to the underlying business. Service orchestration is a common term used for describing the task of service composition.. Often, orchestration is done statically. The ability to perform dynamic orchestration will become a centerpiece of a dynamic enterprise architecture. In addition, the ability to syntactically find and bind to compatible services or components in no way guarantees that the composed whole will satisfy the semantics of the domain in the form of functional and extra-functional requirements. Garlan et al., point out, that there are “a variety of types of mismatch that center around the assumptions a reusable part makes about the structure of the application in which is to appear” [1], including programming language, data model and architectural mismatches. Extending Parnas’ notion of encapsulating design decisions to achieve units of composition [2], Arsanjani et al., have suggested the externalization of this composition through the notion of manners and context-aware software components, to achieve a dynamically re-configurable architectural style [3]. As it turns out, this form externalization can be achieved in the Web services framework, and is a natural consequence of the SOC assumptions we have just discussed. The basic characteristics for a service-oriented architecture (SOC) thus form the base requirements for a dynamic architecture; reconfigurability criterion needs additional characteristics which shall be outlined below. 2.1 Service Composition It is first necessary to distinguish between computation and composition and collaboration. Computations are the fine grained activities performed by using general purpose programming languages (such as Java or C#) that typically include mathematical calculations, Boolean evaluations and performance of functions based on these evaluations. Composition languages such as Piccola [8] aim at a small syntax with the aim of component assembly. Collaborations are defined by flows (BPEL4WS or DAML-S, for example) which may be workflows or other forms of purposeful integration of component behavior to achieve a collective goal; for example, for supporting a business. 2.2 Re-configurability Run-Time and Dynamic Re-configuration are characterized by the ability of underlying software architectures to rapidly respond and dynamically alter the functionalities of its components and services as well as the interconnection between them to suit the problem, and then re-configure necessary extra-functional aspects to maintain QoS and service level agreements (SLA). Practical considerations of performance, security and interoperability make these models currently difficult to realize although the advent of Web services standards in these areas are promising to alleviate many of the problems. The above characteristics have been researched to a large extent within hardware-related systems [27, 28, 29]. We would like to extend this to software systems and architectures. But in order to do so, we cannot take the paradigm and use it as is, from the hardware world; software components and services are not, despite common (mis)conception, “lego™”-like building blocks; but rather are more like organs in the body which are larger conglomerations of more minute components and provide a distinct function and goal within a context. They also exhibit a certain degree of resilience to changes in their functional and extra-functional capabilities. Thus, the re-configurability of software services and components is key. We maintain that this is achievable by exploiting Web services standards and applying novel methods through methods and techniques for composition such as grammar-oriented object design (GOOD). 2.3 The Web Services Framework The Web Services framework consists of a set of open standards, being defined by organizations such as the W3C and OASIS, that collectively act as a realization of the SOC paradigm. . Currently many of the specifications are just proposals or recommendations, but are on the path to standardization and have broad industry support. It is important to note that the framework is not predicated on any software, hardware or networking platform. Standards-based integration and composition of services promises the broadest reach and satisfies assumption (2) of the SOC model. At the base level, the standards consist of a set of communication protocols. In principle, the framework allows any standard protocol to be used. However, SOAP, an XML-based protocol, is the most widely used. The availability of XML parsers and SOAP implementations for a variety of platforms guarantees that data can be exchanged in a platform-independent manner. Applications owned by autonomic enterprises, deployed in heterogeneous systems, can thus communicate in a standard way using SOAP. This satisfies assumption (1) of the SOC model. Standards for security, reliability, transactions and QoS are defined over these base communication protocols. These are defined up front in a platform-independent manner as well, so there can be no underlying assumptions about the platform support, as described in assumption (4) of our SOC model. Currently there are a variety of competing specifications in this space. Service descriptions are defined using WSDL, the Web Services Description Language. This language supports the description of many different kinds of interactions – message-driven, asynchronous, or interface driven and synchronous. WSDL can act as a normalized description of many kinds of software, enabling them to be exposed as Web Services with minimum effort. WSDL descriptions are also the unit of service composition in the Web Services framework. The service description includes the abstract description of the service interface and the types of the data exchanged. This abstract description is then realized through a binding, which describes how the required message exchanges can take place according to a specific protocol such as SOAP. The loose coupling between the service description and its implementation satisfies assumption (3) of our SOC model. Finally, WSDL allows description of specific deployments of a service as well. WS-Policy defines an abstract framework for applying defining various kinds of policies related to a service. Other specifications will define domain-specific policies that can be declared in Web service descriptions. The WS-Security and WS-Transactions proposals for example define specific policies within the framework defined by the WS-Policy specification. UDDI and WS-Inspection are proposals that allow the publication and discovery of information related to services, enabling dynamic lookup and binding. BPEL4WS is the dominant Web Services specification in the domain of service composition. It defines interactions between services at their abstract interface level, as defined in WSDL. These interactions can be conversational or peer-to-peer. The actual protocol, data format, etc. used are of no concern to the modeler. Compositions can themselves be exposed via WSDL as services. This specification covers assumption (5) of our SOC model, and the Web services framework allows alternative specifications to be used as well. 3. The Dimensions of a Reconfigurable Architectural Style We distinguish here three levels at which an a componentized architecture can be dynamically reconfigured. 1. Dynamic component reconfiguration. Individual components, the basic building blocks of the composition, can externalize those aspects of their behavior that are allow run-time or assembly time reconfiguration. We refer to theses aspects as the Configurable Profile of the component. 2. Automated component assembly. The selection of runtime components that form part of an executable composition can be performed at runtime, based on specific deployment and runtime considerations (such as execution context data, user choices, etc.) 3. Automatic composition. Based on a set of high level goals or business rules, a new composition model is generated or existing compositions are modified, at development or, more interestingly, at run-time. 3.1 Dynamic Component Reconfiguration In the beginning there were requirements; for applications and systems. Changes needed to meet new requirements of functionality and quality of service (extra-functional requirements) may be accomplished in two broad categories: intrusive and non-intrusive. Intrusive changes are notorious for project failure as cycle times of re-design, re-implementation, testing and deployment often exceed budgetary and time scale requirements. Non-intrusive changes can be more efficiently incorporated using variation-oriented design (VOD); involving the encapsulation of design decisions and aspects of the application or system that tend to vary. VOD involves a process of externalization of variant aspects [25]; often into a Configurable Profile (CP). Generally, the CP holds two types of characteristics: functional and extrafunctional. The functional aspect is itself divided into the aspects of business architecture (BA) and application architectures (AA). The BA aspect deals with the flow of the application corresponding to the business processes and how they operate. The AA aspect deals with the functional components and services required to fulfill the BA. The extra-functional aspects define the QoS characteristics of the architecture or large-grained component owning the CP. Thus, the general principle is that each architectural element (composite component at what ever level of granularity we are focused on) externalizes their variant aspects into a CP. Externalization is a design-time or refactoring –time activity whereby variations are encapsulated and a description of the axes of variation of a component are externalized into a Configurable profile (CP). A component offers interfaces, abides by contracts and has manners. The manners of the architectural component are contained in the CP [4]. The composition of components is SOAP (Logical Messaging) Messaging WSDL Quality of Service Transactions BPEL4WS XML, Encoding Other protocols Reliable Messaging Security Description Discovery Discovery WS-Policy UDDI, Inspection Composition accomplished by wiring the ports and connectors of the component into a set of collaborating elements. The automation of the composition process introduces interesting new requirements which will be discussed in its corresponding section below. The dynamic re-configuration of an architectural component therefore consists of a) selecting an appropriate level of granularity which encompasses all necessary elements, b) changing the manners of the component by applying the necessary changes to its CP from both functional and operational (extrafunctional) aspects. There at least two main scenarios in which a CP can be used to achieve reconfiguration of a component. A particular component manner may be explicitly selected in components that provide an explicit reconfiguration interface; in the simplest case, a “setManner()” operaton may be made available by the component. More often, however, component manners would be automatically selected based on the execution context associated with component interactions. That is, the presence or absence of particular fields in the execution context passed to the component will trigger a (re-)configuration of the component; an example would be how the presence of a specific transactional context allows the component to understand the type of transaction protocol in which it is expected to participate. 3.1.1 Support for Dynamic Reconfiguration in the Web Services Framework Driven by the need for explicit, declarative descriptions of service functional and extra-functional behavior, typical of service oriented architectures, the Web services framework is developing a set of mechanisms that allow the encoding of both fixed and configurable characteristics of a service in a standard, machine readable format. WSDL service descriptions capture functional and protocol characteristics of a service, while Web services policies provide descriptions of non-functional and business behaviors. At the protocol level, a core notion in WSDL is the ability to offer service functionality over multiple protocols; it is up to the service user to decide what the most appropriate protocol is by selecting among a set of alternative “ports”. WS-Policy, on the other hand provides a simple architecture in which the different extrafunctional behaviors supported by a service component can be externalized and combined using basic Boolean connectors. Alternative authentication schemes, the set of business rules followed, or all the supported transactional protocols are simple examples of the type of policies that can be attached to a service component. Explicit representation of the execution context data that a component may receive and process has been proposed in [WSContext]. WS-Context extends WSDL to allow the representation of middleware information exchanged in an interaction. Context variables can then be used as preconditions that support (and trigger) specific service capabilities; to make this capability explicit, service policies declaratively encoded using the WSPolicy mechanism, identify context variables supported, required or accepted by the service as trigger of specific middleware or business capabilities. 3.2 Component Assembly The first attempts for component assembly have been at best theoretically prescriptive [30] and without the benefit of automation, including the ability to hardwire component connectors to ports. In distributed environments, some form of registry must be accessed that will return a “handle” or reference to a designated object or component. Using that reference, components are statically bound to each other in a static composition using a general purpose programming language, such as Java. This signifies that interface and implementation separation was merely at design time. During run-time, the two aspects merged to be indistinguishable: i.e., interface and implementation cannot be distinguished at run-time. The implication of this implicit run-time indistinguishability was that certain tacit underlying protocols (HTTP, SMTP, TCP/IP or proprietary protocols) had to be present on client and server machines. The flexibility to decide what protocol to bind to was not a run-time decision. Thus, anonymous or automated composition between ad hoc parties was not an option. With the advent of service-oriented architecture, however, static binding that resulted in merging of interface and implementation was relaxed and a WSDL [20] description (interface) was used to find and bind to a service whose implementation could thus be determined at runtime. Thus, the two aspects of interface/implementation separation were implemented in a standardized, ubiquitous fashion. In addition, a third aspect of separation of concerns was introduced due to the distributed nature of web services; namely, protocol separation. Thus, the binding of the implementation to a given transport or messaging protocol was deferred using the WSIF standard [18], until run-time, where the most appropriate protocol may be determined in real-time. Automated Component Assembly must pass through four levels of compatibility determination before assembly of components, namely: interface (syntax) , functional (semantic), operational (extra-functional or QoS) and contextual (group and goal oriented semantics). In order to find a functional /semantic match for a service consumer’s request, a “matchmaking” engine or service is necessary to augment the UDDI “yellow pages” notion of service registration. Explicit, publicly registered component descriptions that include component configuration profiles play an important role in supporting the selection and assembly time configuration of service components. 3.3 Requirements for Automated Component and Services Composition Service orchestration refers to the assembly of loosely coupled components and the coordination of multiple asynchronous conversations over coarse-grain communication protocols. Implementing orchestration logic in an application produces a consistent set of technical infrastructure requirements, such as managing non-linear state and long-lived application context, supporting parallel activities and sophisticated join patterns, handling exceptions and events generated by local and remote components, compensating for failed or cancelled business transactions, and graceful upgrading and management of application functionality. The BPEL4WS specification defines a language with an XML syntax for describing service compositions, called processes. The BPEL4WS process itself is basically a flow-chart like expression of an algorithm. Each step in the process is called an activity. There are a collection of primitive activities: invoking an operation on some Web service (), waiting for a message to operation of the service's interface to be invoked by someone externally (), generating the response of an input/output operation (), waiting for some time (), copying data from one place to another (), indicating that something went wrong (), terminating the entire service instance (), or doing nothing (). These primitive activities can combined into more complex algorithms using any of the structure activities provided in the language. These are the ability to define an ordered sequence of steps (), the ability to have branching using the now common "case-statement" approach (), the ability to define a loop (), the ability to execute one of several alternative paths (), and finally the ability to indicate that a collection of steps should be executed in parallel (). Within activities executing in parallel, one can indicate execution order constraints by using the links. BPEL4WS builds on the WSDL standard that describes the constituent services. The composition itself also has its description published via WSDL, thus enabling recursive composition. Service composition and orchestration has an extra-functional element related to service integration infrastructures. For example, Liu et al. [15] analyze the effects of data-flows on the performances of the centralized and distributed data-flow models and present a model for comparing the performances of megaservices. Traditional workflow applications have also provided mechanism for associating extra-functional requirements to the composed applications; see for example [MQwf]. This same interaction between service orchestrations and extra-functional requirement of the orchestrated services is likely to be further strengthened in a SOC environment, where requirements laid by the orchestration model are matched at component assembly time against the declared set of policies (the extra-functional configuration profile, using the terms of Section 3.1) of individual candidate services. Automated assembly of components implies composition to achieve the construction of software applications which involve aspects of Generative Programming, Model-driven Architecture (MDA) and Grammar-oriented Object Design (GOOD). Generative Programming [6] is well known for providing a vision of automatically generating applications from a specification of the product domain. Goal-driven derivation of a workflow given suitable data constraints and a library of available applications is another approach described in [31]. 4. Context-aware Components have Manners Manners are used to define abstract behavioral specifications for components. They consist of a definition of events, context (extrafunctional and use-case dependent), state (more application and time-dependent), polices (used to determine which set of rules to use with the current context and state) as well as the business rules themselves. A specific type of policy is a workflow or business process flow which determines the conditional sequence of execution of a set of tasks or services. The manners can thus be represented as a set of XML contexts within a WSDL attachment description: SSL-enabled session, security token accepted JMS guaranteed delivery //transactional, security, performance, data bindings, message bindings, etc. //current session and state information platinum(customer) overdraft(customer, 100) platinum(customer) è overdraft (customer) è applyForLoan() Event/ Msg Check context Check state Filter & Check Rules Perform Action Initiate Workflow Configurable Profile [Conditions are true] Rules getRules(AccountType, CustType, TxnType) getFlow() 1 2 3 4 5 6a 7 auth= getCreditCardAuthorization() debitAccount(auth, amount) Order Entry Scenario Policies Perform Exception [Conditions are false] 6b Figure 1: Context-aware Component have Manners In Fig 1, the following functions are performed at each of the numbered steps: 1. “Am I in a secure, authenticated, authorized context?” 1. “I need to pass a PKI first before I enter the transactions” 2. “Promise QoS == “x” to a gold versus a silver card customer versus public user” 2. What is the type of customer (normal|platinum) we are interacting? 3. What is the type of order? 4. Filter rules based on order type by applying appropriate policies; Which subset of rules apply? Load the appropriate subset (may be cached for performance) 5. How many items ordered? Are they in stock? 6a. The pre-conditions conditions are valid; invoke services getGateAuthorization(), debitCreditCard(amount) 6b. Otherwise, handle exceptions, reorder stock, notify client and customer service 7. Initiate Workflow based on output of rule checks Figure 2: Step-by-step description of manners in Fig 1. Manners extend the notion of contracts in terms of augmenting it with stronger semantic context. They specify an abstract component specification which covers not only an extension of the notion of contracts but also includes extra-functional aspects of Enterprise Components and systems. Manners are the rules governing the behavior of a reuse element (such as classes, subsystems, and components) within a given context (with functional or extra-functional aspects). Thus, when a component receives a message or has registered interest in an event, the component’s manners sees to it that the component responds within the semantics appropriate for its current context by checking its state, constraining the rules or flow that apply within the given context and activating extra-functional aspects (that have often been represented as meta-data). Manners cover a wide spectrum, from business analysis expression of business rules assigned to a reuse element, to a grammar-oriented object design specification based on a domain-specific language for a business. Manners of components provide the services for selfdescription, dynamic configuration, and dynamic collaboration. A component can be queried for its manners within a given processing context. 4.1 Context-aware Components Components must collaborate to fulfill business process goals that call upon the services provided by the component. When dynamism is a requirement, for example, to re-negotiate a transaction, the component must exhibit context-awareness. This implies that the context-aware components or (CAC) must be aware of the rules governing the interaction context from a functional and an operational perspective; i.e., context-aware components have manners. We have already mentioned in Section 3.1.1 the close relationship that exists between context variables and policies in the Web services framework. This tight relationship is a necessary to support context awareness and context triggered reconfiguration. Each functional context defines its valid collaboration and interaction sequences; each operational context defines the QoS and assumptions about bindings to explicit protocols, persistence, transactional environments and security, to name a few. Not only must a CAC be aware of the constraints under which it must function, but also the operational and extra –function requirements must remain true – and this may call for dynamic reconfiguration of extra-functional properties based on the domainspecific language that defines the manners for the CAC. The Business Compiler project, outlined below implements these notions. 5. Grammar-oriented Object Design The efforts to use domain-specific languages (DSL) has been successful in specific, very specialized domains but not in the mainstream of information system development. Except, languages like SQL or HTML, general programming languages such as Java, C++, VisualBasic, COBOL, etc., have been used to write the business logic of most information systems. Component composition can be specified through a domain grammar. The domain grammar defines the domain or application context in which the components will collaborate. Higher level flow specifications of major business processes are declaratively specified with domain grammars. During application assembly, component composition can be accomplished through, for example, BPEL4WS using the domain grammar as an abstract specification. MDA [8] is based on model transformations, where a business model is transformed to a Platform Independent Model (PIM), then to a Platform Specific Model (PSM), and finally to the executable code. Although the steps of model transformations contribute to the automated product generation from the high level specifications, current MDA theory and techniques appear to be focused on the model transformation for a single application or system. It also does not address the assembly of a system out of available components. One of the implicit assumptions that is often made is that all components are on a par: they are designed and constructed together. This is most often not the case: available components need to have self-describing features that can be queried for interface compatibility. In addition, components must exhibit self-configuration and collaboration properties and know where they stand when they enter an assembly context. It is our assertion that the use of MDA can facilitate the design and implementation of this “component assembly context.” There are two aspects, functional and extra-functional (sometimes referred to as operational, non-functional, or Quality of Service (QoS) requirements) that both have to taken into account for the deployment of the composition. Components are selected based on the semantics of their service descriptions. WSDL [20] defines service interfaces that can be queried and matched for binding to a service that meets the domain grammar’s requirements. We will use a representative of a business process of Account Management in a banking context. The use-cases of customers are depicted in the following business domain grammar: Table 1: Business Domain Grammar for Account Management 1. Account Mgt = {Login, Txns, Logout} 2. Login = {#displayLoginPage, login, #getUserIdAndPassword, #login, CheckLoginResult} 3. CheckLoginResult = {{success, DisplayMenu} | {invalidUseridOrPassword, #displayInvalidUserError, Login} | newError, #displayNewERRor, Login} 4. DisplayMenu = {displayMenu, #displayMenu, #getTxnType} 5. Txns = {Txn, DisplayMenu, Txns} | end 6. Txn = { {accountInfo, AccountInfo}| {debit, Debit}| {credit, Credit}| {transfer, Transfer}} 7. AccountInfo = {getAccount, #getAccount, #displayAccountInfo(account)} 8. Credit = {getCreditParameters, #getCreditParameters, #performCredit(srcAccount, amount)} 9. Debit = {getDebitParameters, #getDebitParameters, #getCustomerType, CheckFund, CheckFundResult} 10. CheckFundResult = { {success, #performDebit(srcAccount, amount), CheckTxnResult} | {invalidAmount, #displayAmtError} | {insufficientFund, #displayFundError} | {error, #displayGeneralError} } 11. CheckFund = {regularCustomer, #checkFund(srcAccount, amount)| platinumCustomer, #checkCredit(srcAccount.getBalance()- amount)} 12. CheckTxnResult = {{success, #displayDebitConfirmation}| {invalidDebitAmount, #displayDebitAmtError}| {error, # displayGeneralError}} Alternatively, the above business domain grammar can be generated by the Business Compiler tool when given the following UML Activity Diagram describing its business process flow: 5.1 The Business Compiler The Business Compiler (BC) project implements the above grammar-oriented style of defining business architecture and maps it onto a service-oriented architecture in a seamless manner. Within BC, a highly re-configurable architectural style is implemented by externalizing the collaboration, business flow and business rules of a group of collaborating components as a domain-specific language that can be manipulated by business analysts. 5.1 Experiences in Using the Business Compiler The BC has applicability across a spectrum of uses some of these include: · Business Process Documentation · Business Process Consolidation across business lines · Prototyping · Rapid Application Integration without the hassles and nightmares of EAI. The author and his colleagues have implemented and utilized this approach on several industry projects. Some of the lessons learned include the need for a debugging tools at the domain-specific language level which aid the business analysts or architect in defining and testing their business grammar; or in customizing an existing reusable asset (business grammar) for a specific project. 6. DyRec uses GOOD to Compose Contextaware Components A software architectural style is defined through the description of its components, connectors and constraints. DyRec’s components are context-aware components (CAC) with externalized manners. The connectors between CACs is reified in a controller that is implemented in a domain-sepcific language through the process of grammar-oriented object design. Constraints are explicitly specified in an externalized business grammar. DyRec is achieved by externalizing the manners of a set of collaborating components or services into a composition defined by a domain-specific grammar. The Business Compiler tool supports the creation of grammar-driven context-aware components within a DyRec architecture. 7. Related Work Containment Units [25], supports the switching between different resource configurations and operational components at run-time as long as the transition between configurations is relatively simple. We present the DyRec Architectural Style as useful for recognizing environmental changes and dynamically reconfiguring software and resource allocations to adapt to those changes. The work that this project most closely resembles, however, is work in the areas of software architecture, component-based development and domain specific software. Various authors have suggested the use of architectures to guide the composition of software system out of components or modules (e.g., [21, 22]). Our specific approach to module interchange is similar to that suggested by [22] and [23] who propose the use of a defined architecture as the framework within which different components can be interchanged. Containment Units extend this through the inclusion of mechanisms to detect when adaptation is required, and to automate this reconfiguration. A particular system with a similar goal and approach is Chameleon. Chameleon is an infrastructure for adaptive fault tolerance [24]. 8. Conclusion Component and service compositions can be automated when four aspects of compositional compatibility are realized: interface (syntax) , functional (semantic), operational (extra-functional or QoS) and contextual (group and goal oriented semantics). A dynamically re-configurable architecture allows automated composition and collaboration of self-describing components and their service. Grammar-oriented Object Design provides one implementation of this DyReC style which combines domain specific business languages with component-based software engineering and software architecture. Dynamic reconfiguration will be natively supported in the Web services framework because it is based on some of the basic principles of service oriented architectures. 9. REFERENCES [1] Garlan, D., Allen, R., and Ockerbloom,J., "Architectural Mismatch, or, Why it's hard to build systems out of existing parts", Proceedings of the 17th International Conference on Software Engineering (ICSE-17), April 1995. [2] Parnas, D.L. "On the Criteria To Be Used in Decomposing Systems Into Modules" Communications of the ACM, Vol. 15, No. 12, pp. 1053-1058, December, 1972. [3] Arsanjani, A., Grammar-oriented Object Design: Creating adaptive collaborations and dynamic configurations with self-describing components and services, Proceedings of TOOLS 2001, IEEE Computer Society Press. [4] Arsanjani, A., Alpigini., J., “Using Grammar-oriented Object Design to Seamlessly Map Business Models to Software Architectures”, Proceedings of the IASTED 2001 conference on Modeling and Simulation, Pittsburgh, PA, 2001 [5] I. Crnkovic, B. Hnich, T. Jonsson, Z. Kiziltan, "Specification, Implementation, and Deployment of Components", Communications of the ACM (CACM) ( Association for Computing (ACM)), Vol. 45), 2002 [6] C. Sun, R. R. Raje, A. M. Olson, B. R. Bryant, M. Auguston, C. C. Burt, Z. Huang, "Composition and Decomposition of Quality of Service Parameters in Distributed Component-Based Systems," Proc. Fifth IEEE Int. Conf. Algorithms and Architectures for Parallel Processing, 2002. [7] Czarnecki, K., Eisenecker, U. W., Generative Programming: Methods, Tools, and Applications,Addison-Wesley, 2000. [8] Object Management Group (OMG). Model Driven Architecture: A technical perspective. Technical report, OMG Document No. ab/2001-02- 01/04, February 2001. [9] M. Auguston. Program behavior model based on Event Grammar and its application for debugging automation. In Proc. 2nd Int. Workshop Automated and Algorithmic Debugging, pages 277-291, 1995. [10] B. R. Bryant and B.-S. Lee. Two-Level Grammar as an objectoriented requirements specification language. In Proc. 35th Hawaii Int. Conf. System Sciences, 2002. [11] R. R. Raje, M. Auguston, B. R. Bryant, A. M. Olson, and C. C. Burt. A unified approach for the integration of distributed heterogeneous software components. In Proc. Monterey Workshop Engineering Automation for Software Intensive Systems, pages 109-119, 2001. [12] Franz Achermann and Oscar Nierstrasz, “Applications = Components + Scripts — A Tour of Piccola,” Software Architectures and Component Technology, Mehmet Aksit (Ed.), pp. 261-292, Kluwer, 2001. [13] Martin L. Griss, Architecting for large-scale systematic component reuse, Proceedings of the 21st international conference on Software engineering, p.615-616, May 16-22, 1999, Los Angeles, California, United States [14] Jean-Guy Schneider, “Components, Scripts, and Glue: A conceptual framework for software composition,” Ph.D. thesis, University of Bern, Institute of Computer Science and Applied Mathematics, October 1999. [15] Bhaskaran Raman, Sharad Agarwal, Yan Chen, Matthew Caesar, Weidong Cui, Per Johansson, Kevin Lai, Tal Lavian, Sridhar Machiraju, Z. Morley Mao, George Porter, Timothy Roscoe, Mukund Seshadri, Jimmy Shih, Keith Sklower, Lakshminarayanan Subramanian, Takashi Suzuki, Shelley Zhuang, Anthony D. Joseph, Randy H. Katz, Ion Stoica, "The SAHARA Model for Service Composition Across Multiple Providers", Invited Paper, International Conference on Pervasive Computing (Pervasive 2002), August 2002. [16] David Liu , Kincho H. Law , Gio Wiederhold Middleware performance analysis: Analysis of integration models for service composition Proceedings of the third international workshop on Software and performance July 2002 [17] Vaughan-Nichols, Stephen J.. Web Services: Beyond the Hype. Computer. Vol 35, No. 2, p 19. [18] WSIF, Web Services Invocation Framework, [19] WS-Security, dnwssecur/html/securitywhitepaper.asp [20] WSDL, Web Services description Language, [21] D. Garlan and D. E. Perry. Introduction to the special issue on software architecture. IEEE Transactions on Software Engineering, 21(4):269274, Apr. 1995 [22] D. L. Parnas. Designing software for ease of extension and contraction. IEEE Transactions on Software Engineering SE- 5(2):12838, Mar. 1979 [23] C. Dellarocas, M. Klein, and H. Shrobe. An architecture for constructing self-evolving software systems. In Proceedings of the Third International Software Architecture Workshop, pages 29-32, Nov. 1998. [24] Z. T. Kalbarczyk, S. Bagchi, K. Whisnant, and R. K. Iyer.Chameleon: A software infrastructure for adaptive fault tolerance. IEEE Transactions on Parallel and Distributed Systems , 10(6):560579, June 1999 [25] Jamieson M. Cobleigh, Leon J. Osterweil, Alexander Wise, and Barbara Staudt Lerner, "Containment Units: A Hierarchically Composable Architecture for Adaptive Systems", in Proceedings of the 10th International Symposium on the Foundations of Software Engineering, Charleston, South Carolina, November 2002. [26] Arsanjani, A., Zedan, H., and Alpigini, J. Externalizing component manners to achieve greater maintainability through a highly reconfigurable architectural style. In Proceedings of the 2002 International Conference on Software Maintenance. IEEE Press, 2002. [27] Raphael David, Daniel Chillet, Sebastien Pillement & Olivier Sentieys, DART: A Dynamically Reconfigurable Architecture dealing with Future Mobile Telecommunications Constraints, Proceedings of RAW 2002, International Parallel and Distributed Processing Symposium: IPDPS 2002 Workshops, IEEE Press. [28] Proceedings of the 3rd International Conference on Configurable Distributed Systems (ICCDS '96), IEEE Press, May 06 - 08, 1996, Annapolis, MD. [29] Proceedings of the 12th International Workshop on Rapid System Prototyping, une 25 - 27, 2001, Monterey, California. [30] Desmond D'Souza, Alan Wills: Objects, Components and Frameworks With UML: The Catalysis Approach, Addison-Wesley, 1998. [31] Jim Blythe, Ewa Deelman, Yolanda Gil, Carl Kesselman, Amit Agarwal, Gaurang Mehta, Karan Vahi. The Role of Planning in Grid Computing, to appear in Proceedings of the 13th International Conference on Automated Planning and Scheduling (ICAPS), June 9-13, 2003, Trento, Italy.