DISCE: A Declarative Inter-ESB Service-Connectivity Conguration Engine

Kristijan Dragi evi , Luis Garc s-Erice and Daniel Bauer c c e IBM Research Zurich Laboratory S umerstrasse 4, 8803 R schlikon, Switzerland a u Email: {kdr,lga,dnb}@zurich.ibm.com

Abstract
The service-oriented architecture (SOA) has been successfully applied in enterprise environments. Due to decentralized set-ups, mergers and acquisitions and organizational boundaries, many enterprises today operate multiple, fragmented and heterogeneous service infrastructures that are administered by different organizational units. This fragmented infrastructure causes service duplication and unnecessary redundancy. This paper proposes an approach of cross-domain service integration through an automated federation of Enterprise Service Buses (ESBs). ESBs are the mediation centers within a service domain that enable service interaction across technological boundaries by using service proxies. We present DISCE, a conguration engine prototype that enables an operator to congure service connectivity in such an environment in a declarative form, by specifying simple rules. The engine produces a conguration consisting of a set of proxies interconnecting clients and services.

Index Terms
Conguration Engine, Service Connectivity, ESB Federation, Enterprise Service Bus, SOA

1. Introduction
The landscape of Service Oriented Architecture (SOA) in the enterprise is one of heterogeneity, despite its rapid adoption in enterprise computing. Explanations for such a result are 1. A company started an SOA trial in selected business units before committing to a company-wide deployment 2. The deployment of SOA started separately in individual business units inside the same company 3. An SOA infrastructure was inherited from another company being acquired

4. Two SOA infrastructures have to coexist in a business resulting from a merger Architecturally, this situation means that a number of isolated Enterprise Service Buses exist within a company, each of them attached to a particular department or business unit. The services within a particular business unit, the associated connectivity middleware (i.e., the ESB), and the necessary service registry and repository form what we call a service domain. The registry is the only mandatory element in a service domain. These service domains represent a sub-optimal implementation of an SOA. Owing to the lack of communication between domains, some services are reimplemented at each service domain, wasting resources and increasing complexity. Moreover, the processes at the enterprise cannot be fully integrated and have to rely on ad-hoc exchanges of information to actually work. This is in stark contrast with the principles of SOA, one of its advantages being service reuse. The architectural solution is to recursively apply the ESB pattern to the already existing ESBs. However, in practice services in the different domains are accessed through a network, and the resources used have to be administered; the corresponding security policies must be applied to the trafc exchanged; access control policies have to be applied which might differ depending on whence the service is accessed, etc. Most of these requirements can be met by using the appropriate connectivity mechanisms. Thus, to make different applications with different requirements (re)use the same service or services, correctly congured connectivity is needed between service consumers and service providers. The process of generating an extended ESB by the interconnection of services and applications from multiple service domains is denoted federating ESBs or domains. Setting the right connectivity for every service and service consumer pair is a daunting task for a system administrator as soon as a few domains hosting a

couple dozen services have to be integrated: services may be overlooked, connectivity requirements that are incompatible with the services being accessed may be put in place, and the number of parameters to consider grows polynomially. Some mechanism by which an administrator can manage all this information efciently is required. This paper describes DISCE1 (Declarative InterESB Service-Connectivity Conguration Engine), an automated conguration engine that computes the connectivity features required by applications accessing services in the domains of a SOA networked environment based on 1) the semantic content of connectivity rules as expressed by the system administrator 2) the capabilities and requirements of the services available on the different domains We term the high-level connectivity rules federation intents. We refer to the system administrator performing the domain federation a federation architect. DISCE implements the required connectivity by instantiating service proxies with the required functionality between the clients and the services. The service proxies are selected from a catalog of proxies available at the different ESBs on the service domains. In a nutshell, DISCE detects whether a service capability is a superset of a federation intent and no proxy is needed, even if the service capability is expressed using a different syntax than the federation intent. Also, DISCE detects incompatibilities between service capabilities and federation intents. As a consequence, only semantically correct service execution path are being computed. We assume the existence of a management protocol that enables the engine to query and manipulate the conguration of the different elements in a service domain. Recent commercial software provides similar features, so this paper does not get into the details of such a protocol. The paper is organized as follows: in Section 2 we present related work; Section 3 introduces an overview of the DISCE operation; Section 4 describes the internal details of DISCEs prototype implementation.

