Visual Application Integration Through Web Services for e Services Hub Edición Única

Texto completo

(1)INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY. Campus Monterrey. Graduate Program in Electronics, Computing, Information and Communications. Visual Application Integration through Web Services for eServices Hub THESIS PRESENTED AS PARTIAL REQUIREMENT TO OBTAIN THE ACADEMIC DEGREE OF. Master in Science in Information Technology BY. Javier Mijail Espadas Pech MONTERREY, N.L.. May, 2006.

(2) INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY Campus Monterrey. Graduate Program in Electronics, Computing, Information and Communications The committee members hereby recommended this thesis presented by Javier Mijail Espadas Pech to be accepted as partial fulfillment of the requirements for the Degree of Master in Science in Information Technology.. Committee Members:. ___________________________ Ph. D. Guillermo Jiménez Pérez Thesis Advisor. ___________________________ Ph. D. José Ignacio Icaza Acereto. __________________________ M.S. María Esperanza Garza Leal. __________________________________ Ph. D. David A. Garza Salazar Director of Graduate Program in Electronics, Computing, Information and Communications.

(3) Visual Application Integration through Web Services for eServices Hub. BY. Javier Mijail Espadas Pech. THESIS. Presented to Graduate Program in Electronics, Computing, Information and Communications This thesis is a partial requirement to obtain the Degree of Master in Science in Information Technology. INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY. May, 2006.

(4) Dedicatorias A Dios que todo lo hace posible. A mis padres, Freddy y Silvia, ejemplos de vida, lucha diaria y sobre todo, ejemplos de amor. Gracias por todo su apoyo y confianza. Los quiero mucho.. A mi hermana Nicte-Ha, porque puedo contar con ella en todo momento, la quiero mucho.. A Leydi, el amor de mi vida, sin ella nada de esto hubiese sido posible, ha sido mi gran apoyo en este largo camino. Gracias preciosa.. A mis abuelitos Rosa, Gilda, Benigno y Filiberto, que han luchado toda su vida para darme un ejemplo de esfuerzo y dedicación para salir adelante. Dios los bendiga.. A todos mis familiares, tíos y primos, que siempre me han apoyado.. iv.

(5) Reconocimientos A mi asesor, el Dr. Guillermo Jiménez, por haber compartido su conocimiento en este trabajo de tesis, por sus enseñanzas y esfuerzo dedicado. Muchas gracias.. A mis sinodales, el Dr. José Icaza y a la M.C. María Esperanza Garza Leal, por sus valiosos comentarios que hicieron de este documento un mejor trabajo.. A mis compañeros de maestría, a todos cada uno, los estimo mucho y fueron parte importante en este proceso de aprendizaje, no solo académico, sino también de vida.. v.

(6) Summary An open platform named Hub is an infrastructure for deploy electronic services (e-services) in order to offer to Small and Medium Enterprises (SME) more opportunities in new global markets. The enterprises that contract the eservices in the Hub commonly have legacy applications or commercial information systems that must be integrated to the platform to form an heterogeneous system with the e-services implementation and external applications. The conceptual architecture of the Hub is a service oriented approach and the use of new techniques of application integration as web services is needed for this kind of integration. Because the variability of legacy applications and the number of enterprises into the Hub, the manual integration (coding each case) is almost impossible. This thesis proposes the elaboration of a visual tool prototype to integrate enterprise applications to a business process based infrastructure through distributed systems and application communication techniques known as Web services; and the use of automatic software generation. The main areas involved are the concept of e-services Hub, enterprise application integration, web services technologies and automatic code generation. In order to reach an automatic integration this thesis proposes the use of software product lines. The idea of software product lines is to reduce both development time and cost. An applicative area of software product lines is generator technology, whose aim is the automatic production of software from a formal specification. With this applicative approach of software product lines, a visual tool can be developed by using code generation techniques (i.e. configuration wizards), and web services as application integration interfaces.. vi.

(7) Contents Dedicatorias ......................................................................................................... iv Reconocimientos...................................................................................................v Summary.............................................................................................................. vi Contents.............................................................................................................. vii Index of Figures ................................................................................................... ix Chapter 1 Introduction...........................................................................................1 1.1 Background................................................................................................1 1.2 The PyME CREATIVA project....................................................................2 1.3 Problem definition ......................................................................................3 1.4 Justification ................................................................................................4 1.4.1 Need of integration ..........................................................................4 1.4.2 Integration complexity......................................................................4 1.5 Hypothesis .................................................................................................5 1.6 Goals .........................................................................................................5 1.7 Document Organization .............................................................................6 Chapter 2 Literature Review..................................................................................7 2.1 Hub Architecture and e-Services ...............................................................7 2.2 Enterprise Application Integration ............................................................10 2.3 Related projects.......................................................................................11 2.4 Service Oriented Architecture ..................................................................15 2.5 Supply Chain Integration..........................................................................18 2.6 Software Generation ................................................................................21 2.7 Chapter Summary....................................................................................25 Chapter 3 Analysis and Design of the Visual Integration Tool ............................26 3.1 e-Services Hub Context ...........................................................................26 3.1.1 E-Services Structure........................................................................26 3.1.2 Integration level ...............................................................................27 3.2 Software Analysis ....................................................................................28 3.2.1 Requirements ..................................................................................28 3.2.2 Integrating through Web services ....................................................29 3.2.3 Web services interfaces ..................................................................31 3.3 Visual tool architecture.............................................................................32. vii.

(8) 3.3.1 Architecture definition ......................................................................32 3.3.2 Tools and techniques ......................................................................34 3.4 Visual Tool Design ...................................................................................35 3.4.1 Uses Cases .....................................................................................36 3.4.2 Class diagrams................................................................................39 3.4.3 Interaction diagram..........................................................................43 3.5. Implementation .......................................................................................44 3.5.1 GUI for Visual Specification.............................................................44 3.5.2 XML mapping as integration mechanism.........................................45 3.5.3 Integration Code Generator.............................................................47 3.6 Chapter Summary....................................................................................50 Chapter 4 Test Case for e-Supply service integration .........................................51 4.1 e-Supply Service overview.......................................................................51 4.2 Process definition ....................................................................................53 4.3 Defining the remote operations................................................................55 4.4 Generating the integration code...............................................................56 4.5 Adapting the generated code...................................................................58 4.6 Chapter Summary....................................................................................59 Chapter 5 Results and conclusions.....................................................................61 5.1 Results.....................................................................................................61 5.2 Conclusions .............................................................................................64 5.3 Future work..............................................................................................66 5.4 Chapter Summary....................................................................................67 Appendix A. XML files .........................................................................................68 Appendix B. UML diagrams.................................................................................74 Appendix C. Source codes..................................................................................78 Bibliography ........................................................................................................87 Vita......................................................................................................................90. viii.

