Architectural view model for an integration platform

(1)

Architectural view model for an integration platform

Tomasz Górski

Military University of Technology, Faculty of Cybernetics, Poland [email protected]

Abstract: The most common architectural view model is "4+1" by Philipe Kruchten. This mod-el presents the views required for a full description of computer system architecture. By contrast, this model seems to be insufficient to describe architecture of integration platform. Definitely lacks the view of integrated business processes. In the service-oriented approach, one of the basic elements is a contract. It should also be included in the description of the architecture. Moreover, very important are integration mechanisms and mediation flows that should be presented in the description of architecture. Hence the need for integrated services view, and manner of their integration on the enterprise service bus. Use case view should also be extended by stereotypes required for presenting function-ality exposed for other computer systems. It is therefore proposed architectural view model “1+5” for an integration platform. This model has following architectural views: Integrat-ed processes, Use Cases, Logical, IntegratIntegrat-ed Services, Contracts, Deployment. Further-more, in article was presented new UML profile "UML Profile for Integration Flows". In the profile were placed stereotypes corresponding to integration patterns and mediation mechanisms. It is important, that UML activity diagram was extended and its special form was obtained to model mediation flows on integration platform. Thus was proposed a new UML diagram: mediation flows diagram.

Keywords: Information systems integration, architecture of information system, modeling

1. Introduction

Service-oriented architecture is the concept of creating IT systems based on defining of services that system should offer. The service, in this context, is the software component acting completely independently and having clearly defined interface. The basis for the specification of the modeling method is the SOA reference model, with particular emphasis on the integration layer. In this layer, the basic element is a enterprise service bus (ESB)1. It is software, which enables the efficient and standardized communication between connected applications. ESB allows you to connect applications and services, regardless of implemen-tation, technology, operating systems and data types. Services interact with each other using XML (eXtensible Markup Language). Integration platform consists of enterprise service bus and connected information systems.

The most common architectural view model is "4+1" Philipe Kruchten2. This model pre-sents views required for a full description of the information system architecture. But, this model seems to be insufficient to describe in full architecture of an integration platform. Model "1+5" takes into account the business process layer and the layer of integration of

1

Keen M., Achraya A., Implementing an SOA Using an Enterprise Service Bus, IBM, 2010

2

(2)

services between systems. A completely new element is the mediation flow diagram that shows the mediation required to complete service calls between different systems. This model is definitely better suited to the specific of integration solutions.

2. “1+5” architectural view model

“4+1” view model definitely lacks the view of integrated business processes. In the ser-vice-oriented approach one of the basic elements is notion of contract. It should also be in-cluded in architectural description. Moreover, very important are integration mechanisms and mediation flows that should be presented in the description of architecture. Hence the need for integrated services view, and manner of their integration on the enterprise service bus. Use case view should also be extended by stereotypes required for presenting function-ality exposed for other computer systems. Hence redefined architectural view model was proposed which is tailored to the needs of integration platforms designing. This model was called "1+5" and its first version was presented and published in article3. The model was refined and now consists of following architectural views:

• Integrated processes, • Use cases, • Logical, • Integrated services, • Contracts, • Deployment.

Figure 1 shows an architectural view model "1+5".

Figure 1. Architectural view model „1+5”

The basic architectural view is the integrated processes view. The next four views are used to present design of an integration platform. All products of design of integration plat-form should be deployed on common runtime environment. This environment is presented within deployment view. Table 1shows the comparison of architectural view models: archi-tectural view model "4+1" and archiarchi-tectural view model "1+5" (proposed by author of the article). The main difference is the proposal of two additional views: Integrated processes and Contracts. In Integrated processes view are modeled business processes which should be automated on integration platform. In both approaches are present following views: Use cases, Logical and Deployment. In “1+5” model Use cases view contains additional stereo-type for integrated information system which is connected by integration platform. The

3

Górski T., Metoda modelowania architektury platformy integracyjnej „1+5”, Inżynieria Oprogramowa-nia w Procesach Integracji Systemów Informatycznych, PWNT Gdańsk, 2011

