B. Liu and C. Chai (Eds.): ICICA 2011, LNCS 7030, pp. 577–584, 2011. © Springer-Verlag Berlin Heidelberg 2011
Application Integration Patterns Based on Open
Resource-Based Integrated Process Platform
Yan Zheng, Hongming Cai, and Lihong Jiang
School of Software, Shanghai JiaoTong University, Shanghai, China zhengyan.claire@gmail.com, {cai-hm,Jiang-lh}@cs.sjtu.edu.cn
Abstract. The push toward more interactive and flexible applications, motivated by huge demand in terms of cost saving, shorter development cycle, faster adjustment, and more reliable execution, has generated the need for integrating the different applications and attract more business people involved in. New approaches and tools for enterprise lightweight collaboration and composition, such as Mashup and Web service, bring various fresh and significant elements into present system architecture. In this work, we firstly indentify and classify the integration architecture framework systematically. Subsequently, five typical patterns for enterprise integration are identified, characterized, and evaluated with focus on the practical applicable scenarios. Within the current research project ORIPS, a resource-based platform that allows for different options to realize resources reorganization and application integration, verifies the correctness and feasibility of integration framework and patterns, and creates promising solution in rapid system development.
Keywords: Integration, Resource, Web Service.
1 Introduction and Motivation
Along with the extensive use and fast update of enterprise software, the company generates an urgent need for integrating different applications in terms of efficient communication and reliable interaction. To respond to rapidly changing business requirements, the company is suggested to develop new applications by reusing their existing resources including applications, web services and data assets, for lower cost, higher quality and shorter development cycle. Integration has led to a large body of research and development in several areas such as data integration, service integration, and recently light weight composition named Enterprise Mashup.
The purpose of the enterprise integration is to realize intra- and inter- enterprise function invocation and information exchange in two main scenarios: integrating internal systems of each enterprise, referred to as enterprise application integration (EAI), and integration with external entities, referred to as business-to-business integration (B2B). In the internal, there is a need to integrate data applications relocated to various systems, while the expectation of the external interactions is that services of each enterprise can communicate seamlessly with those of its partners [1]. In Fact, there are many feasible proposals and technologies advanced for software integration issues after several decades’ deep research such as data integration.
However, they cannot meet the growing needs. Moreover, rapid changes and huge demands in business desire new integration approaches for situational and ad-hoc usage that allow for End User Development (EUD) first introduced by Martin[2], but most of today’s software lack in providing its users intuitive ways to modify or recompose the original applications. Most existing approaches insufficiently support EUD for infrequent, situational, and ad-hoc integration and collaborations [3]. Nowadays, enterprise lightweight composition approaches and tools turn to be fairly popular within the concept such as software as a service (SaaS) and Mashup since they are promising solutions to unleash the huge potential of integrating the mass of users into development.
Service-oriented Architectures (SOAs) provide an architectural paradigm and abstractions that allow simplifying integration. There are a number of technologies available to realize SOA. Among them XML-based Web service is a step in the right direction, as the best-known enabler supporting SOA [4]. Web service as a programmable Web application with standard interface descriptions that provides universal accessibility through standard communication protocols, provide a holistic set of XML-based, ad-hoc, industry-standard languages and protocols, using Web Service Description Language (WSDL) for description, Universal Description Discovery and Integration (UDDI) for publication and discovery, and Simple Object Access Protocol (SOAP) for transportation. The service built under the Representation State Transfer (REST) architecture, referred to RESTful service, is another step forward on the process side [5]. In REST architecture, applications in the network are modeled as a set of resources, which are uniquely addressable using a URI (Uniform Resource Identifier). REST promotes a client-server, stateless and layered architecture.
We believe it is useful to study the integration in terms of layers, which address various parts of problem at different level of abstractions. At a conceptual level, information systems are designed around three layers: presentation, application logic and resource management. Presentation layer plays the role in communicating with external entities, human users or other computers. Application logic layer involves programs that implement the actual operation requested by the client through the presentation layer. Resources management layer encompasses the data that resides in database, file systems, or other information repositories [6].
Based on the current research project ORIPS (Open Resource-based Integrated Process Platform), a resource-based platform that allows for different options to realize resources reorganization and enterprise integration in system development. The integration framework and integration patterns are proposed to support multi-layer enterprise application integration.
2 Enterprise Integration Patterns
2.1 Enterprise Resources Integration Platform for Layer Perspectives
From the discussion above, we should know it is necessary to deeply understand the constituent components of the relatively representative system that needs to be integrated due to the various integration perspectives. In this paper, the architecture is
separated into five layers horizontally, which goes from lower lever layer to higher lever layer that mostly build on top on the lower ones and may or may not be need depending on the application[7].
Fig. 1. Enterprise resources integration platform
Figure 1 summarizes conceptualization with regard to the involved actors and their roles in the development and allocation process. The lowest data layer solves the core problem of system integration, data interaction. Data service as a major advance in the data-level integration should be taken into consideration [8]. On the resources layer, the external and internal resources are located. Standardized interfaces abstract these resources from their technical implementation and facilitate the loose coupling of different resources fulfilling a central requirement of service-oriented architecture [9]. These resources are provided by internal developers or offered by external vendors. The business logic layer refers to business process modeling, business process execution language for Web Services (BPEL4WS) and BPEL engine. On the highest level of abstraction, knowledge workers create, adopt, use and share applications. They facilitate the adding and removing of pre-built components as well as accessible services and other resources, e.g., by linking well-defined input and output ports with a graphical development tool and therefore personalizing their work environments to fulfill individual, situational business needs [10].
2.2 Enterprise Resources Integration Patterns
There are several ways to achieve the integration and collaboration from heterogeneous systems. In this paper we present five patterns, including UI integration, component integration, business logic integration, resource integration and data integration, each of them describing one option for realizing the integration. The five integration patterns in different system layers describe how to integrate resources from disparate
systems. We are exploiting the opportunity created by recent rapid emergence of SOA and its derivatives for enterprise application integration. As provided by previous examples, we will discuss the characteristics for each integration pattern from the perspective of the enterprise in accordance with the implementation from the simplest to the hardest way. Each business scenario could find its corresponding integration patterns and vice versa. However, all patterns have certain advantages and disadvantages, shown in table 1.
Table 1. Five integration patterns’ comparison
Pattern Advantage Disadvantage Participates
UI Integration Few integration operation, easy to implement by non-IT
stuff
No automated data exchange, functionality limited
End user
Component Integration
Fine-grained integration with more flexibility, easy to implement by
non-IT stuff
Gadget needs to be available, pre-defined and limited functionality, homogeneous building platform Analyst /Consultant Business Logic Integration
Reusing exiting business logic, easy to implement
by non-IT stuff
Task and Web service need to be available, complex to
execute Analyst /Consultant Resource Integration Reorganize service resources with great
flexibility
Web service needs to be available, low touch by the
end user
System Developer Data
Integration
Data service makes low complexity on data access and control.
Data service needs to be available, low touch by the
end user
System Maintainer
When you choose a pattern for integration, it always tends to suffer the trade-off between reach and richness. UI integration has high reach due to the fact that it has nearly no technical requirements for most participants in the collaborations. On the other hand, the richness would be quite low, because of the limitation of the pre-defined applications which makes the extensible integration difficult or not possible. Data integration on the contrary has a very low reach, as it strictly depends on the code or even hard-wired connections to be established. Still, it allows a high richness, as the completely interacted systems can be configured to handle any data exchanges. Beside the corporate development strategy, the trade-off between reach and richness should also be taken into consideration when company chooses a proper pattern.
3 Enterprise Integration Implementation Based on ORIPs
Enterprise Integration mostly begins with the existing resource, the employees’ information and inner logic, or specific function in legacy system that ran well before. Then an efficient business process should be designed and described in standardized modeling language that improves the comprehension and execution of the process. Moreover, the existing resources are expected to operate following the pre-defined sequence and decision logic. Ideally, all the functions are running as we assumed.
ORIPs as a powerful integrating and developing platform can satisfy the demand of enterprise system integration. Services management, business process visualized design, simulation and optimization are realized in the ORIPs.
Fig. 2. Mockups of ORIPs for services registration and business process modelling
In this session, we will explain and verify the integration pattern through the operation in ORIPs step by step. A simple scenario is given as follows: The procurement company A is in charge of goods purchasing. The sales company B, as a supplier, provides the goods for the purchaser. A typical purchasing request between the two companies would like this: an employee at the company A creates Request for Quotation (RFQ) specifying the type and quantity. An employee at company B can approve or decline this request depending whether they have enough materials to fulfil the order by checking their inventory IT system. Ideally, supplier can accept this request and give a respond to the purchaser including the price and delivery time, etc. After comparison among several proposals from each supplier, the procurement department chooses one company as their supplier and creates the purchase order (PO) to enter the procurement process.
As depicted in figure 3. Consultants in company A design reasonable and efficient workflow, named process here, consisting of various tasks in a configurable sequence. Company B could package the quotation function into an independent task as a node in their original process. Thereby company A could add the quotation task into the procurement process. Furthermore, if the quotation function refers to more than one task, we could package them into process and we could see that tasks and processes are flexible enough for invocation and reorganization. Business logic integration mainly refers to the process and task supporting by both the internal service and external service. The integration in this layer targets on the reusing of the existing business logic and external business function. The consultant could arrange tasks in optimized executing sequence in terms of efficiency and lower cost by defined them into process unit using the Business Process Execution Language (BPEL) for the sake of future reusing, and the process and task concept enable the workflow invocation from other systems. Process as a set of tasks with specified functions could be defined in different granularities, which is a very important in system analysis and design. Each task binds the specific services downwards and presents on the components upwards, typically related to one Form.
Fig. 3. Business logic integration of an sample scenario
Step 1: Discovery existing resources and register in the system service library First of all, we should distinguish the necessary resources and make sure they are available. Then, publish and register them into ORIPs. Some of the services could be drawn in the old system, e.g., creating RFQ and PO, and services in other systems should be invocated with authority, e.g., evaluating the quotation.
There are three possibilities at the beginning of the integration. First and the simplest, all necessary services are standby and you just register them in to our system service library. The register course analyzes the service information and extracts the operations and input and output parameters in the WSDL. Secondly, users want to find services that match the functions they specified. They could query their target services via key words since services have been named following specified principles, or discovery services adopting the semantics. System allow for services management and auto expression as a service tree, considering the services’ semantic, which makes it easier to find the proper services. The query results are registered in the library as well. In the third case, the ideal services are not available. So, users have to add new services with the help of IT staff. The frequency of third case depends on the capacity of the existing resource library. The services accumulation play important role in the integration in term of efficiency and automation.
Step 2: Analyze and design the business process using embedded modeling tools Secondly, figure out the reasonable and efficient business logic. Developers will draw the procurement process in the business modeling interface by dragging the shapes provided. Each task in this process is corresponding to a step in the procurement process.
System users, especially business people, prefer to draw the business process in a visualization way via drag-and-drop. Here, we define the unit in a “process” as a
“task”, component to drag. Referred to previous scenario, PO submission is a task of the procurement process. The relation among tasks, can be added in the process, such as “and”, “or”, “not” or even more complicated logic.
ORIPs adopt Business Process Modeling Notation (BPMN) as the default business modeling language while various kinds of language are supported at the same time, such as Event Process Chain (EPC), used in ARIS, SAP prominent modeling tool. In addition, our system allows to export the process or input the process that created in other modeling tools due to the advantage of the standardization, and the smooth conversion among several modeling languages, such as from the BPMN to JPDL (jBPM Process Definition Language) and vice versa.
It’s an essential and common method to describe the business process using workflow diagram following some standardized principles, BPMN 2.0 here. In this way, we could define the complex relation, execution sequence and the decision logic among tasks. Moreover, it could be easily executed through the process execution language and workflow engine, BPEL and JBPM are adopted in this system.
Step 3: Draw the UI corresponding to each task in the process.
In this step, users could design their own UI corresponding to specified task by drag-and-drop. For PO submission task, you could add textbox on a Form to present the PO number and another textbox to let the purchaser input the price and quantity. Each task corresponds to one Form. Moreover, the better UI design the more user experience improving. Other web pages developing tool can involve in through the input method in ORIPs that support standard XHTML.
Step 4: Bidding UI to services
After the personalized UI have finished, we need to attach the executable function to the UI component. Each component, e.g., textbox, label, grid, get a unique id during UI editing. In this step, we need mapping operations and parameters of the specified service to the component id in order to realize the service function. The mapping allows to two kind of service invocation, SOAP and REST, which adopt different invocation path. After four steps have been set up correctly, the customized system is accomplished.
A complete system integration building is start from the requirement and end in the new system with unified UI. The definition of system integration in not limited to coordinate several existing systems. The better way to realize system integration is to collect the function chips and arrange them into a new system by the business requirement.
The integration method saves efforts on creating a new system than other traditional developing way. From the perspective of cost, it greatly shortens the system development cycle, from several months to few days. Also, integrating development leads to retrench IT stuff. Ideally, end users could develop a complete system without the participation of the IT stuff, while more attention could be paid on the business logic to reduce the mistaken understanding. Furthermore, once the system is created and authorities granted, end users could execute the functions in a process with specified role. In our scenario, for example, manager in procurement department could execute the purchasing workflow and verified PO submitted by the employee. In addition, the established business process is flexible enough to change the sequence of the tasks or add new tasks in. Moreover, ORIPs also support the B/S structure. Users managed by work group, could design and execute the new workflow on the website.
4 Conclusion
The identified patterns, which describe ways how to integrate applications in different architecture layers, including UI layer, component layer, business logic layer, resources layer and data layer, show the possibility and systematicity in the integration architecture involving four participated roles in the course of integration to construct new applications that fulfill their individual and heterogeneous needs. In addition, we line up an efficient way to construct executable business process by ORIPs and verify the feasibility and efficiency of the integration method.
We believe the end user is the focus of next wave of research and development work in the various approaches in SOA. In addition, we should consider the influence brought by the introduction of cloud environment.
Acknowledgments. This research is supported by the National Natural Science
Foundation of China under No.70871078, the National High Technology Research and Development Program of China (“863” Program) under No.2008AA04Z126, and Shanghai Science and Technology Projects 09DZ1121500.
References
1. Boualem Benatallah, L., Nezhad, H.R.M.: Service oriented architecture: Overview and directions, pp. 116–130 (2008)
2. Martin, J.: An Information Systems Manifesto. Prentice Hall, New Jersey (1984)
3. Spahn, M., Dörner, C., Wulf, V.: End User Development: Approaches Towards a Flexible Software Design. In: ECIS 2008: 16th European Conference on Information Systems, Galway, Ireland (June 2008)
4. Alonso, G., Casati, F., Kuno, H., Machiraju, V.: Web Services - Concepts, Architectures and Applications. Springer, Berlin (2004)
5. Richardson, L., Ruby, S.: The Resource-Oriented Architecture. In: Restful Web Services. O’Reilly, USA (2007)
6. Sneed, H.M.: Integrating Legacy Software into a Service Oriented Architecture. In: CSMR 2006, pp. 3–14. IEEE CSP (2006)
7. Wirtsch, D., Beck, R.: Enterprise Mashup Systems as Platform for Situational Applications. Business & Information Systems Engineering 2, 305–315 (2010)
8. Carey, M.: Data delivery in a service-oriented world: the bea aqualogic data services platform. In: SIGMOD (2006)
9. High, R., Krishnan, G., Sanchez, M.: Creating and maintaining coherency in loosely coupled systems. IBM Syst. J. 47(3), 357–376 (2008)
10. Simmen, D., Altinel, M., Markl, V., Padmanabhan, S., Singh, A.: Damia: data mashups for intranet applications. In: Proceedings of the 14th International Conference on Management of Data, Vancouver (2008)