(9) Index of Figures Figure 1.1 e-Services Hub containing SME portals...............................................3 Figure 1.2 Interface for information access ...........................................................4 Figure 2.1 e-Services Hub architecture.................................................................8 Figure 2.2 Application integration problem domains ...........................................10 Figure 2.3 Visual tool for AI in B2B .....................................................................12 Figure 2.4 Components of the EAI framework ....................................................12 Figure 2.5 Information heterogeneity with XML integration .................................13 Figure 2.6 Overview of the layer to build a B2B platform ....................................14 Figure 2.7 Service interfaces and implementation ..............................................16 Figure 2.8 Service Oriented approach ................................................................18 Figure 2.9 Architecture for a Supply Chain .........................................................19 Figure 2.10 Architecture of an Integrated Supply Chain......................................20 Figure 2.11 Supply Chain Integration architectural approach .............................20 Figure 2.12 Example of a Web Service broker....................................................22 Figure 2.13 Example of Code Generator ............................................................23 Figura 2.14 Configuration wizard’s architecture ..................................................24 Figure 3.1. e-Service implementation within a portal platform.............................27 Figure 3.2. Hub architecture - Application Integration .........................................28 Figure 3.3. Web services integration...................................................................28 Figure 3.4. Enterprise’s information domain........................................................29 Figure 3.5. Application Integration through dynamic web services......................30 Figure 3.6. Mechanism for integration through Web services .............................30 Figure 3.7. Web services interfaces ....................................................................31 Figure 3.8. Retrieving of Web services interfaces ...............................................32 Figure 3.9. Visual tool elements ..........................................................................33 Figure 3.10. Service level integration ..................................................................34 Figure 3.11. Tools for the visual tool ...................................................................35 Figure 3.12. Interfaces of application integration tool..........................................35 Figure 3.13. Introduction of configuration data ....................................................36 Figure 3.14. Screen of configuration of generic Web services ............................36 Figure 3.15. Login use case ................................................................................37 Figure 3.16 Screen of Login ................................................................................37 Figure 3.17 Web Service and Operation specification use case .........................37 Figure 3.18 Screen of Web Service and Operation specification ........................38 Figure 3.19 Code generation use case ...............................................................38 Figure 3.20 Screen for Code generation .............................................................39 Figure 3.21. Main packages of the visual tool .....................................................40 Figure 3.22 Visual Specification classes .............................................................40 Figure 3.23 Data mapping classes......................................................................41 Figure 3.24. Code generator classes ..................................................................42. ix.

(10) Figure 3.25 Interaction diagram ..........................................................................43 Figure 3.26 Visual specification flow ...................................................................44 Figure 3.27 Code generator description..............................................................47 Figure 4.1 Simple supply chain workflow ............................................................52 Figure 4.2 Workorders Web interface .................................................................52 Figure 4.3 Report of dead times..........................................................................53 Figure 4.4 A supply integration process ..............................................................54 Figure 4.5 Access to external application through web services .........................55 Figure 4.6 Enterprise selection and login information .........................................55 Figure 4.7 Selection of getPurchaseOrders operation ........................................56 Figure 4.8 Code generation for getPurchaseOrders operation ...........................57 Figure 4.9 Application for report generation through Web services.....................58 Figure 4.10 Report of material usage..................................................................59. x.

(11) CHAPTER 1. INTRODUCTION. 1.1 Background Today, for a large number of companies, the information systems landscape is a complex mixture of old and new technologies (Linthicum, 2004). Linthicum has found that traditionally, companies built heterogeneous applications to support their operation in order for taking advantage of business opportunities within their organization. The typical approach is that enterprises develop their applications in an isolated way, with every department independently developing or acquiring their own applications and data storages. Currently, these companies confront the necessity of sharing information among those heterogeneous applications (commonly named legacy systems) and the new systems being developed. Linthicum (2004) has also observed that the Internet brought about an increased necessity for companies: the need of Web presence and integration of their systems. As more and more organizations pursue the benefits of e-business, they are looking to a process called enterprise integration, or EI, as key technical enabler in transforming their business processes (Lam, 2004). A typical form of EI happens when a company wants to offer its existing products and services over the Internet, so it builds web front-end systems and integrate them to its back-end legacy systems (any IT system already in operation). A more complex EI scenario involves enterprise application integration. By this process, the organization links up previously separated and isolated systems to give them greater leverage. An emerging EI scenario is business-to-business (B2B) integration (also called extended enterprise models), which occurs when an organization integrates its own business processes with those of its business partners to improve efficiency within a collaborative value chain (Lam, 2004). Examples of B2B applications include procurement, human resource, billing, Customer Relationship Management (CRM) and supply chains (Medjahed, 2003). In fact, effective and efficient supply chain integration is vital for the competitiveness and survival of organizations. With the emergence of the e-Business era, supply chain needs to be able to extend beyond the traditional boundaries (Siau, 2004). The need for supply chain integration techniques and methodologies has been increasing as a consequence of the globalization of production and sales, and the advancement of enabling information technologies (Ball, 2002). This document describes the design and implementation of a visual tool for.

(12) automatic application integration by using Web services technologies within the PyME CREATIVA project (explained next). The tool provides visual specification facilities and capability of code generation to produce code for B2B integration of enterprises focused in supply chains. 1.2 The PyME CREATIVA project The creation of industrial networks to foster the competencies of Small and Medium Enterprises (SME) requires the definition of new business models based on Internet availability. These networks need integrated electronic information services (e-Services) that offer and enable coordination and cooperation among the different SMEs, allowing them to share their technological resources, thus creating virtual organizations (VOs). These e-Services should be integrated into an easy to access open technological platform, easy to access, known as e-Hub or just ‘Hub’ (Molina, et, al. 2004). A main goal in the PyME CREATIVA project (Program ICT4BUS, 2003) is to produce a low cost management and operational infrastructure for value-added networks of SMEs. The Hub platform (Integrated e-Services for Virtual Business) offers a variety of integrated e-Services necessary for dynamic market competition. This e-Services Hub can be seen as a marketplace platform, where SMEs can execute trading processes, issue purchase orders, get into supply chain management, issue request for quotations, and other types of business processes with other SMEs integrated to the Hub. In this project the following e-Services are being developed and integrated within the Hub architecture (Molina, 2004): • • • • •. e-Supply. Implements technologies for the integration of logistic services, industrial plant configuration, client/supplier relation management and supply chain tracking. e-Brokerage. Integrates technologies to support the development of virtual organizations, enterprise industrial clusters, etc. e-Marketing. Integrates different technologies for the development of customizable portals to promote products and services of the SMEs. e-Productivity. Incorporates technologies for the diagnosis, planning, and monitoring of SMEs. e-Engineering. Engineering collaboration that integrates design and manufacturing technologies for integrated product development.. With the global competition being posed to global enterprises, the limited resources of SMEs put them in a difficult situation to compete. The Hub reduces critical troublesome problems that traditionally limit SME’s competitiveness, thus allowing new business opportunities to be exploited and increasing access to new global markets. The Hub is based on open source technologies to implement the collaboration services, and as enterprise that provides consultancy to implement, operate, and manage the ICT infrastructure for SMEs collaboration at low cost.. 2.