(3)

name of Implementation view was changed on Integrated services view. In this view are presented services exposed from information systems, their way of inclusion on enterprise service bus and mediation flows defined for services.

Table 1. Architectural view models comparison „4+1” architectural views „1+5” architectural views

- Integrated processes

Use cases Use cases

Logical Logical

- Contracts

Implementation Integrated services

Deployment Deployment

Processes -

2.1. Integrated processes view

The purpose of this view is the identification of business processes defined across all the analyzed organizations, which will require the integration. The view is presented in the Pro-cesses Model. Business proPro-cesses are presented on a business process diagram of BPMN language. As a swim lines on business process diagrams are organizations (systems) ana-lyzed in this model. This is a basic view for the rest architectural views. In this view are identified all services which require support by information system. Those services encom-pass both human and automated tasks. In business process are identified following types of tasks BPMN:

• Manual task – this kind of task represents work which is entirely designed for hu-mans and does not require contact with electronic devices,

• Human task – this kind of task represents work for human, but his results must be entered to the electronic device,

• Automated task – this work is entirely designed for electronic devices and requires no human intervention.

2.2. Use cases view

Use case view defines the scope and expected functionality of information systems in the form of use case diagrams. This view is presented in the Use case model. The function-ality of each system is presented on use case diagrams. For each of the integrated system is built separate use case diagram. One of the main tasks of this view is presentation of sys-tem’s use cases provided by the platform to other systems, without indicating the specific technical solutions. Use case diagram for integrated system has the same abstractions as in standard UML notation. It is possible therefore to define the actors who are computer sys-tems that use the services exposed by the enterprise service bus. In order to distinguish the actors, such as integrated systems, a new stereotype <<IntegratedSystem>> has been pro-posed with a defined shape, which is part of the newly created UML profile "UML Profile for Integration Platform"4. The flow of events within each use case can be presented onto the UML activity diagram.

4

Górski T., Profil „UML Profile for Integration Platform” do modelowania architektury platformy

inte-gracyjnej, Inżynieria Oprogramowania w Procesach Integracji Systemów Informatycznych, PWNT Gdańsk, 2011

(4)

2.3. Logical view

The view from one side presents the realizations of the use cases identified in infor-mation systems. For this purpose following diagrams are used: sequence, communication, and classes. Moreover, the important task of this view is to present the structure of business entities as defined in the integrated processes view. On class diagrams are present-ed structures of classes nepresent-edpresent-ed for realization of requests of human tasks. Interaction with the user of the human task can be presented in sequence or communication diagrams. It is also important to present the class implementing service calls from external systems. In ad-dition, this view shows an executable business process in form of BPEL (Business Process Execution Language). Elements of Logical view are presented in the Design model.

2.4. Contracts view

This view is presented in the Services model. It is important to present participants of the integration which are systems that are connected to the enterprise service bus. So, it is important to define the contracts that will be implemented on the platform integration. This view is used to illustrate the cooperation of components in order to realize the contract. This view presents all contracts that occur between systems connected to the integration plat-form. The definition of a contract presents two parties: the component implementing the service (<<provider>>) and a component that uses the service (<<consumer>>). Contracts are presented in the UML diagram – composite structures diagram. The contract is repre-sented on this diagram as a collaboration.

2.5. Integrated services view

The purpose of this view is to show all the services included in the integration platform. This view is presented in the service model. The view presents service customers and pro-viders through appropriate interfaces and references. For this purpose component diagram is used, which illustrates the services with relevant stereotypes. On the same diagram the main elements of the platform are presented, without describing the details of their operation and implementation. The central part of the diagram is enterprise service bus. It is presented as a component with stereotype << ESB >>, which is part of the created UML profile "UML Profile for Integration Platform". Other elements in this view are services which should be included in the integration platform. These are components with stereotype <<capability>> on integration platform according to the notation SoaML5. These can be either a single ser-vice such as SCA components, as well as all composites. Inclusion condition of composite is the need to expose a common interface and reference to receive results from executed service on the ESB. Each of these elements should have clarified role on the platform by using stereotypes. Such an element can be provider or customer of service. In this view should be hidden all logical structures defined in the individual components. Their analysis is subject in the logical view. In addition, this view shows the structure of the enterprise ser-vice bus on component diagram. An important aim of this view is to present integration flows on enterprise service bus. For this purpose, activity diagram is used with applying UML profile "UML Profile for Integration Flows." Note that in this way, UML activity dia-grams were extended, and its special form was obtained for modeling mediation flows on integration platform. Thus was proposed a new UML diagram: mediation flows diagram.

