Mälardalen University School of Innovation, Design and Engineering November 2014 Master thesis High level design tool integration: the Orchestrator _____________________________________ Jelena Matić Darko Šupe Supervisor: Gaetana Sapienza Examiner: Ivica Crnković Abstract School of Innovation, Design and Engineering Address: Högskoleplan 1 Västerås Sweden Telephone: +46 (0) 21-­‐10 13 00 +46 (0) 16-­‐15 36 00 Web address: www.mdh.se ____________________________________________________________ High level design tool integration: the Orchestrator Today, developers of complex embedded systems are using a number of development tools connected in a tool chain, which do not work together effectively. Our idea is to develop a new component called the Orchestrator and integrate it into the existing iFEST integration framework. The Orchestrator would control all the communication between the tools, that is, it would represent the interface between tools. This thesis deals with tool integration using the Open Services for Lifecycle Collaboration (OSLC) as a core technology. The implementation of the Orchestrator is described to show how the mentioned mechanism works. The analysis of the implementation proved that the concept is worth of further development and showed that the OSLC technology can be used to ease the integration process, although it is still not widely used. Acknowledgements Acknowledgements Firstly, we would like to express our deepest gratitude to our examiner at MDH Ivica Crnković who gave us the opportunity to develop our thesis in cooperation with ABB. Further, we would like to express gratitude to our supervisor at Mälardalen Högskola Gaetana Sapienza for great guidance throughout our master thesis. Besides our supervisor at MDH, we would also like to thank our supervisors at ABB Corporate Research Center Tiberiu Seceleanu and Morgan E. Johansson for giving us useful feedback. Special thanks to Jad El-­‐Khoury from KTH, who gave us a lot of valuable suggestions during the development of the Orchestrator. In addition, we would like to thank Maja Štula, a professor at the Faculty of Electrical Engineering, Mechanical Engineering and Naval Architecture of the University of Split, for giving her best suggestions and believing in us. We would also like to thank our family for sending us lots of love. Special thanks to Maja Matić, for her efforts in proofreading our thesis. Acronyms Acronyms EA HTTP IF iFEST OSLC RDF REST SDK SOA SOAP UI URI WWW Enterprise Architect Hyper Text Transfer Protocol Integration Framework Industrial Framework for Embedded Systems Tools Open Services for Lifecycle Collaboration Resource Description Framework Representational State Transfer Software Development Kit Service Oriented Architecture Simple Object Access Protocol User Interface Uniform Resource Identifier World Wide Web Contents Contents 1 2 3 4 5 6 Introduction .................................................................................................................... 1 1.1 Motivation ........................................................................................................................ 2 1.2 Objective ........................................................................................................................... 2 1.3 Research questions ........................................................................................................... 3 1.4 Contribution ...................................................................................................................... 3 1.5 Research Methodology ..................................................................................................... 4 1.6 Thesis structure ................................................................................................................. 4 State of the Art ................................................................................................................ 5 2.1 Tool integration paradigms ............................................................................................... 5 2.2 Tool integration definition ................................................................................................ 7 2.3 Related work ..................................................................................................................... 9 2.3.1 The Jazz Integration Approach ................................................................................ 9 2.3.2 ModelBus Approach .............................................................................................. 10 2.3.3 Atego Workbench .................................................................................................. 11 Technical background .................................................................................................... 12 3.1 Service oriented architecture ......................................................................................... 12 3.2 Representational State Transfer ..................................................................................... 14 3.3 Resource Description Framework ................................................................................... 16 3.3.1 SPARQL .................................................................................................................. 17 3.3.2 IRI ........................................................................................................................... 17 3.3.3 Literals ................................................................................................................... 17 3.3.4 Blank nodes ........................................................................................................... 17 Open Services for Lifecycle Collaboration ...................................................................... 18 4.1 Introduction to OSLC ....................................................................................................... 18 4.2 Core Concept .................................................................................................................. 19 4.3 Basic OSLC integration techniques .................................................................................. 21 4.3.1 Linking data via HTTP ............................................................................................. 22 4.3.2 Linking Data via HTML User Interface ................................................................... 22 The iFEST Tool Integration Framework ........................................................................... 23 5.1 iFEST Architecture ........................................................................................................... 24 5.2 iFEST concept .................................................................................................................. 25 Orchestrator .................................................................................................................. 28 6.1 Architecture .................................................................................................................... 28 Contents 6.1.1 OSLC Core specification ......................................................................................... 29 6.1.2 Service catalogue ................................................................................................... 29 6.1.3 Core services ......................................................................................................... 30 6.1.4 Repository ............................................................................................................. 32 6.1.5 Graphical User Interface ........................................................................................ 32 6.1.6 Delegated User Interface ....................................................................................... 38 6.2 Implementation .............................................................................................................. 39 6.2.1 Construction of OSLC-­‐compliant Tool Adaptors ................................................... 40 6.2.2 Construction of the Orchestrator Adaptor ............................................................ 45 6.2.3 Database ................................................................................................................ 51 6.2.4 User Scenarios ....................................................................................................... 53 7 Development Environment ............................................................................................ 67 7.1 Eclipse IDE ....................................................................................................................... 67 7.1.1 Eclipse Lyo ............................................................................................................. 67 7.1.2 eGIT ....................................................................................................................... 68 7.1.3 Maven .................................................................................................................... 68 7.1.4 Acceleo .................................................................................................................. 70 7.1.5 WindowBuilder ...................................................................................................... 70 7.2 Apache Derby .................................................................................................................. 70 8 Future work ................................................................................................................... 71 8.1 Versioning ....................................................................................................................... 71 8.2 Orchestrator Configuration Window .............................................................................. 76 8.3 The improvements to the code generator ...................................................................... 77 9 Conclusion ..................................................................................................................... 79 Bibliography ......................................................................................................................... 81 Appendices ........................................................................................................................... 84 Appendix A. Installation Guide ............................................................................................. 84 Appendix B. List of figures ..................................................................................................... 85 Appendix C. List of tables ...................................................................................................... 86 1 Introduction 1 1 Introduction Nowadays system development projects use various tools from different vendors in order to support the process. Their complexity increases with time, which means that the lifecycle process gets more complicated as well. By easing the communication between those tools, products can be developed more quickly and with less effort. In the existing implementations, tools communicate directly to each other (Figure 1.1) using their adaptors, i.e. they communicate in pairs. This implies that a pair of tools has a certain common standard they follow in order to exchange data. In case we want to add a new tool to the environment, those tools must be adapted so they can communicate with the new one. With every change inside one tool, other tools must adapt to changes as well. This approach is not adequate since it takes an enormous amount of time and effort for that kind of the environment to function properly. By standardising the communication between the adaptors, new tools can be introduced to the framework without great effort. Figure 1.1: Point-­‐to-­‐point communication 1 Introduction 2 1.1 Motivation The motivation behind this thesis is to make the tool integration process quicker and less expensive. The existing iFEST [14] integration framework developed by ABB uses the Open Service for Lifecycle Collaboration (OSLC) technology [22] to standardise the communication between the tools in the framework. By using a common standard, tools can be integrated more easily. This solution, however, has one problem – tools communicate in pairs. Since their communication is not organised, it cannot be tracked. In order to solve this issue, a component, called the Orchestrator, should be added to the existing iFEST integration framework. The Orchestrator would control the cooperation of tools during the life-­‐cycle process of an embedded system product. It would serve as a common interface to all other tools and manage all communication inside the framework. Figure 1.2: Communication through the framework 1.2 Objective The thesis is divided into two parts. In the first part, we provide a theoretical framework where we state that the tool integration and the OSLC standard represent an accepted approach in the area of tool integration. The theoretical research is based on previous studies in this area, as well as on published articles listed under Bibliography, and specification provided by ABB CRC. The offered specification for the implementation of an OSLC-­‐compliant tool, called the Orchestrator, is not fully completed, but it outlines the basic concept. In the second part of this master thesis, we present a practical implementation of the Orchestrator and Tool Adaptors. 1 Introduction 3 1.3 Research questions The main area of research is divided into a set of three questions which need to be answered in order to get a full insight on how various tools can communicate through the Orchestrator. Research Question 1: Is it possible to develop the Orchestrator following the OSLC standard? Research Question 2: How will the communication through the Orchestrator differ from a traditional tool2tool communication and what benefits will the communication via the Orchestrator bring? Research Question 3: Will it be more valuable to develop versioning system through the OSLC Configuration Management specification instead of traditional development through the central repository? 1.4 Contribution In this thesis, we proposed and explained the practical implementation of the Orchestrator. The Orchestrator was defined as the central tool that would control the cooperation of tools during the life-­‐cycle process of an embedded system product and manage all communication inside the framework. In regard to the research questions stated above, our contribution is: 1. We have proved that it is possible to develop the Orchestrator as the OSLC-­‐compliant tool. As the starting point of our research, we developed a pilot project where our implementation deviated from the OSLC standard, but in the end that realisation led us to the right approach. Once the Orchestrator core resources were identified, it was easy to generate the adaptor skeleton by using Lyo Code Generator [15]. 2. Instead of traditional tool2tool communication, we have proposed the communication through the Orchestrator. The development of the Orchestrator provides common framework through which all communication between tools is done. This solution is more efficient compared to tool2tool communication and in the future it will provide the possibility for selecting hardware or software solutions and changing the decision later with minimal re-­‐design effort. 3. Instead of traditional central repository, we propose the development of the versioning system that follows the OSLC Configuration Management specification. In that way, the Resource Description Framework (RDF) representation of artefacts can only be exchanged. The tool with corresponding adaptors will be able to fetch representations and convert them back to the real artefacts, as described in Section 8.1. 1 Introduction 4 1.5 Research Methodology The main objective of the thesis was to investigate possibility of tools communication using a common orchestration adapter. Our research includes the following steps: 1. analysis of existing literature in the area of tool integration 2. finding a solution based on theoretical research and practical efforts 3. construction (design and implementation) of a prototype that provides specified solution 4. feasibility demonstration of the implemented tool using different user scenarios The process (steps 2-­‐4) was performed in several iterations to achieve an acceptable level of the feasibility. Our research was based on the existing Open Services for Lifecycle Collaboration (OSLC) [22] standard for tool integration. The components developed for the verification of our research were two tools called Tool A and Tool B and the Orchestrator component which were made from scratch. 1.6 Thesis structure This thesis report is structured as follows: In Section 2, the state of the art in tool integration is presented. In the first part, the concept of tool integration is defined based on an existing bibliography. In the second part, already available solutions in the area of tool integration are described. In Section 3, the service – oriented approach and all the techniques that have been used in this thesis are presented. In Section 4, a brief description of the OSLC standard in terms of a standard which is used for standardisation of the communication between the tools in the existing framework is given. In Section 5, based on existing literature, the iFEST integration framework is defined as a general tool integration framework for hardware-­‐software co-­‐design of heterogeneous and multi-­‐code embedded systems. In Section 6, the Orchestrator architecture is proposed and the detailed implementation of the OSLC Orchestrator adaptor is presented, as well as of the OSLC-­‐compliant Tool adaptors. In Section 7, environment used throughout the development phase is described. In Section 8, possible future work is discussed and new ideas for the development of the versioning system are presented. In Section 9, conclusions are drawn about the possibility to have a central component managing the tools in the framework. 2 State of the Art 5 2 State of the Art Every product has its lifecycle which begins with the concept and, as presented in this thesis, ends with the finished product entering the market. In every case, time spent on transferring the concept into the final product has a crucial role, observed from financial and many other aspects. The main goal of every project is to get the product pushed to the market in the shortest amount of time possible while keeping its quality at high level. Today, there are many software tools which were developed to support the lifecycle process and shorten that time. For example, there are tools for managing the list of user requirements and tools for modelling. By integrating these tools, the time to the market drastically shortens. What does actually mean to integrate tools? We say that the tools are integrated provided they can exchange data. Thus, requirements can, for instance, be sent to the modelling tool. The user of the modelling tool can use those requirements and make corresponding models. The requirement is bound to the resulting model and can be tracked throughout the whole lifecycle process. There are many more tools which can be integrated, e.g. tools for validation of the user code by running test cases, tools for checking the syntax of the code, etc. So far, tool integration has not been standardised, and tools are being integrated in different ways. Tool integration [27] can be designed on the same platform, by creating an integrated development environment. In that way, tools follow the platform’s guidelines and use common components. Nevertheless, this approach does not provide enough flexible data used for integration of tools and it is not suitable solution for tools built on different platforms. As their complexity increases, integration of tools using traditional platforms becomes less maintainable. As an alternative solution, the Open Services for Lifecycle Collaboration (OSLC) [27, 22] has been proposed. The OSLC enables tools to cooperate uniformly by sharing their data. The specification introduces Linked Data, described in Section 4, as a primary technique for tools integration. In the following Section, we provide explanations for two different tool integration paradigms and the tool integration definition by Wasserman and Thomas and Nejmeh. In Section 2.2, Jazz Integration Approach, ModelBus approach and Atego Workbench are described. 2.1 Tool integration paradigms Every system development process is composed of a number of clearly defined phases which use different tools. Therefore, various tools can be integrated using the framework integration or point-­‐to-­‐point integration. There are different definitions of the tool integration in the 2 State of the Art 6 literature, but most common definition is that the integration represents relationship between tools and other elements in the environment. In the point-­‐to-­‐point integration, tools communicate directly with each other. The number of interconnections with N tools is given by equation N ( N − 1) / 2 . Hence, for five tools displayed in Figure 2.1, ten interconnections need to be implemented. Figure 2.1: Point-­‐to-­‐point tool integration In practice, this often means that different adapters need to be implemented. Every tool must be able to convert its internal data into the format which can be read by some other tool. The main problem is the number of connections between tools, and number of implemented adaptors, since the standard for exchanging the data is not used. On the other hand, the framework integration decreases the number of interconnections and reduces the complexity of implementation. Tools are connected to a common framework and communicate through it, as it is shown in Figure 2.2. Figure 2.2: Framework tool integration 2 State of the Art 7 2.2 Tool integration definition One of the earliest articles on the tool integration is written by Wasserman [1]. He identifies five types of integration: platform integration, presentation integration, data integration, control integration and process integration. Platform integration deals with common framework services used by tools. The basic issue for an integrated solution is that the different tools must be interoperable. Presentation integration is related to user interaction. New tool users are capable to make certain assumptions about how to use the tool and how will it operate to defined inputs. Data integration is concerned with the interchange of data between tools. Every tool can insert, modify and access data produced by other tools through shared repository. Control integration deals with the interoperability of tools in the way that each tool has possibility to influence the behaviour of other tool. Process integration is concerned with the role of tools within the entire software process. The process management tool is used to manage and monitor the other tools in the framework. Wasserman concludes that the key issue within the tool integration is the ability to establish the proper level of integration and to find a set of conforming tools for the chosen level. In addition, Wasserman defines three-­‐
dimensional space of tool integration, as it is shown in Figure 2.3, where the axes of the graph illustrate presentation, data and control integration. It is evident that tools T1 and T2 in the following graph cannot be integrated because they do not agree in any of three dimensions. Here, the key issue of tool integration becomes visible: minimal tool integration requires a set of tools to agree on at least one dimension and effective tool integration requires a set of tools to agree on all three dimensions. Wasserman ends by suggesting that all tools need to be implemented using layered approach and that integration needs to be managed through standards where all tool manufacturers must agree on common mechanism. Figure 2.3: Three dimensional space of tool integration [1] 2 State of the Art 8 Thomas and Nejmeh, based on Wasserman´s work, [2] give an accurate answer to the question what tool integration means by extending relationships between tools. They describe tool integration as a property of tool relationships with other tools in the environment. Tool integration considers the extent to which tools agree, and understanding it will help us design better tools and integration mechanisms. In their approach, they discard platform integration and expand Wasserman’s three-­‐dimensional space with process integration, as shown in Figure 2.4: • presentation integration – to improve the effectiveness of the client’s cooperation with the environment, authors identify properties of appearance and behaviour • data integration – data consistency, interoperability, synchronization, non-­‐
redundancy and similar properties are established to allow users to easily share data between tools and to recognize the level of redundant data • control integration – to grant the adjustable combination of environment functions, properties of appropriate “provision and use” are identified • process integration – to ensure that tools collaborated adequately in support of a defined process, authors identify the property of a process step, process event and process constraint. Figure 2.4: Types of tool relationship [2] 2 State of the Art 9 2.3 Related work This Section describes similar tool integration approach, such as JAZZ Foundation, ModelBus and Atego Workbench. Here, we shall state the pros and cons of each approach, and explain the basic structure of their frameworks as well as all similarities with iFEST approach. 2.3.1 The Jazz Integration Approach The Jazz Platform [16, 17] is one of the modern tool integration platforms built on OSLC. Jazz platform is a team collaboration tool by itself and it starts with the needs of team collaboration and project management in software development. It comprises architecture and a set of application frameworks, toolkits and building blocks. The Jazz Integration Architecture empowers different tools to be used together in an integrated environment. Different tools can share data with similar functionalities using OSLC resources, separating implementation of tools from the definition of the data. Jazz architecture is based on two basic concepts: Linked Data, which use standard interfaces and methods to establish links between data, and Integration services, which provides capabilities for all lifecycle tools. Linked data concept is built on Open Service for Lifecycle Management (OSLC) approach which consists of Providers and Consumers. An OSLC Provider represents a tool that exposes data to other tools as described in OSLC specification, and an OSLC Consumer is a tool that approaches other tool data through its interface. The central part of Jazz Integration Architecture is Jazz Team Server providing core services which enable different tools to work together. All core and specific services are implemented as RESTful web services where all communication between tools goes through REST API using standard resource definition. The Jazz Platform is designed to support integration of different tasks across the software lifecycle, to simplify team collaboration and coordination, to support globally distributed development teams, and to facilitate teams to build software more effectively. Figure 2.5: Jazz Team Server [16] 2 State of the Art 10 Following the principles of WWW, like RESTful resources and semantic data in RDF, Jazz developers built robust integration between different tools and produced a set of tools which provide better traceability across the lifecycle of application [17]. Today, Jazz represents an outstanding, scalable and extensible team collaboration platform with full integration support of IBM´s Rational products. Furthermore, an open community is built, thus, making it possible to see Jazz – based products. Therefore, with the development of community, Jazz will perhaps become the industrial standard for team collaboration and coordination. 2.3.2 ModelBus Approach ModelBus [7] is an integration solution based on the Web services providing services such as model storage and version management. ModelBus discusses everyday problems in software development process, e.g. inconsistencies between artefacts, small amount of automation, deficient common terminology and complexity of the systems. The key concept for tool interoperability is the existence of virtual bus and the way it processes the data transmitted via the bus. ModelBus communication platform associates different services provided by tools connected to ModelBus. Its architecture is built on SOAP web services, following SOA approach. ModelBus offers a service registry and notification service as core services and, by using the Orchestrator tools, automatically executed workflows can be defined. ModelBus contains one central repository, called Model Storage, for sharing the models between various tools and providing the traceability of different models. Additionally, it contains verification service which is responsible for verification of intermediate modelling results and transformation service which can be used to transform the results produced by one tool to be adaptable for purposes of another tool. Figure 2.6: ModelBus Approach [7] 2 State of the Art 11 In the modelling context, ModelBus is one of the most important approaches built on transformations and models in order to create a tool chain. ModelBus does not provide any support to simplify the development of tool adaptor and gives only basic support for other integration efforts. Furthermore, all providing services are developed directly on application servers what implies the complexity of managing services of the tool adaptors. 2.3.3 Atego Workbench Atego Workbench [26] is another tool integration technology built on thin client architecture which enables collaboration, information sharing and traceability between different tools. As opposed to the Model Bus approach, all providing services are running on the servers. Atego provides rich User Interface where users can update different artefacts or configure a set of user role based access to a number of tools, etc. It provides the ability to manage the reusability of artefacts within and across projects while reducing the costs of the development. Additionally, Atego eliminates the need for point to point integration by using fully integrated, collaborative deployment framework. The framework contains one common multi-­‐user repository for sharing various data, and it is built on Configuration Management. This integration solution is good for integrating some of known applications to users because it allows them to spend more time engineering and less time on administration, but still it does not provide general tool integration solution. 3 Technical background 12 3 Technical background 3.1 Service oriented architecture A service-­‐oriented architecture, abbreviated SOA, is essentially a collection of autonomous interoperable services. Services are units of functionality with unambiguously defined and implementation independent interfaces. These services can either pass simple data to each other or coordinate some activity. Each service interaction is independent in regard to other interactions and protocols of the communicating devices. Due to its platform independence, clients from any devices using any operating system can use the service. SOA provides great reusability in a way that every client can use arbitrary number of units of functionality. Every service that functions as a part of SOA needs to fulfil the requirements shown in the following table. Requirement Statelessness High cohesion Loose coupling Local transparency Document-­‐oriented Metadata-­‐driven Table 3.1: Service requirements Description Separate services from their state data whenever it is possible Strengthen the bonds between the responsibilities of a single component Decrease dependencies between components Every consumer can invoke a service regardless of its location inside the network It is necessary to send data between services as documents Services are complemented with metadata by which they can be properly described and organised SOA is usually built using different web services standards, such as SOAP, REST, etc. OSLC (Open Services for Lifecycle Collaboration), described in Section 4, follows the REST architectural pattern which depicts principles by which data can be transmitted over the HTTP protocol. By using Representational State Transfer, beneficial properties of services, like performance and scalability, are increased. 3 Technical background 13 Figure 3.1: SOA Conceptual Model SOA relies on three entities: Service Consumer, Service Provider and Service Registry. The Service Consumer consumes the service, i.e. the functionality the service offers. Different functions within the service are called for different functionalities. The consumer can directly call the service provided he/she knows its location. Provided that the service location is not known, the consumer can look up its location in the Service Registry. The Service Provider accepts and executes request received from the consumer. It contains service implementation and its description. The Service Registry is a network directory which contains addresses from all the available services offered by service providers. It stores and publishes service contracts of different providers, and provides them to interested service consumers. A Service Contract describes the way for the service consumer to interact with the service provider in order to use the service provided. It contains information about the message format, quality of service and conditions that need to be fulfilled before the service can be consumed. SOA has many advantages that can be useful both in entrepreneurial business and IT areas. Some of its advantages are business decision improvements, employee productivity improvements, easy integration of customer and supplier systems, more productive, flexible, manageable and secure applications and smaller developing expenses. 3 Technical background 14 3.2 Representational State Transfer Representational State Transfer [25], in further text REST, is an architectural style which consists of a coordinated set of architectural constraints applied to components, connectors and data elements, within a distributed hypermedia system. Hypermedia is an extension of the term hypertext. It is a nonlinear medium of information which includes graphics, audio, video, plain text and hyperlinks. A nonlinear medium is intended to be accessed in a nonlinear fashion, for instance newspapers which contrast with the term multimedia, the superset of hypermedia. Firstly, REST is used to describe desired web architecture, but its other application is important for our purposes, and that is the development of web services. REST is an alternative to other distributed-­‐computing specifications such as SOAP. A web service is considered to be RESTful if it conforms to the REST constraints: 1) Client-­‐server: There must be a uniform interface that separates clients from servers. Clients must not be concerned with the server duties, such as data storage, which remains internal to the server. In that way, the portability of client code is highly improved. On the other hand, servers are not concerned with the user interface or user state. Thus, servers are simpler and more scalable. Clients and servers can also be developed independently, as long as the interface between them is not altered. 2) Stateless: Client data is not being stored on the server between requests. Every request contains all the necessary data, while the session state is held in the client. The session state can be transferred through the server to another service, for instance a database, to maintain a persistent state for a particular period of time and allow authentication. 3) Cacheable: Clients must be able to cache responses. Responses must define themselves as cacheable or not, so to prevent clients from reusing them for further requests. Caching improves scalability and performance by eliminating some client-­‐server interactions. 4) Layered system: The communication between clients and servers may go through several intermediary servers. Intermediary servers improve system scalability by enabling load-­‐balancing and providing shared caches. This is beneficiary for managing the security issues. 5) Code on demand (optional constraint): Servers can sometimes extend the functionality of the client by transferring executable codes. Those can be Java applets and/or client-­‐
side scripts such as JavaScript. This is an optional constraint. 6) Uniform interface: This constraint is fundamental to any REST service. Interface makes it possible for clients and servers to be developed independently. There are four guiding principles to this interface: a. Identification of resources: Every resource is uniquely identified, for example using URIs. The resources are separated from their representations. b. Manipulation of resources through these representations: Representation of the resource is sufficient for the client to make changes to the resource itself. c. Self-­‐descriptive messages: Each message contains all the relevant information on processing the message. 3 Technical background 15 d. Hypermedia as the engine of application state: the client makes state transitions only through actions previously defined by the server. The client does not assume that any particular action is available for any particular resource beyond those described in representations previously received from the server. If a service violates any of the constraints described above, except the optional one, it cannot be considered RESTful. Therefore, web service APIs that adhere to the constraints are RESTful. Main aspects of this type of a web service are: •
•
•
•
•
Base URI, for example http://website.com/artifacts/ An Internet media type for data. The Internet media type is an identifier used on the Internet to indicate the type of data that a file contains. The media type used in this work is the Resource Description Framework (RDF) which is described in the following chapter. Standard HTTP methods – GET, PUT, POST and DELETE Hypertext links to reference state Hypertext links to related resources REST service uses resources which are uniquely identified by their URIs, in other words it uses their representations and manages those using standard HTTP methods. The table below shows what specific HTTP methods do when executed on the URI of the collection of resources, for example http://website.com/artifacts/. GET List the URIs and possibly other details of the collection's members. Table 3.2: Collection URI’s HTTP methods [25] PUT POST DELETE Replace the entire Create a new entry in Delete the entire collection with the collection. The collection. another one. new entry's URI is assigned automatically and is usually returned by the operation. If, on the other hand, we execute the methods on the URI identifying unique resource, like http://website.com/artifacts/artifact1, their behaviour is altered, as described in Table 3.3. Table 3.3: Artifact URI’s HTTP methods [25] GET PUT POST Retrieve a Replace or create the Usually not used. The representation of the addressed number of addressed member is addressed member of the collection. treated as a collection the collection, in its own right and a expressed in an new entry is created appropriate Internet in it. media type. DELETE Delete the addressed member of the collection. 3 Technical background 16 3.3 Resource Description Framework The Resource Description Framework (RDF) is a framework developed by the World Wide Web Consortium (W3C) which is used to describe web resources. The description of resources is called a resource representation. By using RDF, the data can be exchanged independently of their original format, through their RDF representations. RDF was made to be read primarily by machines. RDF uses a construct called a triple to describe data. The triple consists of a subject, a predicate and an object. The predicate can also be called a property. A set of triples is called RDF graph. Figure 3.2: RDF triple Graph consists of nodes and arcs. The subjects and objects are represented with nodes and predicates with arcs. The most appropriate way to describe this is through the next example: <New York> <is> <big>. <New York> <has> <great taxi service>. <Ivan> <lives in> <New York>. <Ivan> <is> <a taxi driver>. <Ivan> <was born in> <Croatia>. One subject can be referenced multiple times. By combining these triplets into a set of triplets, we get a graph shown in Figure 3.3. Figure 3.3: Triples graph 3 Technical background 3.3.1 SPARQL 17 SPARQL is a query language which can be used on graphs like the one shown in Figure 3.3. It is used to query, for example, where Ivan lives. SPARQL is an acronym for SPARQL Protocol and RDF Query Language. It is a type of RDF query language which is capable to retrieve and manipulate data stored in RDF format. 3.3.2 IRI IRI is an abbreviation for International Resource Identifier. It is a generalization of the uniform resource identifier (URI). Unlike URIs, IRIs are not limited to a subset of the ASCII character set but can also contain characters from the Universal Character Set (Unicode/ ISO 10646). 3.3.3 Literals Literals are basic values that are not IRIs. They can only appear in the object position of a triple. In this example literals are “big”, “Croatia”, etc. Literals must be associated with their data types which are defined inside the RDF specification. 3.3.4 Blank nodes A blank node represents a resource that may not be identified by a global identifier. Blank nodes represent resources without stating their value, what makes them similar to variables. They can be found in the subject and object position of a triplet. Figure 3.4: Blank node 4 Open Services for Lifecycle Collaboration 18 4 Open Services for Lifecycle Collaboration The iFEST integration framework consists of lifecycle tools whose goal is to make the product development process quicker and less expensive. Before describing the framework in details, OSLC concept must be explained as it presents the core technology used. 4.1 Introduction to OSLC Open Services for Lifecycle Collaboration (OSLC) is an open community [22], founded in 2008, whose goal is the creation of specification for integrating lifecycle tools. These specifications allow different lifecycle tools to share their data. Examples of lifecycle tools in software development include defect tracking tools, requirement management tools and test management tools. The OSLC community is organised in workgroups where each workgroup represents an OSLC domain. An OSLC domain describes a part of the lifecycle, like configuration management (CM specification), requirement management (RM specification) or quality management (QM specification). Each domain specifies a common set of resources, formats and services that can be used by tools in this domain. All OSLC domains are built on OSLC core specification where core concepts and integration patterns are described. The main goal of each workgroup is to address integration scenarios, define the common vocabulary for individual topics and to create open and public specification of resources. The OSLC is a rapidly increasing community comprised of important companies, such as ABB, IBM, Ericsson, General Motors, Siemens, etc., which work on designing and correcting standards and specifications. Created standards can be used to produce tool interoperability and traceability. The ending goal of OSLC is to improve data usage and process of integration. The OSLC is not the real solution to all integration needs, and adopting OSLC in the framework does not mean that one cannot use other technologies that are not supported by OSLC. iFEST intends to propose extensions to OSLC to meet the needs in the area of embedded systems. The areas of such extensions include specifications for embedded system domains and needs for handling established exchange formats. OSLC does not cover aspects such as transformations, transactions or handling data integration at different levels of granularity which represents the main lack of OSLC and, because of that, deviation from certain OSLC specifications may be necessary. 4 Open Services for Lifecycle Collaboration 19 Figure 4.1: OSLC domains [22] 4.2 Core Concept Key concepts [10] for tool integration provided by OSLC are: a uniform access to shared resources, a common vocabulary and formats and a loose coupling between tools, established through REST architecture. In OSLC, all the information is exchanged using Web services. OSLC Web services are programmes which communicate over a network in a RESTful way, using HTTP as a protocol. Data is usually represented in RDF/XML format. OSLC is based on W3C Linked Data in which separated data sets are linked together. Linked Data concept is created for publishing structured data. It rests on standard Web technologies such as HTTP, RDF and URIs, but instead of using them to provide web pages for human readers, it extends them to share information in a computer readable way. There are several rules provided by Linked Data concept: 1. Use URIs as names for things 2. Use HTTP URIs so that people can look up those names 3. When someone looks up a URI, provide useful information using the standards (RDF, SPARQL) 4. Include links to other URIs, so that they can discover more things In OSLC, data is called an OSLC Resource which represents for instance a model or a test case. Each Resource is identified by a unique URI, and each Resource must be accessed by HTTP commands: GET, PUT, POST using Linked Data principle described above. Also, a Resource must be available in the RDF standard. The resource storage medium is unconstrained by OSLC, it could be stored in a rational database, on disk, a source code system or in any other way. When 4 Open Services for Lifecycle Collaboration 20 describing an OSLC Resource type, OSLC Specifications must provide information listed in Table 4.1. Property Name URI Table 4.1: Basic OSLC properties [11] Type Description String The name of the resource which must be valid as the Local Name part. URI The Uri of the resource definition formed by appending the Name to the end of the Namespace URI in the specification that defines the resource. Likewise, OSLC Specifications may provide a list of allowed or required properties for a particular domain. For each defined property, specification should provide information listed in Table 4.2. Any defined resource, depending on the needs, may have many more user defined properties in practice. Property Name URI Description Value-­‐ types Representation Read-­‐only Table 4.2: Mandatory OSLC properties [11] Type Description String The name of the property which must be valid. URI The URI that identifies the property. String Description of the property. Literal Value can be Boolean, Date Time, Decimal, Double, Float, Integer, String, XMLLiteral. Resource Resource (value is a resource at specified URI). Local Resource (value is a resource available only inside the resource being defined). AnyResource (value is either a Resource or Local Resource). String For properties with a resource value-­‐ type, OSLC specifications should specify how the resource will be represented. True False Unspecified Providers should not permit clients to change the value of a property. Providers may permit clients to change the value of a property. Indicates that domain specification leaves the choice up to provider implementations. 4 Open Services for Lifecycle Collaboration 21 The core OSLC concept [11] is shown in the Figure below. Figure 4.2: OSLC core concept [11] Service Provider Catalogue is the main entity in the concept. It lists multiple Service Providers which are represented as a product that provides implementation of one or more OSLC Services, which may independently implement different Domain specifications. So, Service Provider describes the Services it offers in the form of a service catalogue. The service catalogue functions as a phonebook for services where OSLC Service is represented as a set of capabilities that enable a web client to create, retrieve, update and delete resources managed by ALM product. The catalogue contains all service contracts, allowing the lookup of a certain service provider based on service descriptions it provides. Each Service can provide Creation Factories for Resource creation, Query Capabilities for resource querying and Delegated UI Dialogs in order for clients to create and select resources via (graphical) UI. Query Capabilities and Creation Factories may offer Resource Shapes that describe resource properties managed by the Service. Resource Shapes are essentially the meta-­‐models for Resources and they are not mandatory. 4.3 Basic OSLC integration techniques OSLC specification presents two basic techniques for integrating tools [10]. Both of these techniques are built on the HTTP and RDF standard. The first technique is only applicable when HTML UI is not present and the other technique permits the integration to exploit existing UI. 4 Open Services for Lifecycle Collaboration 22 4.3.1 Linking data via HTTP OSLC defines a general tool protocol for creating, retrieving, updating and deleting lifecycle data based on internet standards, such as HTTP and RDF, using the Linked data concept. To establish connection between data of one tool with the other, HTTP URI of one resource is embedded in the representation of another. 4.3.2 Linking Data via HTML User Interface In “Linking Data via HTML Interface“ technique the URL of the client’s UI is embedded in the representation of another client, instead of a principle where one tool integrates with the other by linking resources to each other. OSLC allows the user to link the resource or see information about resource in another tool. This enables the tool to exploit existing UI and business logic in other tools. In some cases, this principle is more effective and suggests more user function than implementing a new UI and integrating via CRUD methods. 5 The iFEST Tool Integration Framework 23 5 The iFEST Tool Integration Framework The iFEST integration framework is a general tool integration framework for hardware-­‐software co-­‐design of heterogeneous and multi-­‐code embedded systems. It allows tools to be readily placed within the tool chain. Furthermore, it enables tools to exchange data automatically, eliminating the need for engineers to make the transition from the tool in one lifecycle phase to the tool in another. To validate the integration framework, industrial case studies based on tools with V-­‐
model are used. The V-­‐model [23] is a software development process which can be represented as an extension of the waterfall model. It has two separate, converging “streams” of lifecycle activities or phases, together constituting the resemblance of a letter “V”. On the left side, activities related to development are shown and, on the right side, activities concerning verification and validation of the activities from the left side are shown. As we move from the upper part of the model to the bottom, we move from activities dealing with artefacts on a higher meta level, down to tools dealing with more specific system details. Figure 5.1: V-­‐model [23] As we can see in the picture above, the activities on the left side descending down the V become more detailed as we get lower to finally end up in the implementation activity in which 5 The iFEST Tool Integration Framework 24 the system is fully developed. We can also notice dashed arrows which show us that every activity on the left side has a counterpart on the right side that validates and verifies the activity. The left side consists of two major parts: Requirement Engineering & Analysis (RE&A) and Design & Implementation (D&I). In RE&A phase, requirements are defined and a blueprint, which ought to function as the basis of the implementation, is provided. D&I is a set of phases: Architecture, Detailed Design and Implementation. In this phase, we define and develop the components that implement the requirements from the previous phase. The right-­‐hand side consists of Verification & Validation (V&V) activities. It consists of Unit Testing, Integration Testing and System and Acceptance Testing which ensure components are of an adequate quality and behave as expected. The maintenance activities are not considered within iFEST. The centre of iFEST IF represents the traceability between the artefacts in different phases. The dashed arrows in the picture above symbolise the traceability relationship between the development activities and tests. The goal of iFEST IF is to show benefits for tools in all three categories of lifecycle phases. In RE&A, it will show the link between the requirements and actual models and simulations. Requirements can easily be traced through all upcoming phases. In D&I phase, iFEST IF should show the connection between the high level design of the system and its actual implementation components. As for V&V, verification becomes available earlier in the lifecycle and flaws can be detected more quickly what, furthermore, leads to reduced development time and cost. Every tool functioning as a part of the iFEST framework belongs to one of the three categories. Every category defines process patterns, transformations and metamodels for tools. 5.1 iFEST Architecture The Framework consists of tool instances, tool adaptors, IF repository and the Orchestrator [14]. Every instance communicates with the rest of the framework using its adaptor. The adaptor converts all data to common format so that is understandable to all tool adaptors in the framework. The IF Repository is used to store all the relevant data. It contains different versions of published models which are stored in corresponding folders. The last component in the framework, The Orchestrator, is used to provide general services to all tools in the framework. For instance, tool adaptors can register themselves with the Orchestrator in order to receive notifications on newly published IF versions of models from tools they are interested in. 5 The iFEST Tool Integration Framework 25 Figure 5.2: iFEST Tool Integration Framework architecture [14] The IF repository is the main storage of the framework. Every new version of data is stored separately for every tool, in the tool’s unique folder. However, most of the new versions do not include major changes so there is no need to publish every one of them. It is only when the tool user publishes them that it is created in the repository. For that reason, every tool has its local versioning system where it keeps all the versions made. 5.2 iFEST concept The essential concept of iFEST framework is shown in Figure 5.3. Tree fundamental components are iFEST Integration Framework, Tool Chain and Integration Platform [14]. The framework consists of principles, specifications, guidelines and technological space representing technology on which tool implementations will rely. iFEST framework is based on OSLC technology, described in the previous chapter. Various tools with their adaptors, which represent tool interfaces, can be integrated in Tool Chain and Integration Platform. 5 The iFEST Tool Integration Framework 26 The framework consists of the following main building blocks: •
•
Integrated tool – Tool with its adaptor. It can be integrated into a Tool Chain and/or Tool Platform. The adaptor is implemented to be compliant with iFEST Integration Framework. Tool Adaptor – A piece of software which is actually a tool interface towards other tools in the framework. It provides and also consumes both services and data. The services and data are standardised in the Adaptor Specification. Figure 5.3: iFEST fundamental concept [14] iFEST integration framework consists of the following components: •
•
•
•
•
The Technological Space onto which tool integration implementations rely, e.g. communication protocols, data exchange formats, etc. Adaptor Specifications specify the data to be manipulated by Tool Chain and services provided and requested by the tools of Tool Chain. Adaptor Specifications rely on the set of data and services defined in OSLC. Guidelines support specifications for Tool Adaptors and their implementation according to specifications. The guidelines are useful for developers who plan to provide a Tool Adaptor for their tool or use existing services provided by iFEST Tool Adaptors to create value added services. Technical and non-­‐technical Principles define rules for specifications and implementations. Tool Chain is a set of Integrated Tools which form development environment in order to facilitate its product development and maintenance. 5 The iFEST Tool Integration Framework •
27 Integration Platform is a package of Integrated Tools including their adaptors that can facilitate the development of Tool Chain. It also provides tooling support such as SDKs and adaptor generators, as well as tools to help deploy, configure and maintain Tool Chains. Tools provided by the Integration Platform are usually generic and can be of use across many Tool Chains. Considering the fact that the Integration Platform consists of Tools and their Tool Adaptors, the question is what the difference between the Integration Platform and Tool Chains is. The difference can be best explained considering the following two concepts. Industrial organisation, focused on product development, develops Tool Chains and their specific Tool Adaptors, and uses tools as well. An Integration Platform vendor, focused on tool and tool integration, develops a combination of Integration Platforms, tool adaptors and tooling support in order to aid the development of Tool Chains. It has a broader knowledge of a specific domain and can offer reusable Integration Platform to many organisations. A good integration framework needs to support both the developers of Tool Chains and the developers of Integration Platforms. 6 Orchestrator 28 6 Orchestrator The aim of the iFEST project is to define and realise a tool integration framework for hardware-­‐
software co-­‐design of heterogeneous and multi-­‐core embedded systems. To enable the communication between tools, tool adaptors are developed. The adaptor represents an interface between the tools and the framework. By having adaptors which follow the same standard, tools can exchange data regardless of the format data was originally in. The iFEST integration framework made the process of product development much quicker and less expensive. By developing a new component which would manage the communication between the tools in the framework, the time framework of its arrival to the market would be even shorter. This Section explains that component, named the Orchestrator. Its architecture with core services is described, as well as its detailed implementation and some of the possible scenarios of usage, followed by sequence diagrams. 6.1 Architecture The Orchestrator is a tool that manages other tools that are involved in the system, and their respective services offered to the integration network. It registers the tools along with their services and manages tool2service subscriptions. The Orchestrator receives messages from tools and forwards them to the respective registered tools. It also stores links related to traceability and history, with information on tools, files, versions, etc. The components which compose the Orchestrator are shown in Figure 6.1. The Orchestrator uses a repository to store all the relevant data that can be related to the tool or the Orchestrator itself. The tool interoperability across the IF is based on a service-­‐oriented approach, where the Orchestrator and tools interact via services, by “providing” and “consuming” them. In this context, services are considered as means to interact and exchange data between the Orchestrator and Tools operating in the integration network. 6 Orchestrator 29 Figure 6.1: Orchestrator architecture 6.1.1 OSLC Core specification The OSLC Core specification is developed by the Core workgroup to define the basic integration technologies for integrating lifecycle tools. As it was stated before, OSLC specifies resources using URIs, which can be customised using HTTP methods. The Core specification in combination with one or more domain specifications defines OSLC protocols suggested by a domain tool. OSLC domain specification defines additional resource types, but does not define new protocol. In this thesis, OSLC Core Specification Version 2.0 and Change Management Specification Version 2.0 are used. 6.1.2 Service catalogue The Orchestrator and tools interact via consuming and providing services from each other. All the available services offered by the tools in the framework are listed in the Service catalogue which is managed by the Orchestrator. Tools can browse through the service catalogue and subscribe to services they want to. The example of a catalogue entry is given in Table 6.1. Catalogue Entry Service Title Description Table 6.1: Service catalogue entries Tool A Tool B http://localhost:8080/ToolA/1/ http://localhost:8585/ToolB/1/ Tool A_service1 Tool B_service1 This is a service of tool A. This is a service of tool B. 6 Orchestrator 30 6.1.3 Core services The Orchestrator can provide two types of services: Core and Specific services. Core services are the ones that are common for all tools in the framework (e.g. registration, subscription etc.). This group of services is “domain-­‐less”, which implies that services are provided by all tools regardless of the domain they belong to. Specific services are related to the single specific tool and they can vary depending on the tool. In this case, if the tool leaves the framework, this group of services will not be available for other tools anymore. For the tool to be able to join the Integration Framework and work in one domain, it is necessary that all of the core services are offered by the tool. So, the tool has to be core services – compliant to each particular domain. A) (De)Registration: The Orchestrator implementation consists of two registration services: Tool Registration for registration of tools and Service Registration for registration of services offered by the individual tool. Whenever the tool turns up online, it registers itself with the Orchestrator, using Tool Registration service. Tool Registration service manages Tool Registration Resource whose properties are described in Table 6.2. Whenever the registered tool shuts down, it needs to be deregistered. All services provided by the tool which left the framework will be usable for the entire lifecycle time. For more details on Tool Registration service, Tool Registration resource and other core services see Section Implementation. Table 6.2: Tool Registration properties Property Type Description title String The name of the tool being registered. label URI The URI of the tool being registered. The registered tool offers services via Service Registration service and Service Registration resource, whose properties are described in Table 6.3. A list including all of the available services is defined as the Service Catalogue and provided to the Orchestrator. The registered service needs to be deregistered from the Service Catalogue when it is not accessible. Table 6.3: Service Registration properties Property Type Description service URI The URI of the service being registered formed by appending the name of the provided service to the end of the tool URI. title String The name of the service being registered. label String The name of the tool which provides registered service. B) (De)Subscription: After the tool has registered with the Orchestrator and the Orchestrator acknowledges it, the Orchestrator will inform the tool about all of the available services on the Integration Framework, by sending the Service Catalogue. The tool needs to subscribe to the services that it intends to consume. Furthermore, different tools may subscribe to 6 Orchestrator 31 the services offered by other tools. Subscription service and Subscription resource, with the properties listed in Table 6.4, are developed for this purposes. Also, the subscription needs to be updated every time a new service is available. Table 6.4: Subscription properties Property Type Description service URI The URI of the service being subscribed to toolName String The name of the tool that is subscribed to the mentioned service C) Update notification: Every tool has services which expose certain data artefacts, e.g. models. Other tools can subscribe to those services so they can be informed when changes on the artefacts are made in the future. In case the user makes changes to the model managed by the service which has tools subscribed to it, the tools must be informed about the change. That is why UpdateNotificationService is developed. Every time such changes are made, UpdateNotification resource is formed and sent to corresponding tools. Table 6.5 shows properties used in implementation of UpdateNotification resource. Table 6.5: Update notification properties Property Type Description title String The name of the tool from which the update came from. label URI The URI which represents the identifier of the new version that was published D) User notification: Tools, that is, users of the tools must be able to send plaintext messages to other tools as well. That is why UserNotificationService was developed. Every time the user wants to send a notification, UserNotification resource is formed and sent. In Table 6.6 properties used in UserNotification resource are shown. Table 6.6: User Notification properties Property Type Description label String The name of the tool from which the message is sent. description String Notification message. identifier String User Notification resource URI. destination String The name of the tool to which user wants to send a notification. read Boolean Indicates if the notification is read. 6 Orchestrator 32 6.1.4 Repository The Integration Framework contains a repository, which functions as a physical storage location. This may be a distributed physical solution or centralised solution. The repository is also described as “IF Project Disk”. Each tool that operates in the framework has its own directory which contains information related to the development of the project. In addition, all tool directories can be accessed by the Orchestrator. Every time the tool intends to publish any data, it will store it into its own directory. 6.1.5 Graphical User Interface The Java Swing based GUI provides these basic functionalities: identify Orchestrator, register tool, register available services, edit own services, subscribe to the services offered by the other tools, send user notification and send update available notification. The implemented functionalities are shown in Table 6.7. Table 6.7: Implemented functionalities on the tool side Title Swing Controls Orchestrator identification Label/ TextArea Register Button Deregister Button Read Service Catalogue Table Select subscriptions Checkbox/ Table Subscribe Button Edit own services Button/ Table Select own services for Checkbox/ Table offering Send message Button/ Label/ TextArea/ Table/ Checkbox/ TextBox Read user notification Button/ Table/ Label/ TextBox Send updates Button/ ComboBox Read updates Table The Orchestrator graphical user interface enables us to see the service catalogue and the list of registered tools, as well as to send notifications to the registered tools. Also, entries inside the catalogue can manually deregister deleted and registered tools. The prototypes are shown in the next pictures. 6 Orchestrator 33 Figure 6.2: Prototype of Tool Registration Window Figure 6.3: Prototype of Service Catalogue Window 6 Orchestrator 34 Figure 6.4: Prototype of User Notification Window on the Orchestrator side Figure 6.5: Prototype of Update Available Window on the Orchestrator side Within this work, tool GUIs were also developed. They have functionalities such as: register the tool register, register services, send user notifications and send update notifications. Prototype of the Tool graphical user interface is shown below. 6 Orchestrator 35 Figure 6.6: Prototype of the Registration window In Figure 6.6 the Registration window prototype is shown. From here, the tool can register itself and its services. The user checks the services he/she wants to register and presses the “Register” button. The Orchestrator receives the services as a list of ServiceRegistration resources and includes them to the service catalogue. Figure 6.7: Prototype of the Edit Services window Figure 6.7 shows the window which pops up when the Edit own services button is clicked. In this window, the data about all the services can be changed. By clicking on the “Save changes” button, changes that are made are then saved. 6 Orchestrator 36 Figure 6.8: Prototype of the Subscription window In Figure 6.8, prototype of the Subscription window is shown. After the tool has registered itself with the Orchestrator, it receives the service catalogue which is then shown in the Subscription window. The user can check services he/she wants to subscribe to and by clicking the “Subscribe” button, the list of services he/she wants to subscribe to is sent to the Orchestrator. Next two prototypes represent windows for the user and update notification. The User notification window consists of three parts. The first part is the list of all registered tools in the framework. We check the ones we want to send the message to. The second part is the subject field in which we write the subject of our message. The third part is a space where we can write the message. By clicking the button “Send”, the notification is sent to all the selected tools. Figure 6.9: Prototype of the User Notification window 6 Orchestrator 37 The Update notification window contains a drop-­‐down list which lists all the services offered by the tool. We choose the service which manages the artefact in which the changes are made. By clicking the “Send” button, the Update notification is formed and sent to the Orchestrator. The Orchestrator forwards the message to all tools subscribed to the service in question. Figure 6.10: Prototype of the Update Available Notification window 6 Orchestrator 38 6.1.6 Delegated User Interface For each OSLC Resource, Service Provider will include Delegated UI for creation and selection. Delegated UI can accept user input and interact with the tools to select or create resources. To enable clients to create or select the resource via UI, @Oslc:Dialog annotation is used. In the example below, the annotations for the selection dialog are shown. @OslcDialogs( { @OslcDialog ( title = "Change Request Selection Dialog", label = "Change Request Selection Dialog", uri = "/{productId}/changeRequests/selector", hintWidth = "525px", hintHeight = "325px", resourceTypes = {Constants.TYPE_CHANGE_REQUEST}, usages = {OslcConstants.OSLC_USAGE_DEFAULT} ) }) The JSP page selector_dialog.jsp provides the HTML and JavaScript code for Selection Dialog. The form for the user to enter search terms is shown below. <input type = "search" style = "width: 335px" id = "searchTerms" placeholder = "Enter search terms" autofocus> <button Type = "button" Onclick = "search( '<%= selectionUri %>' )">Search</button> </input> Providing a delegated UI dialog for creating new resource is very similar to the process for providing one for selecting existing resources. It is neccesary to create: HTML Form, the fields within form and to set up the server-­‐side handling of the form submission. In the example below, the annotations for creation dialog are shown. Furthermore, the JSP page creator_dialog.jsp provides the HTML and JavaScript code for Creation Dialog. @OslcDialog ( title = "Change Request Creation Dialog", label = "Change Request Creation Dialog", uri = "/{productId}/changeRequests/creator", hintWidth = "600px", hintHeight = "375px", resourceTypes = {Constants.TYPE_CHANGE_REQUEST}, usages = {OslcConstants.OSLC_USAGE_DEFAULT} ) 6 Orchestrator 39 6.2 Implementation The Orchestrator architecture is service-­‐oriented and based on the consumer-­‐provider approach. When we talk about OSLC service providers and consumers, there are three different approaches to implementation. 1)
2)
3)
The Native Support approach implies the direct change of the tool code so to make it OSLC-­‐compliant. The advantages of this approach are a complete control over the quality implementation and a good way to deliver products with OSLC support to tool vendors. On the other hand, it is necessary to have control over the application code, so we need to know the product language and platform, and it is definitely not a good approach for customers who want to add OSLC support to products. The Plugin approach implies adding OSCL support by developing the code which plugs-­‐in to the tool and uses its add-­‐on API. The advantage of this approach is in its use of established and supported mechanism to extend product and add OSLC support. The disadvantages, on the other hand, are plugin limitations which can limit quality of OSLC implementation and the fact that we need to know the product language, platform and plugin architecture. The Adaptor approach is to create a new application – OSLC Adaptor, which runs along with the tool and makes it possible for the tool to handle incoming and outcoming OSLC messages. It serves as an interface between the tool and the other OSLC tools in the framework. This approach can be implemented without modifying the product; it is decoupled from the product itself. It can also use any language and language preferred. However, limitations on the tool API may limit quality of OSLC implementation. We have chosen the adaptor approach for this work since it will not affect existing implementation of the tools in the framework. Implementation will be described in regard to the project three main components: the Orchestrator, Tool Adaptor and Database. The database component functions as a repository where the Orchestrator stores all the information needed for its work. All the resources must be stored in the database in order to be retrievable provided the Orchestrator restarts for some reason. Figure 6.11: Interaction between components 6 Orchestrator 40 6.2.1 Construction of OSLC-­‐compliant Tool Adaptors Figure 6.12 shows the metamodel of OSLC tool adaptor, generated by the Lyo code generator. It can be separated in two parts [15]. The left side contains classes which are part of OSLC core and the right side contains classes that are specific to a certain OSLC domain. Figure 6.12: Tool adaptor metamodel [15]
If we look the left side, the first class we see is the Service Provider Catalogue. It is OSLC implementation that lists one or more Service Provider resources. It can also reference another 6 Orchestrator 41 Service Provider Catalogue. The Service Provider is a resource that describes a set of services offered. The Service describes specific services offered by OSLC implementation. Every Service can provide Creation Factory, Query Capability and Dialog. The Creation Factory describes a creation factory which is capable of creating new resources using HTTP POST. In other words, we can create new resources by simply forming a resource and posting it to the Creation Factory. The Query Capability makes it possible to query resources using HTTP GET or POST method. The Dialog can be used as a delegated user interface which allows users to create a new resource or pick a resource from a list of resources. The Publisher resource identifies and describes the software product that provides OSLC implementation. The OSLC tool adaptor implementation in Java can be divided into four main parts: •
•
•
•
Servlet Resources Services Adaptor manager The Servlet makes it possible for the tool to have the Service Provider Catalogue and creates corresponding Service Providers. It contains a ServletListener class containing methods that are initiated when a context is initialized or destroyed, that is, when the adaptor turns on or off. The Resources package contains classes of all the resources used. The Orchestrator has all the resources implemented: •
•
•
•
•
ToolRegistration ServiceRegistration Subscription UserNotification UpdateNotification The task in this project is to make a tool adaptor that can communicate with the Orchestrator, the controlling component of iFEST framework described in one of the previous chapters. To make the communication possible, the adaptor has to be OSLC-­‐compliant, that is, it should be made in accordance with the OSLC paradigm and the metamodel shown in Figure 6.12. The main operations that the adaptor ought to perform are as follows: tool (de)registration, service (de)registration, subscription, user notification and update notification. This implies that it should be capable of consuming corresponding Services on the Orchestrator´s side. The first thing the adaptor performs is the formation of the adequate resource, depending on the wanted action. After that, it consumes the Orchestrator service responsible for handling that type of resources by invoking HTTP method over it. On the other hand, each tool adaptor that accepts a certain type of resources must implement a service to handle those resources. In those cases, the tool adaptor can accept ServiceRegistration, UserNotification and UpdateNotification. That means that services capable of receiving those resources must be implemented on the side of the tool adaptor. The communication between the Orchestrator and the Tool is shown in Figure 6.13. 6 Orchestrator 42 Figure 6.13: Communication between the Tool and the Orchestrator
In general, when we consider coding a service in Java, @OslcService annotation is used in order to define a piece of code as OSLC service. The annotated class is considered to be the code of OSLC service. Inside the service we define actions for HTTP methods – GET, POST, PUT and DELETE, again using annotations: @GET, @POST, @PUT and @DELETE. These annotations are bound to one method. Code inside the method is executed after the corresponding HTTP method is invoked. By using annotations, we can also define what the method consumes and produces -­‐ @Produces and @Consumes annotation. Every OSLC resource that is managed by the corresponding service is defined as an annotated Plain Old Java Object (POJO) inside Java code. By using OSLC4J, we can obtain their RDF, JSON or XML representation shown below. 6 Orchestrator 43 Services which need to be implemented on the tool side are: A) UserNotificationService: manages UserNotification resources. Every time the user wants to send a notification to other tools in the framework, UserNotification resource is formed and then posted to the Orchestrator. It has an attribute called destination and the Orchestrator forwards the message to the corresponding tools according to it. Tools are then able to accept the message due to UserNotification service implemented on their side. Class property label, description, identifier, destination and read are all attributes of one resource. Every property has its setter and getter what enables the user to form the resource by setting its attributes. Description on UserNotification resource attributes was given in one of the previous chapters. B) ServiceRegistrationService: manages ServiceRegistration resources. This service is mandatory on the tool side because it makes it possible for the Orchestrator to send the service catalogue to the Tool. Service catalogue is composed of a list of ServiceRegistration resources. When the Orchestrator wants to send these to the tool, it uses HTTP POST method and posts the list of ServiceRegistration resources, described in details in one of the previous chapters. The code below shows the part of the service implementation. @OslcService(ToolAdaptorConstants.TOOL_DOMAIN) @Path("serviceProviders/{serviceProviderId}/serviceRegistrations") public class ServiceRegistrationService { @Context private HttpServletRequest httpServletRequest; @Context private HttpServletResponse httpServletResponse; @Context private UriInfo uriInfo; public ServiceRegistrationService() { super(); } @GET @Path("creator") @Consumes({MediaType.WILDCARD}) public void serviceRegistrationCreatorAsHtml( @PathParam("serviceProviderId") final String serviceProviderId ) throws IOException, ServletException { httpServletRequest.setAttribute("serviceProviderId", serviceProviderId); RequestDispatcher rd = httpServletRequest.getRequestDispatcher( "/se/abb/oslc/ta/serviceregistrationcreator_html.jsp"); rd.forward(httpServletRequest, httpServletResponse); } }
6 Orchestrator 44 The ServiceRegistration resource implementation is shown in the following text. @OslcNamespace(OrchestratorAdaptorConstants.ORCHESTRATOR_NAMSPACE) @OslcName(OrchestratorAdaptorConstants.SERVICEREGISTRATION) @OslcResourceShape(title = "serviceRegistration Resource Shape", describes = OrchestratorAdaptorConstants.TYPE_SERVICEREGISTRATION) public class ServiceRegistration extends AbstractResource { private String title; private String label; private URI service; private String description; @OslcName("description") @OslcPropertyDefinition(OrchestratorAdaptorConstants.ORCHESTRATOR_NAMS
PACE + "description") @OslcDescription("service description.") @OslcOccurs(Occurs.ExactlyOne) @OslcReadOnly(false) @OslcTitle("") public String getDescription() { return description; } public void setDescription(final String description) { this.description = description; } }
OSLC4J takes every resource class and, by following annotations, it generates its representation. In this case, RDF representation shown below is generated.
<?xml version="1.0" encoding="UTF-­‐8"?> <rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/" xmlns:rdf="http://www.w3.org/1999/02/22-­‐rdf-­‐syntax-­‐ns#" xmlns:oslc_data="http://open-­‐services.net/ns/servicemanagement/1.0/" xmlns:oslc="http://open-­‐services.net/ns/core#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-­‐schema#" xmlns:j.0="http://oslc.abb.se/orch#" > <rdf:Description rdf:about="http://localhost:8181/orchestratorAdaptor/services/serviceProvide
rs/1/serviceRegistrations/2"> <j.0:service rdf:resource="http://localhost:8080/ToolA/1/"/> <dcterms:title rdf:parseType="Literal">ToolA_service1</dcterms:title> <rdfs:label>ToolA</rdfs:label> <rdf:type rdf:resource="http://oslc.abb.se/orch#serviceRegistration"/> </rdf:Description> </rdf:RDF>
6 Orchestrator 45 C) UpdateNotificationService: manages UpdateNotification resources. UpdateNotification is sent in cases when the user wants to alert other tools in the framework that an artefact, for instance a model, was changed. The tool posts the resource to the Orchestrator. The resource is then forwarded to all the tools which are subscribed to the service exposing the artefact in question. After describing the three relevant parts of OSLC tool adaptor: Servlet, Resources and Services, we come to the last component – Adaptor Manager. Every time the resource is received by the tool, the corresponding service is invoked. The service then calls the Adaptor Manager and its appropriate method. 6.2.2 Construction of the Orchestrator Adaptor On the Orchestrator side, certain services must be implemented: •
•
•
•
•
ToolRegistrationService ServiceRegistrationService SubscriptionService UserNotificationService UpdateNotificationService ServiceRegistrationService, UserNotificationService and UpdateNotificationService were described in the previous chapter. A) ToolRegistrationService: manages ToolRegistration resources. This service makes it possible for the tool to register itself with the Orchestrator. By registering itself, it is capable of registering its services so that other tools in the framework can subscribe to them. Every registered tool is capable of receiving notifications from other tools. If the tool adaptor goes offline, it automatically deregisters. B) SubscriptionService: manages Subscription resources. Every tool which enters the framework by registering itself receives the Service Catalogue from the Orchestrator. The Service Catalogue contains the list of all services offered by the rest of the tools in the framework. The user can then subscribe to the services he/she wants to by filling-­‐in the check-­‐boxes next to the service and clicking the button „Subscribe“. The Subscription resource is created “under-­‐the-­‐hub” for every service checked and then posted to the Orchestrator. The SubscriptionService accepts the list of Subscription resources, and then creates the resources in memory, as well as a database entry for each of them in order to keep the track of subscriptions in the framework. If one of the tool reports changes in an artefact by sending the UpdateNotification resource to the Orchestrator, the Orchestrator uses the list of Subscription resources to send the UpdateNotification to all the subscribed tools. The partial implementation of the SubscriptionService is shown in the following code. 6 Orchestrator 46 @OslcService(OrchestratorAdaptorConstants.ORCHESTRATOR_DOMAIN) @Path("serviceProviders/{serviceProviderId}/subscriptions") public class SubscriptionService { @Context private HttpServletRequest httpServletRequest; @Context private HttpServletResponse httpServletResponse; @Context private UriInfo uriInfo; public SubscriptionService() { super(); } @GET @Consumes({MediaType.WILDCARD}) public void subscriptionCreatorAsHtml( @PathParam("serviceProviderId") final String serviceProviderId ) throws IOException, ServletException { httpServletRequest.setAttribute("serviceProviderId", serviceProviderId); RequestDispatcher rd = httpServletRequest.getRequestDispatcher( "/se/abb/oslc/oa/subscriptioncreator_html.jsp"); rd.forward(httpServletRequest, httpServletResponse); } //... } The implementation of the Subscription resource is shown below. @OslcNamespace(OrchestratorAdaptorConstants.ORCHESTRATOR_NAMSPACE) @OslcName(OrchestratorAdaptorConstants.SUBSCRIPTION) @OslcResourceShape(title = "subscription Resource Shape", describes = OrchestratorAdaptorConstants.TYPE_SUBSCRIPTION) public class Subscription extends AbstractResource { private URI service; private String toolName; 6 Orchestrator 47 @OslcName("toolName") @OslcPropertyDefinition(OrchestratorAdaptorConstants.ORCHESTRATOR_NAMS
PACE + "toolName") @OslcDescription("the OSLC service being registered, and/or being subscribed to.") @OslcOccurs(Occurs.ExactlyOne) @OslcValueType(ValueType.String) @OslcReadOnly(false) @OslcTitle("Tool Name") public String getToolName() { return toolName; } public void setToolName(final String toolName) { this.toolName = toolName; } } 6 Orchestrator 48 Every time a resource is received by the Orchestrator, the corresponding service is invoked. In this case, the service performs two things (shown in Figure 6.14). Firstly, it invokes the Adaptor Manager component which handles the resource in a proper way, described in the previous chapter. The second thing the service performs is creating a database entry for the every resource. This part is very important since all the representations stored in the memory and accessible through the browser disappear if the adaptor goes off. By storing the data into the database, we keep the representations safe from disappearing. Every time the Orchestrator is turned on, all database entries are read and all OSLC resources are recreated. Figure 6.14: Resource and database entry creation 6 Orchestrator 49 The Orchestrator application is divided into four logical layers which are displayed in the picture below. .
Figure 6.15: Orchestrator layered architecture The Database Management Layer directly interacts with the database. Its role is to execute CRUD methods on the database and provide data to the Adaptor Management Layer. The Adaptor Management Layer creates and keeps created OSLC resources in the memory. It interacts with the Database Management Layer in a way that it forwards the resources to it so they can be stored in the database. The Service Layer consists of services which receive requests and forwards them to the Adaptor Management Layer. The Application Layer represents all the relevant data to the user, and enables the user to form requests using GUI. Finally, the connection between the packages described above and the layered architecture needs to be made in order to complete the Orchestrator implementation. The following picture shows which package belongs to which layer and how packages interact with each other. 6 Orchestrator 50 Figure 6.16: Interaction between packages 6 Orchestrator 51 6.2.3 Database A Database is developed by using Apache Derby and hosted on the Apache Derby Network Server 10.8.2.2. The database is used to store resources so they can be restored when the Orchestrator turns on. In this project, five tables were made, one for each resource: •
•
•
•
•
Registrations ToolRegistrations Subscriptions UserNotifications UpdateNotifications Table 6.8: Database tables Property SERVICEURI SERVICETITLE TOOLNAME TOOLURI TOOLNAME SUBSCRIBEDTOOL SERVICE STATUS MESSAGE DESTINATION SOURCE ID TITLE IDENTIFIER SERVICE TOOLNAME Table Name Registrations ToolRegistrations UserNotifications UpdateNotifications Subscriptions Type VARCHAR(255), PK VARCHAR(255) VARCHAR(255) VARCHAR(255), PK VARCHAR(255), PK VARCHAR(255), PK VARCHAR(255), PK BOOLEAN VARCHAR(1000) VARCHAR(255) VARCHAR(255) VARCHAR(255), PK VARCHAR(255) VARCHAR(255), PK VARCHAR(255), PK VARCHAR(255), PK 6 Orchestrator 52 The SQL below is used to create the database described in Table 6.8. CREATE TABLE "USER"."TOOLREGISTRATIONS" ( "TOOLNAME" VARCHAR(255) NOT NULL, "TOOLURI" VARCHAR(255) NOT NULL ); CREATE TABLE "USER"."REGISTRATIONS" ( "SERVICEURI" VARCHAR(255) NOT NULL, "SERVICETITLE" VARCHAR(255) NOT NULL, "TOOLNAME" VARCHAR(255) NOT NULL ); CREATE TABLE "USER"."SUBSCRIPTIONS" ( "SERVICE" VARCHAR(255) NOT NULL, "SUBSCRIBEDTOOL" VARCHAR(255) NOT NULL ); CREATE TABLE "USER"."USERNOTIFICATIONS" ( "ID" VARCHAR(255) NOT NULL, "SOURCE" VARCHAR(255), "DESTINATION" VARCHAR(255), "MESSAGE" VARCHAR(1000), "STATUS" null ); CREATE TABLE "USER"."UPDATENOTIFICATIONS" ( "TITLE" VARCHAR(255) NOT NULL, "IDENTIFIER" VARCHAR(255) NOT NULL ); ALTER TABLE "USER"."REGISTRATIONS" ADD CONSTRAINT "PK_SERVICEID" PRIMARY KEY ("SERVICEURI"); ALTER TABLE "USER"."SUBSCRIPTIONS" ADD CONSTRAINT "PK_ID" PRIMARY KEY ("SERVICE", "SUBSCRIBEDTOOL"); ALTER TABLE "USER"."TOOLREGISTRATIONS" ADD CONSTRAINT "PK_TOOLID" PRIMARY KEY ("TOOLNAME", "TOOLURI"); ALTER TABLE "USER"."USERNOTIFICATIONS" ADD CONSTRAINT "PK_USERNOTIFICATIONID" PRIMARY KEY ("ID"); ALTER TABLE "USER"."UPDATENOTIFICATIONS" ADD CONSTRAINT "PK_UPDATEID" PRIMARY KEY ("IDENTIFIER"); 6 Orchestrator 53 6.2.4 User Scenarios The Orchestrator and the tools interact with each other in order to publish and retrieve services. The scenarios below describe their communication focusing on the core services, such as tool registration, service registration, service deregistration, service subscription, service desubscription and notification. The main role of the Orchestrator in the mentioned scenarios is to register all the tools in the framework with their offered services, as well as to provide subscription in the way that every tool can subscribe to a list of services that it intends to consume. Also, the Orchestrator needs to manage both types of notification, User Notification and Update Available Notification. Furthermore, the scenarios provide examples with deregistration and desubscription of the tool resources. Scenario 1: In this scenario, the ToolA and ToolB operate on the framework using their adaptors. The scenario defines an example of communication which includes registration of the tool adaptors as well as registration of their services. Furthermore, the scenario defines a situation when the tool needs to subscribe to the list of services that it intends to consume. The steps of communication are defined below and visualised in the sequence diagram shown in Figure 6.17. The steps of the Scenario 1 are: •
•
•
•
•
•
•
•
•
•
•
An OSLC ToolA appears online using its adaptor and registers itself with the Orchestrator. The adaptor of the ToolA registers its services with the Orchestrator. The Orchestrator acknowledges the registration of the ToolA services by sending the catalogue containing all the available services in the IF at the moment. The OSLC ToolB appears online using its adaptor and registers itself with the Orchestrator. The adaptor of the ToolA registers its services with the Orchestrator. The Orchestrator acknowledges the registration of ToolB services by sending the catalogue containing all the available services in the IF at the moment. The Orchestrator sends a new version of the catalogue containing registered services of both tools to the ToolA. ToolA sends a list of services it wants to subscribe to The Orchestrator acknowledges subscription to the selected services by sending a message to the ToolA with the content: Successfully subscribed to services! ToolB sends a list of services it wants to subscribe to The Orchestrator acknowledges subscription to the selected services by sending a message to the ToolB with the content: Successfully subscribed to services! 6 Orchestrator 54 Figure 6.17: Communication between the Orchestrator and the tools (1)
6 Orchestrator 55 Scenario 2: In this scenario, the Tool A operates on the framework using its adaptor. The scenario defines an example of communication which includes the registration of the tool adaptor, registration of it services and tool attempt to register services that are already registered. The steps of communication are defined below and visualised in the sequence diagram shown in Figure 6.18. The steps of the Scenario 2 are: •
•
•
•
•
OSLC ToolA appears online using its adaptor and registers itself with the Orchestrator. The adaptor of the ToolA registers its services with the Orchestrator. The Orchestrator acknowledges the registration of the ToolA services by sending the catalogue containing all the available services in the IF at the moment. The adaptor of the ToolA tries to register services that are already registered to the Orchestrator service catalogue. The Orchestrator informs the ToolA that services cannot be registered by sending a message with the content: Service is already registered! Figure 6.18: Communication between the Orchestrator and the tools (2)
6 Orchestrator 56 Scenario 3: In this scenario, the ToolA and the ToolB operate on the framework, using their adaptors. The scenario defines an example of communication which includes the registration of the tool adaptors, registration of their services, deregistration of the ToolA service and the ToolB attempt to subscribe to the list of services which it wants to consume. The steps of communication are defined below and visualised in the sequence diagram shown in Figure 6.19. The steps of the Scenario 3 are: •
•
•
•
•
•
•
•
•
•
•
An OSLC ToolA appears online using its adaptor and registers itself with the Orchestrator. The adaptor of the ToolA registers its services with the Orchestrator. The Orchestrator acknowledges the registration of the ToolA services by sending the catalogue containing all the available services in the IF at the moment. The OSLC ToolB appears online using its adaptor and registers itself with the Orchestrator. The adaptor of the ToolA registers its services with the Orchestrator. The Orchestrator acknowledges the registration of the ToolB services by sending the catalogue containing all the available services in the IF at the moment. The Orchestrator sends a new version of the catalogue containing registered services of both tools to the ToolA. The adaptor of the ToolA deregisters its service. The Orchestrator sends a new version of the catalogue without deregistered service to the ToolB. ToolB sends a list of services it wants to subscribe to The Orchestrator acknowledges subscription to the selected services by sending a message to the ToolB with the content: Successfully subscribed to services! 6 Orchestrator 57 Figure 6.19: Communication between the Orchestrator and the tools (3) 6 Orchestrator 58 Scenario 4: In this scenario, the ToolA and the ToolB operate on the framework, using their adaptors. The scenario defines an example of communication which includes the registration of the tool adaptors and their services, the ToolB attempt to subscribe to the list of services which it wants to consume and deregistration of the service provided by the ToolA. The steps of communication are defined below and visualised in the sequence diagram shown in Figure 6.20. The steps of the Scenario 4 are: •
•
•
•
•
•
•
•
•
•
•
•
OSLC ToolA appears online using its adaptor and registers itself with the Orchestrator. The adaptor of the ToolA registers its services with the Orchestrator. The Orchestrator acknowledges the registration of the ToolA services by sending the catalogue containing all the available services in the IF at the moment. OSLC ToolB appears online using its adaptor and registers itself with the Orchestrator. The adaptor of the ToolA registers its services with the Orchestrator. The Orchestrator acknowledges the registration of the ToolB services by sending the catalogue containing all the available services in the IF at the moment. The Orchestrator sends a new version of the catalogue containing registered services of both tools to the ToolA. ToolB sends a list of services it wants to subscribe to The Orchestrator acknowledges subscription to the selected services by sending a message to the ToolB with the content: Successfully subscribed to services! The adaptor of the ToolA deregisters its service. The Orchestrator removes the ToolA service that the ToolB is subscribed to. The Orchestrator sends a new version of the catalogue containing registered services of both tools to the ToolB. 6 Orchestrator 59 Figure 6.20: Communication between the Orchestrator and the tools (4)
6 Orchestrator 60 Scenario 5: In this scenario, the ToolA and the ToolB operate on the framework, using their adaptors. The scenario defines an example of communication which includes the registration of the ToolA and its services, registration of the ToolB and its services, subscription of the ToolA and saving registrations and subscriptions in database. The steps of communication are defined below and visualised in the sequence diagram shown in Figure 6.21. The steps of the Scenario 5 are: •
•
•
•
•
•
•
•
•
•
•
•
An OSLC ToolA appears online using its adaptor and registers itself with the Orchestrator. The adaptor of the ToolA registers its services with the Orchestrator. The Orchestrator saves services in the database table REGISTRATION. The Orchestrator acknowledges the registration of the ToolA services by sending the catalogue containing all the available services in the IF at the moment. An OSLC ToolB appears online using its adaptor and registers itself with the Orchestrator. The adaptor of the ToolB registers its services with the Orchestrator. The Orchestrator saves services in the database table REGISTRATION. The Orchestrator acknowledges the registration of the ToolB services by sending the catalogue containing all the available services in the IF at the moment. The Orchestrator sends a new version of the catalogue containing registered services of both tools to the ToolA. ToolA sends a list of services it wants to subscribe to. The Orchestrator saves subscriptions in the database table SUBSCRIPTION. The Orchestrator acknowledges subscription to the selected services by sending a message to the ToolA with the content: Successfully subscribed to services! 6 Orchestrator 61 Figure 6.21: Communication between the Orchestrator and the tools (5) 6 Orchestrator 62 Scenario 6: In this scenario, the ToolA and the ToolB operate on the framework, using their adaptors. The scenario defines an example of communication which includes the registration of the tool adaptors and their services, the ToolB attempt to subscribe to the list of services which it wants to consume and deregistration of the ToolA. The steps of communication are defined below and visualised in the sequence diagram shown in Figure 6.22. The steps of the Scenario 6 are: •
•
•
•
•
•
•
•
•
•
•
•
•
OSLC ToolA appears online using its adaptor and registers itself with the Orchestrator. The adaptor of the ToolA registers its services with the Orchestrator. The Orchestrator acknowledges the registration of the ToolA services by sending the catalogue containing all the available services in the IF at the moment. OSLC ToolB appears online using its adaptor and registers itself with the Orchestrator. The adaptor of the ToolA registers its services with the Orchestrator. The Orchestrator acknowledges the registration of the ToolB services by sending the catalogue containing all the available services in the IF at the moment. The Orchestrator sends a new version of the catalogue containing registered services of both tools to the ToolA. ToolB sends a list of services it wants to subscribe to The Orchestrator acknowledges subscription to the selected services by sending a message to the ToolB with the content: Successfully subscribed to services! The adaptor of the ToolA deregisters itself. The Orchestrator removes all registered services by the ToolA. The Orchestrator removes the ToolA services that the ToolB is subscribed to. The Orchestrator sends a new version of the catalogue to the ToolB. 6 Orchestrator 63 Figure 6.22: Communication between the Orchestrator and the tools (6)
6 Orchestrator 64 Scenario 7: In this scenario, the ToolA and ToolB operate on the framework, using their adaptors. The scenario defines an example of communication which includes the registration of the tool adaptors and ToolA attempt to send user notification through the framework to the ToolB. The steps of communication are defined below and visualised in the sequence diagram shown in Figure 6.23. The steps of the Scenario 7 are: •
•
•
•
An OSLC ToolA appears online using its adaptor and registers itself with the Orchestrator. The OSLC ToolB appears online using its adaptor and registers itself with the Orchestrator. The ToolA sends a user notification containing a comment related to the model to the ToolB, through the Orchestrator. The Orchestrator forwards the message from the ToolA to the ToolB. Figure 6.23: Communication between the Orchestrator and the tools (7)
6 Orchestrator 65 Scenario 8: In this scenario, the ToolA and the ToolB operate on the framework, using their adaptors. The scenario defines an example of communication which includes the registration of the tool adaptors and their services, the ToolB attempt to subscribe to the list of services which it wants to consume and the ToolA attempt to send Update Available notification to the ToolB, through the framework. The steps of communication are defined below and visualised in the sequence diagram shown in Figure 6.24. The steps of the Scenario 8 are: •
•
•
•
•
•
•
•
•
•
•
•
OSLC ToolA appears online using its adaptor and registers itself with the Orchestrator. The adaptor of the ToolA registers its services with the Orchestrator. The Orchestrator acknowledges the registration of ToolA services by sending the catalogue containing all the available services in the IF at the moment. The OSLC ToolB appears online using its adaptor and registers itself with the Orchestrator. The adaptor of the ToolA registers its services with the Orchestrator. The Orchestrator acknowledges the registration of the ToolB services by sending the catalogue containing all the available services in the IF at the moment. The Orchestrator sends a new version of the catalogue containing registered services of both tools to the ToolA. ToolB sends a list of services it wants to subscribe to The Orchestrator acknowledges subscription to the selected services by sending a message to the ToolB with the content: Successfully subscribed to services! The adaptor of the ToolA makes changes to the one of the ToolA services. The ToolA sends an Update Available notification to the ToolB, through the Orchestrator. The Orchestrator forwards the notification from the ToolA to the ToolB. 6 Orchestrator 66 Figure 6.24: Communication between the Orchestrator and the tools (8)
7 Development Environment 67 7 Development Environment This project is implemented by using Java programming language. Eclipse was chosen as an Integrated Development Environment and Apache Derby as a database management system. 7.1 Eclipse IDE As the programming language chosen for the implementation is Java, Eclipse is chosen as the IDE. Eclipse integrated development environment contains a base workspace and an extensible plug-­‐in system for customising the environment. The specific version used in this work is Eclipse Java EE IDE for Web Developers, version: Kepler Service Release 2. 7.1.1 Eclipse Lyo Eclipse Lyo [13] is an SDK that is developed to help the Eclipse community to adopt OSLC specifications and implement OSLC – compliant tools. Lyo is focused on Java by using OSLC4J toolkit for developing Open Services for Lifecycle Collaboration providers and consumers. OSLC4J includes: annotations to describe Java objects with OSLC attributes, annotations to help with preview of resource UIs, build – in support for service providers and consumers, libraries to simplify the development of service providers and consumers, sample applications and test for the applications. The basic components of Eclipse Lyo are: •
•
•
•
OSLC4J – the core component providing OSLC annotation and model support Apache Jena Provider – a library to help with serialization and deserialization of OSLC Java objects to or from RDF Apache Wink Json4J Provider – a library to help with serialization and deserialization of OSLC Java object to or from JSON Apache Wink JAX – RS Provider – containing classes which make development easier using the Apache Wink JAX – RS implementation 7 Development Environment 68 The annotations written in the following text are useful for: • @OslcDescription provides descriptive text about a resource. • @OslcPropertyDefinition provides the namespace qualified attribute name. • @OslcTitle provides the resource title. • @OslcValueType indicates the type of the attribute. //sample simple string attribute @OslcDescription("Descriptive text about resource.") @OslcPropertyDefinition(OslcConstants.DCTERMS_NAMESPACE + "description") @OslcTitle("Description") @OslcValueType(ValueType.XMLLiteral) public String getDescription() { return description; } 7.1.2 eGIT Egit is an Eclipse Team provider for Git. It can be installed as a plug-­‐in inside the Eclipse IDE. Git is a distributed revision control and source code management system. The main advantages of using this system are speed, data integrity and support for distributed, non-­‐linear workflows. By using it, every developer has a full copy of all the history of every revision of the code. Users can make queries against the history and get the results very fast. 7.1.3 Maven Maven is a build automation tool used primarily for Java projects. Maven describes two things: First, it describes how software is built, and second, it describes its dependencies. An XML file describes the software project being built, its dependencies on other external modules and components, the build order, directories, and required plug-­‐ins. It comes with pre-­‐defined targets for performing certain well-­‐defined tasks such as compilation of code and its packaging. Maven dynamically downloads Java libraries and Maven plug-­‐ins from one or more repositories such as the Maven 2 Central Repository, and stores them in a local cache. Maven project configuration is stored in a Project Object Model file called pom.xml. Here is the example of the file: 7 Development Environment 69 <project> <modelVersion>4.0.0</modelVersion> <!-­‐-­‐ project coordinates, i.e. a group of values which uniquely identify this project -­‐-­‐> <groupId>com.mycompany.app</groupId> <artifactId>my-­‐app</artifactId> <version>1.0</version> <!-­‐-­‐ library dependencies -­‐-­‐> <dependencies> <dependency> <!-­‐-­‐ coordinates of the required library -­‐-­‐> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <!-­‐-­‐ this dependency is only used for running and compiling tests-­‐-­‐> <scope>test</scope> </dependency> </dependencies> </project> Having POM is enough for building the project and running the unit test associated with the project. Normal Maven project has the structure shown in Figure 7.1. Figure 7.1: Maven project directory structure 7 Development Environment 70 7.1.4 Acceleo Acceleo is code generator software which implements Object Management Group's Model-­‐to-­‐
text specification. The concept of Model to Text means that the rules are defined on the basis of understanding the model structure from which different texts can be generated. Acceleo is integrated in Eclipse, and it provides full development environment. Developers can create model-­‐to-­‐text rules from which codes and configuration files can be generated. In this thesis, Acceleo is used in order for Lyo's Code Generator to work. 7.1.5 WindowBuilder WindowBuilder is built as a plug-­‐in to Eclipse and the various Eclipse-­‐based IDEs. It facilitates the creation of Java GUI applications without writing the code. Components are created by drag-­‐and-­‐drop and the underlying Java code is generated automatically. WindowBuilder is composed of SWT designer and Swing designer. Java Swing is the main Java GUI toolkit. Swing is developed to provide a more sophisticated set of GUI components than the earlier Abstract Window Toolkit (AWT). It has more powerful and flexible components than AWT. Swing offers familiar components such as buttons, check boxes and labels, as well as some advanced components such as tabbed panel, scroll panes, trees, tables and lists. Components implemented in Swing are entirely written in Jana and therefore are platform-­‐independent. 7.2 Apache Derby Apache Derby is a relational database management system developed by the Apache Software Foundation. The version used in this work is 10.8.2. 8 Future work 71 8 Future work This thesis revolves around the framework integration by using OSLC. In future research, it would be of great interest to define the ways in which various tools from different domains, e.g. Matlab Simulink, Enterprise Architect and HP-­‐ALM, work together through the Orchestrator. Furthermore, the versioning system, which is responsible to manage the tool data and share these among multiple users, is specified below. However, it is not implemented yet. As for new GUI features, it is necessary to implement the Orchestrator Configuration Window in order to configure the Orchestrator basic properties before the Orchestrator is turned on. In addition, current implementation contains bugs that need to be fixed in the future. 8.1 Versioning Generally, versioning is assigning a unique identifier to a certain state of an entity. In computer science, that entity is computer software. Identifiers are usually numbers, but names can also perform the function. When versions are identified with numbers, every new version is usually denoted with higher number. Revision control, also known as control or source control, keeps track of all the different versions. With control like that, each version can be restored, compared or merged with other versions. Every component inside the iFEST IF keeps track of versions of their artefacts because they are often shared among multiple tools in the framework. In most of versioning systems there are two main operations: 1) Check-­‐out: action of taking the repository copy of the file into ownership 2) Check-­‐in: action of writing the local working copy back to repository For the purposes of our framework, we extended those operations. Now we have: 1) Publish: operation needed for sharing new or modified data/artefacts with other tools operating in the IF. By this action, data is stored in the IF repository and are accessible to all of the subscribed tools. This operation corresponds to the Check-­‐in operation. 2) Retrieve: operation of fetching data from the IF repository. Every tool keeps track of its own artefact versions. When the user of the tool wants to publish a new artefact version, this is stored in the central repository. The central repository 8 Future work 72 keeps all published versions of all artefacts. Thus, tools can get any version they want at any time. The central repository has the standardised directory structure so that the versions can be stored in a proper way. Every tool has its folder inside the repository. The folder consists of artefact folders. Every artefact folder contains different versions of the artefact. The structure of the repository is shown in Figure below. Figure 8.1: Repository directory structure Not every artifact version is needed to be published to the central repository. Certain changes may be performed and left unrevealed to the rest of the framework. However, provided that the user wants to share these, he/she can make the new version availabel to the central repository anytime. 8 Future work 73 Figure 8.2: Communication between the Orchestrator and the tools (1) The Repository consists of two main components: the Repository Tool and the Repository itself. The Repository Tool handles all incoming and outcoming communication, and the Repository is used for storage. The process of checking-­‐in is show in the picture below. Figure 8.3: Communication between the Orchestrator and the tools (2) 8 Future work 74 Every tool stores the data locally. The first step is to take the data from the local storage and send it to the Repository Tool. Repository Tool handles the data by creating a new version entry in the Central Repository. After the new version is created, the Orchestrator needs to be informed about the change. The tool which published the new version creates the UpdateNotification resource and POSTs it to the Orchestrator which then forwards the resource to all tools which need to be informed on the update. This process is shown in the picture below. Figure 8.4: Communication between the Orchestrator and the tools (3) Now the tools which receive the UpdateNotification resource after the process described above are informed that changes to a specific artifact were made. In cases when the tool user wants to fetch the new version, he/she contacts Repo Tool to get the model from the Central Repository and stores it in its local storage. The sequence is shown in Figure 8.5. 8 Future work 75 Figure 8.5: Communication between the Orchestrator and the tools (4) The versioning system can be implemented in two ways. It can be done in a traditional way, by having a standardized structure of folders inside the central repository described above. In this case, artefacts are stored in the corresponding folders and the tool interested in a certain artefact fetches the artefact itself from the repository following the folder structure. Likewise, the same can be done by following the OSLC standard. There is the Configuration Management specification [21] published by the OSLC community. It specifies the Configuration Management domain which offers new properties suitable for versioning. By using these properties and adding them to existing resources, data can be easily versioned and tracked. In addition, there is no need for exchanging the real artefacts anymore. Thus, the RDF representation of resources can only be exchanged and the central repository will contain a number of these representations. The tool with corresponding adaptors will be able to fetch representations and convert them back to the real artefacts. This can also be done provided that the central repository contains only URIs of resource representations, and functions like a database of pointers as well. In this way, there is no need for transferring data to the repo, only URIs of the representations of resources will be sent to the repository. The Configuration Management introduces properties which can be added to the existing resources to implement the versioning. These are as follows: •
•
oslc_scm:fullName -­‐ A full human-­‐readable name of an object, unique amongst all current existing object versions from this service provider. oslc_scm:status -­‐ A string indicating the current status of the object version. Also, properties that should be common to all Configuration Management resources are: •
•
•
dcterms:created -­‐ Timestamp of the resource creation. dcterms:modified -­‐ Timestamp of the latest resource modification. dcterms:creator -­‐ Creator or creators of resource.
8 Future work 76 8.2 Orchestrator Configuration Window In order to make it possible for users to define the Orchestrator basic properties, the prototype of the Orchestrator Configuration window is developed and shown in Figure 8.6. The prototype needs to provide functionalities such as: •
•
•
•
allowing users to define arbitrarily port and URI for the Orchestrator allowing user to set up initial layout of the window allowing users to select centralised or distributed repository etc. Figure 8.6: Orchestrator Configuration Window Prototype 8 Future work 77 8.3 The improvements to the code generator For the development of an OSCL4J provider, the code generator [15] provided by Lyo is used. It provides a metamodel of the adaptor consisting of two sides: a model of the OSLC core resources and a model of a typical OSLC domain specification. The metamodel is shown in Figure 6.12. It facilitates the development phase significantly, but the following improvements could be made: 1) Having Graphical User Interface, the code generator would be more intuitive and easier to use. 2) In situation when the adaptor is regenerated, certain implemented methods could disappear. The code needs to be written inside the comments Start of user code and End of user code. For example, when we manually add a new method, we also need to manually add mentioned comments. The code generator could be changed in a way that it does not remove the existing code. 3) In cases when we add a new resource to the existing adaptor, the properties of the resource are occasionally invalid, and a great deal of data needs to be manually changed. This is demonstrated in the following fragments of code. Note: the solution to this bug is shown in the code generator tutorial. package se.abb.oslc.na.resources; @OslcNamespace(NotificationAdaptorConstants.QUALITY_MANAGEMENT_NAMSPACE) @OslcName(NotificationAdaptorConstants.UPDATENOTIFICATION) @OslcResourceShape(title = "updateNotification Resource Shape", describes = NotificationAdaptorConstants.TYPE_UPDATENOTIFICATION) public class UpdateNotification extends AbstractResource { private Boolean invalid; private Boolean invalid; //… There are two properties inside this class, both named “invalid”, although they were named while being created through the Code Generator. In addition, their data types do not fit the ones defined. For some reason, they are both Boolean. 8 Future work 78 @OslcOccurs(Occurs.ExactlyOne) @OslcValueType(ValueType.Boolean) @OslcReadOnly(false) public Boolean isInvalid() { return invalid; } @OslcOccurs(Occurs.ExactlyOne) @OslcValueType(ValueType.Boolean) @OslcReadOnly(false) public Boolean isInvalid() { return invalid; } public void setInvalid(final Boolean ) { this.invalid = ; } public void setInvalid(final Boolean ) { this.invalid = ; } //… The same can be found in the rest of the class code. At some places we can notice blank fields where it should write something. <h1>Resource Presentation</h1> <p>Summary: <%= aUpdateNotification.toHtml() %><br /></p> <h2>Properties</h2> <table style="clear: both;"> <tr> <td><%= aUpdateNotification.invalidToHtml()%></td> </tr> <tr> <td><%= aUpdateNotification.invalidToHtml()%></td> </tr> </table> We have the same situation in the html files used for the html representation of resources, shown in the code above. 10 Conclusion 79 9 Conclusion The work presented in this thesis is in relation to the iFEST project which specifies a tool integration framework for different tools. Our goal was to make a component inside the iFEST framework which would control all the communication and would serve as an interface between all tools. Therefore, by successfully introducing this unit, less effort in integration process is required now. The iFEST supports a set of specifications, called Open Services for Lifecycle Collaboration (OSLC), which specifies the way of sharing data between various tools. The OSLC is a new technology which provides a flexible way of tool integration by using the Web services and consumer-­‐provider concept. With the lifecycle tools integrated into the framework, products can be developed more quickly and with less effort. With less time required for launching the product, profit grows respectively. One of the main pros of the tool integration is reusability; design data can be reused at different stages of the lifecycle. Other improvements which tool integration brings are: •
•
•
•
•
reduction of high criticality defects across the entire life-­‐cycle; increase in the Defect Removal Effectiveness for Requirements and Design defects mainly, as these were the areas where industrial organisations had identified the largest potential gains; more efforts spent on early phases of Requirements and Design lead to a reduction of the Implementation phase and to a reduction of the total development duration; reduction of rework, leading to reduction of Cost of Poor Quality and time to market: reduction of defects related to the tool integration and tool chains installation. Within our work, the core OSLC concept was explained. In addition, adaptors which follow the OSLC standard were described and implemented. Through the implementation of adaptors, we explained the concept of OSLC resources exchanged between the adaptors by providing and consuming services. Both the tool and the Orchestrator adaptors were developed. After many attempts of implementing the tool adaptor, the right model of the adaptor emerged. Detailed description is given in Section 6.2. For the generation of the Tool Adaptor, Code Generator from Lyo project was used. It automatized and accelerated the generation of OSLC resources and corresponding services. However, after the resources were generated, certain errors in the code emerged, and these needed to be fixed for the resource to be fully functional. Also, methods responsible for handling the requests were generic and 10 Conclusion 80 needed to be implemented. Besides the cons, the Code Generator made the resource creation much simpler and quicker. Every adaptor has two sides, the one which communicates with the tool and the other which communicates with the Orchestrator. By developing few of these adaptors, we discovered the possibility to have the adaptor template which could be applied to all the tools in the iFEST framework. More precisely, the part of the adaptor responsible for information exchange with the Orchestrator could be used as the template, and the part communicating with the tool could be implemented for every tool individually. By implementing all of the previously mentioned, we can say that the OSLC has proven to be a good technology for integrating tools because of its resource paradigm. However, there are several issues that should be addressed here. Although many big companies work with the OSLC at the time, the community support is lacking. Furthermore, it requires a certain amount of time to understand the concept because the documentation available is not clear enough, and in some cases it is not even completed. The OSLC technology is relatively new concept and it will probably take some time until the specifications are completely finished. Lyo SDK has proven to be useful, but in some cases it may appear as confusing and not intuitive enough. To conclude, the Orchestrator concept represents an acceptable solution, but it is still far from the real use. The implementation shown in this project proves that it is possible to have a central component managing the tools in the framework. To make the whole framework along with the Orchestrator fully functional, additional implementation efforts will be needed. Bibliography 81 Bibliography [1]
A. Wasserman, “Tool integration in software engineering environments“, Software Engineering Environments, vol. 1, no. 6, pp. 137 – 149, 1990. [2]
I. Thomas, B.A. Nejmeh, ”Definitions of Tool Integration for Environments”, IEEE Software, vol. 9., no. 2, pp. 29 – 35, 1992. [3]
F. Asplund, M. Biehl, J. El – Khoury, M. Törngren, ”Tool Integration Beyond Wasserman“, Advanced Information Systems Engineering Workshops, pp. 270 – 281, 2011. [4]
M. Wicks, ”Tool integration in software engineering: The state of the art in 2004”, Integration The VLSI Journal, pp. 1-­‐26, 2004. [5]
E. Kapsammer, T. Reiter, W. Schwinger, "Model-­‐based tool integration-­‐state of the art and future perspectives." Proceedings of the 3rd International Conference on Cybernetics and Information Technologies, Systems and Applications (CITSA), 2006. [6]
C. Hein, T. Ritter, M. Wagner, “Model – Driven Tool Integration with ModelBus, “Workshop Future Trends of Model – Driven Development, pp. 50 – 52, 2009. [7]
X. Blanc, P. Gervais, P. Sriplakich, “Model Bus: Towards the Interoperability of Modelling Tools“, Model Driven Architecture, pp. 17 – 32, 2005. [8]
S. Burmester, H. Giese, J. Niere, M. Tichy, J. P. Wadsack,, R. Wagner, ... & A. Zündorf, “Tool integration at the meta-­‐model level: the Fujaba approach”, International journal on software tools for technology transfer, 6(3), pp. 203-­‐218, 2004. [9]
M. Biehl, J. El-­‐Khoury, M. Torngren, "High-­‐Level specification and code generation for service-­‐oriented tool adaptors." Computational Science and Its Applications (ICCSA), pp. 35 – 42, 2012. [10] Open Services for Lifecycle Collaboration, “OSLC Primer” [Online]. Available: http://open-­‐services.net/resources/tutorials/oslc-­‐primer/ Bibliography 82 [Last accessed: 10 June 2014] [11] Open Services for Lifecycle Collaboration, “OSLC Core Specification“, [Online]. Available: http://open-­‐services.net/bin/view/Main/OslcCoreSpecification [Last accessed: 28 August 2014] [12] Open Services for Lifecycle Collaboration, “OSLC RM Specification“, [Online]. Available: http://open-­‐services.net/bin/view/Main/RmSpecificationV2 [Last accessed: 1 July 2014] [13] Eclipse, “Eclipse Lyo“, [Online]. Available: http://www.eclipse.org/lyo/ [Last accessed: 3 February 2014] [14] ARTEMIS iFEST Consortium, “iFEST” [Online]. Available: http://www.artemis-­‐ifest.eu [Last accessed: 10 Mart 2014] [15] Eclipse, “Adaptor Code Generator Workshop“, [Online]. Available: http://wiki.eclipse.org/Lyo/AdaptorCodeGeneratorWorkshop [Last accessed: 26 September 2014] [16] IBM, “Jazz Team Server“, [Online]. Available: https://jazz.net/products/jazz-­‐foundation/jazz-­‐team-­‐server/ [Last accessed: 15 July 2014] [17] Frost, "Jazz and the eclipse way of collaboration", Software, IEEE24.6 (2007): 114-­‐
117. [18] R. Scott. "IBM's jazz integration architecture: building a tools integration architecture and community inspired by the web." Proceedings of the 19th international conference on World wide web, ACM, 2010. [19] Fraunhofer FOKUS, “ModelBus Users Guide“, [Online]. Available: http://www.modelbus.org/ [Last accessed: 16 July 2014] [20] R. T. Fielding, “Architectural styles and the design of network-­‐based software architectures”, Doctoral dissertation, University of California, Irvine, 2000. [21] Open Services for Lifecycle Collaboration, “Configuration Management Resource Definitions”, [Online]. Available: http://open-­‐services.net/wiki/configuration-­‐
management/Configuration-­‐Management-­‐Resource-­‐Definitions/ [Last accessed: 26 September 2014] [22] Wikipedia: The free encyclopaedia, “Open Services for Lifecycle Collaboration”, [Online].Available: http://en.wikipedia.org/wiki/Open_Services_for_Lifecycle_Collaboration [Last accessed: 29 September 2014] [23] Wikipedia: The free encyclopaedia, “V -­‐ Model”, [Online]. Available: http://en.wikipedia.org/wiki/V-­‐Model [Last accessed: 29 September 2014] Bibliography 83 [24] Wikipedia: The free encyclopaedia, “Apache Maven”, [Online]. Available: http://en.wikipedia.org/wiki/Apache_Maven [Last accessed: 29 September 2014] [25] Wikipedia: The free encyclopaedia, “Representational state transfer”, [Online]. Available: http://en.wikipedia.org/wiki/Representational_state_transfer [Last accessed: 29 September 2014] [26] Atego, “Atego Workbench”, [Online]. Available: http://www.atego.com/products/atego-­‐workbench/ [27] M. Elaasar, A. Neal, “Integrating Modeling Tools in the Development Lifecycle with OSLC: A Case Study”, Model-­‐Driven Engineering Languages and Systems, pp. 154-­‐169, 2013. Appendices 84 Appendices Appendix A. Installation Guide Eclipse 1. Install Eclipse IDE for Java EE Developers Kepler Edition. 2. Install Egit plug-­‐in. In the Work with field paste add: http://download.eclipse.org/egit/updates 3. Install M2E plug-­‐in. In the Work with field paste add: http://download.eclipse.org/technology/m2e/releases Setup Maven Dependencies To clone needed Maven dependencies following steps need to be performed: 1. Windows ! Show view ! Other ! Git repositories ! Clone a Git Repository ! in the URI field add: http://git.eclipse.org/gitroot/lyo/org.eclipse.lyo.core.git 2. On the Branch selection page, select master 3. In the Git Repositories view, right click org.eclipse.lyo.core ! Import Projects Setup Database 1. Install Apache Derby plug – in. 2. File ! New Java Project !Set orchestratorDatabase for Project Name 3. Right click on orchestratorDatabase ! Apache Derby ! Add Apache Derby nature 4. Add .jar files from org.apache.derby.core_10.8.2 folder. 5. Go to the Database Development view ! Right click on database ! Open SQL Scrapbook ! Copy SQL code from orchestratorDatabase.sql ! Execute 6. Go back to Java EE view !Right click on orchestratorDatabase ! Apache Derby ! Start Derby Network Server Appendices 85 Setup Project 1. File ! Import ! Existing Maven Projects ! Browse the location of the adaptor and import 2. Right click on pom.xml file ! Run As ! Maven Clean 3. Right click on pom.xml file ! Run As ! Maven Install If “Build Success” message shows in the console window, the imported project was successfully build. 5. Run ! Run Configurations ! In the Main tab, in Goals textbox add: jetty:run-­‐exploded Appendix A. List of figures Note: To create the figures Adobe Photoshop CreativeCloud version 14.0 x64 and Enterprise Architect Version 10 are used. Figure 1.1: Point-­‐to-­‐point communication ..................................................................................... 1 Figure 1.2: Communication through the framework ...................................................................... 2 Figure 2.1: Point-­‐to-­‐point tool integration ..................................................................................... 6 Figure 2.2: Framework tool integration .......................................................................................... 6 Figure 2.3: Three dimensional space of tool integration [1] ........................................................... 7 Figure 2.4: Types of tool relationship [2] ........................................................................................ 8 Figure 2.5: Jazz Team Server [16] ................................................................................................... 9 Figure 2.6: ModelBus Approach [7] .............................................................................................. 10 Figure 3.1: SOA Conceptual Model ............................................................................................... 13 Figure 3.2: RDF triple .................................................................................................................... 16 Figure 3.3: Triples graph ............................................................................................................... 16 Figure 3.4: Blank node .................................................................................................................. 17 Figure 4.1: OSLC domains [22] ...................................................................................................... 19 Figure 4.2: OSLC core concept [11] ............................................................................................... 21 Figure 5.1: V-­‐model [23] ............................................................................................................... 23 Figure 5.2: iFEST Tool Integration Framework architecture [14] .................................................. 25 Figure 5.3: iFEST fundamental concept [14] ................................................................................. 26 Figure 6.1: Orchestrator architecture ........................................................................................... 29 Figure 6.2: Prototype of Tool Registration Window ..................................................................... 33 Figure 6.3: Prototype of Service Catalogue Window .................................................................... 33 Figure 6.4: Prototype of User Notification Window on the Orchestrator side ............................. 34 Figure 6.5: Prototype of Update Available Window on the Orchestrator side ............................. 34 Appendices 86 Figure 6.6: Prototype of the Registration window ........................................................................ 35 Figure 6.7: Prototype of the Edit Services window ....................................................................... 35 Figure 6.8: Prototype of the Subscription window ....................................................................... 36 Figure 6.9: Prototype of the User Notification window ................................................................ 36 Figure 6.10: Prototype of the Update Available Notification window .......................................... 37 Figure 6.11: Interaction between components ............................................................................ 39 Figure 6.12: Tool adaptor metamodel [15] ................................................................................... 40 Figure 6.13: Communication between the Tool and the Orchestrator ........................................ 42 Figure 6.14: Resource and database entry creation ..................................................................... 48 Figure 6.15: Orchestrator layered architecture ............................................................................ 49 Figure 6.16: Interaction between packages .................................................................................. 50 Figure 6.17: Communication between the Orchestrator and the tools (1) .................................. 54 Figure 6.18: Communication between the Orchestrator and the tools (2) .................................. 55 Figure 6.19: Communication between the Orchestrator and the tools (3) .................................. 57 Figure 6.20: Communication between the Orchestrator and the tools (4) .................................. 59 Figure 6.21: Communication between the Orchestrator and the tools (5) .................................. 61 Figure 6.22: Communication between the Orchestrator and the tools (6) .................................. 63 Figure 6.23: Communication between the Orchestrator and the tools (7) .................................. 64 Figure 6.24: Communication between the Orchestrator and the tools (8) .................................. 66 Figure 7.1: Maven project directory structure .............................................................................. 69 Figure 8.1: Repository directory structure .................................................................................... 72 Figure 8.2: Communication between the Orchestrator and the tools (1) .................................... 73 Figure 8.3: Communication between the Orchestrator and the tools (2) .................................... 73 Figure 8.4: Communication between the Orchestrator and the tools (3) .................................... 74 Figure 8.5: Communication between the Orchestrator and the tools (4) .................................... 75 Figure 8.6: Orchestrator Configuration Window Prototype ......................................................... 76 Appendix B. List of tables Table 3.1: Service requirements ................................................................................................... 12 Table 3.2: Collection URI’s HTTP methods [25] ............................................................................ 15 Table 3.3: Artifact URI’s HTTP methods [25] ................................................................................. 15 Table 4.1: Basic OSLC properties [11] ........................................................................................... 20 Table 4.2: Mandatory OSLC properties [11] ................................................................................. 20 Table 6.1: Service catalogue entries ............................................................................................. 29 Table 6.2: Tool Registration properties ........................................................................................ 30 Table 6.3: Service Registration properties .................................................................................... 30 Table 6.4: Subscription properties ................................................................................................ 31 Appendices 87 Table 6.5: Update notification properties .................................................................................... 31 Table 6.6: User Notification properties ........................................................................................ 31 Table 6.7: Implemented functionalities on the tool side .............................................................. 32 Table 6.8: Database tables ............................................................................................................ 51