(13) Clients, suppliers. Internet Internet HTTP Server. Hub. SME portal. App Server. Others access. SME portal SME portal SME portal Corporative Portals. SME portal. e-Services. Figure 1.1. e-Services Hub containing SME portals [Adapted from (Molina, 2006)] As shown by Figure 1.1, a number of SMEs will be integrated as clients or suppliers to this Hub by deploying their own web portal that will serve as an access point for its users to contracted e-Services. The e-Services Hub implementation pretends to integrate nearly 200 Mexican SME's for the first deployment (Program ICT4BUS, 2003). All the information will be introduced through web portals and the information processes will reside within the Hub platform. SMEs need always maintain consistent and updated information of their core processes such as purchase orders, quotations, material stock, or customer contacts. As the number of SMEs interested in integrating their existent systems to Hub platform increases, it becomes necessary the implementation of mechanisms to integrate them to the Hub. From its conceptualization and design, the Hub platform was considered as Service Oriented architecture. Also, the architecture defines that integration with external application should be achieved through Web services techniques (Molina, 2006). The Hub’s architecture (explained in detail in Chapter 2) defines external access from enterprise applications through a Service Oriented approach, in this case, Web services technologies. This kind of integration involves manual tasks that have to be designed and developed with specific requirements as data types, data sources or different information domain. 1.3 Problem definition One of the aims of the PyME CREATIVA project is have at least two hundred thousands SMES with access contracted to the eServices in the Hub. Integrating hundreds of enterprises applications from SMES to the eHub following a manual approach is a task that seems inappropriate. However is something that should be performed unless something more elaborate could be think out.. 3.

(14) The e-Services Hub needs to be integrated with external applications and internal services, using web services technologies. By now, these activities must be carried out in a manual way, which can consume considerable time and the possibility of errors. Considering and conciliating several data sources involves a meticulous and well-designed development tasks. 1.4 Justification This research work is divided in two principal aspects based on the SME’s integration needs; the first one is in the need of integration, the second is the integration complexity. 1.4.1 Need of integration The integration of existing systems in SMEs is a common need in the PyME CREATIVA project. A good example is when a legacy application or an ERP system must create a report of the work orders to check their status and update its produced quantity. If these work orders were introduced through e-Services interfaces at the web portal, the enterprise applications could not have access to this information. A web service interface could be implemented in order to achieve this kind of integration.. Figure 1.2. Interface for information access Figure 1.2 shows the operation of this interface, where a legacy system can execute a remote method, implemented into the Hub platform, and get a list of the work orders in order to process them. Another explicit example, is a supply chain process, when a work order can be introduced at the Hub interface or at the legacy application, so, it is necessary that the information of this work order can be retrieved from the e-service by the enterprise systems. 1.4.2 Integration complexity Once that the need of integration is considered, another important aspect is the integration complexity confronted by the PyME CREATIVA project. The e-Services Hub implementation pretends to integrate nearly 200 SME's for the first deployment (Program ICT4BUS, 2003). Considering that each (system) enterprise could be integrated with the Hub platform, the problem to achieve these integration grows in complexity according to the number of enterprises. So, it is necessary to consider the following issues: •. Number of enterprises within the Hub.. 4.

(15) • • •. Diverse requirements of integration, data or access. Different and diverse applications to integrate. Dynamic increment in the number of enterprises.. The described scenario shows how manual application integration could become a complicated work. Manual integration requires creating composite application with almost all external applications. The goal in this thesis work is to integrate external applications with the complete functionality of the e-Services. 1.5 Hypothesis The integration of e-Services Hub with external and internal applications through web services can be automated by using a software generator with a visual interface. The hypothesis presumes that the development of a software tool to generate code for information sharing will constitute an easiest, faster and more reliable application integration approach, instead of manual integration, for the e-Services Hub and SME’s systems. Research questions • Can application integration with the e-Services Hub be achieved through web services technologies? • Is it possible to implement a software generator wizard to generate the integration code for external applications? • What kind of integration code needs to be generated (e.g., WSDL, Java, other language)? • Is it possible to generate code with generic templates for different programming languages? • What are the characteristics of an interface for different applications? 1.6 Goals The main goal in this work is the design and development of a visual tool that allows the automatic integration of the SME’s systems with the e-Services Hub, integrating their legacy or commercial applications with the e-Services functionality. The specific goals of this work are: • • • • • •. Research about enterprise application integration and their technologies. Research code generation approaches. Define the common integration requirements. Design the software architecture of the visual integration. Develop the software tool components. Design and validate basic test cases.. 5.

(16) The basic approach involves the use of web services technologies provided by the Hub platform. The tool will provide a visual interface to specify the correct end points and methods to get and set the data that the external application needs, then the tool will generate the necessary code to access the information. 1.7 Document Organization The present document is divided in five chapters. The first chapter presents an overview of the PyME Creativa project and the eservices Hub. Also it explains the problem and the need for application integration, and how this integration tool can help to generate automatically the code for application integration. The second chapter includes a literature review of the main technological areas involved within this work, including enterprise application integration and similar projects related to application integration. Also it describes the main concepts used in this thesis like “service oriented architecture” including the web services technologies and software generation. It sets the conceptual base for the tool development process. The third chapter describes the design and development of the visual tool, including the conceptual software architecture, UML design diagrams as classes and use cases, and the component model of the software. Finally, it shows implementations of the main components. The four chapter analyses test cases for the visual tool functionality, presenting a business process that needs to be integrated with an e-service through web services, and describes how the visual tool can generate the necessary code and for application integration through web services mechanisms. The last chapter presents results and conclusions.. 6.