5

Casanave C., Service Oriented Architecture Using the OMG SoaML Standard, Model Driven Solution, 2009

(5)

2.6. Deployment view

This view is represented in the deployment model. System specifications at the physical level should include a description of the deployment architecture of equipment required for proper operation of the proposed integration platform. This applies to list all the necessary equipment and connections between them. UML diagram which realizes these tasks is de-ployment diagram, which specifies the location of the designed application on the infra-structure node in the organization. The central element is the integration server, which will communicate with computer systems connected to the platform. The main objective is to analyze the equipment necessary for services exposition on the enterprise service bus. The view for integration platform is a combination of deployment views for each of the analyzed systems. However, only those elements are analyzed which are necessary to provide ser-vices on enterprise service bus. In the diagram, it can also be described connection protocols between integrated systems.

3. Architecture modelling elements of integration platform

In the presented approach were proposed models and diagrams of languages BPMN, BPEL and UML for modeling architecture of integration platform (Table 2).

Table 2. Architecture modelling elements of integration platform

Model View Diagram

Processes Integrated processes (BPMN) Business process

Use cases Use cases (UML) Use case

(UML) Activity

Design Logical (UML) Sequence

(UML) Communication (UML) Class

(BPEL) Business process in XML format

Services Integrated services (UML) Component

(UML) Activity

Contracts (UML) Component

(UML) Composite structure

Deployment Deployment (UML) Deployment

4. UML Profile for Integration Flows

UML Profile "UML Profile for Integration Flows" contains stereotypes needed to show mediation patterns and mechanisms6. UML activity diagram was extended and therefore specific form of this diagram was obtained for modeling mediation flows on integration platform. Thus it was proposed a new UML diagram: mediation flows diagram. This dia-gram shows the flow of actions to be taken to transfer a call from the service consumer to

6

G. Hophe, B. Woolf, Enterprise Integration Patterns: Designing, Building, and Deploying Messaging

(6)

service provider's system. In particular, these may include data format conversion, message enrichment or message filtering. It is important that in the existing tools modeling of media-tion flows was limited due to small range of offered mediamedia-tion icons. Repeated modeling icons confused both modeler and reader of the models. In the profile for each of media-tion patterns was proposed unique icon. In this way was provided full transparency of mod-eled mediation. The profile in its present form can be very useful for Integration Architect. This profile was created in an IBM Rational Software Architect. The manner of UML pro-file design and its application to the modeling project were described in detail in the litera-ture7. This profile can be used to model the mediation flows on enterprise service bus. Table 3 shows selected stereotypes defined in the described profile.

Table 3. Description of selected stereotypes in profile “UML Profile for Integration Flows” Pattern’s name Pattern’s icon Pattern’s description

ContentEnricher Enrichment of message content.

ContentFilter Message content filter.

Endpoint (Message End-point)

Point of sending or receiving messages.

EnvelopeWrapper Wraps the data to be sent in accordance

with the requirements of the messaging sys-tem.

Translator Transformation of data formats.

5. Integration platform design for electronic circulation of prescription

Issue under consideration is implementation of electronic circulation of prescription in the National Health Services. Basic processes in the circulation of prescription are:

• Writing a prescription by a licensed physician (doctor), • Realization of a prescription at a pharmacy.

These processes are closely related. In the present situation, prescriptions are written by hand by a doctor and next handed to the patient. The patient goes to the pharmacy where pharmacist based on paper prescription passes him drugs. In these processes are also

