M.B. Juric et al. / Patterns for Enterprise Application Integration 91 interfaces. The interoperability interfaces define what services the client applications can request from the server applications. Interoperability interfaces define the relations between applications on which the applications depend. Interfaces define the coupling between integrated applications as long living contracts. They provide a facade through which the client applications access the interoperability services and encapsulate the applications. As long as the interfaces stay unchanged we can replace parts or the whole server application without influencing any client application. Therefore a lot of effort has to be put into the definition of the interoperability interfaces. BusmessComponent NewGeneration I Application Figure 1: Integration broker pattern Integration Broker should support one or more of the following communication models: - Synchronous one to one communication, where the client requires immediate response from the server and waits (blocks) for the response. - Deferred synchronous one to one communication, where the client asks for a response later or is notified by the server (call back or event). - Asynchronous one to one communication, where the client does not require an answer from the server, nor does it require for the server to be online by the time of submitting the request. - Asynchronous one to many communication, where a single client can communicate with more servers. This model is also called "publish and subscribe". Typical representatives of Integration Broker pattern are common middleware technologies, particularly remote method invocations (object request brokers) and message oriented middleware. Integration Broker pattern is usually implicitly used in integration. This pattern requires one or more middleware products, which implement the functionality. As today a high level of abstraction is achieved, this pattern is not modeled in the design time. However, the architecture has to be aware of this pattern and should adapt the communication requests between the components. 2.5. Consequences - The number of connections between applications is reduced, which also reduces the level of coupling between the integrated applications - The dependencies between the applications are defined as contracts in form of interoperability interfaces - If the interfaces are carefully designed we can replace parts or the whole application without influencing other involved applications - The location transparency is achieved 92 M.B. Juric el al. / Patterns for Enterprise Application Integration — The maintenance effort and costs are therefore reduced to an acceptable level 2.6. Related Patterns This pattern is related to all other integration patterns, covered in this chapter. It is also related to the GoF Mediator pattern. 3. Integration Wrapper Pattern 3.1. Context Providing programmatic access to the existing applications is important for reusing the functionality of the existing applications and developing new solutions. The existing applications may not provide APIs, or the provided APIs might not be sufficient. 3.2. Problem If we want to reuse the functionality of the existing application, we have to access them somehow. The most obvious possibility is to access them through the application programming interfaces (APIs) that existing applications provide. Sometimes, however, existing applications will not provide any APIs to access their functionality, not even the proprietary ones. Or, they will provide only a subset of functionality through the APIs, but we would need to access the other functions as well. 3.3. Forces - For integrating and reusing the existing applications we need to access them programmatically - Through the API access we can reuse data and functionality of the existing applications - Accessing the application through the APIs is better than going into the database directly. because we do not avoid the business logic 3.4. Solution The Integration Wrapper pattern is about layered approach to adding APIs to existing applications. This means that the services and the functionality of the existing applications are exported to the other applications, thus enabling interoperability and integration. Its motivation lies in the Adapter pattern (GoF), however the goal of Integration Wrapper is to provide reusable interfaces for multiple clients to access the wrapper simultaneously. Figure 2: Integration Wrapper pattern To develop the wrappers, we will build a layer around the existing application and add the necessary interfaces. We will call the added application interfaces a wrapper and the modified existing application will be called a "wrapped existing application". The Integration Wrapper has two major objectives. First, it should provide open, reusable interoperability interfaces. Second, it should convert the calls to the reuse the services and functionality of existing M.B Juric et al. / Patterns for Enterprise Application Integration 93 application. For the latter the Integration Wrapper can reuse the already provided APIs, or need to add such APIs. The structure of the Integration Wrapper is shown in the Figure 2. Generally, the wrapper can add APIs in an intrusive or non-intrusive way. There are two possibilities how to add wrappers to the existing applications: - We can modify the existing applications and provide the missing access - We can use screen scraping or terminal emulation to access the functionality though the user interfaces. One criterion that will influence the decision between modifying the existing applications and using screen scrapping or terminal emulation will be the availability of source code and the required tools. We have to make sure that the versions of source code are complete and reflect the current executable code. If we do not have the source code and all the tools and the libraries necessary to build the working executable of the existing application our only choice will be to utilize the user interface wrapping (discussed a little later). Even if we have the source code and all the required tools, we might choose not to modify the existing applications and rather use screen scraping or terminal emulation. The reasons can be that we do not want to risk introducing bugs into existing application, that we are not familiar with the technology of existing application, and so on. Even before we select one of these choices, we have to identify the operations through which we will access the existing application functionality. We will figure this out with the analysis of the existing application. We have to analyze the application, and we must focus on what we actually need. The Integration Wrapper pattern is related to the Integration Broker pattern. The structure of the wrapper depends on the type of communication. If we use synchronous communication style, such as remote method invocation, then the infrastructure will force typed communication and will check the operation signatures. When using the asynchronous communication, the wrapper is responsible for decomposing the messages. 3.5. Consequences - Integration Wrapper enables programmatic communication with existing applications - It enables reuse of the services and the functionality of the existing applications - It hides the details of internal structure of the existing applications, their technologies, the programming model, and the communication details - It reduces the complexity and decouples the clients 3.6, Related Patterns Integration Broker, Virtual Component, GoF Adapter 4. Integration Mediator Pattern 4.1. Context When integrating applications, the integration logic often needs to be separated from all the involved applications and also needs to be encapsulated, which minimizes dependencies, increases the reuse, and simplifies the maintenance. 4.2. Problem In cases when we have the existing applications, which need to be integrated with each other, or where a common functionality is distributed among several applications and/or 94 M.B. Juric et al. / Patterns for Enterprise Application Integration duplicated in several existing applications, we often need integration logic, which will solve these problems and represent a service or a functionality in a common way to its clients. The clients should not be aware of the complexity, hidden inside the mediator. 4.3. Forces - The existing applications often need to be integrated among each other - Certain functionality is often distributed among more than a single existing application - Certain functionality is often duplicated in more than one existing application - The interaction between the applications is complex - The clients should not be aware of this complexity 4.4. Solution The Integration Mediator acts like a controller for the involved existing applications and provides an interface for the clients. It should be aware of the existing applications and include the interaction logic to fulfill certain higher-level operations which require complex interaction with the existing and/or newly developed applications. The integration logic, contained inside the Integration Mediator can be used for different integration levels, such as data level integration or function and method level integration. The Integration Mediator should not access the existing applications directly. Rather, it should use the integration wrappers. The structure of the Integration Mediator is shown in the Figure 3, and shows the client, integration wrappers, and the mediator. Generally, there are two forms of the integration mediators: Single step or Stateless; and Multi step or Stateful. Stateless mediators are used for those integration scenarios, where the maintenance of the state during an interaction with the existing applications is not necessary. This means that the way the mediator acts depends only on the response from the existing applications. Examples are routing and brokering, and vocabulary transforming. A typical example of stateless mediator is an XSLT engine. Stateful Integration Mediator is used when we have to keep track of the previous interactions with applications. The mediator then accumulates the data about the previous interactions and uses this information for further interactions. Stateful Integration Mediators are also those based on events, where they remember events and after all required events have been triggered, they perform a certain action on the activity. Stateful Integration Mediators require that the state is managed and sometimes even persisted. State persistence might be needed for the interactions with the existing applications, which take a longer time and thus must be able to survive system shutdowns. Such long lasting interactions might be very complex, lasting from a few minutes to hours or even days. Figure 3: Integration Mediator pattern M. B. Juric et al. / Patterns for Enterprise Application Integration 95 4.5. Consequences - Application dependencies are minimized - The integration logic is encapsulated and decoupled from the participating existing applications and new clients - Maintenance is simplified as the integration logic is centralized rather than distributed among existing applications - Services can be built on top of the functionality, provided by the mediator, thus they do not have to be aware of the complexity of the existing applications 4.6. Related Patterns Integration Wrapper, Virtual Component, GoF Mediator, GoF Facade. 5. Virtual Component Pattern 5.1. Context Accessing the services of an integrated information system can vary, particularly if the integration system uses a variety of existing applications, implemented in different technologies. Accessing these services directly would require that the clients possesses the knowledge of the internal structure of the information system. Virtual components provide a common, unified access point to the services, thus acting as a fa9ade to the existing applications. 5.2. Problem Clients, accessing the integrated information system should not be aware of the complexity of the existing applications and should not access them directly. Integrated information system is also more than just connected existing applications. Integrated information system should provide new services and functionalities. They should be exposed to the clients in a common, uniform way. If clients would access the existing applications directly, they would be too highly coupled with them, making the maintenance and the replacement very difficult. 5.3. Forces - Existing applications do not provide the high level services and functionalities, required by clients - Clients should not be aware of the complexity of the information system - Client should use high level services 5.4. Solution Virtual Component pattern provides a solution for integrating the existing applications with the clients. The pattern has its motivation in the Facade pattern, however, the Virtual Component pattern is targeted towards the integration and provides reusability and the ability to re-engineer and replace the applications behind the virtual component with the actual, modern implementation. Integrated information system based on the Virtual Component pattern is a system that looks like a newly developed information system where in fact it reuses the functionality of the existing applications. 96 M.B. Juric et al / Patterns for Enterprise Application Integration Virtual components do not differ from the newly developed components from the perspective of the clients. Both provide the functionality through the interfaces. The concept of virtual components will therefore allow us to make existing applications look like new developed components and to mix existing and new applications in all and any possible way. Virtual Component pattern encapsulates the details that the existing applications contribute to satisfying requests and the methods by which they are satisfied. On one side, the virtual component presents the exiting application through abstract interoperability interfaces. On the other side, the virtual component communicates with the integration wrappers and the integration mediators. This is shown in the Figure 4. Figure 4: Virtual Component pattern Virtual component might be for example an order placing component, which provides a simple interface to place an order and internally accesses the existing systems like a payment system, an inventory system etc. Virtual component, together with the abstract interoperability interfaces present an application view that is implementation independent. If we keep the abstract interface constant, the other applications are not aware of any changes that are done on the original application. Thus, there is no need for modifying other applications that depend on the original application when a change is made. In other words, client virtual components are unable to determine how the server virtual components are implemented. The Integration Broker pattern influences the way in which a virtual component will be actually implemented. In each case the virtual component masks the complexity of the existing applications that implement the high level business functionality in the background. Virtual components are deployed on the business logic tier. They will be built in several stages during the integration. The different virtual components will expose the interfaces that will offer different abstraction levels to access the functionality. Therefore, we will organize the virtual components into several sub tiers on the business logic tier. The virtual components on a lower level will take care of the technology adoption, and will be built on data level and application interface level integration. Virtual components on higher levels will transform the high level business request into a series of lower level calls to different low level virtual components for the existing applications. High level virtual components will also do some data conversions and adoptions to finally reach the goal of implementing the functionality through the reuse of existing applications. We will typically use virtual components for one or a combination of the following functions: - Virtual components encapsulate functionality of existing applications and present them in the same way, or some rearranged way. Virtual components can, for example, present exactly the same functionality that can be found in the existing application APIs. In this M.B. Juric et al. / Patterns for Enterprise Application Integration 97 case they just mask the technology differences and are called lower level virtual components. - Lower level virtual components implement the code that translates the method invocations into one or more calls to APIs of the existing applications and databases accesses. This code will often have to do parameter transformations, alignment of data types, and other transformations to mask the technology differences between the J2EE technologies and the technologies used by the existing applications. In more simple terms, the lower level virtual components will act as adapters between the new and the existing applications. - Virtual components can provide a different, higher level interface and thus mask the way existing applications implement their APIs, too. Such virtual components are called higher level virtual components and their interfaces should be defined based on a global design model, which we will discuss later in this paper. - Virtual components can encapsulate several existing applications and help in maintaining the transaction integrity and the security. - Virtual components are also useful to encapsulate or abstract persistent data. For this purpose the virtual components can access EIS databases directly or though provided protocols. In this case they will often also implement the validation logic. This is an extra level of security, which might not have been handled by the old application that will keep the database in a consistent state. - Virtual components can provide a unified access to several EIS databases and can handle different combinations of databases in the background. Alternatively, they can use APIs to access data, if those APIs are provided by the existing applications. - Virtual components will often be layered, thus higher level virtual components will aggregate the behaviors of lower level virtual components and provide the higher level of abstraction required for multiple levels of abstraction of EIS application functionality. - Virtual components can also be used to map technical differences. A particularly useful scenario is to adapt synchronous and asynchronous communication models. 5.5. Consequences - Virtual components provide a unified view on the services and the functionality of integrated information system - Virtual components abstract the details of the information system, thus providing a sort of facade - Virtual components provide high level, business process oriented interfaces for interoperability - They enable easy replacement with newly developed components as long as the interfaces remain unchanged 5.6. Related Patterns Facade, Integration Wrapper, Integration Mediator, Integration Broker. 6. Data Mapping Pattern 6.1. Context When integrating the existing applications, the data often needs to be moved from one application to other. Access to the databases of existing applications varies from the type of 98 M.B. Juric et al. / Patterns for Enterprise Application Integration datastore (relational, object, hierarchical, flat files, and so on.) and the way data is accessed (directly to the database, through application, physical, and so on.). 6.2. Problem The data mapping logic can become complex, therefore it is preferable if it is encapsulated and decoupled for the existing applications. This way the data mapping logic is less coupled with the existing applications, which improves maintenance. 6.3. Forces - Data needs to be moved between the existing applications - Data is stored in different formats in the existing applications - Accessing the data varies from the type of storage and the access technologies - The data mapping logic should be separated and should not be complicated with technical details. 6.4. Solution The Data Mapping pattern is used to encapsulate and abstract the data mapping logic for transferring, replicating and updating data between the related integrated existing applications. This pattern accesses the data store, either directly through DAO, or wrappers. The Data Mapping pattern comes in two variations: the Direct Data Mapping; and the Multi Step Data Mapping. The Direct Data Mapping pattern handles the mapping, where data needs to be moved from a certain data store to the other, without transformations. The Multi Step Data Mapping also transforms the data. The structure of the pattern is shown in the Figure 5. DataSource uses ' DataMapping • BusinessComponent uses uses DAO uses lntegralionWrapper DirectData ' MultiStepData Mapping Mapping Figure 5: Data Mapping pattern 6.5. Consequences - The data mapping logic is encapsulated and decoupled from the participating existing applications and their data stores. - Data dependencies are minimized. - Maintenance is simplified as the data mapping logic is centralized rather than distributed among the existing applications. - Business components can use the functionality, provided by the Data Mapping pattern, thus they do not have to be aware of the data complexity of the existing applications. M.B. Juric et al. / Patterns for Enterprise Application Integration 99 6.6. Related Patterns Integration Wrapper, Integration Mediator, Data Access Object. 7. Process Automator Pattern 7.1. Context System interactions should often be hidden and abstracted by the process controller. The dependencies between the business process controllers and the system logic of the information system should also be minimized. 7.2. Problem The services of an integrated information system should be exposed to the clients though high level methods, which reflect their business processes. A typical business process method will require an interaction with different virtual components and integration mediators. This interaction should not be delegated to the clients, because this enhances the complexity, increases the maintenance effort, and does not allow us to use declarative transaction management. 7.3. Forces - Services of the integrated system should be exposed as high-level business process methods - The business process interaction logic should be abstracted and encapsulated on the middle tier - Clients should not be responsible for making the necessary operation invocations - Business process logic should often be performed inside transactions - The dependencies between process automation control and the information system technology should be minimized 7.4. Solution Process Automator pattern enables to gather and encapsulate the business process logic and thus enables to minimize the dependencies between the business process automation logic and information technology system logic. All interactions are hidden by the process automator controller. This pattern helps to improve the quality of business processes, reduces the process execution costs and reduces the necessary time. Therefore, this pattern is highly appropriate for defining integration process within and between the companies. The Process Automator pattern sequences the activities of a business process and delegates steps to the corresponding parts of the information system. It does this using virtual components and integration mediators, through which the automator components access the functionality of the existing applications. The process automator, however, can access the newly developed components as well. The structure is shown in Figure 6. Common uses for the Process Automator pattern are the definition of the business activities, the timers, and process context informators. It comes in two variations: Closed Process Automator; and Open Process Automator. The difference is exclusively in the semantic understanding of both types of processes. The Closed Process Automator implements a process, which is managed internally and externalizes the key process activities 100 M.B. Juric et al. / Patterns for Enterprise Application Integration only through the data exchange. The clients are able to monitor the activities within the process, but cannot actively participate in their execution. The Open Process Automator enables sharing of business process between the clients. Such processes are managed by more than one client and are particularly useful for inter EAI, or B2B integration, where a single process is shared by more than one company. ProcessAutomator Figure 6: Process Automator pattern 7.5. Consequences - The architecture allows easy analysis of business processes, their bottlenecks, utilization, downtime, and so on. - Flexibility is achieved for redefining the business proceses - The process automator components are aligned with the business managers view, which reduces the semantic gap between IT and management - With the connection to the virtual components and the integration mediators, a highly flexible integration architecture can be defined 7.6. Related Patterns Virtual Component, Integration Mediator. 8. Conclusion The major contribution of this article is the definition of six new integration patterns: Integration Broker pattern, Integration Wrapper pattern, Integration Mediator pattern, Virtual Component pattern, Data Mapping pattern, and Process Automator pattern. These integration patterns are a result of a systematical analysis and identification of common integration problems. They represent sound solutions for these common integration problems and have been verified according to the "rule of three", that is, they have been successfully implemented in several integration projects. The presented integration patterns are useful for intra-EAI as well as for inter-EAI and B2B integration. We have followed the principle that successful inter-EAI and B2B integration can be built on a well-defined intra-EAI only. Therefore, the integration patterns have to be applied step by step, first to enable the intra-EAI integration. Then we should build B2B interactions on top of an integrated architecture. In this context all the presented patterns are important. However, the process automator pattern is the one that deserves a special consideration. Typically, we will apply this pattern when implementing shared business [...]... Defs.3 and 4, we obtain the weak-connection graph and the strong-connection graph shown in Fig.2 : a c ( m l a l ) , ac(m3.al) and ac(m4.al) are true, so that the edges {ml,m3}, {ml,m4} and {m3,m4} are shown in Fig.2(a); 'm4 invokes m l ' , 'ml writes data onto al' and 'm3 reads data from a l ' , so that w r ( m l a l ) , wr(m4.al) and r e ( m 3 a l ) are true Thus the edges (ml,m3) and (m4,m3) are... Measurement in Object-Oriented Systems, Empirical Software Eng : An Int'l J 3(1) (1998) 65–117 [5] S.R Chidamber and C.F Kemerer, A metrics suite for object-oriented design, IEEE Trans, on Software Eng 20(6) (19 94) 47 6 49 3 [6] M Hitz and B Montazeri, Chidamber and Kemerer's metrics suite : a measurement theory perspective, IEEE Trans, on Software Eng 22 (4) (1996) 267–271 [7] J.M Bieman and B.-K Kang,... the maximum extent of attribute-sharings among methods within the class For example, in the case of Fig.2, Rw,(ml) = {m2, m3, m4}, Rw(m2) = {ml, m3, m4}, Rw(m3) = {ml, m2, m4}, Rw(m4) = {ml, m2, m3} Thus |R w (ml)| = • • • = |R w (m4)| = 3 We can calculate as OCC = max[3/ (4 – 1)] = 1.0 Definition 6 (Pessimistic Class Cohesion (PCC)) Given a class C Let M be the set of methods, and A be the set of attributes,... Kaufmann Publishers, ISBN 155860 48 9–8, San Francisco 2000, p 550 10 M J Zaki, Parallel and Distributed Association Mining: A Survey, In: IEEE Concurrency, special issue on Parallel Mechanisms for Data Mining, Vol 7, No 4, December 1999, p 14 25 11 V Kubicek: A Construction of a Grammar, In: Proceedings of ISM 2002, 8 p (accepted for) 16 116 Knowledge-based Software Engineering T Welzer et al (Eds.)... {m3}, R ss (m2) = {m3}, Rs(m3) = {}, Rs(m4) = {m3} Thus |R s (ml)| = |R s (m2)| = |R s (m4)| = 1and|R ss (m3)| = 0 We can calculate as PCC = m a x [ l / ( 4 – l ) , 0 / ( 4 - l ) ] = 1/3 3 Analytical Evaluation of Metrics Briand, Morasca and Basili have proposed a mathematical framework (BMB framework) including properties to be satisfied by several types of software metrics[10] The supported types... Professional J2EE EAI, Wrox Press Inc; ISBN: 186100 544 X, December 2001 [2] Alexander Christopher, Sara Ishikawa, Murray Silverstein, A Pattern Language: Towns, Buildings, Construction, Oxford University Press, ISBN: 0195019199, 1979 [3] Richard P Gabriel, Patterns of Software: Tales from the Software Community, Oxford University Press; ISBN: 0195121236, May 1998 [4] Erich Gamma, Richard Helm, Ralph Johnson,... system, Proc ACM Symp Software Reusability (1995) 259-262 [8] B Henderson-Sellers, Software Metrics, Prentice Hall (1996) [9] Y.-S Lee, B.-S Liang, S.-F Wu and F.-J Wang, Measuring the coupling and cohesion of an object oriented program based on information flow, Proc International Conference on Software Quality (1995) [10] L.C Briand, S Morasca and V.R Basili, Property-based software engineering measurement,... http://b2b.ebizq.net/ebiz_integration/yee_l.html [10] Deepak Alur, John Crupi, Dan Malks, Core J2EE Patterns: Best Practices and Design Strategies, Prentice Hall PTR, ISBN: 0130 648 841 , June 2001 102 Knowledge-based Software Engineering T Welzer et al (Eds.) /OS Press 2002 A Proposal of Class Cohesion Metrics Using Sizes of Cohesive Parts Hirohisa AMAN 1 , Kenji YAMASAKI 1 , Hiroyuki YAMADA 1 , Matu-Tarow... discuss the usefulness of BMB framework in the software engineering discipline References [1] G.J Myers, Software Reliability-Principles and Practices, John Wiley & Sons, Inc (1976) [2] M Page-Jones, The Practical Guide to Structured Systems, 2nd ed., Yourdon Press (1988) [3] E Yourdon and L Constantine, Structured Design, Englewood Cliffs, Prentice Hall (1979) [4] L.C Briand, J W Daly and J Wust, A Unified... software engineering measurement, IEEE Trans, on Software Eng 22(1) (1996) 68-86 [11] D.F Stanat and D.F McAllister, Discrete mathematics in Computer Science, Prentice-Hall (1977) [12] H Aman, H YamadaandM.T Noda, A Proposal of Class Cohesion Metrics focusing on Sizes of Cohesive Parts, Technical Report of IEICE KBSE2001-19 (2001) 108 Knowledge-based Software Engineering T Welzer et al (Eds.) IOS Press . {m2, m3, m4}, R w (m2) = {ml, m3, m4}, R w (m3) = {ml, m2, m4}, Rw(m4) = {ml, m2, m3}. Thus |R w (ml)| = • • • = |R w (m4)| = 3. We can calculate as OCC = max[3/ (4 – 1)] = . on Software Eng. 20(6) (19 94) 47 6 49 3. [6] M. Hitz and B. Montazeri, Chidamber and Kemerer's metrics suite : a measurement theory perspective, IEEE Trans, on Software Eng. 22 (4) . Patterns: Best Practices and Design Strategies, Prentice Hall PTR, ISBN: 0130 648 841 , June 2001 Knowledge-based Software Engineering T. Welzer et al. (Eds.) /OS Press. 2002 A Proposal of