(17) CHAPTER 2. LITERATURE REVIEW. This chapter presents the technologies involved to design and development of the software tool for the application integration of the SME systems with the eservices Hub. It is described the software architecture of the Hub platform and its main technologies. A Business-to-Business scenario is presented within the PyME CREATIVA project and its Hub implementation. Integration of information systems is depicted within the e-Services contexts. For this integration issues, is defined the Enterprise Application Integration as an approach to solve sharing data requirements between information systems. The Service Oriented Architecture (SOA) is a set of emerging technologies and XML standards used to build distributed systems through Internet protocols. The SOA technologies allow developing implementations for Application Integration. As described in the previous chapter, the context of this research work resides in the PyME CREATIVA project, which plans to integrate small manufacturing enterprises within a technological platform. One of the most important services of this platform is a supply service with Supply Chain Management features, such as work orders tracking, material stock and production plant configuration. The integration of these functionalities with external application is the core target of the software tool proposed in this document. Due to this, the chapter describes the concept of Supply Chain Integration and its role in application integration and supply chains. Finally, the last important technology is software generators, specifically configuration wizards, because the software tool should be able to build several software programs in agreement with input specifications and requirements of each system to integrate. 2.1 Hub Architecture and e-Services In the Chapter 1 was explained an overview of PyME CREATIVA project and the Hub platform, in the following paragraphs is detailed the Hub architecture. The e-Services Hub architecture is a robust platform that involves many components and technologies. This platform includes a set of components to deploy a number of e-Services and sub-portals. The main component is a corporate portal with a portlet container (JSR-168) in order to separate the components into the ModelView-Controller (MVC) architectural pattern and provide more flexibility to development and management of user interfaces. Within the main portal implementation are integrated sub-portals (one for each SME) that consume the main portal infrastructure.. 7.

(18) The concept of creating Hubs is considered a “technological innovation” because it enables the integration of value added networks, creating virtual and smart organizations. This concept reduces critical troublesome that limits SME's competitiveness, allowing new business opportunities to be exploited and having access to new global markets. The Hub offers a variety of integrated e-Services that are necessary for dynamic market competition. Innovation has three variants (Molina, 2006): • • •. e-Hub's (Engineering Hub's with Internet based services) Development, allowing SMEs to have access to a wide range of value added e-Services. e-Services implementation methodology, to demonstrate its impact and benefit for the SME through an integrated process to achieve competitiveness. Creation and demonstration of the new SME business model based on value added industrial networks that enable the creation of virtual and smart organizations.. An e-Service implementation could be defined as a composite component from a combination of user interfaces (views) and portlets (controllers) that interacts with the services stack (model) explained later. Another component is the BPM engine integrated to the portal platform to manage many workflows; it interacts with other components through its API (Application Programming Interface) and the services stack. The component that serves as broker of the entire platform is a services stack containing definition and implementation of applications, database connections, content management system, security, organization management, LDAP protocols, and other.. Figure 2.1. e-Services Hub architecture [Adapted from (Molina, 2006)]. 8.

(19) Figure 2.1 shows the Hub architecture, where the principal approach used is a service-oriented architecture and a Business Process Management (BPM) in order to carry out the activities within the e-Services. This platform includes a set of tools and frameworks to define, deploy and manage a number of electronic services. In Figure 2.1 is shown the components of this platform: Corporate Portal, BPM Engine, Web Service Bus (WSDL), Process Repository, File Repository, Collaboration Services and others. Below this platform is the technological enterprise infrastructure that support the services stack consisting in collaboration services (P2P, SMTP, POP3), file repository, network services (FTP, SFTP), security (Kerberos, SSL), databases, etc. The e-Services Hub can be seen as a market place platform, where the SME can execute trading processes, purchase orders, supply chain management, request for quotations, and other types of electronic business (e-business) with others SME into the Hub. Electronic commerce applications like e-services must support the interaction between different parties participating in a commerce transaction via the network, as well as the management of the data involved in the process. The Internet provides access to a large and diverse body of such applications. For the supplier’s viewpoint, the variety of available applications generates new business opportunities for providing new services by integrating, enhancing, or customizing existing commerce applications (Eyal, 2001): • • •. Comparative services are obtained by integrating several sources, providing the user with a uniform interface for posing requests. Integration of complementary services may also be a useful. Existing applications may also customized for special needs.. Unfortunately, the diversity of applications in each specific domain and the disparity of interfaces renders the integration and manipulation of applications a rather difficult task: application data (e.g. store catalogs, form attributes, orders information) may have different formats, making the collection and comparison of data complex. In addition, the application flow, the roles of the various actors participating in the applications, complication the coordination of activities performed in the component applications (Eyal, 2001). The Hub architecture provides a scenario for heterogeneous information integration. The purposed number of SME that will be integrated into the Hub (near 200) represents a great diversity of heterogeneous information that could be founded in enterprise legacy system. Even within a SME, is common to found a Visual Basic accounting system, a FoxPro inventory application or a web-based J2EE sales intranet module.. 9.

(20) The integration of this information with the e-Services Hub should be possible, but is necessary to combine different technologies like Enterprise Application Integration (focusing in B2B integration), Service Oriented Architectures and Software Generation. 2.2 Enterprise Application Integration Business-to-Business (B2B) applications based on information systems’ interoperability are increasingly available over Internet. These emerging systems involve the exchange of both data and services among business information systems. They have created many challenges, including the need for novel interoperability techniques and architectures. Emerging B2B integration approaches must answer several questions: 1) how to process and share data in various business formats; and 2) how to integrate various business functionalities into Web services (Nicolle, 2003). For this purpose is described the Application Integration concept to solve diverse problems of systems integration and heterogeneous information. Application Integration (AI) is a strategic approach for binding many information systems together, at both the service and information levels, supporting their ability to exchange information and leverage processes in real time. Application integration can take many forms, including internal application - Enterprise Application Integration (EAI) - or external application integration -Business-toBusiness application integration (B2B). AI involves a combination of issues. Each organization and trading community has its own set of integration issues that must be addressed. Because of this, it is next to impossible to find a single technological solution set that can be applied universally. Therefore, each AI solution will generally require different approaches (Linthicum, 2004).. Figure 2.2. Application integration problem domains (Linthicum, 2004). 10.

