Component and Service Technology Families

Transcription

1 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 1 STUDIES AND REPORTS OF THE PLUGIT PROJECT 1 Juha Mykkänen, Marko Sormunen, Kirsi Karvinen, Tomi Tikkanen, Sami Päiväniemi Component and Service Technology Families UNIVERSITY OF KUOPIO SAVONIA POLYTECHNIC KUOPIO 2004

2 Authors: Juha Mykkänen (editing, chapters 1-3, 7, 8, 6, 4.1) Marko Sormunen (chapters 1-3, 5, 4.2, 7, 8, A, B) Kirsi Karvinen (chapters 1-3, 5, 8, C) HIS R & D Unit University of Kuopio, Finland Tomi Tikkanen (chapters 1-3, 4.1, 7, 8) Department of Computer Science University of Kuopio, Finland Sami Päiväniemi (chapters 1-3, 6) Savonia Business Savonia Polytechnic, Kuopio, Finland Sales: IT Service Centre (Tietotekniikkakeskus) University of Kuopio tel tike@uku.fi ISBN (all reports) ISBN (report 1) ISBN (PDF) Kopijyvä Oy, Kuopio, Finland 2004

3 Mykkänen, Juha; Sormunen, Marko; Karvinen, Kirsi; Tikkanen, Tomi; Päiväniemi, Sami. Component and Service Technology Families. Studies and Reports of the PlugIT project p ISBN (all reports) ISBN (report 1) ISBN (PDF) Summary This study covers several technology families for component- and service-based software engineering. We introduce basic concepts and a comparison framework for component and service technologies. Then we use the framework to examine, evaluate and compare four families of component and service technologies, namely Microsoft, Java, OMG and Web service technologies. Finally, we summarize and compare the results from different families, especially to provide guidelines for technology selections for application integration and production in health care domain. The evaluation framework can be used also generally in evaluation and selection of technologies for software production. The technology family specific chapters provide introduction of the features of key technologies in each technology family. The summary and conclusions provide comparison between the studied technologies and suggest solutions for different types of integration needs. Component and service technologies presented in this study offer many features to support needs in enterprise systems development also in healthcare domain. Yleinen kymmenluokittelu UDK: Asiasanat (YSA): tietojärjestelmät, systeemityö, tiedonhallintajärjestelmät, ohjelmointi, oliokeskeisyys, terveydenhuolto, tietoteollisuus Medical Subject Headings (MeSH): information systems, information management, medical informatics, software, hospital information systems

4

5 Preface The aim of this study is to provide background for technology evaluations and selections for component- and service-based application production and integration in health care. The study is intended for decision makers and technical experts. It introduces and compares main features of several technology families and can be used as a basis for technology selections. This study has been conducted in the PlugIT project during , and partly updated (Web Services technologies) in The PlugIT project has been funded by the National Technology Agency TEKES, Mawell konserni, Medimaker Oy Ltd, Medici Data Oy, Mediweb Oy, Mylab Oy, Tietoenator Oyj, WM-data Novo Oyj, Atkos Oy, BEA Systems Oy, Commit; Oy, Enfo Oy, Fujitsu Services Oy, General Electric Healthcare CIS EMEA, Mediconsult Oy, Microsoft Oy, Oracle Finland Oy, Hospital district of Helsinki and Uusimaa, Hospital district of Pirkanmaa, Hospital district of Northern Savo, Northern Ostrobothnia Hospital District, Hospital district of Satakunta, Hospital district of Southwest Finland, City of Kuopio and the joint municipal board for healthcare of Siilinjärvi and Maaninka. Kuopio, 30 August 2004 Authors

6

7 Contents 1 INTRODUCTION Goals and methods of the study Terminology CONCEPTS Components Interfaces and Services Customization FEATURES OF COMPONENT TECHNOLOGY FAMILIES Reference application architecture Parts of component technology families Communication middleware Interface definitions Component model Support for programming languages and execution platforms Deployment and transferability of components Other quality properties Additional properties Application development process Implementing user interfaces Implementing application server components Implementing persistence Example application Summary MICROSOFT TECHNOLOGIES COM and COM COM/COM+ architecture overview Interface definitions COM Component model Support for programming languages Communication model in COM and COM Types of COM+ applications Parts of a COM+ Application Dynamic-Link Libraries (DLL) ActiveX controls Microsoft application development process Summary of COM/COM+...39