7

(7)

involved the National Health Fund (NHF) which acts in Poland as the agency responsible for reimbursement of medicines. Pharmacies and doctors are required to regular-ly provide information to NHF about prescriptions issued and realized. Replacement of pa-per prescription by its electronic equivalent would automate NHF control process and reduce the requirements for entities issuing and realizing prescriptions. In addition, there would be eliminated problem of damaged, unreadable or incorrectly filled prescriptions. The e-Prescription (pol. e-Recepta8) project involves the preparation of an integration plat-form for the electronic version of a prescription exchange between a doctor, pharmacy and the National Health Fund. During a visit, doctor would issue prescription for the patient in system e-Prescription. Then, in the pharmacy the patient would tell his/her Social Security Number (pol. PESEL) and the pharmacist would have insight into all of patient’s issued and unrealized prescriptions.

In design of integration platform were used selected architectural views from model “1+5”. As modeling language was used Unified Modeling Language9 and UML profiles “UML Profile for Integration Platform”10 and “UML Profile for Integration Flows”.

5.1. Use cases view

In this business case we have two parties who carry out their activities. The first is the doctor who must be able to write prescriptions and view them. This second feature will be available for a pharmacist in order to find a prescription to be realized. The application which implements the functionality has been called "e-Prescription". Figure 2 shows the use case diagram for the application "e-Prescription" with a separate system, integrated by the integration platform. This is “e-Pharmacy” system and to that system it has been applied the stereotype <<IntegratedSystem>> from profile "UML Profile for Integration Platform". This diagram is a part of the use cases view form model "1+5". The basic functionality of appli-cation “e-Prescription” is use case “Write prescription”.

Figure 2. Use case diagram for „e-Prescription” with integrated system „e-Pharmacy”

The other side is a pharmacist, which realizes prescriptions issued by doctors. The pharmacist must be able to realize prescriptions and view realizations of prescriptions. This second feature will be available for the doctor to find the realization of prescription that has previously been issued. The application which implements the functionality has been called

8

http://www.e-recepta.gov.pl

9

Fowler M., UML Distilled Third Edition, Addison-Wesley, 2005

10

(8)

"e-Pharmacy" (Figure 3). The basic functionality for application "e-Pharmacy" is use case “Realize prescription”.

Figure 3. Use case diagram for „e-Pharmacy” with an integrated system „e-Prescription”

5.2. Integrated services view

Use cases "Get prescriptions" and "Get prescription’s realization" are implemented as services and they are exposed to the integration platform using WSDL11. Services exposed from individual systems and required by individual systems are shown in the UML compo-nent diagram (Figure 4). This diagram is a representation of integrated services architectural view of model “1+5”.

Figure 4. Component diagram in Integrated services architectural view

Data exchange involves the selection of format for documents which will be sent on in-tegration platform. In applications XML12 document format was chosen to write a prescrip-tion. However, the use of XML implies a lot of overhead in the size of the files exchanged between systems. In the realization of the target system should be considered using a data format that does not make such large overhead in file size. This view is used, the mentioned above mediation flow diagram. Mediation flow for getting prescriptions is shown in fig-ure Figfig-ure 5.

11

Web Services Description Language (WSDL) Version 2.0, W3C 2007 http://www.w3.org/TR/wsdl20/

12

(9)

Figure 5. Mediation flow diagram for getting prescriptions for patient

5.3. Implementation of applications and integration