(21) For example in Figure 2.2, a business process is represented as a set of steps to be accomplished. Every step may require information from different applications, and in some cases applications need to interact and share information with other applications or Web portals. Business-to-Business integration occurs when companies integrate their own business processes with those of their business partners to improve efficiency within a collaborative value chain (Lam, 2004). Examples of B2B applications include procurement, human resource, billing, Customer Relationship Management (CRM) and supply chains (Medjahed, 2003). In fact, effective and efficient supply chain integration is vital for competitiveness and survival of organizations and with the emergence of the e-Business era, supply chain needs to be able to extend beyond the traditional boundaries (Siau, 2004). Whether or not they follow these specific patterns, all of today’s e-business solutions draw heavily on AI requirements to integrate Web-based systems with each other and with heterogeneous middle and back end legacy systems belonging to the organization its business partners, or other service providers (Lam, 2004). According to (Lam, 2004) without a well-structured, systematic approach, AI projects become dangerously unpredictable and risky. That is because in the IT industry exist the basic lifecycle processes for developing new systems (for example, the classic waterfall model and prototyping) but relatively few have structured approaches that can apply to AI-intensive projects. Interoperability is generally hampered by heterogeneity issues. Platform (hardware, software, communication) heterogeneity is resolved by communication standards and protocols such CORBA, IP and HTTP. Syntactic heterogeneity requires common or pivot metamodels to represents the data of the participating systems. Finally semantic heterogeneity, which difficult to tackle, requires semantic models and languages that can capture the meaning of the representation concepts of different information systems (Nicolle, 2003). 2.3 Related projects A number of tools for application integration have been developed in order to satisfy specific needs in electronic commerce or business-to-business environments. These software tools allow the enterprises or platforms to integrate applications with different approaches and technologies. Visual tool for AI in B2B (Juárez, 2001). This tool was created for SINCOe (“Sistema Integrador de Comercio Electrónico”) developed at the ITESM university. The prototype extracts the databases metadata, allows specify in a visual way the business process and the detailed operations that happen during each process, and the data interchange required for each operation. Finally, source code is generated, based in the specifications of the operations described previously. 11.

(22) Figure 2.3 Visual tool for AI in B2B [Adapted from (Juárez, 2001)] As is seen in Figure 2.3, this visual tool applies the integration at the data level, at method level through a ORB (“Object Request Broker”) technology, in this case, CORBA, and at application execution level. By means of the visual integration tool uses the specification of operations to achieve the interaction between applications, object methods and data storages, and produces automatically the implementation code through a code generator. XML Based Framework for EAI (Pendyala, 2003). This framework is a template that can be applied repeatedly to different EAI situations. It suggests an open architecture and spans the four crucial areas for EAI: communication, data, process and monitoring. EAI Framework. UI. UI. CRM XML Business interface Logic. Inventory XML Business interface Logic. Integration Engine (translation and messaging). Event Editor. Process Editor. Events repository. Process repository. ERP XML Business interface Logic. UI. Billing XML Business interface Logic. UI. EAI Portal. Figure 2.4. Components of the EAI framework [Adapted from (Pendyala, 2003)]. 12.

(23) The application integration architecture revolves around the envisaged framework. Figure 2.4 gives an overview of the components of the framework. As can be seen, the framework is XML-based where the EAI is achieved through XML and related technologies, the components of the framework are (Pendyala, 2003): a) A XML interface, which is part of the enterprise applications, b) Enterprise Integration Engine, which handles the core functionality and, c) EAI portal, used to configure and define events and processes. The XML interfaces of the applications handle DBMS to XML conversion and vice versa, while the Enterprise Integration Engine transforms XML data in one format to the other, based on the inputs statically generated from event and process editor. XML as event Data. JDBC. XML. XML. JSP. JDBC DOM. Data. DOM XSLT CRM vocabulary. ERP vocabulary Stylesheet. Figure 2.5. Information heterogeneity with XML integration [Adapted from (Pendyala, 2003)] The figure 2.5 shows the management of information heterogeneity of the framework. The design of the framework can be better described based on a scenario. For instance, is considered the scenario of a retail seller of consumer electronics, such as PC’s. When a new order comes in, the customer information is entered through a Customer Relationship Management (CRM) system interface. Purchase Order details and customer details are updated in the CRM database, by the CRM application. The framework extracts the product information from CRM database and generates corresponding XML mapping file. An AI Engine of the framework, driven by the XML process data generated by a process editor, it takes this XML file, transforms the required data fields and passes them over to the XML interfaces of other applications (Pendyala, 2003). Through this approach (and technologies), is possible to generate a common information for several heterogeneous systems by accessing and retrieving data from different sources such as CRM, ERP and so on. Toolkit for B2B Applications (Nicolle, 2003). This tool framework, called XTIME, is for the development of business-to-business (B2B) design environments and applications. X-TIME provides a data model translator toolkit based on an. 13.

(24) extensible meta-model and XML. It allows the creation of adaptable semantics oriented meta-models to facilitate the design of wrappers or reconciliators (mediators) by taking into account several characteristics of interoperable information systems such as extensibility and composability. X-TIMES defines a set of meta-types for representing meta-level semantic descriptors of data models found in the web. The meta-types are organized in a generalization hierarchy to capture semantic similarities among modeling concepts of interoperable systems. It is possible use the X-TIME methodology to build cooperative environments for B2B platforms involving the integration of web data and services (Nicolle, 2003). T1. T1. Tn. Set of translators. Translator Compiler Transformation Rule Builder. Translation Layer Integrated XML grammar. Strategic Hierarchy Builder. Grammar Integration Layer BNF + DL. BNF + DL. X-Editor. Specification Layer. A. N. Figure 2.6 Overview of the layer to build a B2B platform [Adapted from (Nicolle, 2003)] Figure 2.6 depicts an example of B2B platform development using X-TIME methodology. It consists of three layers: specification layer, grammar integration layer and translation layer. The specification layer allows local administrators to graphically describe local data model concepts and map them into Description Logic and Backus-Naur Form (BNC) descriptions. The grammar integration layer is used to build the meta-model. It takes as input a set of description logic and BNF files of local systems and produces as output a meta-model in which the local concepts are mapped to meta-types and classified according to semantic similarities. The meta-model is represented as an XML-schema file. The goal of translation layer is to create data model translators to support information and service exchanges (Nicolle, 2003). The X-TIME methodology can be applied to web services to classify and integrate the XML concepts defined in the Web Services Description Language. Related technologies. For several years, many technologies have been available for application integration, for example RPC (Remote Procedure Call) was one of the first technologies used to build distributed systems with serverbased applications. Other important technology is RMI (Remote Method Invocation) that allows the communication between distributed Java objects.. 14.

(25) CORBA (Common Object Request Broker Architecture) and DCOM (Microsoft technology) are component objects models for distributed systems and application interoperability. A clear trend is the movement away from information-oriented to service-based integration. Information-oriented integration provides an inexpensive mechanism to integrate applications because, in most instances, there is no need to change the applications (Linthicum, 2004). 2.4 Service Oriented Architecture A newer technology for application integration is Service-Oriented Application Integration (SOAI), which allows enterprises share application services. Enterprises could accomplish this by defining application services they can share, and therefore integrate, or by providing the infrastructure for such application service sharing. Application services can be shared either by hosting them on a central server or by accessing their inter-application (e.g., through distributed objects or Web services) (Linthicum, 2004). The recently middleware technologies for application integration, such as IBM Websphere, Microsoft .NET Framework, BEA WebLogic, and so on, are being focused in the Services Oriented Architecture, as solution to application integration problems. The SOA approach roots their concept in the web services technologies. Software as service. An emerging approach linked to service oriented architectures is the Service Oriented Computing that is a computing paradigm that utilizes services as fundamental elements for developing applications/solutions (Papazoglou, 2003). The concept of software as a service espoused by SOC is revolutionary and appeared first with the ASP (Application Service Provider) software model. By providing a centrally hosted Intent application, the ASP takes primary responsibility for managing the software application on its infrastructure, using the Internet as the conduit between each customer and primary software application (Papazoglou, 2003).. 15.