8 4.2 NET Framework Overview of.net Framework Common Language Runtime and assemblies NET Framework Class Library NET core languages Visual Studio.NET Persistence using ADO.NET Web forms using ASP.NET Web services using ASP.NET Windows Forms COM+ Services in.net Framework Deployment of.net applications Third party CLR implementations NET demonstration application Summary of.net JAVA TECHNOLOGIES Java 2 Platform Java Standard Edition (J2SE) Java Enterprise Edition (J2EE) Java Community Process Communication using Remote Method Invocation RMI basics RMI through a firewall Locating remote objects RMI over IIOP Database connectivity with JDBC J2EE specifications Enterprise JavaBean container Java Naming and Directory Interface (JNDI) Java Transaction API (JTA) Java Message Service (JMS) Enterprise JavaBeans (EJB) Home and remote interfaces of an EJB Entity beans Session beans Persistence of Enterprise JavaBeans Message-driven beans Integrating legacy systems with a J2EE server Enterprise distribution using archives Creating a user interface for applications Application development process Example application XML and Java Technologies About J2EE implementations Summary of Java technology family...78

9 6 OMG TECHNOLOGIES CORBA Object Management Architecture Object request broker (ORB) CORBA services and facilities Communication middleware: IIOP and AMI Interface definitions: OMG Interface Definition Language (IDL) Component model: CORBA objects and CCM Support for programming languages and execution platforms: language mappings and ORB products Deployment and transferability of components Other quality properties Additional properties Application development process Implementing user interfaces Implementing CORBA server components Implementing persistence: PSS and PSDL Example Application Summary of OMG family WEB SERVICES Web services communication protocols Simple Object Access Protocol (SOAP) XML-RPC HTTP and XML communication Web service description and registry specifications Web Services Description Language (WSDL) Universal Description, Discovery and Integration (UDDI) Designing and implementing web services Synchronous and asynchronous services and client invocation models Service-oriented and document-oriented web services Additional features Web services and security Securing the connection on network level Encryption and digital signatures on message level Securing the web services infrastructure Web service workflow specifications ebxml Other web service specifications Web services standardization communities Summary of web services...123

10 8 COMPARISON OF TECHNOLOGY FAMILIES AND SUMMARY OF THE STUDY Comparison of features Comparison table Usage models, interfaces, encapsulation and services Stateless and stateful server components and performance Interoperability between technology families Selecting technologies for integration Workspace-level application coordination APIs (e.g. clinical context) Data or service interface API on workstation level Distributed data or service interface API Simple Data or service interface API based on web server API for invoking user interface on user workstation API for invoking web user interface Summary of the study REFERENCES APPENDIX A:.NET EXAMPLE APPLICATION APPENDIX B: JAVA EXAMPLE APPLICATION APPENDIX C: CORBA EXAMPLE APPLICATION...149

11 1 INTRODUCTION Today s software systems are large, complex and distributed. Also end users are demanding. Systems should be open, scalable and reliable (Tanenbaum 2002). There are several needs in systems development that need to be addressed (See Figure 1.1). Reuse of existing parts and systems reduces amount of overlapping functionality and data as well as the amount of implementation work needed in systems implementation. Systems and their technical infrastructures are very heterogeneous, for example systems in large hospitals have been implemented using variety of different technologies. Interoperability between these heterogeneous systems has remained a major challenge. The idea of component market, selection of readily-made building blocks for applications enables new ways of acquiring and selling functionality in systems, as well as possibility to choose the most suitable implementation from a set of alternatives. Systems are also becoming larger and larger both technically and functionally, they potentially have large amounts of concurrent users a holistic approach, where separate systems are integrated into seamless overall system is goal in many organizations. Systems also need to cope with changes in business processes and usage contexts as well as changes in technology: it should be possible to adapt systems dynamically upon new and changing requirements and to make use of new and promising technologies. A. Improved reuse -encapsulating existing functions -reducing overlapping functionality -offering consistent services -programmer productivity B. Support for heterogeneity -different operating systems, user interfaces, servers -different technologies in applications C. Component market -ability to sell and buy readily made, tested building blocks -possibility to choose most suitable solution D. Improved level of control in large systems -large functional entities -lots of concurrent use -scalability E. Fast adaptation and preparation for changes -changes in business processes and environment -changes in technology 1. Interfaces, encapsulation 2. Distibution of systems and multi-tier architectures 3. Building components separately from building applications 4. Use of standards, application frameworks, and design patterns 5. Business process -based systems engineering Figure 1.1 Component and service technologies supporting needs of systems development. Software component and service technologies offer solutions to these needs using encapsulation through well-defined interfaces, distribution of systems in multi-tier architectures, separating component implementation from the application implementation (assembly), providing standards-based frameworks and design patterns to support the interoperability and setting constraints for the development work. They are also often used together with business-processbased systems (re)engineering (See Figure 1.1). Many of these features support the needs in the system development described above. Using components we can divide large and complex systems into more manageable parts. Components have features that can be used to adapt them to different platforms. Components can also be tested separately and then used as parts. 11 COMPONENT AND SERVICE TECHNOLOGY FAMILIES

