Journal of Theoretical and Applied Computer Science ISSN 2299-2634
Vol. 6, No. 1, 2012, pp. 25-34 http://www.jtacs.org
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 model 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 serviceoriented 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 functionality exposed for other computer systems. It is therefore proposed architectural view model “1+5” for an integration platform. This model has following architectural views: Integrated processes, Use Cases, Logical, Integrated Services, Contracts, Deployment. Furthermore, 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 implementation, 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 presents 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 2
Keen M., Achraya A., Implementing an SOA Using an Enterprise Service Bus, IBM, 2010 Kroll P., Rational Unified Process Made Easy-A Practitioner's Guide to the RUP, Addison-Wesley, 2003
26
Tomasz Górski
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 service-oriented approach one of the basic elements is notion of contract. It should also be included 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 functionality 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 platform should be deployed on common runtime environment. This environment is presented within deployment view. Table 1 shows the comparison of architectural view models: architectural view model "4+1" and architectural 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 stereotype for integrated information system which is connected by integration platform. The 3
Górski T., Metoda modelowania architektury platformy integracyjnej „1+5”, Inżynieria Oprogramowania w Procesach Integracji Systemów Informatycznych, PWNT Gdańsk, 2011
Architectural view model for an integration platform
27
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 Use cases Logical Implementation Deployment Processes
„1+5” architectural views Integrated processes Use cases Logical Contracts Integrated services Deployment -
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 Processes Model. Business processes are presented on a business process diagram of BPMN language. As a swim lines on business process diagrams are organizations (systems) analyzed 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 encompass 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 humans 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 functionality 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 system’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 systems that use the services exposed by the enterprise service bus. In order to distinguish the actors, such as integrated systems, a new stereotype has been proposed 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 integracyjnej, Inżynieria Oprogramowania w Procesach Integracji Systemów Informatycznych, PWNT Gdańsk, 2011
28
Tomasz Górski
2.3. Logical view The view from one side presents the realizations of the use cases identified in information 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 presented structures of classes needed 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 addition, 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 platform. The definition of a contract presents two parties: the component implementing the service () and a component that uses the service (). Contracts are presented in the UML diagram – composite structures diagram. The contract is represented 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 providers 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 >, 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 on integration platform according to the notation SoaML5. These can be either a single service 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 service 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 diagrams 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
2009
Casanave C., Service Oriented Architecture Using the OMG SoaML Standard, Model Driven Solution,
29
Architectural view model for an integration platform
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 deployment diagram, which specifies the location of the designed application on the infrastructure 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 services 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 diagram 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 Solutions
30
Tomasz Górski
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 mediation flows was limited due to small range of offered mediation icons. Repeated modeling icons confused both modeler and reader of the models. In the profile for each of mediation patterns was proposed unique icon. In this way was provided full transparency of modeled 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 profile design and its application to the modeling project were described in detail in the literature7. 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 ContentEnricher
Pattern’s icon
Pattern’s description Enrichment of message content.
ContentFilter
Message content filter.
Endpoint (Message Endpoint)
Point of sending or receiving messages.
EnvelopeWrapper
Wraps the data to be sent in accordance with the requirements of the messaging system.
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
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
Architectural view model for an integration platform
31
involved the National Health Fund (NHF) which acts in Poland as the agency responsible for reimbursement of medicines. Pharmacies and doctors are required to regularly provide information to NHF about prescriptions issued and realized. Replacement of paper 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 platform 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 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 application “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 Fowler M., UML Distilled Third Edition, Addison-Wesley, 2005 10 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 9
32
Tomasz Górski
"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 component 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 integration platform. In applications XML12 document format was chosen to write a prescription. 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 figure Figure 5.
11 12
Web Services Description Language (WSDL) Version 2.0, W3C 2007 http://www.w3.org/TR/wsdl20/ eXtensible Markup Language, http://www.w3.org/XML/
Architectural view model for an integration platform
33
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. Implementation 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 doctors 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. Subsequently, on the enterprise service bus were registered service made available by system "ePharmacy" 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 "ePrescription", the second forwards requests to the application "e-Pharmacy". Application "ePrescription" allows on writing prescription and searching for prescriptions which are already 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 issuing a prescription and realizing it pharmacist. Pharmacist having available, specified by patient 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
34
Tomasz Górski
was proposed – mediation flows diagram. This diagram shows the flow of actions to be taken 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. Usually various systems have different data structures, protocols, message formats. For that reason mediation flows diagram can be very useful for Integration Architect. In order to fully describe the integration platform architecture were included previously defined “UML Profile for Integration Platform” and a new UML profile "UML Profile 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 language, 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 development 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, Addison-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 Wojskowej Akademii Technicznej, Vol. LXI, Nr 1, 2012,
