Integration of Component-Based Development Concepts and RM-ODP Viewpoints Zoran Stojanovic1, Ajantha Dahanayake1, Henk Sol2 1
Department of Information Systems, Faculty of Information Technology and Systems, Delft University of Technology, Zuidplantsoen 4, 2628 BZ Delft, The Netherlands
[email protected],
[email protected]
2
Department of Information, Communication and Systems, Faculty of Technology, Policy and Management, Delft University of Technology, Jaffalaan 5, NL-2628 BX Delft,
[email protected]
Abstract. The most prominent solutions for efficient management of complexity and rapid changes in the modern enterprise world are standardisation efforts in the field of open distributed systems such as ISO Reference Model of Open Distributed Processing (RM-ODP) as well as a new plug-and-play component-based system development (CBD) paradigm. This paper shows the way for a seamless and meaningful integration of these two powerful concepts that can be beneficial for both sides. RM-ODP can adopt high-level component-based concepts in order to reach more consistent system specification, which can be effectively mapped to component-based system implementation using already available component technology. CBD can effectively use RM-ODP as an underlying specification framework in order to provide a systematic, consistent and integrated CBD approach, by integrating component concepts consistently into all phases and aspects of the enterprise system development, from business to implementation.
1 Introduction Remarkable increase in the range and variety of available information technology (IT) today provides a number of possibilities for building enterprise-scale solutions. Many organisations are intensively looking for the way to effectively use advanced technology opportunities in conducting their business, under the constant pressure of ever-changing demands in the business and IT environment. It raises the necessity for open, interoperable systems, not only open in terms of topology (distributed systems) and platform (heterogeneous hardware and software), but particularly in terms of changing requirements, which evolve rapidly and are neither closed nor stable [17]. The most important standardisation effort in this field is the ISO Reference Model of Open Distributed Processing (RM-ODP) [22-25]. Although the ideas of ODP were founded much earlier, only recently it has started gaining a growing interest and popularity. On the other hand, there is a growing interest in the research community and industry over component-based development (CBD) [5,30]. CBD is often being introduced as a new paradigm for the development of enterprise distributed information systems. CBD provides organisations with a method for building
complex enterprise-scale solutions that are flexible and able to accommodate the everchanging demands in the environment, in a cost-effective, timely manner. By using the CBD approach, a system development becomes the selection, reconfiguration, adaptation, assembling and deployment of encapsulated, replaceable and reusable, building blocks with hidden interior called components, rather than building the whole system from scratch [4]. This paper explores the possibilities for a seamless and meaningful integration of these two powerful concepts for the system specification and development that can be beneficial for both sides. RM-ODP can adopt component-based concepts and way of thinking to reach more advanced system specification, which can be effectively, mapped to component-based implementation using already available component technology. On the other hand, CBD can effectively use RM-ODP as an underlying specification framework in order to provide a systematic, consistent and integrated CBD approach, by integrating the component concept consistently into all phases and aspects of the enterprise system development, from business to implementation.
2 RM-ODP Basics RM-ODP is a joint standardisation effort of the ISO (International Standardisation Organisation) and ITU-T (International Telecommunication Union) [22-25]. It has just recently reached the focus of attention from academia and industry. An enterprise system development using advanced IT solutions and trying to be business adaptive has a strong need for a standard, structural and consistent framework which can be offered by RM-ODP. During the last few years, many initiatives in industry and academia over advanced specification and standardisation of open and interoperable systems in various domains based on RM-ODP have started to appear. The examples in the area of Geographic Information Systems (GIS) are Open GIS Consortium (OGC) [20] and ISO/TC211 [12] with the aim of the full integration of geospatial data and geoprocessing resources into mainstream computing. The General Ledger Facility specification based on RM-ODP has recently been adopted as an OMG Finance domain standard [7]. Finally, in the telecommunications field, TINA-C (Telecommunications Information Networking Architecture Consortium) has defined an architecture for the telecommunications system development based on the RMODP concepts [31]. The initial efforts of the ODP community were concentrated on the computational and engineering aspects of open distributed systems. Along with strengthening the connections between business and IT in the modern enterprise systems, currently much attention is focused on the enterprise concepts of the system and accordingly on the Enterprise ODP Viewpoint [11]. Although the ODP viewpoints do not have to correspond to the phases of system development lifecycle, intuition behind the viewpoint definitions results in various interpretations. For example, in [21] Enterprise Viewpoint is related to requirements analysis, Information and Computational Viewpoints to functional specification, Engineering Viewpoint to design, and Technology Viewpoint to implementation. The methodology proposed in the ODAC project informally associates ODP viewpoints and software engineering phases in the same way [9]. As a conclusion, for each
development phase several (if not all) of the viewpoints can be used, but with corresponding emphasis on each of them and with different level of importance and details. Since the RM-ODP is not prescriptive about the use of any particular notation for specifying viewpoints, the use of the Unified Modelling Language (UML) as a standard object-oriented modelling language [18] for that purpose seems to be a natural choice. Many research efforts have been invested in defining the way of how to use UML diagrams in representing and specifying all five viewpoints [10] or particularly Enterprise Viewpoint [1, 3, 16, 28]. The common conclusion is that the UML concepts and its notation can be used for describing and representing RM-ODP viewpoints and accompanying concepts to some extent, mainly thanks to the extension mechanisms of the UML, such as stereotypes, tagged values, pre- and postconditions and naming conventions. Furthermore, the object-oriented structure of the RM-ODP framework naturally fits into the object-oriented foundation of the UML. The relation between RM-ODP and object-orientation is quite tight, making RMODP by definition an object-oriented specification framework. This might be the result of the fact that at the time RM-ODP concepts were developing, the objectoriented (OO) paradigm was gaining the full power and wide popularity in IT (but also in business) community. Furthermore initial efforts in ODP standardisation were concentrated on the engineering and computational aspects of the system, making object-orientation a natural solution through at that moment advanced distributed object computing paradigm. Due to wide acceptance of distributed object computing concepts and platforms such as OMG’s CORBA, object-oriented paradigm naturally fits in specification of Technology and Engineering Viewpoints. To some extent it can be used for Computational and Information Viewpoints specifications, owing to the rich experience in object-oriented analysis and design. But object-orientation cannot provide a natural solution for expressing higher-level concepts of the Enterprise Viewpoint, such as role, behavior and contract. Objects and/or classes in the objectoriented paradigm with accompanied data and functions, represent more implementation than conceptual and specification concepts. They rather suggest OO implementation using some OO programming language than technology-independent specification of the system, which is the main purpose of the RM-ODP specification framework. This results in following solutions commonly found in the literature: • defining the ODP object model as different and with wider scope than the conventional object model of the OO technology [15], • defining a common object model for the overall specification of the system across all viewpoints [32], • defining the object model for Enterprise Viewpoint with higher level of abstraction and with richer semantics than the object models for Information and Computational Viewpoints [1], • stating that object modelling is not appropriate and intuitive enough to be used in enterprise modelling inside the Enterprise Viewpoint [33]. The solution that naturally arises is to use the higher-level concepts concerning abstraction, semantics and granularity than simple OO objects and classes, as the central specification and modelling artifact across the RM-ODP framework. These concepts should adopt object principles (unification of data and behavior, encapsulation and identity) and extend these principles by hiding interior,
strengthening the role of the exterior, i.e. interface and becoming as independent as possible from the particular implementation technology. These requirements suggest using the concept of a component, but not along the standard way of treating it as a software package of binary or source code, than in a broader, more specification, and implementation-independent sense. This will be presented in the Section 4.1. The support for using component concepts in ODP specification framework can be found also in the current state of distributed computing models and infrastructures, potentially used for Technology and Engineering Viewpoints, that become highergrained and more component- than object-oriented. By adopting and integrating the component concepts uniformly and consistently into all RM-ODP viewpoints, an unified component-oriented specification of the system will be provided, where components are the central specification artifacts and common correspondence points among the viewpoints and across the framework. Such component-oriented specification of the system will be easily mapped to its component-based implementation using advanced CBD technology solutions.
3 Component-Based System Development Component-based development is rather an evolutionary than revolutionary approach. It inherits many concepts and ideas from the earlier encapsulation and modularisation, “divide-and-conquer” initiatives in the information technology (IT), such as module programming and object-orientation. During the last few years, due to the rapid development of Internet technology and enterprise applications, CBD paradigm has seen as the main strategic imperative for in-time and high-quality solutions [5]. Higher productivity, flexibility, and quality, through reusability, replaceability, efficient maintainability, scalability and parallel work are among the CBD claimed benefits [30]. Components can be placed on any network node, depending on application needs and regardless on the type of particular network structure. So far the CBD paradigm has been mainly introduced through the new technological solutions and distributed component infrastructures and models such as Microsoft’s Component Object Model (COM) [6], Object Management Group’s (OMG) Common Object Request Broker Architecture (CORBA) [27] or Java-based tools [14]. While the technology is necessary element of any solution, it is not sufficient by its own. Methods, techniques and tools for developing componentoriented applications are equally important, targeting that technology at the final phase. Conventional methods and approaches do not offer a full support for CBD, so that new approaches that are much closely aligned with CBD principles are required. IT community has just recently started exploring and inventing the methods and best practices for developing enterprise-scale, web-based systems from components. The further problem can be the lack of proper component-oriented modelling and specification notation. While the Unified Modelling Language is the standard objectoriented modelling language based on the assumption of object-oriented programming and implementation, it does not offer the first class component modelling concepts. UML takes more physical perspective on components, treating them as binary and/or source code packages and handling them only through implementation (component
and deployment) diagrams [18]. Although the current version of UML does not provide necessary elements and concepts for component-oriented modelling and specification, available extension mechanisms such as stereotypes, tagged values and naming conventions, are widely used for that purpose. Typically, today’s CBD methods and approaches to enterprise system development tend to consider business and technology issues and concepts separately, which leads to unsatisfactory results from both viewpoints. They use component concept in rather an inconsistent manner handling a component mainly as a binary package of software, limited by the use of the UML notation [2, 8, 13]. In order to gain a full benefit of CBD in an enterprise system development, a component concept must be an integral part of the whole system life cycle, from business requirements to implementation and deployment. Partition of problem space into constituent, self-contained parts (components) must be founded early in a development process and followed throughout it in a systematic and consistent way. Therefore, a general component concept is needed, providing a consistent and systematic component-oriented pathway throughout the whole lifecycle, and serving as a correspondence point among different aspects and perspectives on the system. A new component-based approach to system development is required, covering all aspects of enterprise-scale, data-intensive applications in integrated and consistent manner. Such integrated solution should provide a total system specification, from concept to deployment, through business, information, application and technology issues, using component-based concepts and principles.
4 Integration of CBD and RM-ODP Concepts In this chapter, the ways for an effective integration of the CBD and RM-ODP concepts will be explored, in order to overwhelm the shortcomings detected previously in both sides. First, an integrated component concepts with accompanying definitions and categorisation will be defined, independently of particular implementation technology and closer to the modelling and specification aspects of the system development. These component concepts will serve as a base for seamless integration of the CBD and RM-ODP. 4.1 Integrated Component Concepts Among the other important characteristics and benefits of the CBD approach claimed so far, in our opinion the component concept represents an excellent solution for providing a meeting point between technology and business worlds. By defining a component as an encapsulated concept, clearly delimited from the environment, with specific roles and behavior in the domain, with hidden interior and exposed functionality through services and interfaces, it can be easily understood by both worlds. Such concept gives business analysts and managers greater ability to model business processes and requirements at a higher-level, in a domain-specific, but implementation-independent way. On the other hand, the application developers
retain control over how their models are turned into complete applications using advanced component-based technology infrastructure. Object-orientation cannot be effectively used for that purposes. Objects can be too small in size and technologically oriented to be considered as basic units of a development process by business side people. The logic is usually too trivial to justify the expense of modelling, building, documenting and reusing a single object interface. On the other hand, business processes are often too fuzzy and complex to be uniformly and easily understood by IT side people. They must be broken down to constituent, semantically separated business building blocks in order to be efficiently handled by application developers. Furthermore, components as behaviour- or process-based concepts, handled through services they offer, represent more natural approach for describing complex business processes than objects as entity-based structures. Thus, a component can represent a lingua franca for business and IT worlds, i.e. a means for integrating instead of separating them. Component hierarchy considering granularity and functionality issues is shown in the Figure 1.
Fig. 1. Component hierarchy
-
-
Business System Component represents a business process built up of functional pieces (components) that cooperate to deliver the cohesive set of functionality required by a specific business need i.e. to provide a solution to a specific business problem, such as Invoice Management or Order Management. It can be a constituent component of a larger business system. Business Component represents a single autonomous real-world business concept in a service-based business architecture. It encapsulates everything about that concept including name, purpose, knowledge, behavior, role, objective, etc. Examples include: Customer, Product, Order, Inventory, Pricing, Credit Check, and Billing. At the specification level, service-based business component is completely independent on particular implementation. It can be developed on any platform using any technique and tool, depending on available technical environment.
-
Software Component is a physical building block used in the assembly of applications. As independent piece of software, it encapsulates data and operations, and fulfills specific service through well-defined interface. This type of component corresponds to the usual concept of component in the software industry, being a Java Bean, CORBA or COM+ component. It is normally, but not necessarily, built up using object-oriented paradigm.
Business component has two facets, specification and implementation, and represents a basic unit of an enterprise-scale information system. Business Specification Components represent the results of applying componentisation concepts and principles in the business domain. They model the enterprise, and thus enable future enterprise applications to more completely satisfy the business needs. They provide service-based, partitioned-partitioned view of the business domain and consequently an excellent way to define and scope the solution space, as a good basis for further development of an enterprise application. On the other hand Business Implementation Components handles the aspects and realities of the technical environment in order to offer a component-based implementation of the certain business concept. They provide an excellent way of applying “divide-and-conquer” principle at the implementation level in a way that ties application to the business domain. They provide the capability to package software realisation into more meaningful and manageable artifacts, inheriting the benefits of CBD approach. Business Implementation Components smoothly evolve from specification ones, simply by taking into account the reality of technical environment. In that way, they provide a mapping between particular business concepts and their technical representation. Business Components can be either entity-centric or process-centric. Business Entity Components have an emphasis on representing significant entities and concepts, as well as related information, inside the particular business domain. Business Process Components represent existing business processes, workflows and functionality in the domain. This categorisation cannot be quite strict, because most business concepts are a blend of both information and functionality. However, this separation of concerns can be important for better understanding the nature of business concepts, but especially in the implementation phase, where concepts like permanent data storage, as well as functions and function calls, are arising. 4.2 Component-based RM-ODP framework Already existing component middleware infrastructure OMG/CORBA is consistent with RM-ODP and provides technological solutions to support the ODP Engineering and Technology Viewpoints can be based on them. Furthermore, CORBA supports many of the common functions and distributed transparencies specified by the ODP standard [27]. Further aim is to incorporate component concepts and principles into the other ODP viewpoints, namely Enterprise, Information and Computational Viewpoints. In that way, the component concept, seen from different perspectives, is the common basis and correspondence point for the ODP viewpoints. Since the RMODP is a specification framework, the concept of Business Specification Components will be used in defining the ODP concepts. Furthermore, definitons, concepts and
constructs from the Part 2 of the RM-ODP standard [23] perfectly match the basic concepts of the component-based development theory. Enterprise Viewpoint defining purpose, scope and policies of an ODP system, naturally fit into behaviour-focused, interface-driven component specification and modelling. The main concepts of this viewpoint, namely community, contract, role, behaviour, enterprise object and policy perfectly meet the component concept theory, and can be represented using the concept of business specification components presented in the Section 4.1. Community is the key enterprise concept in RM-ODP, defined as a configuration of objects formed to meet an objective. It can be represented as a Business System Component or a Business Specification Component of a higher granularity, representing the configuration of corresponding enterprise objects (smaller-grained Business Specification Components) and the collaboration among them in order to reach an objective. Roles are used to identify the behaviour of enterprise objects in the community. On the other hand, a component interface by CBD theory defines a set of component’s behaviour through exposed services. The conclusion is that the role of an enterprise object can be represented through the interface (and its services) of a component representing that enterprise object. Policies are constraints or rules that constrain the behaviour of enterprise objects that fulfil particular roles in communities. They can be defined through specifying constraints, invariants, pre- and post-conditions on interfaces, more precisely on constituent services. Information viewpoint specifies the significant information stored and processed by the system, as well as invariants, constraints, and rules regarding the transformation of this information. Three types of information schemas are used for this purpose in RM-ODP, namely static (rules about state and structure of information at some point in time), invariant (information independent of behaviour) and dynamic (evolving of information through time). Elements of these schemas can be defined as Business Entity Components, representing elements in the ODP system, which carry necessary information. And again, transformation and processing of information can be specified by component interfaces, with corresponding pre-, post- and invariant conditions representing constraints and rules on that information management. Computational viewpoint is used to specify the functionality of an ODP system in still a distribution-transparent manner. It specifies functionality and process flows in the system by defining services offered by service-provider objects and used by service-consumer-objects. This functional linkage between objects is used to define complex collaboration and interaction in the ODP system. Object in the Computational viewpoint can be represented as Business Process Components, while interaction between them can be specified through their provided and required interfaces. Some aspects of the multi-tier environment must be taken into account in this viewpoint. The placement and organisation of component services and service flows in a multi-tier system architecture originally defined as OSE (Open System Environment) service tiers (User Interface, Business Application Logic, Information Storage, Communication) should be considered at this stage [26]. Typically, an Enterprise object in the Enterprise viewpoint as a Business Component of a higher-level of abstraction and granularity can correspond to one or many objects from Information and Computational Viewpoints. Roles, behaviours and policies of an enterprise object are represented by conditions and rules related to
information object(s), along with functions and corresponding constraints specified by computational object(s). As already mentioned there already exist many studies about using UML in specifying ODP Viewpoints, especially for Enterprise Viewpoint. Since component modelling issues are being given a high priority by both the UML Revision Task Force (UML RTF) and the UML 2.0 Working Group [19], resulting in that UML will evolve along with components to meet their special needs, our strong belief is that the future UML version will be sufficient for describing componentbased RM-ODP framework. 4.3 RM-ODP Based CBD Approach In order to synchronise IT and business efforts in enterprise system development, tight integration between them must be provided. The sooner we can identify components and integrate them first at the business requirements level and then into an appropriate model of the enterprise system, the faster and more accurately we can build the target system. All these requirements suggest using RM-ODP as an integrated underlying framework that can guide a component-based development process in a systematic and consistent way, from business requirements to implementation and deployment. Using general, well-grounded CBD theory presented in the Section 4.1, component-oriented viewpoint specifications presented in the Section 4.2, and basic definitions and constructs from the Part 2 of the RM-ODP standard [23] we aim to define a new approach for component-based development of enterprise-scale systems [29], Figure 2.
Fig. 2. An integrated CBD approach
The result of the integration of RM-ODP and CBD concepts should represent an integrated component-based development approach, covering all aspects of building a complex enterprise system, in a systematic and consistent way. Such integrated solution should provide a total system specification, from concept to deployment,
through business, information, application and technology issues, using advanced CBD concepts and principles. The approach provides a rich specification way for describing not only behavioral and structural aspects of complex enterprise systems, then also significant human and organizational aspects. By following semantically separate but consistent tracks defined by component-oriented viewpoints, the approach enables an integrated view on the system through its constituent parts. The viewpoint specifications evolve coordinately through time, resulting in an overall specification used as a firm base for future development of an enterprise system. Using RM-ODP framework as a standard base results in applying of CBD principles and practice, from enterprise concepts and requirements to implementation and deployment, in a rigorous and consistent manner.
5 Conclusion As effective as possible way of using new information and communication technologies are nowadays becoming a crucial point in organisations’ business strategy, and main factor for being competitive on the market. Among the solutions for the new challenges are standardisation efforts in the field of open distributed systems such as ISO Reference Model of Open Distributed Processing (RM-ODP) as well as using a new plug-and-play system development paradigm, known as component-based development (CBD). This paper explores the possibilities for a seamless and meaningful integration of these two powerful concepts for the system specification and development that could be beneficial for the both sides. Classical object model inherited from the OO programming language theory represents mainly an implementation concept, aimed toward OO implementation rather than technology-neutral specification of the system. Furthermore, object-orientation provides only a limited support to higher level concepts defined in the viewpoints, especially in the Enterprise Viewpoint. Finally, component-based distributed infrastructure models, such as CORBA component model, EJB and COM+ are already widely accepted at the level of engineering and technology. All these aspects suggest integrating component-based concepts and way of thinking into the RM-ODP viewpoints in order to reach more advanced system specification. This specification can be effectively mapped to component-based system implementation using available component technology solutions. On the other hand, current CBD methods and approaches do not include the full support for the component concept. It results in the fact that components are handled mainly at the implementation and deployment phases, instead of being focal point of the complete system life cycle. The methods are significantly influenced by their OO origins, while trying to introduce the CBD concepts mainly through the use of standard UML concepts and notation. Such state-of-the-art of the methodology practice suggests using RM-ODP as an underlying specification framework in order to provide a systematic, consistent and integrated CBD approach. It can be done by seamless integration of the component concepts into each of the five RM-ODP viewpoints, making the whole lifecycle, from business requirements to implementation and deployment, truly component-oriented. In that way, the full
benefit of the CBD paradigm in the development of complex and rapidly evolving enterprise distributed information systems will be achieved.
References 1. Aagedal, J., Milosevic, Z.: ODP Enterprise Language: UML Perspective. 3rd International Enterprise Distributed Object Computing Conference (EDOC’99), September 27-30, 1999, University of Mannheim, Germany (1999) 2. Allen, P., Frost, S.: Component-Based Development for Enterprise Systems: Applying the Select Perspective. Cambridge University Press (1998) 3. Blanc, X., Gervais, M.-P., Le-Delliou R.: Using the UML Language to Express the ODP Enterprise Concepts. Research report Laboratoire d'Informatique de Paris 6 1999/024, November (1999) 4. Brown, A.W., Wallnau, K.C.: The Current State of Component-Based Software Engineering. IEEE Software, September/October (1998) 5. Butler Group: Component-Based Development. Management Guide, Researched by D. Sprott and L. Wilkes, available at http://www.butlergroup.com (1998) 6. COM, DCOM, MTS, ActiveX, COM+, information available at http://www.microsoft.com/com/ 7. COMPASS COMPonent based Accounting Service and System (COMPASS) project, General Ledger Facility specification, available at http://www.compassgl.org/ (1999) 8. D’Souza, D.F., Wills, A.C.: Objects, Components, and Frameworks with UML: the Catalysis Approach. Addison-Wesley (1999) 9. Gervais, M.P., Blanc, X., Muscutariu F.: ODAC Project: Open Distributed Applications Construction. Available at http://www-src.lip6.fr/projets/agentseng.html (2001) 10. Hassall, J., Eaton, J., Gray, G., Wilcock, M.: Applying ISO RM-ODP and UML in the Specification of Standard Interfaces to General Ledger Systems. COMPonent based Accounting Service and System (COMPASS) project, available at http://www.compassgl.org/ (1999) 11. ISO/IEC, JTC1/SC7/WG3: Information Technology- Open Distributed Processing – Reference Model – Enterprise Viewpoint. ISO, Washington output N65, March (1999). 12. ISO/TC211 International Standardisation Organisation /TC211, Geographic Information - Geomatics, Web page http://www.statkart.no/isotc211/ (2000) 13. Jacobson, I., Booch, G., Rumbaugh, J.: The unified software development process. Reading MA : Addison-Wesley (1999) 14. JavaBeans, The source for JavaTM technology at http://java.sun.com. 15. Kutvonen, L.: architectures for Distributed Systems: Open Distributed Processing Reference Model. HeCSE Workshop on Emerging technologies in Distributed Systems, Lammi, January 12-13, (1998) 16. Linington, P.F.: Options for expressing ODP Enterprise Communities and their Policies by using UML. In Proceedings of the Third International Enterprise Distributed Object Computing Conference, September (1999) 72-82
17. Nierstrasz, O. and Dami, L.: Component-Oriented Software Technology. ObjectOriented Software Composition, Oscar Nierstrasz and Dennis Tsichritzis (Eds.), pp. 3—28, Prentice Hall, (1995). 18. Object Management Group: Unified Modeling Language 1.3 specification, document ad/99-06-09. Available at http://www.omg.org/uml/ (1999) 19. Object Management Group: UML 1.4 Revision Task Force, UML 2.0 Working Group and Request for Proposal, available at http://www.celigent.com/omg/umlrtf (2000) 20. Open GIS Consortium: The OpenGISTM Guide: Introduction to Interoperable geoprocessing and the OpenGIS Specification. Third edition, available at http://www.opengis.org (1998) 21. Raymond, K.: Reference Model of Open Distributed Processing (RM-ODP): Introduction. Proc. of the 3rd IFIP TC6/WG6.1 International Conference on Open Distributed Processing, Brisbane (Australia), February 20–24, (1995) 3-14 22. RM-ODP , International Standard Organisation (ISO), Information technology Open Distributed Processing - Reference model: Overview, ISO/IEC JTC1/SC07, 10746-1, ITU-T Recommendations X.901 (1996) 23. RM-ODP , International Standard Organisation (ISO), Information technology Open Distributed Processing - Reference model: Foundations, ISO/IEC JTC1/SC07, 10746-2, ITU-T Recommendations X.902 (1996) 24. RM-ODP , International Standard Organisation (ISO), Information technology Open Distributed Processing - Reference model: Architecture, ISO/IEC JTC1/SC07, 10746-3, ITU-T Recommendations X.903 (1996) 25. RM-ODP, International Standard Organisation (ISO), Information technology Open Distributed Processing - Reference model: Architecture semantics, ISO/IEC JTC1/SC07, 10746-4, ITU-T Recommendations X. 904 (1996) 26. Schulz, F.: Open System Environment (OSE): Architectural Framework for Information Infrastructure, NIST Special Publication 500-232 (1995) 27. Siegel, J.: CORBA 3: Fundamentals and Programming. John Wiley & Sons, Inc. (2000) 28. Steen, M.W.A. and Derrick, J.: Applying the UML to the ODP enterprise viewpoint. Technical Report 8-99, Computing Laboratory, University of Kent at Canterbury, May (1999) 29. Stojanovic, Z., Dahanayake, A.N.W., Sol, H.G.: Integrated Component-Based Framework for Effective and Flexible Telematics Application Development. Technical report, ISBN: 90-76412-13-8, Delft University of Technology, November (2000). 30. Szyperski, C.: Component Software: Beyond Object-Oriented Programming. ACM Press, Addison-Wesley (1998) 31. TINA Telecommunications Information Networking Architecture Consortium, Service Architecture 4.0, available at http://www.tinac.com (1996) 32. Vallecillo, A.: RM-ODP: The ISO Reference Model for Open Distributed Processing. Num. especial de la revista de DINTEL sobre normativa en Ingeniería del Software, May (2000). 33. Wood, A., Aagedal, J., Milosevic, Z.: Describing Virtual Enterprises: the Object of Roles and the Role of Objects. OOPSLA'98 Workshop on Virtual Enterprises, Vancouver, October (1998)