12 A software component is an independently deliverable package of reusable software services. Services of the component can be made available over the network or locally and are used through an interface. A more detailed definition of software component is given in Chapter 2.1. Component technology was originally introduced as an attempt to solve some of the problems in object-oriented technology. Objects and programming language classes were too small units for reuse. Components instead are often larger units of reuse. Sessions (2000) sees components as packaging technology, more than an implementation technology. According to him ideal component specifications should be programming language neutral. Components are also more encapsulated than objects. Especially the user of a component should not be able to see the component implementation. Thus components can be made by third party vendors and used as black boxes, enabling the component market. Services are collections of interfaces, typically used over a network. They have different scope in comparison to components. They do not usually consider the deployment as independent units (even if they can be implemented using components). Components can be object-oriented and contain a state in some implementations, whereas services do not usually have state as objects do. Services do not contain runtime data, even though data can be manipulated through them during the execution of the application. Components and Web services can be seen as units of composition: applications are composed using and adapting components and services which implement interfaces. Web services can be component-based or non-component based. For software developer, components are units of reuse and can be used and installed individually and used in assemblies within a specified environment, whereas someone using Web services needs knowledge about the location details and provided operations of service. Several different technology families have been emerging in the field of software components and services. These families have grouped around some major actors or trends in software development. In this comparison, we have identified four different component and service technology families: Microsoft component and services technology family, Java family of technologies, OMG family of technologies and specifications, Web service specifications and technologies. Although we have separated these families in this study, there are actually many product suites, common parts and interoperability solutions that cross these technology family boundaries. Some of these interoperability solutions are discussed in the end of this study. Many tools supporting these technology families are studied in a separate report in Finnish (Karvinen et al. 2004). 1.1 Goals and methods of the study Purpose of this study is to support selection and introduction of technologies both for implementing interfaces between different systems and for implementing the systems themselves, especially in health care. The first chapters provide overview of needed concepts and a structural model for the rest of the study. Technology-specific chapters provide more detailed features of technology families for technology-oriented readers and in conclusions chapter we provide a comparison of different technologies to support technology evaluation and selection. We do not introduce any new methods or specification techniques, but we discuss basics and the most important features of the selected technologies and viewpoints that should be taken care of. The study is based on a literature survey and is complemented with experiences, interpretations and comments from the authors. Some experiences from the PlugIT project and previous projects are also included. STUDIES AND REPORTS OF THE PLUGIT PROJECT 1 12