security in SOAs is presented in [2]. Also on modeldriven SOAs, a declarative constraint framework is used to describe, analyze and verify the conguration of an SOA in [3]. This last focuses on easing the declaration of constrains (e.g., specifying hosts where some service should be installed) on a SOA deployment. Those constrains could be liken to the intents in our conguration engine, but the work we perform is about creating an infrastructure, not just conguring it. The proposal in [4] uses traces of the SOA infrastructure utilization to determine automatically the number of servers required to sustain the current load. Such run-time conguration changes could be implemented by specic proxies in our approach, but the conguration engine does not deal with the internals of proxies. Close to our goals are those of automatic service composition [5], [6]. Conceptually, the fundamental difference is that service composition is about checking the compatibility of services at the functional level, i.e., checking that a service, which is making a request to another service, provides the right number and type of parameters and expects the output that the requested service produces. Our approach checks compatibility at the connectivity or non-functional level, and automatically incorporating proxies with the missing features, a process that is completely transparent to the nature of the services themselves. This way, once we have enabled inter-domain connectivity, service composition at the functional level may take place, but it is oblivious to the underlying infrastructure set up by the methods we describe. For a general discussion of semantic matching of policies, see [7], [8], [9].

3. Overview of DISCE
In order to federate domains, services have to be made visible at the domains of their client applications. A service is made visible at one domain by introducing a description realized as a WSDL le of the service in the registry of the clients domain. Proxies as service mediation elements need to be made visible for client applications, as well. A proxy may be needed for example if some transformation of the communication between the client and the service is required or the service itself cannot be made visible outside the domain, but a proxy of the same service can. The output of DISCE is a set of such proxies enabling connectivity between domains.

2. Related Work
Some work has already been done to try to overcome the complexity of setting up and conguring large SOA systems. The authors of [1] present a mechanism to structure the conguration of SOAs and correlates problems (exceptions) to conguration parameters. For model-driven SOA deployment, a pattern-based policy conguration for end-to-end
1. Disce is the imperative form in Latin for you learn

3.1. Operation description

The goal of DISCE is to automate the conguration of service visibility and service proxies by using as input a rule-based federation declaration. This

Figure 1. DISCE operation overview.

declaration is processed by a conguration engine, which generates the appropriate conguration for the domains to instantiate the federation. This involves the following steps, as depicted in Figure 1: 1. The federation architect puts together a federation declaration that denes where services will be visible and how these services will be accessed from outside the provider domain. How a service is accessed is captured in what is called a federation intent. The federation intent is a qualier for the connectivity between the domains where applications are hosted and the services they use at the provider domains. 2. DISCE uses a control protocol to read the state of the federation. A description of such a protocol is outside the scope of this paper, but it can be considered as a form of SNMP for the services infrastructure. The state consists of a set of service domains, the services available therein as well as the runtime infrastructure such as registries and enterprise services buses that are available in the domains. 3. DISCE computes a conguration for the runtime environment that satises the federation declaration. For this purpose, it accesses a knowledge base that contains federation patterns, i.e., semantic information about service proxies, their conguration and their compatibility with each other. Federation patterns are constraints on the combinatorial space of all proxies available in the catalog to implement connectivity. 4. In the nal step, DISCE deploys the computed conguration plan on the federation, using again the federation control protocol. As a result of this deployment, registry entries are being created as well as service proxies being deployed in different service domains. The registry entries are populated with service denitions and are used to make a service visible in a foreign domain whereas the

service proxies are deployed to provide the nonfunctional and connectivity aspects of service invocation according to the federation architects intent.

3.2. Input to the conguration engine

The federation intents specied by the federation architect deal with the way that services invocations are performed between services domains. The federation architect has no power over the way services are invoked within a service domain. The policies to be satised in order to access a service have been dened for some internal reasons by the architect of that service domain, and those will in general remain unknown to the federation architect. This ensures separation of concerns. With this picture in mind, the only correct federation intents are those that require extra functionality to access a given service. Reality, however, may deviate sometimes from what we consider best practices, and in this sense we must allow for some exibility in what the federation architect is empowered to do through the federation intents. The federation architect may be in a position to decide that certain requirements do not apply between two domains. Moreover, the federation architect may judge that a given intra-domain policy is not applied in a fashion that is appropriate for inter-domain service invocations, and decide to change it. We conclude that federation intents may be applied in two different modes. The augment mode requires extra functionality to be satised for service invocations between domains. It should be the preferred mode of operation for the federation intents. The engine has to take care that the federation intents specied for a service do not conict or contradict the policies dened for that service in its corresponding domain. This could only be an error, as the federation architect has specied that its intention is

