BIZYCLE: Model-based Interoperability Platform for Software and Data Integration

Transcription

1 BIZYCLE: Model-based Interoperability Platform for Software and Data Integration Ralf Kutsche, Nikola Milanovic, Gregor Bauhoff, Timo Baum, Mario Cartsburg, Daniel Kumpe, Jürgen Widiker TU Berlin, Computergestützte Informationssysteme CIS Abstract. The R&D initiative BIZYCLE provides a long-term project frame in order to develop modeling and metamodeling strategies for the (semi) automatic integration of software components. We distinguish between platform specific, platform independent and computation independent (meta) models. Our general philosophy is to solve integration problems on higher levels of abstraction than on the concrete software level. This approach includes our previous work on model-based and metadatabased information integration methodologies and on model-based component conflict analysis and resolution. The models and metamodels on CIM, PIM and PSM level, as well as an overview of our industrial application background, are presented in this article. Key words: software & data integration, modeling, metamodeling Introduction As part of a successful R&D program of the German government, the Berlin- Brandenburg Regional Business Initiative BIZYCLE ( a socalled Regionaler Wachstumskern, was started in early 2007 in order to investigate in large-scale the potential of model-based software and data integration methodologies, tool support and practical applicability for different industrial domains, where software and data integration play a crucial role. This consortium consists of six industrial partners and academia (in this case: TU Berlin/CIS). The long-term goal of BIZYCLE is to create a model-based and more than that, of course metamodel-based tool generation and interoperability platform, in order to allow for improved and (at least partially) automated processes in software component and data integration. The daily business of our industrial partners is software and, as an integral part, data integration. These tasks are performed by well-experienced software engineers and application experts, manually programming the connectors. In general, this requires rather professional skills in the software systems/ components/ applications on one-hand side, and integration requirements analy- This work is partially supported by the Bundesministerium für Bildung und Forschung BMBF under grant number (Förderkennzeichen) 03WKBBB.

2 2 R. Kutsche et al. sis skills on the other. This is a very expensive procedure, and several sources estimate the cost of integration issues between 50 and 80 per cent of the overall IT investments (see e.g. [4]). In order to reduce this cost factor, many initiatives in software industry and science today follow the paradigm of model-based software engineering in order to improve quality and speed of the engineering process by using models. 2 Core of the BIZYCLE initiative is the ISKI project 3, which in its essence follows the strategy of model- and metamodel- based abstractions (formalized as model transformations) from platform specific aspects towards platform independent and computation independent ones. Our strategy focusses on (semi) automated conflict analysis and connector generation. The remainder of the paper is structured as follows. First, the general background of model-based software and data integration, as well as related work are described. In Section 3 the architecture of the BIZYCLE interoperability platform is given, followed by the Section 4 which describes the integration process, involved roles, metamodels and sketches the conflict analysis methods. Finally, Section 5 presents the conclusion and points out the open issues. 2 Background: Continuous Software Engineering and Information Systems Evolution For more than two decades, integration issues are a central challenge in many industry sectors: heterogeneous, distributed software solutions under autonomous responsibilities raised the definite need for data integration in heterogeneous, distributed environment, based on the strongly increasing capabilities of (cheap!) small and medium computer systems. Federated Databases FDBMS (since the 80s) [7], Federated Information Systems FIS [6] and their special case of Mediator-Based Information Systems MBIS [5] [6] (cf. [5], [8], and our Reference Model Federated Information Systems [6]), are some examples of results achieved in this context, among many others. Finally, opening this area towards new paradigms like, e.g. Peer Data Management Systems have consolidated this very challenging and rapidly emerging research area under the name information integration [9]. Moreover, the Service Oriented Architecture [3], service composition [3] and Semantic Web efforts have added the very important aspects of communication and interoperability standardization and semantics to the integration business. 2 The term model in science is heavily overloaded: In this context, it is usually interpreted as using graphical oriented editors for expressing the relevant aspects of the future system by sets of (well-formed) diagrams and additional documents as e.g. constraint specs, following the tradition of RM-ODP [7] and today s strong initiative of MDA under the coordination of the Object Management Group OMG. In most of the cases, UML is used in this context. 3 ISKI stands for Methoden, Werkzeuge und Infrastruktur für die Komponentenintegrationsplattform, i.e. methods, tools and infrastructure for the component integration platform.

3 BIZYCLE Interoperability Platform 3 These activities perfectly meet with a tremendous pressure in business, where integration is a crucial aspect of the success (or only: survival) in a global marketplace. However, simply taking information integration as our challenge is, under a holistic view of I&C infrastructures, taken too short, because full interoperability, i.e. functional and behavioral integration to full extent in conjunction with structural integration, is needed in real business. This requirement additionally is complemented by an evolution view on software development, in our terminology expressed in the term Continuous Software Engineering [] (cf. Figure ), meaning that a consistent view on and continuous development and maintenance of all artifacts in the complex circles of forward/reverse/reengineering processes must be achieved. These two holistic approaches of software and systems engineering, namely integral view of integration issues across wide-scale I&C infrastructures, combining all informational aspects with full interoperability requirements; and integral view on all artifacts in a continuous software engineering process, yielding benefits wrt. consistency goals, constitute the essence of our BIZYCLE philosophy, methodology and concrete work. Basic paradigm of our approach is the use of models and metamodels as containers of the engineering knowledge on all levels of abstraction, to be complemented by special model extensions wrt. to semantic issues or metadata management. RE-ENGINEERING Analysis Models & Specs A A F O R W A R D R E V E R S E Construction Implementation Generation Design Models & Specs Code & Documentation Existing/Running Software Re-Specification Re-Construction Re-Documentation c o n s i s t e n c y D C & Doc S c o n s i s t e n c y D C & Doc S C o n t i n u o u s E n g i n e e r i n g Fig.. Continuous Software Engineering 3 The BIZYCLE Framework Architecture The BIZYCLE framework architecture (Figure 2), comprises the middleware, interoperability platform, business services and specific industrial sector solutions.

4 4 R. Kutsche et al. Fig. 2. BIZYCLE Framework Architecture Middleware (e.g., J2EE) is used to provide basic infrastructural services, such as security, transactions and communication. It also serves as a runtime environment/container for deployed connectors. Interoperability platform has four basic parts: MDA tools, metadata repository, conflict analyzer and connector (code) generator. Tools are (graphical) modeling and transformation editors that enable generation of models describing interfaces and processes and their transformation. Metadata repository manages and stores all artifacts required for and generated during the integration process: external and internal documentation, models and metamodels, transformation rules, generated code, users and roles. Conflict analyzer performs design-time conflict analysis based on the properties specified in models and connector generator generates connector code and deploys it to the runtime environment. Business services and specific sector solutions are provided by our industrial partners, from the health, production/logistic, facility management and publishing sectors. The business services are general purpose business intelligence components, such as event management, workflow engine or KPI analysis, that can be used in any enterprise environment to develop added value services. The benefit of the pluggable solution we provide is that business services can be seamlessly integrated with the existing enterprise services using the BIZYCLE interoperability platform, hence one of the BIZYCLE slogans is Plug and play your business. The main purpose is automated generation of business intelligence and leveraging existing IT infrastructure against the business requirements. Finally, based on the interoperability platform and general purpose business services, each industrial sector (not limited to the four ones listed here) may develop other solutions, tailored to the particular and specific business requirements.

5 BIZYCLE Interoperability Platform 5 4 Methodology in Detail In this section, the BIZYCLE integration process is described in more detail, as well as the roles involved in the integration lifecycle. The abstraction levels already mentioned (CIM, PIM, PSM) are further examined, and the whole process of model transformation, conflict analysis and connector generation is sketched. 4. Integration Process and Roles Four levels of abstractions are supported in the BIZYCLE integration process with appropriate models: computational independent level, platform independent level, platform specific level and deployment/code level. Our integration workflow includes artefacts from each of these levels, influencing the next steps in the wokflow, as shown in the diagramm below (Fig. 3). Identify business process Flow model Transform PSM to PIM Interface PIM Refine integration scenario Identify components to integrate ConnectorPIM Conflict analysis Identify connectors conflictsremained Conflict model Describe static connector scenario Business Connector Model noconflicts Connector generation Describe interfaces Interface PSM Code generation Connector PSM Fig. 3. BIZYCLE Integration Process The Computational Independent Model (CIM) captures the business process that is enacted by the integrated systems. This step consists of identifying business process, components and connectors. Resulting are flow model and business connector model. They abstract technical properties from the integration solution and describe only process- and business-related issues. Flow model describes abstract data and control flow. Integration points and (incomplete) list of potential conflicts are described in the business connector model. This model will be subsequently refined. The following step is identification, definition and modeling of platform-specific system interfaces: input/output parameters, communication capabilities, and non-functional properties (such as security, dependability or semantics) are described. PSM interface descriptions are abstracted to platform independent level (PIM), for the purpose of conflict analysis, as it is not possible to directly define and analyse integration conflicts between heterogeneous

6 6 R. Kutsche et al. platforms. A process of generalization is performed which transforms all PSM interface descriptions to the common PIM level. The process of conflict analysis generates a set of integration conflicts at the PIM level. It is performed iteratively until all conflicts are solved (or only non-solvable conflicts remain). A connector is then generated as a mediator component that matches requirements and capabilities of the observed interfaces. Finally, a physical connector is generated, by transforming connector model from PIM to PSM level, generating connector code and deploying the connector into BIZYCLE integration middleware. Several software engineering roles emerge within the BIZYCLE integration process (Figure 4). They enable not only modularization and separation of concerns in the integration process, but primarily aim to support automation and optimal (re)use of the domain-expert knowledge. Integration solution architect Identify business process Idenfity systems to integrate Identify connectors Create flow model <<include>> <<include>> <<extend>> Create CIM System integrator Solution deployer Conflict analysis Model transformation <<include>> <<include>> Connector generation <<extend>> Code generation PSM to PIM transformation Application specialist Application specialist 2 Describe interfaces to integrate <<extend>> Create PSM <<include>> Runtime environment management Application specialist n Platform specialist Create PSMM Platform specialist Fig. 4. BIZYCLE Integration Roles The integration solution architect develops flow model and business connector model, based on the requirement analysis. Platform specialists create and update metamodels for the platforms that are supported by BIZYCLE interoperability platform. Application specialists refine the work of solution architect, and create detailed platform specific interface models. The system integrator uses platform specific interface models, generalizes them to PIMs and guides conflict analysis process. It is his responsibility to manually intervene when the interoperability platform is unable to solve the conflicts automatically. Finally, solution deployer oversees code generation and connector deployment. He is also responsible for maintaining and managing the runtime environment. The roles can overlap, e.g., it is possible that platform specialist takes the role of the application specialist, or that one or more platform specialists participate in conflict analysis and connector generation process.

7 4.2 Metamodels and Model Transformation BIZYCLE Interoperability Platform 7 The BIZYCLE interoperability platform is based on the principles of modeldriven engineering and Model Driven Architecture (MDA). Therefore, metamodels and model transformation form the core BIZYCLE elements. They are defined at the M2 level of the Meta Object Facility (MOF) hierarchy. The MOFbased BIZYCLE (Meta)model hierarchy is shown in Figure 5. Computation Independent Metamodel Platform Specific Metamodel A Transformation Rules Platform Specific Metamodel B MOF M2 Level Computation Independent Model PSM Interface A PSM Interface B Trafo A Trafo B MOF M Level PIM Interface A PIM Interface B Platform Independent Metamodel Conflict Model Conflict Metamodel Connector Model Connector Metamodel : Interface A : Connector : Inteface B MOF M0 Level Fig. 5. BIZYCLE (Meta-) Models and MOF Levels Computational Independent Metamodels (CIMM) comprise two metamodels: Flow Metamodel (FMM) and Business Connector Metamodel (BCMM). FMM is based on the UML2 Activity Diagram and describes business data and control flow between the integrated systems. For that purpose a signaling mechanism is used: SendSignalAction represents a source system, while AcceptEventAction represents target system. ConnectorNode connects one sending action with one or more receiving actions. BCMM is used to describe connector logic from the business-process perspective. The core element of BCMM is Connector element which connects two or more IntegratableElements. Business Connector defines several DataProcessor elements, such as Aggregator,

8 8 R. Kutsche et al. Router, Transformer or Filter. They capture abstract semantics of integration, which is the result of requirement analysis process. An example of such semantics is a flow model which uses Aggregator to express that customer data from two branch offices should be aggregated in a data warehouse. Technical aspects (e.g., tables to be exported or database drivers) are not addressed at this level. BCMM is refined at the subsequent levels. The connection between FMM and BCMM is shown in Figure 6, where one Connector activates one or more ConnectorNodes. CIMM can be perceived as extended UML 2 activity diagram, where activities between send and receive signal actions represent business connector. The relation between Connector and ConnectorNode thus also has an activation semantics. Action Flow Metamodel Connector Template Metamodel IntegratableElement SendSignalAction AcceptEventAction -source 0.. ConnectorNode.. -target activates Connector Component ActivityNode Fig. 6. Computational Independent Metamodel: Excerpts from FMM and BCMM Platform Specific Metamodels (PSMM) cover a class of metamodels describing technical aspect of systems that are to be integrated. Systems under study, for which we currently provide support within BIZYCLE interoperability platform, are relational databases (including extensions for MySQL, Microsoft SQL Server, Oracle, and Firebird), J2EE applications (EJB 2. and 3.0),.NET Framework applications (version. and 2.0), ERP applications (SAP R/3 BAPI/IDOC and AvERP), XML flat files and SOAP-based Web Services. In accordance with the view that all systems are treated as components, that is, as black boxes that expose their functionality via interfaces, PSMM offers a platform specific interface description. Aspects such as remote addresses, function and parameter signatures and structure, communication properties, diverse non-functional properties specific for each platform (e.g., security or transactions) are supported, as well as interface semantics. The goal of PSMM is to provide enough platform-specific information on interface properties, such that: ) they can be abstracted to platform independent level and be used in the process of conflict analysis (design time requirement) and 2) an automatic connector can be generated, that invokes