13 1.2 Terminology Middleware can be defined as a layer in the system, which is located between an application and platforms and protocols used in the network. It is used to decrease dependencies between application and operating systems, hardware and communication protocols and it improves openness and interoperability of systems. Middleware offers a consistent interface instead of application and tool specific interfaces. Definitions of middleware vary widely. Middleware can be classified e.g. in the following classes: Remote procedure call -based middleware, based on request-reply paradigm, Message-oriented middleware, which enables asynchronous communication, Distributed Transaction processing -oriented middleware, based on the use of transaction processing monitors, Object request broker -based middleware, which extends remote procedure-based middleware and Database middleware. In this study, we focus on middleware used in component technology families, which is often object request broker -based and is used as a communication mechanism between a distributed component implementation and the component user. Component technology families can also offer transaction processing and message-oriented middleware and asynchronous messaging. In some definitions, middleware concept also includes set of common or domain-specific services for the applications. To support interchangeable components, the component model should support modularity. It should be possible to encapsulate several levels of component behaviour (adapted from Assmann 1999): Encapsulate implementation and design decisions to be used only through component interfaces, Support programming language and execution platform neutrality and portability between different execution environments. It is usually not possible to unify different programming languages or operating systems, so there needs to be means to connect components implemented in different languages using middleware. Support location transparency: component user does not need to know the exact physical location of the component to be able to use its services. Offer encapsulation of the component lifecycle: the developer who uses components should not have to consider the lifecycle (activation, creation etc.) of the actual running component implementations, but should only be able to use the component when needed. Support dynamic binding, where components are not connected statically but found in runtime using directories or naming services, transparently to the component user. Application programming interfaces (APIs) are programmatically usable interfaces, which are offered to the developer. All component and service technology families offer services or components which provides APIs to the developer. Synchronous communication is a communication protocol, where a calling program (client) invokes (makes a request to)api of another program (server) and waits for the reply from the server until continues execution. Asynchronous communication is a communication protocol, where client does not wait for the server to reply but continues execution immediately. Server can deliver a reply to client using call-back, client can poll periodically for a result, or client may not wait for a reply at all in asynchronous messaging. Majority of Component-oriented concepts are introduced in Chapters 2 and COMPONENT AND SERVICE TECHNOLOGY FAMILIES

14 2 CONCEPTS 2.1 Components Software components are self-contained, independent software artefacts (Szyperski, 1999; Herzum and Sims 2000). Their services are available only through their published interfaces, which hide details of component's implementation and act as a single point of dependency between different components, forming a contract between the component interface and users. Interfaces may make component services available over a network using an object brokering technology, in which case the component is distributed. Components are built for a specified execution environment and they can be deployed independently. They are units of composition. Applications are assembled by combining different components and the same components can be reused in different applications (Brown and Wallnau 1996). In addition, many component technology families define a component as a single executable and deployable unit of code that provides physical black box encapsulation of related services (Allen 1998). Components should be self-contained, exchangeable, and adaptable. This should be reflected by the description and specification technique. Components should have a structural schema consisting of at least one import interface, a body, and one export interface. Each part should be specified. The specifications of each part of a component must be compatible. There is a clear distinction between different component forms (See Figure 2.1). This also reflects to component-based development. Developers should notice the mapping between different forms. Main forms are explained in figure 2. Component standards, such as EJB and COM+ are part of component technology families evaluated in this study. Component must conform to an environment standard for the developer to be able to assemble applications from components. Component specification is a unit of software that describes the behaviour of a set of component objects and defines a unit of implementation. The behaviour is defined as a set of interfaces. There could be many-to-many mappings between interfaces, specifications and implementations. One component specification can have many interfaces. One interface and specification can in some cases be implemented using different technologies. The component implementation is a realization of a component specification, which is independently deployable. This means it can be installed and replaced independently of other components. It does not mean that it is independent of other components. One implementation can support several interfaces. A collection of interfaces supported by some implementation is called component type (Sessions 2000). Installed component is an installed (or deployed) copy of a component implementation. A component implementation is deployed by registering it in the runtime environment. This enables the runtime environment to identify the installed component to use when creating an instance of the component, or when running one of its operations. Component instance is a runtime concept. It is either an object with its own data and unique identity or a running service implementation. The thing that performs the implemented behaviour. Runtime resources can be increased linearly by creating component (object) instances when needed. This can improve scalability. An installed component may have multiple component objects (which require explicit identification) or a single one (which may be implicit). STUDIES AND REPORTS OF THE PLUGIT PROJECT 1 14

15 Figure 2.1. Component forms (adapted from Cheesman and Daniels, 2001) Figure 2.2. Distributed component model (adapted from Herzum and Sims 2000). Component instances live in component execution environment, often called CEE. It is the run-time socket into which a component plugs and within which it executes. The CEE consists of a defined set of services, facilities, and middleware, and it is the run-time part of the component virtual machine. It is the software that the component is dependent on during runtime. Middleware is part of infrastructure where components lie. Middleware can offer several services to components i.e. naming, security and persistence. A component model gives a unified view of these services for components, often providing a container into which to plug the component and tools to deploy components. A socket is a part of runtime environment. It provides a number of services for components, for example loading and destroying components from memory. Components, especially distributed components may also have network-addressable interfaces for communication mechanisms. Plug is a part of a component that allows the component to be deployed autonomously into the provided socket of the runtime environment. It is specific to the component implementation 15 COMPONENT AND SERVICE TECHNOLOGY FAMILIES

