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

Transcription

1 Visual Application Integration Through Web Services for e-services Hub-Edición Única Title Visual Application Integration Through Web Services for e- Services Hub-Edición Única Issue Date Publisher Instituto Tecnológico y de Estudios Superiores de Monterrey Item Type Tesis de maestría Downloaded 02/05/ :57:58 Link to Item

2 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 e- Services 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

3 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

4 Visual Application Integration through Web Services for e- Services 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

5 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

6 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

7 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 e- services 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

8 Contents Dedicatorias... iv Reconocimientos...v Summary... vi Contents... vii Index of Figures... ix Chapter 1 Introduction Background The PyME CREATIVA project Problem definition Justification Need of integration Integration complexity Hypothesis Goals Document Organization...6 Chapter 2 Literature Review Hub Architecture and e-services Enterprise Application Integration Related projects Service Oriented Architecture Supply Chain Integration Software Generation Chapter Summary...25 Chapter 3 Analysis and Design of the Visual Integration Tool e-services Hub Context E-Services Structure Integration level Software Analysis Requirements Integrating through Web services Web services interfaces Visual tool architecture...32 vii

9 3.3.1 Architecture definition Tools and techniques Visual Tool Design Uses Cases Class diagrams Interaction diagram Implementation GUI for Visual Specification XML mapping as integration mechanism Integration Code Generator Chapter Summary...50 Chapter 4 Test Case for e-supply service integration e-supply Service overview Process definition Defining the remote operations Generating the integration code Adapting the generated code Chapter Summary...59 Chapter 5 Results and conclusions Results Conclusions Future work Chapter Summary...67 Appendix A. XML files...68 Appendix B. UML diagrams...74 Appendix C. Source codes...78 Bibliography...87 Vita...90 viii

10 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 Service level integration...34 Figure Tools for the visual tool...35 Figure Interfaces of application integration tool...35 Figure Introduction of configuration data...36 Figure Screen of configuration of generic Web services...36 Figure 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 Main packages of the visual tool...40 Figure 3.22 Visual Specification classes...40 Figure 3.23 Data mapping classes...41 Figure Code generator classes...42 ix

11 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

12 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

13 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

14 Clients, suppliers Internet HTTP Server App Server Others access SME portal SME portal SME portal SME portal SME portal Corporative Portals Hub 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

15 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 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 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

16 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

17 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 e- services 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

18 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 e- services 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 Model- View-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

19 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

20 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

21 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-to- Business 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

22 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

23 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 CRM XML Business interface Logic Integration Engine (translation and messaging) ERP XML Business interface Logic UI Event Editor Process Editor UI Inventory XML Business interface Logic Events repository Process repository Billing XML Business interface Logic UI EAI Portal Figure 2.4. Components of the EAI framework [Adapted from (Pendyala, 2003)] 12

24 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. Data JDBC JSP XML XML as event DOM XSLT XML JDBC DOM Data CRM vocabulary Stylesheet ERP vocabulary 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 X- TIME, 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

25 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). Translator Compiler Transformation Rule Builder Strategic Hierarchy Builder T1 T1 Tn Set of translators Translation Layer Integrated XML grammar Grammar Integration Layer X-Editor BNF + DL BNF + DL 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

26 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

27 Imported web services interface Web services specification Web services usage interface Web service client Service deployment build buy/build reuse/build Service realization Web services Implementation (outsourced) Web services Implementation (in-house) 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

28 - 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

29 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

30 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). Supplier R&D Logistics Operations Marketing and Sales Service Customer Supplier Relationship Management Products and services flow Funds flow Information flow Customer Relationship Management 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

31 different platforms, different terminologies, to achieve adaptive collaborations (Siau, 2004). Supplier s Supply Chain System Company s Supply Chain System Other supply chain B2B Applications applications Database and B2B Applications operation management applications Customer s Supply Chain System Individual Customer Parts, Services Information Products, Services Figure 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 Visualization and Decision Model Supply Chain Simulation Model MIDDLEWARE Supply Chain Collaborate ERP Module ERP Module ERP Module Figure 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

32 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

33 Web client node awebclient Web service node awebservice Web service broker node awebservice Broker 1: Web Service Discovery Request 3: Web Service Request 4: Web Service Response 1: Web Service Discovery Response <<network>> Figure 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

34 Specification Code Generator Specificator Generator Specification Access Configuration Access DB Code Domain Processes Metadata Access Figure 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

35 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 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

36 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

37 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 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