to preserve all the policies required in the service domain, and then add some on top. The second mode is the override mode. This mode should be used with special care, and is only provided to guarantee enough exibility in the cases stated above. In the context of service domain federation, there are two forms of input. The rst input are policies that describe capabilities of a service which are attached to the service description, i.e. a socalled WSDL le of the service. The second input are federation intents that describe how to federate services. They are part of or referenced in the federation declaration that the architect provides. The federation intents are being satised by augmenting the service capabilities with mediation modules in service proxies along the service execution path as required. Policies that are part of a WSDL service description are used not only to describe capabilities of the service but also the capabilities for the interaction with the service, depending on where the policies are attached. The structure of a WSDL 1.1 description consists of an abstract part that describes the what (port) and a concrete part that describes the how (binding) and where (endpoint). Policies are used to describe capabilities of various elements of the service, e.g. policies for individual operations, endpoint specic policies or policies that encompass the entire service. Also, in order to compute the capabilities of a service operation that is invoked at a specic endpoint, policies have to be merged together in order to compute the effective policy. From a service domain federation point of view, service inherent policies can not be changed, whereas it is possible to dene different interaction policies when federating a service into a new domain. Federation intents may affect mainly three aspects of the inter-domain interaction: 1. How the interaction with a service should be conducted. For example, a federation policy may require that inter-domain service invocations are executed using reliable messaging or encryption. 2. The visibility of a service on domains other than its own. 3. The service execution path routing. For example, a policy might require that service execution paths are always routed through a specic domain. The third form of policy is not yet implemented in this version of DISCE, and is thus not considered in this paper. We expect that most scenarios are not so complex that they require service invocation routing, but is included here for completeness. Supporting arbitrary and generic federation intents is a very complex task and requires that policies are enriched with semantic information so that the conguration engine can make sense out of them.

Even if semantic information is available, achieving a valid end-to-end federation conguration that is valid and consistent with the expressed policies is challenging. Consequently, we favor the utilization of a pre-dened set of supported federation policies, dramatically reducing the scope and complexity of the problem we are trying to solve, while allowing the architect to solve most federation scenarios. This decision is consistent with the requirement of a welldened catalog of service proxies implementing the connectivity features supported.

3.3. Resulting conguration

The output of the operation of the conguration engine is a federation plan that consists of visibility conguration and service proxy location and type. The location and type of service proxies are derived from both federation intents and the underlying service capabilities. The result is a set of proxies that fullls the requirements of the intent, while producing functional and efcient connectivity between applications and services. A nave approach that directly maps each federation intent to a service proxy or service proxy pair is not adequate for the following reasons: Incompatibility. A non-workable set-up results when the proxies that implement the functionality required by the federation intents are not compatible with each other or with the service functionality. For example, a security proxy that encrypts service invocations and a reliable messaging proxy that ensures that invocations are delivered to the services could be conicting if the reliable messaging proxy re-sends a lost message that is then interpreted by the security proxy as a play-back attack. Functionality overlap. An inefcient set-up results when proxies or a service/proxy pair have overlapping capabilities. For example, if the declaration asks for both delegation, which means a service proxy relaying service invocations like a gateway, as well as encryption, it is sufcient to install a security proxy that provides encryption since this proxy also implicitly provides delegation because the proxy has to process the service invocations, and thus relay them. The conguration resulting from the federation intents is implemented by introducing the appropriate proxies at both the ESB of the clients domain and the ESB of the service domain. This is the preferred method for introducing connectivity features between domains, rstly because this allows the use of the clients without modication, as the proxies take care of implementing the required functionality for the federation intent, and secondly because this allows for optimization techniques, like caching, to

be implemented at the clients domain. This setup is illustrated in Figure 2.

Registry 1 Registry 2

Registry 1

Registry 2

Client domain ESB 1 P C

P ESB 1 P C Client domain

P ESB 2 P

Federation policy applies

Service domain

Federation policy applies

Service domain

Figure 4. Applying federation intents with the service domain lacking an ESB.