16 technology used and often transparent or automatic from the developer point of view. Component interfaces and proxies are discussed in next chapter. 2.2 Interfaces and Services Components are put together in order to build more complex components or composable software systems. For this purpose, they should have separated implementation and definition of services. That is why components implement the unification of data and functionality through interfaces. An interface is an access point to component services. It is a set of named operations that can be invoked by clients. The client of a software component is separated from how that software artefact data is stored or how its functions are implemented. We say that the client depends on the component specification, not its implementation. This is discussed in detail in chapter Components have several different types of interfaces: An offered interface (component interface, stub) is a set of services the component can offer to other components and applications. A required interface (proxy, skeleton) is a set of services the component requires from other components or applications. A component platform (plug) is the set of other programs the component requires to operate. These programs include operating system, communications and other programs which are not used through required interface. A configuration interface can be offered by the component to adapt the component into different requirements or specific platforms. Offered interface and required interface are used to compose applications from components and inter-component dependencies are handled through this composition interface. Configuration interfaces are discussed in chapter 2.4. Components can also offer a user interface, but we do not consider it as an interface in this study but discuss user interfaces separately. Also specific interfaces can be offered to use the component in the development environment. Offered interface defines a set of services the component can offer. Interfaces have several functions (Herzum and Sims 2000): they hide the internal implementation details: same interface can be provided by different components or different implementations, they offer a centralized point of service for the component user, as long as the component user can locate the component and know which services are available, they may offer services in a distributed way over the network (location transparency). Composition interfaces can also be seen as contracts between a client of an interface and a provider of an implementation of the interface. The specification of an interface usually includes operations and some kind of information model. Operations define the functionality of the component, and have parameters for the needed or returned information. Each operation can be seen as contract of its own. It defines inputs, outputs and relations between them and also conditions under which they apply. Each operation can have a precondition as a definition of situations under which the post condition will apply. It is the client s responsibility to ensure that the precondition is true before making the call. If the precondition is not met the expected behaviour might not happen and the result is undefined. If the precondition is true, it is then the supplier s responsibility to satisfy the STUDIES AND REPORTS OF THE PLUGIT PROJECT 1 16

17 post condition for example return the wanted value type. In user point of view it does not matter how the response is created, it is sufficient to satisfy the end user goal. This is also known as callee-makes-right principle (Szyperski 1999). Component technologies support location transparency using proxies as surrogates (See Figure 2.3). The principle in remote method invocation is simple: the client s process and the component process are separated. In addition to make the geographical distance transparent a surrogate (proxy) is made of each process and communication is made through them (Sessions 2000). Communication uses standard protocols, like TCP/IP or HTTP. Figure 2.3. Remote method call (Sessions 2000). 2.3 Customization Reusable components are not usually readily suitable in different contexts they are used in. The component must be adjusted to fit it into its final context in the application and in the execution environment. The adaptation can be planned, but it should also be possible to adapt the component in unforeseen situations. With customization many different end products can be designed with the help of component providing some degree of adaptability. Although two components may be developed and defined using the same or compatible component platforms, there are a variety of application-level conventions that need to be adopted by both of them to coexist with an application. For example, they may need to manage errors in the same way. Components can offer variability mechanisms which offer pre-defined means to adapt the component (Bosch 2000): If component is implemented as a class, inheritance can be used to specialize the component. This white-box adaptation requires understanding of the internal implementation of super class and may make the system harder to understand and to test. Extensions are variability points, where the user of the component can select one of predefined implementations or implement a new extension for a given aspect. Configuration interfaces can be offered to the component user, when different implementations in different variability points are included in the component. Configuration interface offers component user parameters like communication port or URL-address, those can be selected a desired variant. 17 COMPONENT AND SERVICE TECHNOLOGY FAMILIES

18 Some programming languages offer templates, which can be used if there is a need for components to be configured using application-specific types. Generation means that the component user can use a language or a tool to prepare a specification, from which a generator creates (typically source code level) new components. Unforeseen adaptation of components can be achieved either in a black-box or in a whitebox manner (Bosch 2000). In white-box adaptation, the internal specifications of the component are changed, or some parts of the internals are overwritten or excluded. In black-box adaptation, the component is used as it is, but the interface is adapted (e.g. wrapping). STUDIES AND REPORTS OF THE PLUGIT PROJECT 1 18