9 BIZYCLE Interoperability Platform 9 the given interface (runtime requirement). As a short PSMM example, excerpt from SOAP-based Web Service metamodel is given in Figure 7. PortType has WSDL binds Binding -style : String -transport : String.. Communication TransportLayer supply.. Operation supply has HTTP FTP SMTP MessagingService receive 0.. OutputMessage InputMessage FaultMessage Service -location : String -targetnamespace : String MessageExchangePattern SOAPMessage Include -schemalocation : String has XSD XMLSchema -targetnamespace : String -elementformdefault : String -attributeformdefault : String XMLNamespace define -prefix : String -url : String Envelope SOAP SOAPHeader SOAPBody SOAPAttachment Fig. 7. PSMM: SOAP-based Web Services (excerpt) All PSMM share the similar structure, where endpoint is described (e.g., WSDL, SQL query or EJB remote interfaces), parameters (e.g., SOAP messages, SQL tables or Java serializable objects), communication properties (e.g., SOAP over HTTP, ODBC or RMI-IIOP) and type system (e.g., XSD schema describing messages, SQL types or Java type system). Non-functional part of interface description has been left out of this example, as it is orthogonal to all PSMMs and will be commented on in the next section in the PIMM context. Platform Independent Metamodels (PIMM) are used to abstract platformspecific properties from interface descriptions, which is precondition for the conflict analysis process. Core excerpt from PIMM is given in Figure 8, containing interface, structure, property, behavior, communication and semantic packages. Depending on the source PSM, interface can be functional (e.g., SAP remote function), method (e.g., EJB) or document (e.g., Web Service). Each interface (more precisely, parameters which are not shown in this view) has a structure defined within platform independent type system. Platform specific types are then mapped into this type system in the process of model transformation (e.g., SQL VARCHAR(20) can be transformed into PIMM String with length 20). Object mapping is also supported through Object element, where object attributes are further PIMM-typed. Therefore, a Java object can be transformed into PIMM object. Properties of platform specific communication