(26) Imported web services interface. Web services specification. Web services usage interface Web service client. Service deployment build. buy/build. Web services Implementation (outsourced). reuse/build. Web services Implementation (in-house). Service realization. Web services Implementation (outsourced). Figure 2.7. Service interfaces and implementation [Adapted from (Papazoglou, 2003)] The services are exposed through interfaces. An interface simply provides the mechanism by which service communicate with applications and other services. Technically, the service interface is the description of the signatures of a set of operations that are available to the service client for invocation. As services interfaces of composed services are provided by other services, the service specification serves as a means to define how a composite service interface can be related to the interfaces of the imported services and how it can be implemented out of imported service interface (Papazoglou, 2003). This is shown in figure 2.7. In this sense the service specification has a mission identical to a composition meta-model that provides a description of how the web service interfaces interact with each other (Papazoglou, 2003). The SOC paradigm allows the software as a service concept to expand to include the delivery of complex business processes and transactions as a service (as the e-services in the Hub platform of PyME CREATIVA project), while permitting applications be constructed on the fly and services to be reused everywhere and by anybody (Papazoglou, 2003). This assertion contributes significantly in this research work, because the way as an e-service is conceived is an application accessible through Internet with web portals and by other applications built on fly with the software tool purposed in this document. A web service is a specific kind of service that is identified by a URI and exhibits the following characteristics (Papazoglou, 2003):. 16.

(27) - It exposes its features programmatically over Internet using standard Internet and protocols, and - It can be implemented via a self-describing interface based on open XML standards. Following is described deepest the web service concept and its actors over the service oriented approach. Web Services. A Web service is a software system designed to support interoperable machine-to-machine interaction over a network (Haas, 2004). Services are described by interfaces using a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with XML serialization in conjunction with other Web-related standards. Basically, Web services are deployed on a collection of XML-based standards that provide means for information passing between applications using XML documents. The loose coupling among applications is provided by Web services interfaces. The wide support of core Web services standards by major enterprise software vendors is the key reason why Web services technology promises to make application integration both within an enterprise and between different enterprises significantly easier and cheaper than before. Loose coupling means that not only applications can be implemented on different platforms and operating systems but also that the implementations can be modified without affecting the interfaces (O'Riordan, 2002). To build integration-ready applications the service model relies on the Service-Oriented Architecture (SOA). As explained before, SOA is a relationship of three kinds of participants: the service provider, the service discovery agency, and the service requester (client). The interactions involve publishing, finding and binding operations (Champion, 2002). These roles and operations act upon the service artifacts: the service description and the service implementation (Papazoglou, 2003).. 17.

(28) Figure 2.8. Service Oriented approach [Adapted from (Papazoglou, 2003)] In a typical service-based scenario a service provider hosts a network accessible software module (an implementation of a given service). Figure 2.8 depicts a service provider that defines a service description of the service and publishes it to a client or service discovery agency through which a service description is published and made discoverable. The service requester uses a find operation to retrieve the service description typically from the discovery agency, and uses the service description to bind with the service provider and invoke the service or interact with service implementation. Technology necessary for SOA implementation relies on a common programto-program communications model, built on existing and emerging standards such as HTTP, XML, SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) and UDDI (Universal Description, Discovery and Integration) (Kreger, 2001). 2.5 Supply Chain Integration Because of the fact that PyME CREATIVA project pretends to integrate manufacturing SME’s with in the e-Services Hub, one of the most important electronic service is e-Supply for supply chain management. Then, it is important to define and describe the concept of Supply Chain Integration in order to identify technologies that allow the application integration in this context. An effective and efficient supply chain is vital to the competitiveness and the survival of an organization (Siau, 2004). Supply Chain Management (SCM) is a common strategy employed by business to improve organizational processes by optimizing the transfer of goods, information, and services between buyers and suppliers in the value chain (Singh, 2005). The SCM has surfaced as an important mechanism which streamlines business processes, enhances productivity, and. 18.

(29) reduces costs (Siau, 2004). A fundamental ongoing endeavor of SCM is to foster information transparency that allows organization to coordinate supply chain interactions efficiently in dynamic market conditions (Singh, 2005). R&D. Logistics. Operations Marketing and Sales. Products and services flow Funds flow Information flow. Service. Customer. Customer Relationship Management. Supplier Relationship Management. Supplier. Figure 2.9 Architecture for a Supply Chain (Siau, 2004) Along the supply chain, as the figure 2.9 depicts, the flows of products/services and funds generate a large amount of information that can be used in SCM decision-making. To ensure that this information is accurate, accessible in a timely manner, and of the correct type, a good supply chain information technology architecture, acting as an information enabler, must be constructed (Siau, 2004). With the growth of e-business, SCM systems are gaining popularity. With the emergence of the e-business era, supply chain systems need to be able to extend beyond the traditional boundaries. The enabling technologies for such a supply chain system include XML, DCOM, CORBA, SOAP, .NET and Semantic Web (Siau, 2004). The information integration requirements of the supply chain have created the concept of Supply Chain Integration to resolve commons information sharing issues for supply chain management. The goal of Supply Chain Integration (SCI) is to link up the marketplace, the distribution network, the manufacturing process and the procurement activity in such a way that customers are better serviced at a lower total cost (Siau, 2004). The need for SCI methodologies has been increasing as a consequence of the globalization of production and sales, and the advancement of enabling information technologies (Ball, 2002). According to (Siau, 2004), it is necessary to design a high level architecture in order to reach the integration of extensive supply chains to enable interactions with several actors like suppliers, customers, ERP systems or legacy applications. To cope with this functionality, and individual enterprise system must cast its eye toward a broader view of entire supply chain to achieve external efficiency. Externally, such a system must be able to communicate with different enterprise systems, as well as individual customers along the supply chain that are using. 19.