19 3 FEATURES OF COMPONENT TECHNOLOGY FAMILIES This chapter clarifies basic concepts and objectives of the study that are used in the following chapters. It introduces common parts of different component technology families. Component technologies contain many diverse aspects. Typical focus in comparing component technologies has been focused on message delivery and structure of the interfaces. In this study, we assess also many other aspects of component technology families. This study evaluates component implementation technologies, technical core and services and facilities which form an execution environment for component-based applications (See figure). It also assesses usability of different service and component-based technologies in integration. Different development tools and environments related to different component technology families are evaluated in a separate study. Technical architecture implementation Component Execution Environment (CEE) Development environment Technical core Services and facilities Component implementation technologies }Technical infrastructure Figure 3.1. Major parts of the technical architecture (Herzum and Sims, 2000). 3.1 Reference application architecture The basic architecture of a component technology family describes the main parts of the applications and their relationships implemented using the architecture. Typically some parts are located on the server(s), others on clients. We use the business component architecture (Herzum, Sims 2000) as reference architecture for distributed parts of the system (Figure 1). In the architecture, several tiers are used to separate the responsibilities of different parts of the system. The execution environment (infrastructure) provides different services in different tiers. In multi-tier or client/server systems, the tiers of the 19 COMPONENT AND SERVICE TECHNOLOGY FAMILIES

20 model can usually be identified, at least as logical layers, some of which may be implemented using healthcare-specific integration platform or middleware. In this study, we use the architecture to locate software parts in component technology family architectures: Dependency Business component User Workspace Enterprise Resource Socket Plug user interface framework local CEE (Java, COM) enterprise CEE persistence framework Infrastructure single user domain multi-user domain CEE = component execution environment Figure 3.2. Application tiers and the execution environment (adapted from (Herzum and Sims, 2000)). The user tier (U), which typically contains a graphical user interface, located in end-user workstation. The user tier may integrate several services or components from lower tiers. It is responsible for all communication with the user. The user tier may consist of one or several components using lower level components and delivering channel to end user to work through all tiers below. The workspace tier (W), which contains application logic for supporting the work of one user, often also the state and the clinical context of the application. Location of the workspace tier may be together with the user interface in the user workstation (fat client) or it may be located on a server (e.g. web server, thin client). The workspace with user tier is client part of the system and represents single user. The workspace tier implements local business logic interacting with the enterprise tier to access any enterprise-level resources needed to support the current user s work. Separation from enterprise level allows different kinds of optimization and specific functions for end users. This tier also may also enable storage for user-specific preferences. The enterprise tier (E) provides distributed application logic of the component or the application, typically used over the network. This tier is critical for many quality attributes of distributed applications. The physical location of the enterprise tier is typically an application server, which provides a runtime execution environment for components in this tier. In some architectures (e.g. Cheesman, Daniels, 2001), server parts of the architecture have domain or application-specific systems services and generic business services. We consider these services to be located in the Enterprise tier, possibly as separate (internal) tiers. In some other approaches (e.g. Ferrara 1998, OMG 2000) some services are seen as part of the infrastructure, and may contain many domain-specific or domain-independent services to support applications (e.g. events, transactions, person identification). Enterprise tier is critical for many quality attributes of the system because it contains most of shared business logic and scalability, performance optimization and security features. STUDIES AND REPORTS OF THE PLUGIT PROJECT 1 20