10 0 R. Kutsche et al. channels are abstracted using AccessPatern and MessageExchangePatern elements, describing function- and document-based communication styles. A synchronous.net remoting service, for example, is then represented with synchronous AccessPatern, asynchronous EJB event handler with asynchronous Event and SQL query with DataAccess. Behavior is associated with each interface, describing pre-conditions, post-conditions and invariants. Properties define quality of service attributes, such as security, performance, reliability, etc. Using combination of behavior and properties, it is possible to express requirements and capabilities of each interface, e.g., login, encryption or transactional behavior. Interface can carry semantic description via association to BusinessFunction. Domain ontologies are used to describe business semantics, together with business objects that are mapped to physical interface parameters. For example, SAP function can be annotated with a business function stating that it performs tax calculation operation for an order object using domain ontology from the logistics sector. Model transformation rules, that perform generalization from PSM to PIM level, are defined and implemented in Atlas transformation language [2]. Connector and Conflict Metamodels represent the last step in the process of interface integration. Connector model is message-based, that is, interface heterogeneity is addressed using messaging as key abstraction concept. Integration data and control flow are determined within a connector, which uses channels to transport messages between interfaces of source and target applications. Message processors operate on the message content, namely, they can route messages (control and data flow) or transform message content. Transformation can take the form of aggregation, filtering, translation, enrichment, normalization, etc. A message-middleware independent transformation language, based on the UML Action Semantics, is developed for expressing message content transformation rules. Business goals, as well as technical requirements are therefore matched within a connector. Connector also contains an application endpoint, which is a placeholder for the interface client-side code. Thus our definition of a connector departs somewhat from definition established in the component-based software engineering, where connectors (from the architectural point of view) are passive first-class architectural entities that describe communication semantics between mismatched components [4]. Our understanding of a connector is pro-active, where a connector not only describes behavior protocol between two components using required/provided semantics, but can activate the behavior of two or more provided interfaces in runtime. According to the principles of generative programming [8], BIZYCLE connectors do not require glue code, as they are generated down to the code/deployment level and can communicate autonomously with the target interfaces. The BIZYCLE interoperability platform recognizes the following conflict types: semantic, structural, behavioral, communication and property. To represent each conflict type, an appropriate formal abstraction is used. Structural conflicts are type conflicts which are detected and solved using typing and subtyping rules. Behavior conflict are solved using either simulation and bisimulation [], or transferring interface descriptions into abstract machine notation