(30) different platforms, different terminologies, to achieve adaptive collaborations (Siau, 2004).. Company’s Supply Chain System Supplier’s Supply Chain System. B2B Applications. Parts, Services. Other supply chain applications Database and operation management applications. B2B Applications. Customer’s Supply Chain System Individual Customer. Information. Products, Services. Figure 2.10. Architecture of an Integrated Supply Chain [Adapted from (Siau, 2004)] An architectural approach proposed by (Siau, 2004), showed in Figure 2.10, is to place the database systems at the heart of the company system, and chose other critical internal supply chain applications which integrate with the supply chain based on the company needs. Finally, a company’s supply chain can be integrated with other supply chins (suppliers’ systems, business partners’ systems and customers’ systems) using e-business applications. Another similar architectural approach to reach SCI is proposed by (Ball, 2002), and it considers information sharing both the focal organization (intraorganizational) as well as across organizations (inter-organizational). Intraorganizational information sharing employs middleware technology, while collaboration technology is used at the inter-organizational level (See figure 2.11).. Supply Chain Management Supply Chain Simulation Model. Visualization and Decision Model Supply Chain Collaborate. MIDDLEWARE. ERP Module. ERP Module. ERP Module. Figure 2.11. Supply Chain Integration architectural approach Intra-organizational information sharing must take place at two levels: one is at the data level and another is at the business process level. Solutions such as. 20.

(31) RosettaNet interoperate at lower level of abstractions to reach this intraorganizational information sharing, and they relay heavily on the definition of EDIlike (Electronic Data Interchange) standards for the exchange of data, process knowledge, messages, etc (Ball, 2002). For information sharing at the intra-organizational level, middleware components tie together the SCM system with factory ERP systems and retailer ERP systems. The middleware serves as an information backbone to transact and convert data among disparate ERP systems and SCM systems. In the middleware-based infrastructure, the message broker is use to implement distributed transactions and the integration manager is used for business processes execution (Britton, 2001). The middleware provides interoperational services such as transactions, shared directories, persistence, eventhandling, messaging and process execution based on standards, e.g. CORBA and DCOM (Ball, 2002). The protocol and data exchange language and format may come in many flavors including flat file, EDI, HTML and XML (Sokol, 1996). 2.6 Software Generation It is well-know that constructing software from available software modules can lead to higher productivity and quality than developing software from scratch (Jiménez, 2003). To reach a high reuse in software modules are defined the application families, which are groups of applications sharing characteristics but also exhibiting variability in their characteristics (Jiménez, 2003). An application family designed and implemented to take advantage of a common structure, common features, and prescribed variables characteristics is known as a software product line (Weiss, 1999). At this point, it is important to mention that the software tool designed for this work is a code generator for an application family. The family has common features as application integration components or web services calls, but each generated program is different to other, because can be integrated with different e-services and calling different methods of the remote web services. Wrapper Components. Although many legacy applications cannot be easily integrated into a software product line, one approach is to develop wrapper components (Gomaa, 2004). A wrapper component is a distributed application component that handles the communication and management of client request to legacy applications (Mowbray, 1997). A wrapper registers its service with the naming service so that it can receive client service requests. Most legacy applications were developed as standalone applications. In some cases the legacy code is modified so that wrapper component can access it. However, such modification is often impractical because there is often little or not documentation and the original developers are no longer present (Gomaa, 2004). 21.

(32) Web client node. Web service node. aWebClient 1: Web Service Discovery Request. 3: Web Service Request. aWebService. 4: Web Service Response. Web service broker node aWebService Broker 1: Web Service Discovery Response. <<network>>. Figure 2.12. Example of a Web Service broker [Adapted from (Gomaa, 2004)] Consequently; wrapper components often interface to legacy code through crude mechanisms such as files, which might be purely sequential or indexed sequential files. The wrapper component reads or updates files maintained by the legacy application. If the legacy application uses a database, the database could be accessed directly through the use of database wrappers components that would hide details of how to access the database (Gomaa, 2004). For example, with a relational database, the database wrapper would use Structured Query Language (SQL) statements to access the database. Developers can integrate legacy code into a component-based application by placing a wrapper around the legacy code and providing an interface to it. The wrapper maps external requests from components in calls in the legacy code. The wrapper also maps external outputs from legacy code into responses to the component (Gomaa, 2004). Code generators. Software system generators automate the development of software. Generators automatically transform compact, high-level specifications of target systems into actual source code, and rely on libraries of parameterized, plug-compatible and reusable components for code synthesis (Batory, 1997). The primary benefit of any code generator is to reduce the amount of repetitive code that must be produced, thus saving time in the development cycle (Whalen, 1999). Another benefit to this approach is the ability to extend the services generated, enabling the code generator to act as a force multiplier for programmers. Having a code generator synthesize complex code dealing with concurrency, replication, security, availability, persistence and other services for each server object will ensure that all servers followed the same enterprise rules (Whalen, 1999).. 22.

(33) Specification. Code Generator. Generator. Specificator Configuration Access. Specification Access. DB Code. Domain Processes. Metadata Access. Figure 2.13. Example of Code Generator [Adapted from (Juárez, 2001)] Also, by using a code generator, developers can experiment more rapidly with different architectures. Other benefit obtained when using a code generator for the data layer of enterprise architecture may be its ability to deal with evolving technology (Whalen, 1999). In the figure 2.13 is illustrated the relationship between a specification software and a code generator. This component system produces new adapted applications based in the output of specification sub-system (Juárez, 2001). Generators are among many approaches that are being explored to construct customized software systems quickly and inexpensively form reuse libraries. CORBA, for example, and its variants simplify the task of building distributed applications from components; CORBA can simplify the manual integration of independently designed and standalone modules in a heterogeneous environment by generating proxys for client interaction with a server. Generators are closer to toolkits, object-oriented frameworks, and other reuse-driven approaches because they focus on software domains whose components are not standalone, that are designed to be plug-compatible and inter-operable with other components (Batory, 1997). Configuration wizards. Two complementary concepts associated to application construction in a product-line are configuration and composition. A configuration consists in a set of features and their arrangement in defining an application; the set of modules implementing a specific configuration in a composition (Batory, 1998). How the modules can be composed to construct applications from configuration specifications could be determined at module design and implementation time. An approach to build this configuration is presented by (Jiménez, 2003) in his product-line development technique. This approach introduces the concept of configuration wizards, which are tools to automatically synthesize software product. 23.

(34) lines in well-understood domains. A configuration wizard is a tool for application specification and generation from prebuilt parameterized modules called wizlets. A wizlet in a software module specifically designed and implemented to be composed with other wizlets using a configuration wizard as a tool to produce applications in a product line (Jiménez, 2003).. Wizlet repository. Specification interface. Generator. Application. Domain knowledge. Figura 2.14. Configuration wizard’s architecture [Adapted from (Jiménez, 2003)] Figure 2.15 depicts a generic architecture for a configuration wizard. Figure shows how the two parts in which is divided wizlet, are stored in two different containers: a wizlet repository storing the application code part, and the domain knowledge repository containing the verification part of wizlets. A specification interface offers the application developer editing facilities to specify the application at hand. The generator receives application specifications from the developer; translates them to concise representations, verifies their semantic correctness and generates the application by adapting wizlets implementing specified requirements (Jiménez, 2003). The specification interface of a configuration wizard displays a collection of domain features available to the application developer. A wizlet implements a feature and encapsulated semantic information describing its environmental requirements and constraints, and information describing to the wizlet environment. Also, the configuration wizard collects this information to produce the application, and compiles it into executable code (Jiménez, 2003). At this point, the concept of configuration wizard has important influence for the software tool developed in this research work, because this tool has to implement the features of the configuration wizards. In the next chapter, is explained how the design of the software tool matches with the main components of a configuration wizard’s architecture.. 24.