21 The resource tier (R) typically contains the persistence aspects of the application, or encapsulates legacy systems. It is preferred to integrate applications on the upper tiers rather than on data storage or the resource tier, which can risk the data integrity controlled by business rules in upper tiers. From each component technology family, we describe the basic architecture as presented by the technology family providers, and relate it to the reference architecture above. Some component technology family architectures only focus on some of the tiers. The separation between various tiers is not always clear, and in this work we try to locate responsibilities related to tiers in this reference architecture in real-world architectures in different technology families. Another aspect on the architecture is whether the architecture is service- or object-oriented. A rule of thumb can be used: if enterprise tier components have states (attributes, one instance for one user or for one entity which is used), the architecture is object-oriented. If enterprise tier components have only operations (and identification of a record or entity is passed as a parameter), the architecture is service-based. Some component technology families support both service-based and object (instance)-based architectural styles. There are also many other views to software architecture, including functional architecture. These views are not addressed in the reference architecture, as the purpose of this reference architecture is to provide means to identify and locate comparable distributed parts in component technology families. 3.2 Parts of component technology families Communication middleware Many component technologies have evolved from remote procedure-based middleware technologies. For distributed communication, component technology models have communications middleware. Purpose of this middleware is to achieve location transparency, i.e. to enable the use of remote objects or services in a transparent way. A typical distributed communications middleware is based on the use of Remote Procedure Calls (RPC). RPC is a simple mechanism, where a sender (client) sends a message to the receiver (server) and receives a response message. The sender s message contains operation name and parameters, which are needed to execute a certain procedure or a method on the receiver, and the result of the method is returned in the response message. RPC communication can be found in all types of distributed middleware, such as Object Request Brokers (ORBs), Transaction Processing Monitors, Message-oriented middleware and SOAP communication over HTTP (Alonso et al. 2004). Communications middleware is used typically between distributed parts of the system (for example, between different components in Enterprise tier, or between Enterprise and Workspace tiers). Furthermore, components or services can be found using different mechanisms. In this study, we identify and describe the distributed communication middleware technology or technologies in each component technology family. Also limitations to the communication are described, including the limitations set by firewalls in the network etc. We also describe mechanisms or services using which the component user can find the installed implementation of the distributed component or service. 21 COMPONENT AND SERVICE TECHNOLOGY FAMILIES

22 3.2.2 Interface definitions Component technology families offer means to define interfaces of the components or the services. As we study interface definitions, we look at the following aspects: Are there Interface Definition Languages (IDL) in the component technology family? How are operations, data contents, modules and objects defined in the interface definitions? How are required and offered interfaces specified? Can objects be transmitted over the network and how is this specified? Each component technology family can offer several different solutions for interface definitions and implementations. For example in Workspace or User tier, different interfaces can be offered than on the server, or the component model can provide extensions to the interface definition language provided by the component communications middleware Component model Component model is a set of defined rules for components in component technology family. Different component categories (such as entity and session components) can be offered in some technology families. Different component models can be offered for distributed components and local components. For example, EJB and COM+ components are distributed component models, whereas JavaBeans and ActiveX controls follow a local component model. In many cases, distributed component models are extensions to local component models. Component model can offer specified or implemented containers for components. Component containers can also offer different services for components. Applications can be adapted by configuring containers in addition to configuring the components themselves. Component model can also offer different component categories or templates (e.g. entity and session beans in EJB) for different purposes. We describe the nature of the component model, (is it binary level or specification level, does it only consider interfaces, does it contain class libraries etc.). Specify what is component in the model (e.g. binary implementation of one or more interfaces, set of classes and their resource files), is there a way to tell if the component follows the standard, what services do containers offer to the component (e.g. lifecycle, persistence). Component model provides a framework for set of components in the technology family. Framework is often explained as a partial architecture of a system. According to Szyperski (1999) a component framework is a dedicated and focused architecture, usually around few key mechanisms, and a fixed set of policies for mechanisms at the component level Support for programming languages and execution platforms Platform neutrality in component technology families can be approached on several levels, in addition to location transparency provided by communications middleware: same components can be executed on different operating system platforms, same components can be utilized using different programming languages, components fulfilling the same interface can be implemented using different programming languages. In this study, we list requirements for the execution environment for different component technology families, and supported programming languages. We also list available or needed repositories (component repository, interface repository) and other software services in component technology families, and some available implementations of the execution environment. STUDIES AND REPORTS OF THE PLUGIT PROJECT 1 22