11 BIZYCLE Interoperability Platform Call Communication 0.. DataAccess Event -readonly : Boolean -delivery : DeliveryEnum AccessPattern MessageExchangePattern Communication Semantic TypedPredicate -type Domain Predicate -subject -object BusinessObject -ExportParameter Behavior Behavior Constraint 0.. -ImportParameter BusinessFunction Literale PreCondition Invariant PostCondition.... Interface.. Structure (PIMM) Object FunctionInterface MethodInterface DocumentInterface.. -objectid : int has Attribute Security Property Property QualityOfService Performance Regulatory Accessibility Integrity Availability Reliability Parameter has Type Fig. 8. Platform Independent Metamodel (excerpt) and performing invariant preservation proofs [2]. Process algebra [0] is used to perform communication and protocol compatibility check, while frame-logic [9] is suitable for semantic and property verification. The benefit of this approach is the possibility to use model transformation (with PIM as a source), to choose adequate target formalisms and languages for verifying properties of interest. 5 Conclusion and Outlook We have sketched the results of the first phase of the BIZYCLE initiative and of our ISKI project, by clarifying the general philosophy, strategy, processes and roles in our model- and metamodel-based approach towards (semi)automatization

12 2 R. Kutsche et al. of software and data component integration. Main benefits of the proposed modeling process are support for different abstraction levels; separation of concerns and expert knowledge reuse; automated conflict analysis and code generation; evolution support (in the context of continuos software engineering). At present, detailed specifications of concrete integration scenarios are being finalized by our industrial partners, which already (in the first round of our cyclic process) have been used for the platform specific models, partially presented in this paper. From that we shall be able to revise and to finalize the PSMs and then integrate them into our tool generator. References. Leicher A. Analysis of Compositional Conflicts in Component-based Systems. PhD Dissertation, TU Berlin, LINA & INRIA Atlas Group. ATL: Atlas Transformation Language User Manual. m2m/atl/doc/atl User Manual[v0.7].pdf, Krafzig D., Banke K., and Slama D. Enteprise SOA. Prentice Hall, Pulier E. and Taylor H. Understanding Enterprise SOA. Manning, Wiederhold G. Mediators in the architecture of future information systems. IEEE Computer, 25(3):38 49, Zhou G., Hull R., and King R. Generating data integration mediators that use materialization. Journal of Intelligent Information Systems, 6(2/3), ISO/IEC. International Standard Reference Model of Open Distributed Computing, Czarnecki K. and Eisenecker U. Generative Programming - Methods, Tools and Applications. Addison-Wesley, M. Kiefer, G. Lausen, and J. Wu. Logical Foundations of Object-Oriented and Frame-Based Languages. Journal of the Association for Computing Machinery (ACM), 42(4):74 843, R. Milner. The Polyadic π-calculus: A tutorial. In Logic and Algebra of Specification. Springer Verlag, H. Mller and H. Weber (eds.). Continuous Engineering of Industrial Scale Software Systems. Dagstuhl Seminar 98092, IBFI, Schloss Dagstuhl, Milanovic N. Contract-based Web Service Composition. HU Berlin, Milanovic N. and Malek M. Current Solutions for Web Service Composition. IEEE Internet Computing, 8(6):5 59, Mehta N.R., Medvidovic, and Phadke S. Towards a Taxonomy of Softwar Connectors. In Proceedings of the 22nd International Conference on Software Engineering, pages 78 87, Toronto, Canada, ACM Press. 5. Kutsche R.-D., Conrad S., and Hasselbring W. (Eds.). Proceedings of the 4th Workshop EFIS 200. Aka GmbH, Busse S., Kutsche R.-D., Leser U., and Weber H. Federated Information Systems - Concepts, Terminology and Architectures. TR Nr. 99-9, TU Berlin, Conrad S. Föderierte Datenbanksysteme: Konzepte der Datenintegration. Springer, W. Sigel, S. Busse, R.-D. Kutsche, and M. Klettke. Designing a Metadata-based Infrastructure for E-Learning. In Proceedings 5th Int. Workshop EFIS 2003, pages Aka GmbH, Berlin, Leser U. and Nauman F. Informationsintegration. Dpunkt Verlag, 2007.