Implementation of applications has been implemented in Java Server Faces. Implemen-tation involved using of several tools: Eclipse IDE, Tomcat application server, database server MS SQL Server and IBM Enterprise Service Bus. Both considered applications were implemented. Then enterprise service bus was configured to integrate applications for doc-tors and pharmacists. The configuration set up the listener endpoint for the SOAP over HTTP protocol and it were created queues for incoming and outgoing calls. Subsequent-ly, on the enterprise service bus were registered service made available by system "e-Pharmacy" allowing for the realization of prescriptions and the service made available by system "e-Prescription", allowing getting issued prescriptions. Incoming services were also registered. First processes requests for access to services provided by the system Prescription", the second forwards requests to the application Pharmacy". Application "e-Prescription" allows on writing prescription and searching for prescriptions which are al-ready issued. The application "e-Pharmacy" offers functionality for finding prescription for realization. In this searching enterprise service bus is involved. After finding a prescription it can be realized in the application "e-Pharmacy". Then in the application "e-Prescription" you can search for realized prescriptions, which was previously done using the application "e-Pharmacy". Enterprise service bus participates in searching for realized prescriptions. In this way, a circulation of electronic prescription was made available between physician issu-ing a prescription and realizissu-ing it pharmacist. Pharmacist havissu-ing available, specified by pa-tient Social Security Number (pol. PESEL) is able to read prescriptions of that person and realize them.

6. Summary

The article presents the refined model of architectural view model “1+5” for designing integration platforms. Model "1+5" takes into account the business process layer and the layer of integration of services between systems. This model is definitely better suited to the specific of integration solutions. In Integrated services view a new type of UML diagram

(10)

was proposed – mediation flows diagram. This diagram shows the flow of actions to be tak-en to transfer a call from the service consumer to service provider's system. In particular, these may include data format conversion, message enrichment or message filtering. Usual-ly various systems have different data structures, protocols, message formats. For that rea-son mediation flows diagram can be very useful for Integration Architect. In order to fully describe the integration platform architecture were included previously defined “UML Pro-file for Integration Platform” and a new UML proPro-file "UML ProPro-file for Integration Flows". Moreover, in architectural description were used following languages: SoaML13, BPMN and BPEL. The proposed model was applied in design of integration platform for electronic circulation of prescription. The proposed architectural approach is dedicated to the design of integration platform with a defined set of architectural views, modeling lan-guage, process design and tool support. Modeling and design of integration platform were made in IBM Rational Software Architect version 8.0. On the market there are many environments for building integration platforms and the proposed method can be used regardless of the type of such an environment. A wide range of enterprise service buses can be used: WebSphere ESB, ServiceMix (FuseESB), Mule and webMethods. Further studies are moving in the direction of design automation of integration platform. Important aspects of design integration platforms, in which ongoing studies are also: simulation model of integration platform, performance analysis of integration platform14, configuration of de-velopment process for integration platforms.

References

[1] Arsanjani A. i in., SOMA: A method for developing service-oriented solutions, IBM SYSTEMS JOURNAL, VOL 47, NO 3, 2008, str. 377-396,

[2] Casanave C., Service Oriented Architecture Using the OMG SoaML Standard, Model Driven Solution, 2009,

[3] Fowler M., UML Distilled Third Edition, Addison-Wesley, 2005,

[4] Górski T., Metoda modelowania architektury platformy integracyjnej „1+5”, Inżynieria Oprogramowania w Procesach Integracji Systemów Informatycznych, PWNT Gdańsk, 2011,

[5] Górski T., Profil „UML Profile for Integration Platform” do modelowania architektury

platformy integracyjnej, Inżynieria Oprogramowania w Procesach Integracji Systemów Informatycznych, PWNT Gdańsk, 2011,

[6] Górski T., Badanie wydajności wybranych środowisk budowy platform integracyjnych, Biuletyn Wojskowej Akademii Technicznej, Vol. LXI, Nr 1, 2012,

[7] Keen M., Achraya A., Implementing an SOA Using an Enterprise Service Bus, IBM, 2010,

[8] Kroll P., Rational Unified Process Made Easy-A Practitioner's Guide to the RUP, Addi-son-Wesley, 2003,

[9] Web Services Description Language (WSDL) Version 2.0, W3C 2007

http://www.w3.org/TR/wsdl20/

13

Casanave C., Service Oriented Architecture Using the OMG SoaML Standard, Model Driven Solution, grudzień 2009

14

Górski T., Badanie wydajności wybranych środowisk budowy platform integracyjnych, Biuletyn Woj-skowej Akademii Technicznej, Vol. LXI, Nr 1, 2012,