38 For its implementation, each e-service is composed by a set of components by using the exo portal platform 1 core API and components: A set of Java web components that contains user interfaces implemented with visual components named JavaServer Faces 2. 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). e-service Portlet Portlet Portlet JSF JSF Components JSF Components Components User Portlet User Portlet User Portlet Service Portlet Service Portlet S e r v i c e 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 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 ( 2 JavaServer Faces (JSF) are a Java Specification Request (JSR-127) that defines a set of visual components for Web applications. 27

39 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 Requirements The main goal of a generator aimed at application integration is to produce code to integrate legacy applications and other platforms with the e-services Hub in order to integrate them through Web services technologies. In this way, the generated code will be deployed at the right locations to allow communication among the different systems. 28

40 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. Web Service E-Services Hub e-supply 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 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

41 Visual tool OnDemand WebService Client Figure 3.5. Application Integration through dynamic web services As the figure 3.5 depicts, the visual tool should be capable to build the necessary code to access the information. This necessary code is defined by zooming to the integration mechanism through Web services technologies. The following figure shows inside this mechanism how is executed a remote operation from a web services container. Server Side (e-hub platform) Web Service //implementation Vector getworkorders() Client Side (External application) Wrapper Proxy proxy = new Proxy() Proxy //remote operation Vector getworkorders() Client remoteobj = Wrapper.getProxy() remoteobj.getworkorders() Figure 3.6. Mechanism for integration through Web services According with the picture 3.6, in the client side, a program client initializes a wrapper instance that encapsulates a set of proxy classes. The proxy classes are a representation of the remote service, defining its operations that can be invoked. In the server side, is deployed a Web service with the real implementation and the business logic of the operation. Therefore, the necessary source code that has to be generated by the visual tool is the following: - A Web service in the Hub platform (server side). - A set of proxy classes. Due the Apache Axis tool can generate proxy code from a remote Web service; the generation of these classes is out of the scope of the visual tool proposed in this work. - A wrapper that instances the proxy classes in a transparent way for the client program. 30

42 - Finally, a client program that invoke the Web service. This client program can be an additional module of an external enterprise application. Besides of this code, the visual tool will generate other type of output in order to deploy and compile the source code. The available remote operations for integration are defined in generic Web services interfaces Web services interfaces To generate web services on demand is necessary to create some infrastructure within the Hub platform. Remembering the Hub platform architecture, there are e-services with several functionalities and business logic implementations. To generate web services on demand it is necessary pre-deploy a kind of web services interfaces (or descriptions) within the Hub platform. Such interfaces are deployed in a Web services container and described in WSDL documents. These web services interfaces are generic and dummy services that will provide the definition (or declaration) of available operations to invoke. They don t implement any business logic. For instance, in the retrieve Work Orders example, this functionality corresponds to e-supply service; therefore a Web service named esupplyweb is pre-deployed into the Axis container implemented within the Hub platform. Hub infrastructure Web Service for e-supply Web Service interfaces Apache Axis container esupplyweb getworkorders() addworkorder(parameters) Figure 3.7. Web services interfaces e-supply Figure 3.7 shows the deployment of Web service interface for e-supply implementation. Through these generic definitions it is possible to retrieve the operation s structure: operation s name, return type, and the list of parameters, the metadata of remote method. For instance, following with the getworkorders example, the esupplyweb web service has a definition of the getworkorders operation. 31

43 3. deploy esupplyweb getworkorders() Visual tool Hub infrastructure Apache Axis container addworkorder(parameters) 1. definition 2. generation 3. deploy e-supply Vector getworkorders() { //business logic for //retrieve WO for an //enterprise Figure 3.8. Retrieving of Web services interfaces This definition will allow the visual tool to build a web service with this operation, but with a real implementation of business logic that could be a database access to retrieve the work orders for an enterprise. Figure 3.8 describes the steps involved in the retrieving process of Web services interfaces that basically consists in three activities: 1. Retrieve and parse the WSDL document, where the generic Web service interface is deployed (through a URI). 2. The Visual Tool generates a Web service code with real implementation of business logic. 3. The Visual Tool deploys the generated Web service into the Hub platform. Also, the visual tool will build the client and wrapper to access this created web service. These invokers (client and wrapper) are automatically adapted and created from generic components. The following sections describe in detail the main components of the visual tool and its general architecture. 3.3 Visual tool architecture Architecture definition The visual tool software has to implements components that allow to achieve the application integration through generated code with Web services techniques. These components are identified and defined in the figure 3.9, depicting the interactions with the Hub infrastructure, the user (developer) and external applications. 32

44 .NET Java Legacy apps Application Integration Web Services Visual specification Hub infraestructure e-service Data mapping Developer Code generator Visual tool scope Figure 3.9. Visual tool s elements Figure 3.9 shows the scope of the visual tool and the main components to be developed. The first component is a Graphic User Interface (GUI) for visual specification of the integration requirements and methods. Basically is a set of forms/screens to introduce information related with application integration. The second component is a XML-data mapping component to define a schema where the integration requirements are saved and could be retrieved. Also, this component allows the creation of integration projects for each enterprise. The last component is a code generator; this component will generate the necessary code to achieve the application integration with web services technologies. The web services are generated in Java code and automatically deployed in the Axis container. For implementing a code generator for application integration in a domain it is necessary to analyze and understand the domain processes or operations. Once operations are identified, it is necessary to define access methods to the information. Visual integration provides the integration developer the necessary elements to build the specification of the information access. In this case, the integration developer just needs to specify the operations in the domain processes through visual selection of information sources (remote operations). 33

45 App Web Service Client Internet E-Services Hub Web Service DB Service level DB Figure Service level integration As described in Figure 3.10, the code generator automatically produces the code (Java for instance) to integrate applications. This code allows web services and clients to interact together through web services mechanism such as SOAP messages Tools and techniques For the prototype construction the software generator uses the following tools: Apache Axis. Is an implementation of a SOAP messaging engine and a Web services container. The Hub infrastructure uses this Web service container for Web services interfaces (explained later) and the on-demand web services generated by the visual tool. SAX. An API to manipulate XML documents. Through this API it is possible to read and write XML documents by following an event-driven parsing method to obtain the document structure. WSDL4J. An API for WSDL documents. This tool allows retrieve the structure of WSDL documents and to obtain detailed information of the Web service described by these documents (i.e. operations, types, descriptions). Castor. A XML framework that allows mapping XML document to Java objects as JavaBeans in order to facilitate the XML management. Each JavaBean is mapped to markup tags with attributes; each attribute corresponds to a property of the JavaBean. Wizards. A component-based development technique. This technique permits adapt generic templates describing a configuration. The generic templates are not executable applications, but once adapted them by a generator, the generic templates are converted to complete and executable applications. 34

46 WSDL4J, Axis Visual specification Castor, SAX Data mapping Code generator Visual tool scope Wizards Figure Tools for the Visual Tool Each technology supports specific main components of the visual tool (figure 3.11), for instance, the Data Mapping component is developed with Castor XMLmapping interfaces and SAX for XML documents manipulation. The Visual Specification is supported by WSDL4J API to retrieve WSDL documents from Axis container. Finally, the Code Generator is implemented with configuration wizards techniques. 3.4 Visual Tool Design The main purpose of visual integration is to provide a simple configuration environment for application integration to the e-services Hub. Visual integration allows application integration by function binding of processes within the domain to specifications of the access mechanism. Application Web services Visual Integration Directives description files Code generator Database Generated code Figure Interfaces of application integration tool 35

47 Figure 3.12 shows the information sources to the visual integration tool: Web service descriptions and directives description. The remaining part of this section describes how the visual integration tool is designed. Visual integration is achieved from the specification of needed operations to perform application interaction through services access, and by automatically producing the implementation code from such specification by the code generator. The visual tool is modeled using UML diagrams which are presented in the following sections. The principal user of the visual tool is a developer, in this case called integrator developer who is responsible to create the integration between the e-services and the external application Uses Cases Use case: Configuration of generic Web Services In this use case (Figure 3.13), the developer configures the set of generic Web services, providing the required information, which is stored and updated in the webservices.xml file. Figure Introduction of configuration data The Figure 3.14 represents the screen where this use case is executed. The screen has a (1) tree of the generics Web services registered in the visual tool. In another section of the screen (2) is possible to add a new generic Web service or editing one

48 Figure Screen of configuration of generic Web services Use case: Login At the Login step, the developer requires authentication for a specific enterprise. The visual tool uses a Web service to retrieve the list of all enterprises that belong to the Hub. Figure Login In the following figure (3.16) is showed the login screen, where the tool shows the list of enterprises (1) belonging the Hub platform. Also, the developer enters a project name (2) for this specific integration Figure Screen of Login The developer also has to type both username and password (3) for the enterprise selected. The authentication process is done by a Web service deployed in the Hub platform, therefore the visual tool acts as client of this Web service in order to secure the use of the information. Use Case: Web service and operation specification The following step to achieve the application integration is to specify the generic Web service and the operation to execute by the program client. Figure 3.17 Web Service and Operation specification 37

49 The figure 3.18 exposes the screen for this input. The screen shows a tree (1) of the generic Web services and its defined operations. The developer makes a click over an operation in the tree and its definition is displayed (2). Then it is possible to select this operation for integration (3) and follow with the code generation Figure 3.18 Screen of Web Service and Operation specification Use case: Code generation The last step for generate the integration is to generate the necessary code both the Web service and the programs of the client side. Figure 3.19 Code generation The developer may independently generate the integration code for any operation by returning to the last screen (Operation selection). The generation code component will take information from the generic Web service and operation description and directives files associated to the operations linked to the Web service and generate the code for Web service mechanism integration. 38

50 Figure 3.20 Screen for Code generation The figure 3.20 presents the screen of code generation step. It is possible to generate clients in Java, C# and Visual Basic 6.0 languages (1). The selection of the language involves the templates adaptations and the creation of the package with the generated source code: the Web service, the wrapper and a client. Once the source code has been generated, the developer can compile and deploy (2) the generated Web service into the Web services container (in this case, the Axis container). Through Axis tools, the visual tool can generate the proxy classes (3) that implement the skeletons of the remote Web service and operation. Finally, the developer can compile and execute (4) both the wrapper and the client in order to test the integration between the client and the remote Web service recently created Class diagrams In order to simplify the description of the principal classes of the Visual Tool, in the figure 3.21 is presented a packages diagram to separate the classes belong to each component and others utilities. 39

51 Figure Main packages of the Visual Tool As the figure 3.21 shows, there exist 5 principal packages that conform the software developed in the proposed solution: - Visual Specification. A set of classes that implement screens. - Code Generator. Sub-model classes for code generation. - Data Mapping. Classes for mapping information in XML files. - Utils. Utilities for WSDL documents, project management, I/O classes. - Templates. A set of files that represents the templates assembled by the Code Generator. Following is described the three main components of the visual tool: Visual Specification, Data Mapping and the Code Generator. Visual Specification The visual specification package comprises a set of forms or screens where the developer introduces information about the integration. Figure 3.22 Visual Specification classes 40

52 The first screen showed by the visual tool is the PrincipalForm class, allowing to developer open or create an integration project. After that, the visual tool shows the LoginForm class where the enterprise is selected, is entered the project name and the username / password authentication. If the authentication is successful, the visual tool shows the SpecificationForm screen, where the user can select the generic Web service corresponding to the e-service and the remote operation of this Web service. The last screen is the GenerationForm where it is possible to select the language for the client of the remote operation. Also, if the selected language is Java, this form allows to compile and deploy the generated Web service and compile both the wrapper and the client. Even, the GenerationForm uses the Apache Axis tools to generate proxy classes (stubs and locators) from a WSDL document. Another screen related with the PrincipalForm is the ConfigurationForm where is configured the set of generic Web services used by the visual tool. Data Mapping The data mapping classes implement the functionality to map information in XML files. These classes define operations that both visual specification and code generation classes use to achieve the complete process of generate code for integration. Figure 3.23 Data Mapping classes 41

53 At the top of the package is ProjectHandler class that allows the retrieving and saving of project (directive files). Once the project is loaded or created, it is possible to manipulate its two attributes: IntegrationInfo and ConnectionInfo classes. The first one involves information for the integration process like operation and Web service. The ConnectionInfo class contains the enterprise, username and the password for authentication. In order to load the generic Web services stored in the webservices.xml file, the ServiceHandler class implements mechanisms to retrieve information from this file. The WSDLParser class read information from each WSDL (specified in the webservices.xml file) like the set of operations, their types and parameters. Then, the ServiceHandler class stored this information in a list of WebService class. Code Generator The package of the code generation represents a sub-model for code generation facilities. Figure Code Generator classes The figure 3.24 depicts an interface named Generator that defines general methods for all subclasses. There exist two subclasses of Generator class: WServiceGenerator and ClientGenerator. The first one defines methods for the generation of a Web service adaptation and it has a subclass named WServiceGeneratorJava that implements the generation functionality for a Web service in Java language including its deployment. The ClientGenerator subclass defines methods for generation of clients. There exist three subclasses for ClientGenerator. The ClientGeneratorJava subclass implements functions for wrapper and client generation in Java language. Both 42

54 ClientGeneratorCSharp and ClientGenerationVBasic implements functions for wrappers and clients in C# and Visual Basic languages respectively Interaction diagram The figure 3.25 shows the basic flow to achieve code generation for application integration through a visual specification and Web services as remote invocation mechanism. Figure 3.25 Interaction diagram As the figure 3.25 presents, the developer begins the flow by opening/creating a new integration project, it throws a login process in the Visual Specification component. If the login is successful, the Data Mapping component returns a project object representing to the opened/created directive file. Then, the developer can select the Web service and the operation that he wants to invoke remotely. The Data Mapping component update both the project object and the directive file. The last interaction occurs when the developer generates the source code according with the directive file. 43

55 3.5. Implementation GUI for Visual Specification One of the main components of the software tool is a visual environment where the user can specify the web service and the operation that wants to integrate with an external system. The visual specification consists in a set of screens allowing the selection of the application integration s information as enterprise, web service and remote operation. - The Login screen filters through an authentication process that the user is authorized to retrieve or modify information for a specific enterprise. - A screen for selection of web service and operation consists in a form that displays a list of web services interfaces (described before) and their operations. The user is able to select a remote operation to invoke. - The last principal screen is for code generation, allowing to user select the language for the client application. User / Developer Login Select remote operation Code generation Figure 3.26 Visual Specification flow Web Service Wrapper Client As the figure 3.26 depicts, the process to specify the complete integration consists in three steps beginning with a login screen, following the web service and operation selection and finalizing with the code generation form. The login step uses some additional features that the visual tool provides like a Web services deployed in the Hub platform to retrieve a list of enterprises that belong to the Hub platform and to authenticate the user/developer that wants to integrate her enterprise. The operation selection step involves the access to XML configuration file (webservices.xml) that declares where the generic Web services are deployed. Then, the screen shows a tree of the generic Web services and the user can select a web service and an operation through a visual selection. <webservicesbean> <webservices name="esupplyweb"> 44

56 <description>web Service for e-supply Hub integration</description> <WSDL> </webservices> <webservices name="emarketingweb"> <description>web Service for e-marketing Hub integration</description> <WSDL> </webservices> <webservices name="ebrokerageweb"> <description>web Service for e-brokerage Hub integration</description> <WSDL> </webservices> </webservicesbean> The last XML code is an example of webservices.xml file, where is declared the set of URI to WSDL documents. These WSDL documents are definitions for the generic Web services mentioned before. The last step, code generation, involves a code generation functionality to produce the necessary code, based on the specified operation in the operation selection step. The code generator component will be explained in the next sections XML mapping as integration mechanism One way to achieve the specification of operation is a directive-based mechanism (Guzman, 2001). A directive is a specification that describes remote operations (e.g., access methods) and parameters for data sources (Guzman, 2001). Such remote operation descriptions are used to automate the operation specification process using the visual integration tool. Directives allow specify access for every parameter which defines the data source. Parameters are stored in XML directives description, by including data type information, field names including remote access interface, IP address and remote operation. Subsequently, these parameters are accessed by the code generator to build the required code for the operations. The directives files in the visual tool are seen as project files because it is possible to open this XML file and recover or save a directive. For a directive representing access to a remote parameter through a Web service interface, the following information is required: Project name Information for authentication and connection o Enterprise to integrate o Username o Password 45

57 Information for integration o Language for client / wrapper o E-Service to integrate WSDL of the generic Web service by including the URI where the web service is located, and is composed by: o Transport protocol (Http, Ftp, File, etc) o Host name or IP address o Port o Relative context of the WSDL (i.e. /axis/services/esupplyweb?wsdl) Operation to execute. o Type of data returned by the operation invocation. o Required parameters for the operation. Name Type Taking the example of the work orders presented before, the directive file for integration through Web services is: <Project name="project1"> <connectioninfo> <enterprise>ipacsa</enterprise> <username>webservice</username> <password>webservice</password> </connectioninfo> <integrationinfo> <language>net</language> <serviceinfo name="esupply"> <WSDL> :8080/axis/services/eSupplyWeb?wsdl</WSDL> </serviceinfo> <operation name="getworkorders"> <return-name>getworkordersreturn</return-name> <returntype>vector</returntype> <inparameters name="releasedate" type="date"/> </operation> </integrationinfo> </Project> This directive specifies an operation named getworkorders, modifying the date parameter releasedate. The operation returns the Vector parameter getworkordersreturn. In this case, the operation access a Web service that resides within an application server implementing http protocol, at the IP address , trough 8080 port, in the /axis/services/esupplyweb context inside the application server. The complete URL specification is 46

58 These previous examples may give an idea of the tasks that should be performed by a visual specification and integration tool using directive description files as input, and the output that should be produced for service level integration. In order to deal with heterogeneity of data types, WSDL documents are commonly deployed with general types that the visual tool converts to specific types. Within the application systems, parameters can be of the following data types: String. Data that represents a succession of ASCII codes. String[ ]. Data that represents an array of String types. Integer. Represents an integer quantity. Float or Double. Represents a floating point value. Date. A time stamp instance. Vector. An array of data objects. Directives represent the basic information necessary to execute operations and their parameters. For every access operation, it is necessary to define a set of directives to identify the parameters involved and the way in which the operation will be executed (Web service). In this way directives are a very flexible mechanism easy to adapt when changes to parameter access are necessary Integration Code Generator The code generator component uses configuration wizards techniques to generate code based on specifications introduced through visual screens and stored in XML directives files. This code generator uses a set of generic templates (known as wizlets) that are adapted by the visual tool according to visual specification of operation to integrate. The code generator takes as input an XML file and parses the directive file to obtain both integration and connection information to adapt each template. Code generator Data mapping Parse directive Adapt service Adapt operation Create and Copy files Web Service Wrapper Client Template Repository Figure 3.27 Code generator description 47

59 As the Figure 3.27 shows, the code generator of the visual tool uses a template repository containing a number of files, mostly pseudo-applications and some deployment descriptors. They have no-valid markup for compilation or execution, but once adapted by the visual tool, it is created a new application with the functionality already implemented. An example of a generic template is the JavaWrapper.temp template presented following: //JavaWrapper.temp import javax.xml.rpc.serviceexception; import localhost.axis.services.%webservice%.*; import java.util.*; public class JavaWrapper { static %Webservice% proxysoap = null; static { try { %Webservice%ServiceLocator my%webservice% = new %Webservice%ServiceLocator(); proxysoap = my%webservice%.get%webservice%(); catch (ServiceException e) {e.printstacktrace(); public static %Webservice% getproxysoap() throws Exception{ return proxysoap; public static void main(string[] args) { try { %Webservice% proxysoap = JavaWrapper.getProxySOAP(); %vars% //%type% = proxysoap.%operation%(%params%); %show_results% catch (Exception e) {e.printstacktrace(); //end of class In the last code is underlined the no-valid markup (percentage symbols % ) where defined identifiers will be replaced by valid code, according with the specification in the XML directive. Taking the last example code and the work orders example, a possible output of the code generator could be the following adapted code: // JavaWrapper.java import javax.xml.rpc.serviceexception; import localhost.axis.services.esupplyweb_montemayor_project1.*; import java.util.*; public class JavaWrapper { 48

60 static ESupplyWeb_montemayor_project1 proxysoap = null; static { try { ESupplyWeb_montemayor_project1ServiceLocator myesupplyweb_montemayor_project1 = new ESupplyWeb_montemayor_project1ServiceLocator(); proxysoap = myesupplyweb_montemayor_project1.getesupplyweb_montemayor_project1(); catch (ServiceException e) {e.printstacktrace(); public static ESupplyWeb_montemayor_project1 getproxysoap() throws Exception{ return proxysoap; public static void main(string[] args) { try { ESupplyWeb_montemayor_project1 proxysoap = JavaWrapper.getProxySOAP(); Vector result0 = proxysoap.getworkorders(); for(int c=0;c<result0.size(); c++){ String[] data=(string[])result0.get(c); for(int i=0;i<data.length; i++) System.out.println(data[i]); catch (Exception e) {e.printstacktrace(); //end of class The last code has been adapted and is ready to compile and execute, the nonvalid markup have been replaced the necessary code. The most important templates are: WebService.temp. Template for the Web service that will be deployed. JavaWrapper.temp. It is a template for a Java wrapper that makes the connection with the Web service created. JavaClient.temp. This template uses the JavaWrapper in order to present an example of how the integration is done. Deployment descriptors. These templates are files for the Web service deployment with in the Axis container. There exist other templates like wrappers in other languages, shell executable files and XML files. These allow the code generator to achieve the complete compilation, deployment and execution of the new generated application (both Web service and wrapper/client). 49

61 3.6 Chapter Summary In this chapter the structure of an e-service was explained, within the Hub architecture context and the way that these e-services are integrated into the Hub platform. A description of how application integration is realized to communicate the e-services with external applications is presented. This information is used to guide the design process of the visual tool for application integration. The software core components of the visual tool: visual specification, XML data mapping, and code generator are explained. The tools and techniques used in the visual tool design and implementation are also described. The software design process is detailed through UML, including the description of use cases and a set of class diagrams. At the end it is described main components implementation by depicting some parts of their relevant code. 50

62 CHAPTER 4. Test Case for e-supply service integration Previous chapters described the technologies necessary for implementing a Hub of e-services and how a visual environment could be used to simplify the integration between the Hub and external applications. This chapter gives more details specific to one e-service in the PyME CREATIVA context for clarifying how the infrastructure described simplify application integration. To show the necessary integration, a common business process is described with the associated applications integrated through Web services technologies. The visual tool is used to facilitate this integration with an external application. 4.1 e-supply Service overview One of the more complex applications supported by the PyME CREATIVA platform is the e-supply service; it is the service that implements more functionality and supports the larger number of business processes. The e-supply service implements the functionality required for Supply Chain Management functions. The principal functions in the e-supply service are: - Configuration of production plant (production areas, lines, work centers, and human resources). - Material stack. - Production reports (dead times, defects and scrap) - Purchase order control. - Quotation processes - Work order control and tracking (material and human resources assignment). Each purchase order has a number of work orders. The supply chain is one of the most important processes in manufacturing enterprises. In the simplest scenario, a supply chain consists in a workflow that begins with a new purchase order submitted by a client enterprise. Each purchase order consists in a list of products that has to be supplied to the client. Each product is associated with a production work order, and each work order uses a quantity of material and is assigned to one human resource. 51

63 Figure 4.1 Simple supply chain workflow The supply chain workflow presented in the Figure 4.1 shows the steps followed to complete a purchase order delivery. The supply workflow ends when all work orders are completed and the products can be delivered to the client. The functions supporting every step implement the correspondent business logic and database access, and have Web interfaces. The functionalities of each step are accessed by the user through Web pages by using Internet navigators (For instance Internet Explorer or Mozilla Firefox), Figure 4.2 Workorders Web interface Figure 4.2 depicts the Web interface for introducing work orders. Using this Web interface, the user can introduce the necessary information to add new work orders to the production plan. The principal information contained in a work order is: - Related purchase order identifier (ID) 52

64 - Work order identifier (ID) - Related product in the purchase order - Release and end date. - Material to use and its quantity - Human resource and work center assigned to this work order. Another main feature of the e-supply service is the possibility of generating graphic reports from work orders information such as: production dead times, scrap, or pieces with defects. One graphic report is shown in Figure 4.3, the graph represent dead times, material scrap or defects in work centers within the production floor. These graphic results can help to make decisions about the effectiveness of machines or human resources. Figure 4.3 Report of Dead Times The e-supply service implements basic functionalities. As a way to offer additional functionality, external applications can be attached. The remaining sections show how the visual tool can be used to produce necessary code to attach extra functionalities by accessing external applications. Supply chain integration (in the PyME CREATIVA context) is necessary when a supplier enterprise member of the Hub platform wants to retrieve information about its work orders in their systems (could be legacies,.net or Java). This could be necessary because clients may want to track their purchase orders submitted through e-supply web interfaces. 4.2 Process definition The access to the e-supply service is described by deploying interfaces to allow an external application produce a graph with the values reported through the 53

65 integration. The example will describe how one external application can use an external module with one function: a report of the material s usage of each purchase order in the production plan. This feature is not currently available in the e-supply service. The visual tool described earlier will generate the integration code for remote access (Web services) to e-supply application deployed within the Hub platform. Figure 4.4. A supply integration process Figure 4.4 shows an UML activity diagram describing the steps involved in the process used to produce the graph (report). The process in itself is very simple but will serve as useful example to describe the functionality of the visual tool in a real integration example. The process begins by retrieving the purchase orders of an enterprise. Then, the purchase order ID is selected. After that, the data about work orders for this purchase and the material information of each work order is retrieved. Once all this information is retrieved, the report will be generated. The numbers in the process depicted in Figure 4.4 refer to the three main activities that represent operations: (1) Retrieve purchase orders, (2) Retrieve work orders (by purchase order) and (3) Retrieve material. Each operation involves one remote operation to invoke: (1) getpurchaseorders, (2) getworkordersbypurchase and (3) getmaterialbyid. To be able to achieve such integration through Web services, the visual tool will: - Generate three Web services each one representing one operation. - Deploy the three Web services. - Generate client examples. 54

66 - Generate proxy and wrapper classes for the server and client side. Client side getpurchaseorder wrapper External report application getworkordersbypurchase wrapper getmaterialbyid wrapper Hub platform Web service Web service Web service DB Figure 4.5. Access to external application through web services Figure 4.5 depicts where the generated code is used and deployed. Also, it gives and overview of a simplified architecture for generic application integration through Web services. The external report application represents the client side of the architecture and the Hub platform represents the Web service provider. In following sections describe the process to generate all these integration artifacts. Code snippets are presented to allow for a better understanding of how the integration is achieved. 4.3 Defining the remote operations The same visual specification described in this section is followed for the three operations mentioned before. In this case, only the first operation (getpurchaseorders) will be described. The first step to generate the application integration through the visual tool is to specify the enterprise and the user/password login information. It is also necessary to specify the name of the project (see Figure 4.6). Figure 4.6. Enterprise selection and login information 55

67 Then the operation that will be necessary for remote invocation is selected. In this case the operation selected is getpurchaseorders, defined in the esupply generic Web service (Figure 4.7). Figure 4.7. Selection of getpurchaseorders operation. The last step involved in the generation process is the integration code for application integration through Web services communication. Due to the scope of the visual tool prototype, it is necessary to create three different projects; one for each operation invoked. Therefore the specification process from project creation to code generation is made for each remote operation. 4.4 Generating the integration code The screen for the last step of the visual tool code generation) is shown in Figure 4.8. First, it is necessary to select the output language (e.g., Visual Basic, etc.). In this case Java is selected as the programming language. This step produces the source files of the Web service and its client wrapper. 56

68 Figure 4.8. Code generation for getpurchaseorders operation In the case of getpurchaseorder operation, it is created the JavaWrapper.java file containing the following implementation: import javax.xml.rpc.serviceexception; import localhost.axis.services.esupplyweblocal_ipacsa_supply1.*; import java.util.*; public class JavaWrapper { static ESupplyWebLocal_ipacsa_supply1 proxysoap = null; static { try { ESupplyWebLocal_ipacsa_supply1ServiceLocator myesupplyweblocal_ipacsa_supply1 = new ESupplyWebLocal_ipacsa_supply1ServiceLocator(); proxysoap = myesupplyweblocal_ipacsa_supply1.getesupplyweblocal_ipacsa_supply1(); catch (ServiceException e) {e.printstacktrace(); public static ESupplyWebLocal_ipacsa_supply1 getproxysoap() throws Exception{ return proxysoap; //end of class 57

69 The last code shows the implementation of a wrapper by using a proxy ( proxysoap ) variable. This proxy code represents the remote object deployed in the Web service container that will be used to call the getpurchaseorders remote operation. A fragment of the wrapper used by the client program is: public static void main(string[] args) { try { ESupplyWebLocal_ipacsa_supply1 proxysoap = JavaWrapper.getProxySOAP(); Vector result0 = proxysoap.getpurchaseorders(); for(int c=0;c<result0.size(); c++){string[] data=(string[])result0.get(c);for(int i=0;i<data.length; i++) System.out.println(data[i]); catch (Exception e) {e.printstacktrace(); For each operation in the example a wrapper and its example client are generated. The report operation substitutes the clients and implements its own wrapper invocations. 4.5 Adapting the generated code To complete the example, it is necessary to use one wrapper for each operation and adapt an application that allows invoke and display the results of the remote Web services calls. Figure 4.9. Application for report generation through Web services The application uses a simple form with a selection list of the purchase orders. It is in the initialization of the form / window when the first remote operation ( getpurchaseorders ) is invoked for retrieving the purchase orders. Figure 4.9 shows the form / window with a combo box component which has loaded the purchase order identifiers. Once selected the purchase order, the application will retrieve the work orders associated to this purchase order (invoking the second operation: getworkordersbypurchase). Then, for each work order, the application retrieves the information about the assigned material (using the third operation: 58

70 getmaterialbyid ). Then, all the information retrieved is displayed in a graphic report (see Figure 4.10). Figure 4.10 Report of Material Usage In this way, all the steps necessary for application integration are finished. The distinguishing characteristics of this example are the combination a set of operations thus being able to perform complex business logic and diverse functionalities. The report application generated in this example can be adapted by an external application by creating a new module or even instantiating the main frame / window of the report. 4.6 Chapter Summary In this chapter the e-supply service is described in detail to show how it implements the functionality for supply chain management within enterprises. A simple scenario presents a workflow of purchase orders containing products that have to be supplied to a client. For each purchase order a set of work orders were assigned to accomplish the production of each product. It was emphasized that work order assignment and tracking is one of the most important functionalities in e-supply service. The data compiled about work orders is important for strategic decisions about production plans, material purchases, machines and human resources effectiveness. 59