Figure 2. Applying federation intents with ESBs in both client and service domains. There may be service domains where an ESB is not available. In the case of the clients domain lacking an ESB as illustrated in Figure 3, the client needs to be modied to access the proxy at the service domain. The registry in the clients domain needs to know about the proxy in the service domain. In this case the federation intent is effectively applied also inside the clients domain and not just between service domains, because of the support required at the client doing the service invocation.
Registry 1 Registry 2

4. Implementation
As described in the previous section DISCE processes three records of information which are federation proles, federation intents, and the current state of the federation. The current state of the federation includes all services and proxies for each known domain and the connectivity among them. Federation proles contain semantic information among service capabilities and proxy patterns. Both federation intents as well as service capabilities are expressed as a set of policy assertions that are described in a machine readable form, for example by a WS-Policy document. While such a policy document does not contain semantic information, its assertions are dened over a specic domain, for example a WS-Security policy. Each policy domain for which federation intents are dened has an associated set of service proxies. For example, the WSSecurity domain might contain proxies for integrity and authentication. Our prototype implementation makes use of this. The approach can be basically outlined as in the following: Semantic Enrichment. Upon reading a policy document, be it a federation intent or a service capability, the planner augments the policy document with a domain specic ontology. This mapping is directly derived from the policy le. The ontology might be expressed in OWL, but other formats could be used as well and is part of the knowledge base. The domain specic ontology provides the information that is used to reason about relationships and compatibility among and between functional domains. In addition, this step also allows to map a federation intent to a proxy pattern, i.e. to one or more proxies that fulll the federation intent. Semantic Reasoning. Semantic reasoning is done over the set of proxy patterns and service capabilities. All proxy patterns associated with a single service are compared to each other and checked whether the patterns are compatible or whether conicts exist. Furthermore, proxy patterns are investigated for functional overlap and redundant patterns

P ESB 2 P C Client domain Federation policy applies

Service domain

Figure 3. Applying federation intents with the client domain lacking an ESB. Even if the service domain does not contain an ESB, federation intents may still be specied. The intents will affect the clients by making them use a proxy at clients domain that fullls the requirements of the federation intent (see Figure 4). However, the exchange of messages between the domains is not affected, because the architect does not have the means to enforce how the invocations are to be received at the service domain, i.e., the architect cannot insert proxies at the service domain according to the specied policies, and of course cannot modify the service itself! These cases can be trivially extended to multiple domains involved in a multi-hop service invocation. The appropriate proxies need to be introduced in the ESBs involved in the service invocation. The case where both the client and service domain lack an ESB does not allow for any federation intents to be set, other than visibility.

are eliminated. Then, non-functional service capabilities are compared to the patterns and checked whether incompatibilities exists. Finally,functional overlap with the non-functional service capabilities are searched and eliminated if existent. Proxy Selection. In a last step, the resulting proxy patterns are mapped to physical service proxy implementations and their corresponding conguration. Figure 6 gives an outline of how a federation declaration on a given federation with some predened semantics is realized as a plan that describes the conguration of proxies added to the federation.

Federation 1 * Domain 1 1 Registry 1 1 * Service 1 * Policy * 1 * 1 Visibility Grp 1 * ESB 1 * Proxy 1

CFDL Rule Set

Plan

Figure 5. Knowledge Base.

4.1. Knowledge Base

The planner requires that semantic information is available in a knowledge base. This knowledge base consists of the following parts: Service capability base. The service capability base contains service capability descriptors that describe individual, named capabilities such as WSAddressing and their relationship to other service capabilities. The relationship among service capabilities can be Orthogonal: these service capabilities can coexist within the same service execution path. Conicting: these service capabilities cannot coexist. Supporting: a given service capability also provides another service capability. Proxy type base. The proxy type base contains proxy type descriptors that describe individual service proxies and service proxy patterns. A proxy type implements a set of service capabilities and thus links into the service capability base. In addition, each proxy type descriptor describes the relationship among proxy types that can be similar as for service capabilities orthogonal, conicting, inclusive and implicit. inclusive means that a given proxy types functionality is also provided by the other proxy type, while implicit refers to the opposite. Most of the time proxies implement service capabilities and thus the relationship among proxy types can be inferred from their provided service capabilities. Nevertheless, it is necessary to distinguish proxy type base from the service capability base since a capability like delegation cannot be a service capability. The knowledge base is an in-memory database. As shown in Figure 5, it stores three types of objects: 1. The description of federations which is a hierarchical structure. The knowledge database offers an API that enables the creation, querying and removal of objects in the federation. Services might be described by WSDL les for example but could also be identied by names. Similarly, policies might be

