Coordination for Orchestration L.F.Andrade1,2 , J.L.Fiadeiro 1,3 , J.Gouveia 2, G.Koutsoukos2 and M.Wermelinger1,4 1
2
3
4
ATX Software S.A., Alameda António Sérgio 7 – 1 C, 2795-023 Linda-a-Velha, Portugal
[email protected]
OBLOG Software S.A., Alameda António Sérgio 7 – 1 A 2795-023 Linda-a-Velha, Portugal {jgouveia,gkoutsoukos}@oblog.pt
Department of Informatics, Faculty of Sciences, University of Lisbon Campo Grande, 1749-016 Lisboa, Portugal
[email protected]
Dep. of Informatics, Fac. Sciences and Technology, New University of Lisbon 2829-516 Monte da Caparica, Portugal
[email protected]
A b s t r a c t – Based on the identification of some shortcomings of objectoriented methodology and technology to address the challenges of supporting the engineering and deployment of Web Services, we suggest that alternative approaches can be found in what we call “coordination methodology and technologies” – a set of modelling primitives, design principles, design patterns, and analysis techniques that we have been developing for supporting the construction and evolution of complex software systems that need to operate in very volatile and dynamic environments.
1
On the challenges raised by Web Services Architectures
In the literature, “Web Services” in general are being promoted as a technology for “dynamic -business”, the next generation of the Internet “culture” in which a shift is made from B2C to B2B. This shift puts an emphasis on program-to-program interaction, which is quite different from the user-to-program interaction that characterised (thin) clients interacting with business applications in the B2C model. In particular, initiatives that were typical of the user side, like “searching” (although not necessarily “surfing”…), have now to be performed on the business side, which means supported by software. Readings on the technologies that have been made available in the past few months will normally emphasise this shift from client-to-server, static, linear interaction to dynamic, mobile and unpredictable interactions between machines operating on a network, and identify it as one of the challenges that needs to be met in full for the architecture to impose itself in its full potential. Web Services have been often characterised as “self-contained, modular applications that can be described, published, located, and invoked over a network, generally the Web” [1]. Building applications (in fact, new services that can themselves be published) is a dynamic process that consists in locating services that provide the basic functionalities that are required, and “orchestrating” them, i.e. establishing collabora-
tions between them, so that the desired global properties of the application can emerge from their joint behaviour. Hence, this new architecture is often characterised by three fundamental aspects for which support is required: publishing services so that they can be used by other services; finding services that meet required properties; and binding to services after they are located to achieve the required integration. The models that have been proposed in the meanwhile, namely the Service Oriented Architectures based on publish/find/bind, address these issues directly in terms of technological solutions that can be supported immediately, at varying levels, by open source software. However, in order to understand what exactly is necessary to support the engineering and deployment of Web Services, and, hence, what is still required in terms of research and development effort, we have to characterise exactly what this new architecture is about and how it relates to the software development methodologies and supporting technologies that are available today. That current technologies have severe shortcomings is there for everybody to see. In the own words of Microsoft [2]: “With the integration and communication infrastructures complete our applications can now “speak” to other applications over the Internet, but we don’t have a good mechanism for telling them when and how to say it. We have no way of representing the process. Today the “process” is spread throughout the implementation code of every participant involved in the process. This mechanism for representing the process of business interactions is fragile, prone to ambiguities, does not cross organizational boundaries well, and does not scale. The larger the process gets and the more participants that are involved, the more static the process is and the harder it is to propagate changes and new players into the process.” The goal of this paper is, precisely, to address these shortcomings. Because of their widespread use in industry, and the fact that a trend seems to be already imposing itself, we start by taking a close look to what object-orientation has to offer to come to the conclusion that there are key issues in services that are beyond its grasp. We then suggest that what is missing in object-orientation can actually be found in the “coordination” realm. Finally, we set up a research agenda on “coordination for orchestration”.
2
Why object-oriented techniques cannot address them
The question of determining how exactly object-oriented techniques can contribute to the engineering of Web Services is a fair one. It reflects a (legitimate) concern for the investments that have been made already on object-oriented technologies. It must be made clear to people and, especially, to the companies that want to be part of the New Economy, what kind of investments this new generation of architectures for the Web requires before it becomes obsolete. This is particularly so because Web Services are often presented as a “logical” evolution of, on the one hand, object-oriented analysis and design and, on the other hand, of “components” as geared to the deployment of ebusiness solutions. In this paper, we would like to disagree with this “evolutionary” view. Not that we do not consider Web Services as the “next step” in what has been the “evolution”
of Software Engineering in the Internet age. What we contend is that this step is itself a simple “evolution” of existing concepts and techniques. We believe that the move from object to service oriented systems is a true shift of paradigms, one that should be fully, and formally, characterised so that both methodologies and supporting technologies can be developed to take maximum profit of its potential. The main reason for our disagreement is precisely the fact that the shift from objects/components to services is reflected fundamentally on the interactions – what in the terminology of Web Services is usually associated with “orchestration”. The view exposed in section 1 is of systems that are in a continuous process of reconfiguration due to the fact that services need to establish, dynamically, the collaborations that allow them to provide the functionalities that are being requested by some other service. Hence, Web Services require flexible architectures in which collaborations can be established and changed dynamically and reactively. For this purpose, interactions cannot be hardwired in the code that implements the services. If collaborations are not modelled directly as first-class entities that can be manipulated by a process of dynamic reconfiguration, the overhead that just-in-time integration and other operational aspects of this new architecture represent will not lead to the levels of agility that are required for the paradigm to impose itself. However, traditionally, interactions in OO are based on identities, in the sense that, through clientship, objects interact by invoking the methods of specific objects (instances) to get something specific done. This implies that any change on the collaborations that an object maintains with other objects needs to be performed at the level of the code that implements that object and, possibly, of the objects with which the new collaborations are established. On the contrary, interactions in the service-oriented approach should be based on the description of what needs to be done, thus decoupling the “what one wants to be done” from “who does it”. This translates directly to the familiar characterisation of Web Services as “late binding” or, better, “just-in-time binding”. It is as if collaborations in OO where shifted from instance-to-instance to instance-to-interface, albeit with a more expressive notion of interface. Hence, the first conclusion that we would like to draw is that Web Services are, indeed, beyond OO methodology and technology, especially in what concerns the support that needs to be provided for establishing and managing interactions. Clientship and other OO means of establishing interactions among objects lead to systems that are too tightly coupled for the kind of dynamics required by the Web.
3
How “coordination” can contribute to “service orchestration”
The second conclusion that we can draw from the discussion on the limitations of object-oriented approaches is that “coordination” technologies, as we have been developing around the notion of “coordination contract”, seem to play a fundamental role in enabling service-oriented architectures, namely in what concerns the “orchestration infrastructure” [1][2] i.e. what supports the dynamic aspects of the paradigm – the “process” and “interaction” aspects. These technologies are based on the separation between what in systems is concerned with the computations that are responsible for the functionality of the services that they offer and the mechanisms that coordinate the
way components interact, a paradigm that has been developed in the context of socalled Coordination Languages and Models [8]. Our own contribution [5] has been directed to making this paradigm usable in the development of a new generation of information systems that exhibit the levels of agility required to operate in contexts of highly volatile business requirements and continuous change in the way they need to support organisational structures and strategies. For this purpose, we brought together concepts and techniques from Software Architectures (the notion of connector [3]), Parallel Program Design (the notion of superposition [10]), and Distributed Systems (techniques for supporting dynamic reconfiguration [12]) that are now integrated in a collection of semantic primitives that support the modelling of systems that are flexible and more amenable to change. In particular, these primitives allow, precisely, for the kind of “just-in-time” binding required by Web Services to be performed in a non-intrusive, compositional way. The technology that we have been promoting supports dynamic configuration, which is exactly what is required for this form of binding. The underlying methodology of “coordination-based” development is also essential for service-oriented systems in the sense that it externalises interactions as connectors (coordination contracts) that can be dynamically superposed on system components, i.e. at run-time, without interruption of “normal business”, and encourages developers to identify dependencies between components in terms of services rather than identities. The notion of component that we assume is the more general one that has been popularised in [15] by which we mean “a unit of composition with contractually specified interfaces and explicit context dependencies only”. The identification of the components to which coordination contracts are applicable is made through “coordination interfaces” that identify the properties that they need to exhibit rather than the classes to which they have to belong To illustrate the kind of approach that we have in mind, consider the case of the services that financial institutions have been making available in recent times through what we could call a “flexible package” – the ability to coordinate deposits and debits between two accounts, typically a checking and a savings account, so that the balance of one of the accounts is maintained between an agreed minimal and maximal amount by making automatic transfers to and from the other account. The service that is offered is the detection of the situations in which the transfers are required and their execution in a transactional mode. Because this behaviour should be published as a service that customer applications looking for flexible account management should be able to bind to, the following aspects should be ensured. In the first place, the service cannot be offered for specific accounts. A “binding process” should be responsible for instantiating, at execution time, the service to the relevant components. Nor should it be offered for specific object classes: the service itself should be able to be described independently of the technology used by the components to which it will be bound. Instead, it is the find/bind process that should be able to make the adaptation that is needed between the technologies used for implementing the service and the ones used by the components to which it is going to be bound. This adaptation can itself be the subject of an independent publish/find/bind process that takes place at another level of abstraction, or be offered for default combinations by the service itself. This is important to enable the implementation of the service itself to evolve, say in order to take advantage of new technologies, without compromising the bindings that have been made.
Hence, in our approach, the description of the applications to which the service can be bound is made of what we call coordination interfaces. For instance, in the case of the flexible package, two coordination interfaces are required: one catering for the account whose balance is going to be managed, typically a checking account, and the other for the “savings” account. The trigger/reaction mode of coordination that our approach supports requires that each coordination interface identifies which events produced during system execution are required to be detected as triggers for the service to react, and which operations must be made available for the reaction to superpose the required effects. The nature of triggers and operations can vary. Typical events that constitute triggers are calls for operations/methods of instance components, and typical operations are those made public through their APIs. Another class of events that we have found useful as triggers is the observation of changes taking place in the system. For such changes to be detected, components must make available methods through which the required observations can be made (something that the mechanism of find/bind must check), and a detection mechanism must be made available in the implementation platform to enable such changes to be effectively monitored (something that is not universally provided). The two coordination interfaces that we have in mind can be described as follows: coordination interface savings-account import types money; operations balance():money; debit(a:money) post balance(a) = old balance()-a credit(a:money) post balance(a) = old balance()+a end
Notice how the properties of the operations that are required are specified in an abstract way in terms of pre and post-conditions. coordination interface checking-account import types money; triggers balance():money; operations balance():money; debit(a:money) post balance(a) = old balance()-a credit(a:money) post balance(a) = old balance()+a end
The difference between the two interfaces lies in the inclusion of the trigger in the checking-account. This is because it is changes on the balance of checking account that will the trigger the service to react. More specifically, we are requiring from the component that will be bound to this interface that it makes changes in the balance to be detected by the flexible-package service. The second important requirement is that the service itself be described only on the basis of these coordination interfaces and its own operations, and in terms of the properties that it ensures when it is bound to components that comply with the interfaces. This description can be made in terms of what we call a “coordination law”:
coordination law flexible-package interfaces c:checking-account, s:savings-account attributes minimum,maximum:money rules when c.balance()maximum do c.debit(c.balance()–maximum) and s.credit(c.balance()–maximum) end contract
Each coordination rule in the law identifies, under “when”, a trigger and, under "do", the reaction to be performed on occurrence of the trigger. In the cases at hand, these reactions define sets of actions that we call the synchronisation sets associated with the rules. As already mentioned, the reactions are executed as transactions, which means that the synchronisation sets are executed atomically. In what concerns the language in which the reactions are defined, we normally use an abstract notation for defining the synchronisation set as above. When the interfaces are bound to specific components, their behaviour is coordinated by an instance of the law, establishing what we call a “coordination contract”. [4]. The behaviour specified through the rules is superposed on the behaviour of the components without requiring the code that implements them to be changed. We need to stress the fact that coordination interfaces are defined so as to state requirements placed by laws on the entities that can be subjected to its rules and not as a declaration of features or properties that entities offer to be coordinated. This means that coordination interfaces should restrict themselves to what is essential for the definition of given laws and hence, in the extreme, can be local to the laws themselves. However, for the sake of reusability and simplification of the binding process, it is useful to externalise coordination interfaces from the laws in the context of which they are defined, and establish a hierarchy between them that is consistent with the compliance relationship in the sense that a component that complies with a given interface also complies with any ancestor of that interface or, that any binder of the component for that interface will also serve as a binder for any ancestor. Hence, in a sense, coordination interfaces fulfil the role of representations of abstract business entities in the sense that the hierarchy of interfaces will, ultimately, provide a taxonomy of all the business uses that are made of entities in the application domain. Given this, we insist that, as a methodological principle, the definition of coordination interfaces should be driven by the modelling of the business services as coordination laws and not by the modelling of the entities of the business domain as it is usual in object-oriented and other traditional “product”-oriented approaches. In this sense, it makes no sense to define a coordination interface for accounts in general but, instead, and in the extreme, as many interfaces as the business services that apply to accounts require (something that is evolutionary in nature because it is as impossible to predict how an information system will evolve as for how the business of an organisation will grow). Ultimately, these will identify all the usages that the specific business makes of the notion of account in a “service-oriented” perspective. As business evolves, new coordination interfaces are defined and placed in the hierarchy. In a product-oriented notion of interface, each such change in the business rules would require a change in the account interface, which is against the spirit of “agilityenhancer” that web services are supposed to deliver.
.
4
Concluding remarks
Our main goal in this paper was to show that, in order to supply a methodology and associated technologies that can support Web Service Engineering, we should be looking more in the direction of “coordination” than “object-orientation”. We hope that the examples were clear enough to illustrate how the modelling primitives that we have developed around the notion of “coordination contracts” [4] can be used for supporting an “orchestration infrastructure”, namely for representing business interactions in a way that makes them independent of their application to specific components of systems. We should add that these primitives have a mathematical semantics defined over a categorical framework [7]. A micro-architecture based on the use of design patterns has also been developed that allow their usage over typical environments for component-based development [9]. This micro-architecture has been deployed for Java components in what we call the ”Coordination Development Environment” – a prototype of a tool supporting the methodology that is freely available from www.atxsoftware.com. This means that we have gone already a long way into the definition of a framework that can support the engineering of web services at the business level. However, it is clear that we have not reached the end! There are a number of issues that need to be addressed before that. The main ones are related to the classification of services and the binding processes. The former present challenges that are more localised and “technological” in nature; basically, there are classification mechanisms available “in the market”, e.g. those based on the UDDI [1], and lots of room for improvement! On the side of the binding mechanisms, there seems to be more scope for methodological work because it addresses the fabric of the paradigm itself. This is one of the areas in which we will be investing for the coming times! The categorical framework is ideal for formalising binding mechanisms but the nature of the process itself has to be better understood in the first place, namely in what concerns the levels of adaptability with which they need to endow the “orchestration” process. Another important research direction concerns the extension of the coordination technologies that we presented to address distribution and mobility. This is work that is starting now in collaboration with IEI/CNR and the Universities of Munich, Pisa and Florence. Finally, we are also engaged in integrating these solutions within the UML [6] for which we have the collaboration of a team of researchers coordinated by Ana Moreira.
References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15]
Web Services architecture overview – the next stage of evolution for e-business, IBM Research 2000 BizTalk Orchestration – a new technology for orchestrating business interactions, Microsoft Research 2000 R.Allen and D.Garlan, "A Formal Basis for Architectural Connectors", ACM TOSEM, 6(3), 1997, 213-249. L.F.Andrade and J.L.Fiadeiro, "Interconnecting Objects via Contracts", in UML'99 – Beyond the Standard, R.France and B.Rumpe (eds), LNCS 1723, Springer Verlag 1999, 566-583. L.F.Andrade and J.L.Fiadeiro, “Coordination Technologies for Managing Information System Evolution", in Proc. CAISE’01, K.Dittrich, A.Geppert and M.Norrie (eds), LNCS 2068, Springer-Verlag 2001, 374-387. G.Booch, J.Rumbaugh and I.Jacobson, The Unified Modeling Language User Guide, Addison-Wesley 1998. J.L.Fiadeiro and A.Lopes, "Algebraic Semantics of Coordination, or what is in a signature?", in AMAST'98, A.Haeberer (ed), Springer-Verlag 1999. D.Gelernter and N.Carriero, "Coordination Languages and their Significance", Communications ACM 35, 2, pp. 97-107, 1992 J.Gouveia, G.Koutsoukos, L.Andrade and J.Fiadeiro, “Tool Support for CoordinationBased Software Evolution", in Technology of Object-Oriented Languages and Systems – TOOLS 38, W.Pree (ed), IEEE Computer Society Press 2001, 184-196. S.Katz, "A Superimposition Control Construct for Distributed Systems", ACM TOPLAS 15(2), 1993, 337-356. H.Kilov and J.Ross, Information Modeling: an Object-oriented Approach, PrenticeHall 1994. J. Kramer. “Configuration Programming – A Framework for the Development of Distributable Systems”, Proc. CompEuro’90, pp. 374-384, IEEE, 1990. B.Meyer, "Applying Design by Contract", IEEE Computer, Oct.1992, 40-51. D.Notkin, D.Garlan, W.Griswold and K.Sullivan, “Adding Implicit Invocation to Languages: Three Approaches”, in Object Technologies for Advanced Software , S.Nishio and A.Yonezawa (editors), LNCS 742, Springer-Verlag 1993, 489-510. C. Szyperski, Component Software: Beyond Object-Oriented Programming, Addison Wesley 1998.