(35) 2.7 Chapter Summary In this chapter the architecture of the eServices Hub was analyzed together with the involved technologies to develop a software tool for application integration within the context of PyME CREATIVA project. Application integration is depicted in a B2B scenario and are described the integration needs by the Hub to communicate external application with the e-Services of the project. Enterprise Application Integration is introduced as an approach for data sharing between information systems. Service Oriented Architecture is presented as the context for developing implementation for Application Integration. The main concepts of Supply Chain Integration are introduced in order to exemplify how Application Integration can be applied in supply chain environments. The visual tool described in the next chapter requires generate code for application integration. Concepts on code generators and how a software generator works are explained, specifically the configuration wizards technique.. 25.

(36) CHAPTER 3. Analysis and Design of the Visual Integration Tool This chapter presents the design process of the software tool for application integration in the PyME CREATIVA project. The first section explains the structure of an e-Service within the Hub platform context and how these e-Services are deployed and integrated into the Hub architecture. Also the section describes how the application integration should be made in order to access to the e-Services business logic. The second section describes the software architecture: the main components to be developed and their relationships. It also describes the tools and techniques used in the visual tool development. The third section details the software analysis process through UML diagrams, including the description of use cases and a set of class diagrams. The last section is an overview of the main components implementation depicting some parts of relevant code.. 3.1 e-Services Hub Context 3.1.1 E-Services Structure In order to present a solution for application integration with the electronic services presented in the last chapter, this thesis introduces the structure implementation of an electronic service (e-service) within the Hub platform. In general, e-Services focus on providing services through the Internet. E-Services have been viewed as Internet-based customer service and online account management services and alternately as an overarching service-centric concept. Synthesizing various definitions, an e-Service is an integrated solution for customized functionalities that are delivered through the Internet (Kim, 2003). The fundamental objective of e-Services is clear: to have a collection of network-resident software applications accessible via standardized Web protocols (HTTP, HTTPS), whose functionality can be easily discovered and integrated into applications or composed to form more complex systems. At a fundamental level an e-Service is considered as an emerging confluence of three distinct technologies: (a) process description formalisms, including automata and workflow; (b) data management (including transforms, mediation, transactions), and (c) distributed computing middleware (Hull, 2003). E-Service components are business modules that represent basic independent e-business service processes or functions such as authentication, authorization, advertisement, negotiation, and process integration (Kim, 2003).. 26.

(37) For its implementation, each e-Service is composed by a set of components by using the eXo portal platform1 core API and components: •. •. e-Service. •. A set of Java web components that contains user interfaces implemented with visual components named JavaServer Faces2. These user interfaces interact with the services stack and business rules engine through action listener classes. A set of user Web components that shows generic information of sessions, site maps, content, tasks, etc. A set of component services that implement views for different services of the platform, like organization service (add users, roles and memberships), workflow services (upload a new business process, cancel a running business process instance), or content management service (add, remove or edit user pages). Portlet Portlet. Portlet. JSF JSF JSF Components Components. User Portlet User Portlet. User Portlet. Service Portlet Service Portlet. Service. Components. Figure 3.1. e-Service implementation within a portal platform Figure 3.1 depicts the components that must be implemented into an e-Service by using a portal platform with a Web container like eXo Platform. This e-Service implementation has a number of modules to develop, beginning with the business processes that must be modeled and deployed to interact with the business rules engine, following with the user interfaces (views) of the Web components by using JSF components and core components of the eXo platform. Another important issue to mention is that the access to these e-Services is done through Web portals. That means, the interaction with the business logic of these applications uses Web pages and an Internet browser as access interface. 3.1.2 Integration level Since the conception of Hub architecture by (Molina, Et. Al, 2006) was a service-oriented design in order to allow external applications, even mobile devices, to interact and integrate information to e-Services deployed within Hub platform. 1. eXo Platform in an Open Source corporate portal and portlet container (http://www.exoplatform.com/) JavaServer Faces (JSF) are a Java Specification Request (JSR-127) that defines a set of visual components for Web applications. 2. 27.

(38) Figure 3.2. Hub architecture - Application Integration Figure 3.2 shows part of Hub architecture (explained in Chapter 2) where is conceived an external access to e-Services implementations through Internet protocols. The principal idea is to provide additional functionality to be accessible through remote integration for external applications. To achieve this required integration it is possible to implement service-oriented mechanisms like Web services technologies. The service-oriented integration is done by defining application as accessible services by other applications. In the Chapter 2 was explained that concept in detail.. Figure 3.3. Web services integration As the Figure 3.3 shows, the mechanisms should allow information’s access for each e-Service’s business logic. Such is the goal of this research work: a visual tool to generate the external integration with e-Services in a service level.. 3.2 Software Analysis 3.2.1 Requirements The main goal of a generator aimed code to integrate legacy applications and in order to integrate them through Web generated code will be deployed at the among the different systems.. at application integration is to produce other platforms with the e-Services Hub services technologies. In this way, the right locations to allow communication. 28.

(39) The principal requirements are: -. Configuration of the visual tool to achieve remote access in order to setup the end points for the Hub web services already deployed. Create integration environments as projects that could be saved or retrieved at any moment. Provide a visual form to specify remote operations contained in web services interfaces. Generate both on-demand web services and clients/wrappers for the visual specification. The software should deploy the generated web services. Generate proxy classes of the generated web services. Compile clients/wrappers.. Each integration project will be binding to an enterprise (through and identifier) because each enterprise has its own information domain within Hub database. E-Services Hub e-Supply Web Service. where enterpriseId = ‘enterprise1’. Business Logic. eHub DB. Figure 3.4 Enterprise’s information domain The figure 3.4 depicts the generated on-demand web service that will implement the access to e-Service’s business logic for that enterprise allowing separate information of each enterprise. 3.2.2 Integrating through Web services Chapter 1 (Section 1.4.1) describes an example scenario for application integration, when an enterprise’s external application must create a report of the work orders to check their status and update its produced quantity. If these work orders were introduced through e-Service web portal, the enterprise applications could have access to this information. A web service could be deployed in order to achieve this application integration.. 29.