given as WS-Policy les but could also be identied by a name only. 2. The rule set that has been applied to a federation. The rule set is associated with a federation description to which it should be applied. 3. The plan that was generated by the rule set. The plan is associated with the rule set and the federation from which it was derived. The API of the knowledge base allows the following operations: Creating elements in the federation like domains, registry, ESBs, services, etc. in a consistent way that makes it impossible to violate the structure given in Figure 5. Querying, in particular listing components. Deleting and removing elements from the structure. Exporting the federation description in XML.

4.2. Planner Algorithm

In this section we describe the semantic planning algorithm that is schematized in Figure 6. Let F be a federation, the set of service instances in F , I the set of possible federation intents, the set of domains in F , and R = {Ri }n the federation i=0 declaration consisting of a set of rules. 4.2.1. Reading in the Federation Declaration. Each rule in the federation declaration R has three components: Ri := (Si , Ii , Di ) where Si , Ii I, and Di . For each i all services in Si shall be made visible for the domains in Di with the properties dened by Ii . 4.2.2. Normalizing Rules. Each rule Ri is expanded into a set of normalized rules RN . The set of i normalized rules is inferred from the cross product of N the sets Si and Di : RN := {Ri,x }xSi Di . So a nori N malized rule has the form Ri,(s,d) := (s, Ii , d), s Si , d Di . That is, each normalized rule expresses how a single service should be federated to a specic domain. The resulting normalized rules have to be

Figure 6. Semantic Planning Algorithm.

unique. For each service/domain pair at most one rule may exist as the planner uses the rst-matching rule applies policy. 4.2.3. Assigning Proxy Patterns. For each normalN ized rule Ri,x each federation intent i Ii is mapped to a service proxy pattern. This is done by rst mapping the intent into a functional domain and then searching the domain for a proxy pattern that ts the federation intent. The semantic knowledge about functional domains and the available proxy patterns is extracted from the knowledge base. The planner supports a limited number of federation intents. The assigning process results in simple proxy patterns which are dened settings of at most two proxy types, where one proxy type is assigned to the service domain and the other to the clients domain. A proxy pattern can also contain an empty proxy type setting for one of the two or both domains, meaning that no proxy is needed there. 4.2.4. Semantic Compatibility Check. The planning engine needs to check whether the specied federation intents are consistent. Therefore, the proxy patterns within a normalized rule are checked for semantic incompatibilities. Likewise, proxy patterns are checked for conicts with the service capabilities. If proxy patterns and service capabilities within a rule are not compatible, then the planning process cannot continue.

4.2.5. Proxy Pattern Merging. The proxy pattern merging step results in a complex proxy pattern that summarizes the requirements of the federation intents. A complex proxy pattern differs from a simple proxy pattern in the way, that it describes a sequence of types that indicates which proxies and how they have to be installed in a domain instead of describing at most one proxy type per domain as in the simple case. If the service already provides entirely all aspects of a pattern or if a proxy pattern is redundant, it is ltered out. Following algorithm delivers such summarizing complex proxy patterns for each domain 1: while non-orthogonal simple proxy patterns exist do 2: search for mergeable patterns 3: merge the pattern pair found 4: end while 5: for each pp : remaining simple proxy patterns do 6: if pp not supported then 7: nd supported simple proxy pattern implementing the smallest superset of capabilities required by the architect 8: end if 9: end for 10: if non-orthogonal simple proxy patterns exist then 11: goto line 1 12: end if 13: for each d : all Domains do 14: build complex proxy pattern out of all simple patterns in d 15: end for The goto statement in line 11 is necessary, because after the rst for loop it might be possible to merge newly arisen patterns again. Merging simple patterns results again into simple patterns whereas the statement in the last for loop takes a set of simple patterns and results in a complex pattern. Hence, the last statement is processed differently than the rst merging step. 4.2.6. Rule Contraction. All rules that are associated with the same service are contracted. This step removes redundancies that occur when a service is invoked from multiple different domains. It allows to remove proxy patterns in the provider domain since those can be shared. Also, inside a domain, if there exist multiple equal instances of a proxy whose role is to select one among a series of equivalent services, those proxies have to be contracted in a further step, too. 4.2.7. Dumping Deployment Plan. The result is a federation plan that denes where proxies have to be