23 3.2.5 Deployment and transferability of components Component models and technologies may offer specialized mechanisms or tools for making deployment packages and deploying components and applications to the execution environment. We discuss these solutions and also assess how dependencies of the execution environment and other components are documented so that components can be reused. We also discuss, on what level the components can be transferred and reused. Software modules and components can be reused: by using the source code of the component (source code reuse), by installing the component in the development environment and compiling and deploying the component as part of the application which is deployed, (static binding to implementation), by installing and reusing a component with the same interface both in the development environment and the deployment environment (early static binding to interface), by installing and reusing a component with the same interface both in the development and deployment environment and configuring several aspects of component in deployment environment (late static binding to interface) by installing and reusing the component in the development or execution environment and finding the component instance based on the runtime requirements of the interface to be used (dynamic binding). Early binding usually increases efficiency and safety, but reduces flexibility of the applications. Typically, component technologies are required to support at least early static binding to interface. Different reuse strategies have different implications to the deployment, installation, maintenance and update of the components and applications. Documentation of dependencies (from the execution environment and other components) has effects on the reusability of the components as well Other quality properties Component models and technology families offer tools or solutions to implementing different nonfunctional requirements of the applications. If the component technology family offers solutions to these aspects, they are documented in this study. If implementation of these aspects is product-specific, these features are not documented in this study in detail. Security: encryption of network traffic, user management and session management, authentication of users and components, authorization, auditing. Scalability: performance monitoring, duplication of components or services on several servers, adding new hardware (e.g. server clusters), quality-of-service (QoS) mechanisms, adaptation to network or hardware limitations. Additional issues concerning for example maintainability and extensibility are also described here. 23 COMPONENT AND SERVICE TECHNOLOGY FAMILIES

24 3.2.7 Additional properties Component technology families offer additional services for event-based communications, distributed transactions etc. These services are listed in this study. Also asynchronous messaging middleware (message services, message queues) that is often used in integration is briefly described, if there are such solutions in the family. Usually the basic message passing in component technologies is synchronous request-reply communication. One important aspect which supports reuse is the ability to adapt or extend components (Bosch 2001). We describe these features in the technology family or component model. Here we also study if the component model offers also separation and sharing of different aspects in application (e.g. security properties separated from the implementation of the functional component). Aspects consist of features that are related to one specific area of requirements, and aspect separation can be supported by offering several component interfaces (one for each aspect) or by defining aspects separately and combining them into components using a separate tool. In additional properties we discuss, which parts of the infrastructure are always needed, which parts are optional or useful only in particular situations. Other important properties of the component technology families are also described as needed. 3.3 Application development process Component-based application development process typically involves the phases in figure 3.3. In requirement specification phase, functional and quality requirements are elicited. In specification phase, component interfaces (required and offered) are specified. In provisioning phase, suitable components are bought, acquired or developed. In assembly phase, applications are assembled from components, after which the integration testing is conducted. After this, the composed application is deployed to the final execution environments. After the deployment, components can be updated with new versions. However, the traditional application development model (including requirements gathering, analysis, design, implementation, testing, deployment and update) is usually also needed, if some of the parts of the application are implemented and not only assembled. In each component technology family, a basic workflow in building applications is described. Different phases of the implementation and deployment are considered in detail. Previous phases of the development process, including requirements gathering, analysis and design of the system are not in focus of this study. In addition to the development process, a management process is also needed to support the acquisition of resources, version control, architectural and managerial visions. There are very many options to acquire functionality into component-based systems (Figure 3.4). Traditional "build or buy" options have many alternatives, from adapting old systems to extending reusable frameworks or subscribing to distributed services (Allen 2001). STUDIES AND REPORTS OF THE PLUGIT PROJECT 1 24

25 Business requirements Use case models Requirements Existing assets Concept models Specification Provisioning Assembly Technical constraints Component specs and architectures Components Test Applications Tested applications Update Deployment Figure 3.3. Component-based application development process (adapted from Cheesman, Daniels 2001). Internal assets Build components Harvest components from old applications Adapt old systems External assets ASP services Subscribe to distributed services Buy components Extend framework Outsource design Existing infrastructure Existing know-how New technologies New know-how Existing assets Provisioning Components Technical constraints Component specs and architectures Figure 3.4. Component provisioning options. There is usually a set of preferred or recommended ways applications are implemented using a given component technology family. We examine how different tiers are typically implemented using the technology family. These tiers include: data storage, application server components, web server components, web/mobile/thin client applications, workstation components and rich client user interfaces. In this study, we also discuss technologies that are not directly related to component model or component middleware but are still part of the technology family or can be easily used together with component family technologies. Typical ways to implement these aspects are studied here, and more detailed study of implementation tools will be conducted in development environment study. 25 COMPONENT AND SERVICE TECHNOLOGY FAMILIES