Table 1. Actions computed by the planner

Test case Simple Complex Instantiations 15 114 Connections 25 223 Time 70-100 ms 70-80 ms

*Intel and Pentium are trademarks or registered trademarks of

Intel Corporation or its subsidiaries in the United States and other countries. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.

References
installed and how they have to be congured.

4.3. Practical Benets

We demonstrate the benet brought by the planner by showing the work required to perform two example federations. In the simple test case there are ve domains containing seven services in total, whereas in the complex test case we have 53 domains containing all in all 54 services. For both cases a simple rule set consisting of three rules is applied. Each rule consists of at most two parameters per rule component. The experiments run on a machine with an Intel Pentium 4 CPU at 3.00 GHz running on Linux 2.6 with 3 GB RAM. The planner computes the number of actions to be performed by applying the rule sets on the corresponding scenarios. Results are shown in Table 1. In the simple test case, the planner has computed 15 instantiations of proxies and 25 connections among clients, proxies, and services. In the complex test case a total of 114 instantiations and 223 connections are produced. The time required to perform these computations is around 80 ms. This is good enough to implement real-time assistance for a federation architect, who could observe in a design tool the result of applying different policies before deploying the federation. Also consider that all these errorprone (hundreds) of operations would need to be done otherwise by hand.

[1] K. Kannan, N. C. Narendra, and L. Ramaswamy, Managing conguration complexity during deployment and maintenance of SOA solutions, in SCC 09: Proceedings of the 2009 IEEE International Conference on Services Computing, Bangalore, India, September 2009, pp. 152159. [2] F. Satoh, Y. Nakamura, N. K. Mukhi, M. Tatsubori, and K. Ono, Methodology and tools for end-toend SOA security congurations, in SERVICES 08: Proceedings of the 2008 IEEE Congress on Services Part I, Hawaii, USA, July 2008, pp. 307314. [3] J. Luo, Y. Li, J. Qiu, and Y. Chen, Declarative constraint framework for SOA deployment and conguration, in ICWS 08: Proceedings of the 2008 IEEE International Conference on Web Services, Beijing, China, September 2008, pp. 637644. [4] T. Phan and W.-S. Li, Automated conguration of system infrastructure for SOA-based enterprise computing, in ICEBE 08: Proceedings of the 2008 IEEE International Conference on e-Business Engineering, Xian, China, October 2008, pp. 205212. [5] B. Medjahed and A. Bouguettaya, A multilevel composability model for semantic web services, IEEE Transactions on Knowledge and Data Engineering, vol. 17, no. 7, pp. 954968, 2005. [6] B. Medjahed, A. Bouguettaya, and A. K. Elmagarmid, Composing web services on the semantic web, The VLDB Journal, vol. 12, no. 4, pp. 333351, 2003. [7] R. Akkiraju, B. Srivastava, A.-A. Ivan, R. Goodwin, and T. Syeda-Mahmood, Semaplan: Combining planning with semantic matching to achieve web service composition, in ICWS 06: Proceedings of the IEEE International Conference on Web Services, Chicago, IL, USA, 2006, pp. 3744. [8] M. Paolucci, T. Kawamura, T. R. Payne, and K. P. Sycara, Semantic matching of web services capabilities, in ISWC 02: Proceedings of the First International Semantic Web Conference on The Semantic Web, Sardinia, Italy, June 2002, pp. 333347. [9] K. Verma, R. Akkiraju, and R. Goodwin, Semantic matching of web service policies, in Proceedings of the Second Workshop on Semantic and Dynamic Web Processes (SDWP), in ICWS05, Orlando, FL, USA, July 2005, pp. 7990.

5. Summary and Outlook

In this paper we have introduced DISCE, a conguration engine for cross-domain service federation. This tool is designed to help architects manage and keep control of the domain heterogeneity present in the SOAs deployed today in the enterprise. DISCE takes input in the form of a federation declaration provided by the architect, and a collection of supported federation proles and service denitions. We have described the principles behind DISCE and its implementation, as well as a glimpse of the advantages it brings to an architect. As part of our future work, we want to introduce semantic reasoning in order to make the processing of federation intents more exible, extending the number of supported federation proles.