Keywords:ODP reference modelInter-enterprise collaboration environmentService ecosystemInteroperabilityService-oriented computing and softwareproduction
This paper reflects on the use of the ODP reference model in the development of Pilarcos open service ecosys-tem architecture. The Pilarcos open service ecosystem architecture provides an environment where inter-enterprise collaborations can be collectively managed, utilizing correctness and acceptability criteria set inecosystem-wide dynamic processes. The correctness requirements are defined in terms of business networkmodels, policies and service definitions that are dynamically utilized as complex conformance referencepoints. Failures to conform to these reference points trigger pre-committed recovery behavior. The ODPreference model provides sufficient and efficient facilities for the design of this kind of complex, adaptivesystem.
The success and competitive edge of enterprises have become in-creasingly dependent on the enterprises' agility to act as members inbusiness networks that support their own business strategies. There-fore, integration solutions with their well-weathered strategic net-works are no longer sufficient. Instead, there is need for more openmarketplaces where previously unknown services and partnershipscan be utilized.
In fact, just the marketplace is not sufficient, but open service eco-systems are required. In biology, an ecosystem means an environ-ment where flora and fauna live and die, utilize resources andinteract with each other, and eventually, new species can develop.This behavior is restricted by laws of nature, or by, for example,human interventions.
Similarly, inter-enterprise collaborations (i.e., business networks)that are governed by multi-party contracts can be bred, run their nat-ural life-cycle, become terminated, and leave experience knowledgebehind in a service ecosystem. The open service ecosystems comprisegovernance processes for inter-enterprise collaboration creation,competition, and ecosystem evolution controlled by its “naturallaws”. The ecosystem is supported with infrastructure services thatsolve the evident problems of semantic and pragmatic interoperabil-ity and collaboration-governing contract management. Furthermore,the ecosystem must support the creation of trust relationships withpreviously unknown partners, and reacting to encountered breachesof trust within collaborations.
Enterprises seeking success through networked business expect toimplement their strategies through the creation of new market op-portunities by new collaboration models (i.e., business network
rights reserved.
models), new collaborations and offering new services. They also ex-pect efficiency of service production through reusability, model-based, platform-independent methodology and tools. Furthermore,enterprises need automation utilities for decision-making for com-mitting to collaborations and for producing feedback for businessprocess improvement (BPI), ecosystem improvement and improvingtheir own positioning on the open service markets that the ecosystemrepresents.
To address this challenge, we have set as our goal to create a com-putating environment to support consistent service ecosystems [1].The criteria for a successful service ecosystem architecture includevalid functionality for the needs of networked business, involving
• the life-cycles of individual collaborations,• the gaining of experience on the suitability of services and businessnetwork models available and utilizing that knowledge to improvethe ecosystem,
• the production of services and business network models to the eco-system, and
• the guarding of membership in the ecosystem.
In addition, the ecosystem architecture nonfunctional propertiesneed to satisfy the stakeholders, such as acceptable performanceand overhead in terms of operation time and effort of system man-agement, and correctness and completeness of computationalsolutions.
The functional and non-functional requirements address thebusiness-level expectations a) from an individual enterprise pointof view, b) from the established collaboration point of view, andc) from the ecosystem point of view. The involved stakeholders alsoinclude those enterprises that provide infrastructure services to sup-port the basic processes of collaboration management in the system.
The resulting service ecosystems are complex, adaptive systems.The ecosystem infrastructure has the role of helping enterprises and
collaborations to react to business-related and technical changes intheir environment, and governing the correctness and acceptabilityof collaborations.
The design of such a large complex, adaptive system requires the useof a consistency-supporting conceptual model and the use of viewpointmodeling to succeed. In our work on developing the Pilarcos open ser-vice ecosystem [2,1] the interaction with the development of the ODPreference model framework (open distributed processing referencemodel [3,4], ODP RM) has had a significant role. We have directly uti-lized many of the ODP basic concepts and terms, while enhancingsome of them to directly address the networked business domainneeds. Furthermore, we have adopted the ODP viewpoints for the sep-aration of concerns in the management of ecosystem artefacts.
This paper discusses the governance principles, processes, andecosystem infrastructure functionalities in the Pilarcos open serviceecosystem architecture. We will see how ODP concepts and view-points have been utilized for dynamically declared reference pointsthat ensure some correctness and appropriateness properties ofthe established collaborations. Further, we find ODP referencemodel to be a sufficient and efficient tool for specifying complex,adaptive systems.
The remaining paper is structured as follows. Section 2 discussesthe challenges of open service ecosystems and their governance,while Section 3 recaptures the essential features of the ODP refer-ence model. Section 4 discusses the ecosystem utilities and meansfor collaboration management in such a way that the correctnessand appropriateness of the collaboration can be controlled throughdynamic reference points. The section also indicates where theODP concepts, viewpoints and functions are utilized. Section 5 iden-tifies the extensions the Pilarcos architecture has made to the ODPelements, compares Pilarcos to service-oriented computing (SOC)environments such as the Web Services technology stack (WS),and virtual organization breeding environments (VBE). We concludewith recommendations on future ODP family standardizationthemes.
2. Towards open service ecosystems
The challenges of modeling and engineering services and manag-ing inter-enterprise collaborations have risen as technological en-ablers have been developed. In addition to supporting technicalinterworking transparency in enterprise systems and in distributedcomputing generally, recent development has increased the pressureof incorporating business-level intelligence into the interoperabilitysolutions. Moreover, automation and dynamism of collaborationmanagement have become an important requirement. However, cur-rent solutions are still largely working on ad hoc solutions, instead ofincorporating systematic solutions of verified, monitored consistencycontrol across both the development and operational environments.
In the following we give a brief overview of the technology evolu-tion steps required for reaching service ecosystemmaturity, provide ageneral overview of the ecosystem members and roles, and the eco-system structure. We also reflect this approach against solutions likevirtual organization breeding environments, enterprise architectureframeworks, and web services and service-oriented computing, eachtouching on an aspect of ecosystem challenges.
2.1. From eBusiness to service ecosystems
The rapid growth of computing and internet communication facil-ities has enabled a few essential, intertwined steps towards automa-tion of inter-enterprise collaborations.
The first step involves the development of enterprise interopera-bility domain. In its early days, it involved automation of enterpriseprocesses for efficiency and integrating “stovepipe” systems acrossenterprise units and technology stacks. However, the enterprise
systems remained monolithic, so establishing collaborations acrossenterprise boundaries required slow standardization and system de-velopment projects.
The second step involves the development of software-based ser-vices and rising service development to a new discipline of servicescience. While the computational concept of a service provides aconcept of encapsulation that is rational also for business-level con-siderations, it also provides means for isolating technological solu-tions, allows modeling of autonomy of service providers, andnaturally considers remote utilization of the services across the inter-net. The automation of business processes in enterprises providessufficient support for service-oriented computing and businessenvironments.
The second step is marked also by the increased interest in model-driven engineering [5] and its application to service engineering (e.g.[6–9]). Services are designed by creating platform-independent andcomputation-independent models of them, and using transformationtools to generate implementations (platform dependent models) ofthem, or to generate wrappers for legacy applications. The modelscan further be utilized at operational-time matching of services, andfor interoperability checking and monitoring.
A further essential enabler for this development comes from thedomain of business process modeling and management (BPM). BPMtools help in defining and enacting both external information andcontrol exchanges between collaborating partners and internal work-flows required for providing services of business interest.
The third step involves the present status of enterprise interoper-ability domain. Here, the focus is in the support of networked organi-zations that collaborate as services provided by the collaboratingenterprises instead of integrating the computing systems of the en-terprises. The focus is in the creation of a universal, transparent utilityof interoperability and collaboration governance.
This compressed history view illustrates the common timeline of“how we learn to create computing environments” that is also cap-tured in Fig. 1. The computing environment development normallystarts from an ad-hoc phase where the problem is pragmaticallysolved in various ways, finally forming a best-practices knowledge-base. The second wave of development creates software engineeringtools that systematically provide the repeating patterns to the soft-ware, based on the gained experience. However, all changes to thesoftware require modifications through the software engineeringprocess. Finally, experience is gained on change patterns instead.Thus, it becomes possible to push the generic parts of the solutionto the computing platform (infrastructure) so they can be pervasivelyutilized. The generic solution is then governed with configurations,metamodels and policies for each specific need.
Fig. 1 indicates a first wave of proprietary solutions and focus ontechnology standards interoperability concerns. The secondwave fo-cuses on generated solutions and indicates concerns over the devel-opment processes and the tools interoperability, resulting to modelsinteroperability across enterprises. The evolution is dependent ontools. The third wave is about global, generic infrastructure services(inter-enterprise middleware), making business process modelsand service description model pools available for it and being ableto govern it thought policies and collaboration-specific temporaryconfigurations.
As we aim for the third wave solutions, we have to capture thefunctional and correctness requirements for such an environment. Itis essential that the service engineering and ecosystem governanceaspects match the operational environment solutions.
2.2. Overview of the open service ecosystem architecture
Our goal for the collaboration management is that in future, indi-vidual users, enterprises or public organizations can easily composenew services from open service markets, or establish temporary
Fig. 1. System evolution phases from eBusiness to service ecosystem infrastructures.
collaborations with complex peer relationships. Furthermore, thesecontract-governed collaborations can be managed by their partners.All this is supported by a global infrastructure with facilities for inter-operability control and contract-based community management(establishment, control and breach recovery) among autonomousorganizations; this infrastructure also takes responsibility of govern-ing trust and privacy-preservation issues.
The embedded interoperability support spans technical, semanticand pragmatic interoperability. We define interoperability, or the ca-pability to collaborate, as the effective capability to mutually commu-nicate information in order to exchange proposals, requests, results,and commitments. Technical interoperability is concerned with con-nectivity between the computational services, allowing messages tobe transported from one application to another. Semantic interopera-bility means that the message content becomes understood in thesame way by the senders and the receivers. This concerns both infor-mation representation and messaging sequences. Pragmatic interop-erability captures the willingness of partners to perform the actionsneeded for the collaboration. This willingness to participate refersboth to the capability of performing a requested action, and to poli-cies dictating whether it is preferable for the enterprise to allowthat action to take place.
The Pilarcos architecture views inter-enterprise collaboration as aloosely-coupled, dynamic constellation of business services. A busi-ness service is a software-supported service with a functionality suit-able for a business need on the market and thus relevant for thenetworked business. Each constellation of services is governed by acontract that captures the business network model (BNM, intuitively,business scenario) in terms of the roles and interactions within thecollaboration, the involved member services, and policies governingthe joint behavior [2].
We define the service ecosystem as an environment – open ser-vice market – where service providers and clients can meet, establishcontract-governed collaborations and gain experience on the servicesand partners involved. Our goal is to create a consistent but evolvingenvironment to support governance of inter-enterprise collabora-tions, and to provide for consistency control of the inter-enterprisecollaborations themselves [10].
As the ecosystems are required to intertwine the engineering,governance and operational needs of collaborations, the Pilarcos eco-system architecture involves actors involved in these areas as follows:
• enterprises providing and needing each other's business services,with their published business service portfolios [1];
• business-domain governing consortia, with their published modelsof business networks and business models [2];
• infrastructure service providers of individual functions such as part-ner discovery and selection, contract negotiation and commitmentto new collaborations, monitoring of contracted behavior of part-ners, breach detection and recovery services [2] and reputation in-formation flow, collected from past collaborations [11,12];
• consortia and agencies that define legislative rules for acceptablecontracts [13] and joint ontology about vocabulary to be used forcontract negotiation, commitment and control [14,15,13]; and
• infrastructure knowledge-base providers that maintain the infor-mation underlying the ecosystem infrastructure functions; thisrole is essential in enforcing the conformance rules over all catego-ries of metainformation governing the ecosystem activities [10].
The main ecosystem activities are illustrated in Fig. 2, involvingservice engineering (left and bottom), ecosystem and collaborationgovernance (left and right) and operational-time collaboration sup-port (right and bottom). These aspects will be further refined inSections 4.3.1 and 4.3.2, after this overview on their relationships.
The left side of Fig. 2 depicts processes related to engineering stepsat each involved enterprise or consortia. Here, metainformation isbrought to the system by designers and analyzers. First, available ser-vices are published by service providers (enterprises including publicand private sector providers). Second, the publicly known businessnetwork models are created by teams of designers and publishedafter an acceptability analysis. Third, regulations for conductingcollaboration at administrative domains are fed in by enterprise andecosystem administrators knowledgeable about local and interna-tional laws and business domain practices.
This body of knowledge accumulates into metainformation repos-itories within the globally accessible infrastructure layer. The reposi-tories only accept models and descriptions that fulfill the consistency
Collaborationestablishment- goals- roles- interoperability- trustAgreement process- level of automation- distributed control- quality of agreement
Collaborationenactment and control- interoperability levels- equality- subjective control- NFAs- expectations on computing platforms to be minimized
Collaborationevaluation- metrics on success and dissappointments- trust, reputation, …- feedback for BPR, service improvement
Modelling of services and
business processes
Servicesoftware
Service & ecosystem quality
knowledge
Regulations
Services from providers
Collaboration models
Private know-ledge
Private know-ledge
Public know-ledge
Col-labo-ration
Col-labo-ration
Col-labo-ration
Col-labo-ration
Local support agents
Global infrastructure services for ecosystem support
Contract negotiator Private
policies
Protectingmonitor
Trust
Privacy
Businessnetworkmodels
Service discovery
and selectioneContracts
Decision-makingsupport
Ecosystemdisciplines
Vocabulary IdentitiesReputation
flows
SOSE Open service market Ecosystem improvement
Fig. 2. An overview of the Pilarcos open service ecosystem.
criteria defined for them, thus providing a point of control.Section 4.3.3 explains this in more detail.
The arrows leading to the right at the right side of Fig. 2 depict thelife-cycle of each collaboration from negotiation to termination phase.The collaboration establishment phase is initiated by one of the part-ners suggesting the use of a commonly known business networkmodel that can be picked from the infrastructure repositories. Further,the infrastructure services help in discovery and selection of suitablepartner services for the collaboration and running a negotiation proto-col between the selected partners. Within the negotiation step, thelocal, private support agents of each partner consider especially thesuitability of the collaboration for the enterprises strategies and suffi-ciency of trust to the other partners in the collaboration. In the enact-ment and control phase, the local support agents provide protectivemonitoring and the required contract-related communication.
The arrows leading to the left at the right side of Fig. 2 depict theexperience information gathered from all the collaborations in theecosystem and providing feedback information for re-engineeringand future decision-making processes in the ecosystem. Especiallyimportant is the reputation information generation, as thereputation-based trust management concept facilitates the scalabilityof the ecosystem. Here we can rely on social ecosystem studies [16]:The number of potential partners in the ecosystem is very limited ifthere are no established behavior norms, and only slightly higher ifmisbehavior is sanctioned. However, if also leaving misbehaviorunreported is considered to be misbehavior, an increasingly largeecosystem can be kept alive. The reputation production mechanismtogether with the negotiation step where partners can reflect on thecollaboration suitability for their strategies, their resources, and thepotential risk predicted with reputation information creates a cyclethat has this necessary control function. It effectively emulates the so-cial or legal system pressure of a business domain. This functionalityis largely missing from other approaches.
In conclusion, the bottom part of Fig. 2 represents the global, fed-erated infrastructure services that participates in the governance,
engineering and collaboration management processes. The ecosysteminfrastructure services provide generic protocols and knowledge-bases for enterprises to
• match the collaboration management needs; including service dis-covery and selection, eContracting, and breach management [1];
• evolve the ecosystem with processes to keep and enhance a coher-ent knowledge-base; this includes the control of collaboration typesand available services and interoperability management informa-tion [14,10];
• regulate collaborations in such a way that only acceptable collabo-ration types are allowed, and by controlling the behavior of servicesthrough contracts and enterprise policies [10];
• perform private decision-making on collaborations; this includesenterprises' expert system for making decisions related to con-tracts, breaches and trust [11];
• perform (globally) distributed service production; this involvesproduction methods for service software and coordination models,and definition of open service ecosystem quality requirements forsoftware; and
• collect feedback information about the reputation of the (success-fully or prematurely) terminating collaborations and their compo-nent services.
These rely on pervasive services such as persistent identity man-agement, as it is essential that traceability of partners is preserved,although anonymity may be provided for.
From the business point of view, the architecture provides a globalinfrastructure for establishing, operating and completing collabora-tions utilizing services provided by other ecosystem members. Italso provides a natural environment for innovating new servicesand new collaboration types with other ecosystem members. Theecosystem helps enterprises in adjusting to rapidly changing businesssituations and participation in natural competition between collabo-rations and ecosystem members. Sharing experience informationwith other ecosystem members allows enterprises to gain better
market share due to their close relationships with other ecosystemmembers.
2.3. Related approaches
Related approaches can be found in the domains of virtual organi-zation breeding environments, enterprise architectures, and SOC do-main including Web Services technologies.
The purpose of the Pilarcos ecosystem comes close to the virtualorganization breeding environments [1], such as ECOLEAD [17–19]and CrossWork [20]. However, the virtual organization breeding envi-ronments provide for enterprise assessment processes and joint BPMdesign processes. In contrast to this, Pilarcos pushes the level of auto-mation further: building capabilities for automating routine deci-sions, preserving autonomy and mistrust for potential and presentpartners, and adaptation to changing business situations at the mar-ketplace and changing strategy situations within the organizationsthemselves.
In Pilarcos, the negotiation phase is “democratic” as all potentialpartners can participate in the business network model definitionprocess, and the service discovery process. Only when the finaldecision-making phase including final commitment to the formulatedcontract is performed, are the decisions made at each partner accord-ing to private rules. In contrast, ECOLEAD and CrossWork allow a co-ordinator to do the selection, and the selected partners startnegotiating about the roles and interaction patters suitable for thebusiness case at hand and the competencies of the partners. In thisphase, Pilarcos utilizes more automation, while in the mentionedcomparison architectures, the role of infrastructure is to supporthuman decision-making.
Enterprise architecture frameworks (such as Zachman [21],TOGAF [22]) addresses questions about the enterprise's organization-al structure and responsibilities of units, business strategies, businessprocesses involved aiming at the set goals, and computing solutionsselected to support those processes. Also relevant are relationshipsto clients and collaboration partners, and portfolios of services andsoftware available, as well as human resources and skills. These ele-ments are also present in the Pilarcos ecosystems, but within a frame-work where the ecosystem infrastructure services are available forcontaining the metainformation and descriptions on-line and evolv-able at all times.
For our purposes, the missing element in the enterprise architec-ture domain is the modeling of collaboration relationships betweenenterprises. The tradition in enterprise architectures is long-termchange processes from one well-described state to a visioned stateof affairs in future. The enterprise architecture tools are to supportthe decision-making on the future state and defining a roadmap onhow the organization is to reach that state by changes in its strategiesand portfolios, for example. Pilarcos aims at providing an environ-ment where light-weight “enterprise architectures” for the individualcollaborations can be created and controlled [23].
The SOA roadmap [24] expects a reactive and adaptive computingenvironment for business-oriented use. It introduces the enterpriseservice bus (ESB), but leaves dynamically configurable runtime archi-tecture as a grand challenge; it introduces service orchestration andservice management, but leaves automated composition and self-reflection as future grand challenges. Later, the SOC environmenthas developed towards service-oriented software engineering andthe computational environment has been enhanced with identifica-tion, access control and policy frameworks.
Web Services [25] provide a standard means of interoperating be-tween different software applications, running on a variety of plat-forms and frameworks. Thus, the Web Services architecture is aninteroperability architecture for generic use. However, the Web Ser-vices stack limits itself to the technical and semantic interoperabilitysolutions only. The technical level is solved by the standard protocol
stack, the semantic level is supported by ontologies and annotations,and the pragmatic level is not within the scope. Federations betweenautonomous administrative domains are addressed in WS-federationbut limit to identifying services and sharing credentials.
We return to a more detailed comparison in Section 5 after intro-ducing the key technical concepts of the ODP reference model andPilarcos ecosystem architecture.
3. ODP reference model as an architectural framework
The open distributed processing reference model, ODP RM[26,3,4,27], provides a family of standards for distributed informationprocessing systems that can be exploited in heterogeneous environ-ments and under multiple organizational domains. The model is tar-geted for architecture designers, standardization bodies, and vendorconsortia, to guide them in the design of software architectures —
and nowadays, increasingly in the design of enterprise architecturesand inter-enterprise ecosystem architectures.
These goals are aspired by three basic reference model aspects:
• a division of an ODP system specification into viewpoints, in orderto simplify the description of complex systems [4]; these view-points are connected with different scientific and engineering disci-plines as well, for example, the enterprise viewpoint has clearconnections with enterprise modeling [28]; the enterprise modelthat brings in business-related aspects has been especially elaborat-ed on [29] and provided with concrete tools, too [29,30];
• a set of general concepts for expressing the specification [3]; and• a model for an infrastructure supporting, through the provision ofdistribution transparencies, the general concepts that it offers forspecification purposes [4].
The basic framework standards have been augmentedwith a set offunction standards: ODP trading service [31]; naming framework[32]; type repository function [33]; interface binding framework[34] together with the supporting protocols [35]; and recently, UMLprofiles for ODP [30].
3.1. ODP object model
The ODP reference model is based on a strong object model. Now-adays the concept of service has also been incorporated for better un-derstandability in relation to other frameworks. The novel features ofthe ODP object model at the time of introduction included two essen-tial elements for managing autonomy of collaboration members. Firstof all, the separation of client and server sides of the interface throughwhich the objects communicate, and secondly, the variety of mecha-nisms for introducing objects to a system. Consequently clients andservers could have different, relaxedly matching views of the inter-face through which they need to communicate. More importantly, itis relevant to know only how the partner behaves externally whilethe internal behavior is encapsulated.
More technically, the ODP reference model differentiates betweentypes and templates for objects [3, clauses 9.7 and 9.11]. This separa-tion is heavily used in our approach. The service templates are onlyused within an administrative domain responsible for executing aservice. An administrative domain is a term related to federations [4]and we use it for denoting a technologically consistent system withinan enterprise. Outside that administrative domain, the service tem-plate has no relevance, but instead, a less restrictive concept of servicetype is of importance.
The ODP object model also introduced an explicit binding object [4]between clients and servers, or in fact, between multiple communi-cating partners. The binding type defines what services the abstractcommunication layer is expected to provide and what role-related in-terfaces for communicating peers are provided. The concept of envi-ronment contract [3, clauses 11.2.3 and 13.2] refers to commitments
between an object and its environment, i.e., prerequisites underwhich the service in question can be provided.
The ODP model allows objects to appear in the system in twoways, namely instantiation and introduction [3]. Instantiation is need-ed within the administrative domain responsible for running a ser-vice, but at other domains, the presence of that service is createdthough introduction. The introduction process is required to revealthe type of object in question, i.e, associate the object with a usefulpredicate it matches to. The ODP trading function (OMG trader [31])reflect the introduction process.
Object interfaces are bound based on their type, the object tem-plate is not considered. Because of the separation of client and serverinterfaces, also the sub-typing and substitutability concepts for ODPobjects differ from other object models. The type system of objectsfocus on the shared features required from interfaces that need tobe bound together, instead of focusing on implementation inheri-tance hierarchies. The essence of sub-typing rules for ODP objects iscontravariance [4]: the offered information flows must include atleast the information expected by the receiver. In most object models,sub-typing is based on covariance: the replacing object can both ex-pect to receive and offer more information than the replaced objectexpects and offers.
3.2. Structuring concepts
For managing distributed collaborations, the ODP reference modelintroduces the structuring concepts of community, domain, and feder-ation. These concepts can be used for organizing objects for producingand exploiting services. The structuring concepts can be consideredto be either static, design time concepts, or dynamic, operation timeconcepts.
A community is a configuration of objects with a common objec-tive. For example, a pair of protocol objects forms a communitywhere the shared objective is to transport information from a com-puter to another.
A bX> federation is a community of bX> domains where there is ashared objective ([4], clauses 5.1.2,5.1.1). A bX> domain is a set of ob-jects, each of which is related by a characterizing relationship bX> toa controlling object ([4], clauses 10.3). A technology domain is the setof objects conforming to a technical standard, and a trading domain isthe set of objects known to a trader object, for example. Further, atrading federation is a federation where two trader objects work to-gether to serve the trading domains controlled by either trader.
Also the platform defined by ODP functions is a fundamentalstructuring concept. The architecture view indicated by the ODP ref-erence model contains a global infrastructure that is composed of au-tonomously administered systems. Each system may be supported bydifferent platform services, but in addition, some common facilitiesmust be available. The common services do not necessarily form aunified middleware layer that homogenizes the application layerview to the infrastructure. Instead, the autonomous domains areexpected to be able to establish cooperation relationships amongstthemselves, dynamically.
The ODP reference model defines an abstract computing platformthat comprises of a set of coordination, management, and repositoryfunctions. The functions are described using a set of supporting con-cepts (nodes, capsules and clusters), that give an internal engineeringview of the middleware software. However, these concepts are onlyused for descriptive purposes, to ease discussion, not as technologyguidelines.
The relevant functions for inter-enterprise collaboration manage-ment are those of trading, type repository and binding framework.The ODP trading function is designed to mediate server interface of-fers. The interface offers are required to contain the service identifier,the exporter identifier, abstract service type name, an interface signa-ture, and a set of attributes. The attributes declare service properties
as name value pairs according to the property types listed for thenamed service type. The attributes can describe quality of service as-pects or they can describe the supporting platform features of inter-est. The trading function specifies only the mediation mechanismand information structuring rules, not the interpretation of offers.
The type repository services [33] mediate type information that isavailable at run-time. Traders use type repositories for checking con-formance between object interfaces. The type repository supports op-erations for a) publishing type descriptions, b) checking conformanceof two type descriptions, c) retrieving subtypes and super-types,d) translating types, and e) name management operations for types.What initially was an ODP type repository definition as an annex ofthe ODP trading function standard, was later independently maturedto MOF model (meta object facility) [36] in joint work with OMG. TheMOF standard defines layers of models: level 0 is formed by object in-stances, level 1 of rules on declaring information in these instances,level 2 on conceptual rules to be used when expressing declarations,and level 3 on the founding concepts. The MOF repositories wereaimed for model-driven engineering tools to store models and trans-formations needed when generating more detailed models, but arevery suitable also for collecting structured knowledge-bases such asODP traders' set of service offers.
The bindings between ODP objects are modeled by explicit, openengineering-level binding objects. The objects can be managed andconfigured to the need through management interfaces. The ODPmodel supports multi-party communication with selective transpar-encies and quality of service contracts [34].
3.3. Viewpoints
The ODP viewpoints allow object systems to be specified in an or-ganized manner. However, the viewpoint rules do not instruct on thelevel of detail or completeness of the specifications. Those aspectsmust arise from the software engineering process in which the view-point specifications are involved. The relationship between the view-points and the software engineering process phases has been widelydiscussed and various interpretations have arisen. Officially, theODP reference model does not bind the viewpoints to any specificsoftware engineering process.
The ODP reference model defines five viewpoints— enterprise, in-formation, computational, engineering and technology viewpoints[26,4]. A system must be specified from each of these viewpoints.Each viewpoint specification is a consistent and complete specifica-tion on its own, but it only considers those aspects of the systemthat are valid in its point of view. So the viewpoint specifications donot overlap totally, but they may show different levels of detail inthe areas where they need to discuss the same or related features.
The enterprise viewpoint description of a system specifies the ac-tivities and the responsibilities of the system. Activity means any in-formation exchange sequence and it is a high-level abstraction ofthe operations within the system. The system itself can have anygranularity that is interesting. The system can be as wide as a globalinformation network with all applications or as small as a memorycache in a processor. The enterprise specification identifies the sys-tem, its environment, and the required communication of the systemand its environment. The specification answers the questions “Whatis the purpose of the system?” and “What services the system is re-sponsible for providing?” and “Who needs the services?”.
The information viewpoint description of a system identifies logi-cal information entities, their logical contents, their repositories andthe objects that are responsible for the information flow in the sys-tems. Questions for the information viewpoint specification are“What information is needed to support the system's services?”,“Where does the information come from and go to?”, and “Is it neces-sary to store the information somewhere?”. The information view-point specifications should not describe data structures, but only the
semantics of the information. Also, the technique of storing informa-tion is irrelevant in this viewpoint (as the logical infrastructure sup-ports storage services).
The computational viewpoint specification captures the behavior ofthe system. Behavior is an abstraction of how things are done, in con-trast to the notion of what things are characteristic in enterprise view-point activities. An activity identified in the enterprise viewpoint mayinvolve several objects to perform a sequence of operations in the com-putational viewpoint. The computational viewpoint shows the systemas a composition of logical objects. For each object its interfaces are de-scribed. If the interface involves operations, each operation gets logicalparameter descriptions (information structures, not data structures) —if the interface involves streams, each data flow component of a streamgets logical protocol descriptions instead. This is the viewpoint that usu-ally explicitly shows potential for distribution. Neither the enterpriseviewpoint nor the information viewpoint specifications need to expressany distribution concerns. The computational viewpoint answers ques-tions like “Which operations are available?”, and “Who (which logicalentity) performs the operation?”.
The engineering viewpoint specification identifies the infrastruc-ture services needed for the system to operate. The ODP engineeringviewpoint defines the set of available infrastructure services, and allother engineering viewpoint specifications should show how thespecified system utilizes these services. The engineering specificationtherefore answers the question “By which services are the computa-tional objects supported?”. The ODP infrastructure model identifiesa set of global, distributed basic services that should be available ateach node in the global system. These include invocation of opera-tions, transfer of continuous data as streams, trading, type repositoryfunctions, etc. These services facilitate selective transparency of com-munication between objects.
The technology viewpoint specification shows in a concrete hard-ware and software configuration how the system services and otherrequired components are realized. The specification answers thequestion “How are the infrastructure services realized?”.
The system specification includes five complete specifications,that all can be analyzed as separate. Each viewpoint reveals a differ-ent aspect of the system, and therefore the full functionality canonly be seen by looking at all specifications together. As the viewpointspecifications are all complete alone, the abstraction levels of objectsin the specifications can differ. Still, the specifier must show how thespecifications are mapped together. The use of viewpoints helps thespecification of large systems by separating concerns to separatespecifications.
The ODP reference model introduces a vocabulary and a set of lan-guages to discuss (distributed) systems, but originally it does not pre-scribe any special techniques to do this. Any specification language ortechnique that supports the same concepts can be utilized for ODP-style specifications. The problem with current formalisms that areclose to the ODP concepts is that they do not support the level of dy-namism required in ODP specifications.
3.4. ODP approach to conformance
The ODP reference model aims for specifications that allowplatform-independent services and service interoperability. In orderto accommodate both of these requirements, the ODP referencemodel defines four classes of reference points — points where theconformance to the standard specification needs to be tested and isallowed to be tested. Other behavior than that visible at these refer-ence points is not considered.
The four classes of reference points are [3, clause 10]:
• A programmatic reference point specifies the limits for an object be-havior. Object implementations that pass the conformance test atthis reference point can be replaced by each other.
• A perceptual reference point sets requirements on some interactionbetween the system and the physical world.
• An interworking reference point sets conformance requirements forcommunication between two or more systems in terms of the ex-change of information.
• An interchange reference point defines conformance requirementsfor the manipulation of information on a physical medium. The ma-nipulation rules are described in terms of access methods and for-mats. The goal is to ensure that physical storages can betransferred, directly or indirectly, to another system.
Each ODP system specification may comprise specifications fromall five viewpoints, and the related reference points. For the selectedreference points the conformance statements must be specified in atestable way. The conformance statements can be expressed interms of coherence between a number of reference points and viewedfrom a number of viewpoints too.
The completeness of an ODP system specification also requiresthat correspondence relationships between essential elements ofeach viewpoint specification are defined. Each viewpoint specifica-tion can be considered as a projection of the system, and thus, theconformance requirements become defined only by explicitly assign-ing the points where an item is visible frommore than one viewpointsimultaneously. The defined system is only to be considered a confor-mant ODP system if it conforms to a set of compulsory basic conceptcorrespondences, although the system designer can freely define ad-ditional correspondence requirements. These additional correspon-dence requirements indicate complex reference points.
4. Building service ecosystem utilities
Having recalled the ODP reference model elements that are mostrelevant for the Pilarcos ecosystem concepts, we now proceed toviewing the Pilarcos design in more detail. First, an overview isgiven on the ODP specification style the approach follows; then, keyconcepts and ecosystem infrastructure functions are detailed.
4.1. Viewing Pilarcos ecosystem as an ODP specification
In order to view the Pilarcos ecosystem architecture as an ODPspecification, we need to select the suitable design elements fromthe ODP viewpoint languages: An ODP specification of a system in-cludes five viewpoint specifications and correspondence rules be-tween related objects visible in different viewpoints. The enterpriseviewpoint specification basic structure is that of a community defin-ing the scope and objective of the system and the essential enterpriseobjects, their interactions and policies governing the specified com-munity [29, clause 7.1]. This community can further be subdividedinto other communities interacting with each other, each havingtheir individual sub-objectives. In this case, some of the enterpriseobjects can have roles in several of the inner communities [29, clause7.4]. Further, the correspondence rules must also specify the informa-tion object types involved in the communication or processing be-tween these inner communities [29].
The ecosystem specification scope is to support open business ser-vice ecosystems to provide a consistent environment for governinginter-enterprise collaborations. The main objective is to improve thecorrectness and acceptability of the collaborations through the jointcontribution of ecosystem management processes, engineering pro-cesses and operational-time collaboration control processes. Theseprocesses must be capable of detecting inconsistencies and providefacilities for recovery.
The challenge is too difficult for just a computing platform tosolve, for a number of reasons, including the following two. Firstly,the service offers are just declarations made by enterprises andthere is no guarantee of their truthfulness. Certification systems
help this situation to some extent. We can carefully test each serviceto work according to its declared service offer, but still, dynamicchanges in its providing enterprise, technical failures, or even attackson the enterprise's computing system can cause deviations from this.In the end, only assuming service offers to be business tenders andleading to legal contracts gives the solution stability. Secondly, wecan verify business processes by analyzing their liveness, freeness ofdeadlocks, fairness and other properties. However, here we needcombinations of business processes as business network models. Fur-thermore, current theories (e.g. process algebras) do not guaranteeknown properties of the full system if only the abstract level jointmodel is verified. No further ensurance is gained by knowing thatthe services filling roles in the business network models have correctreplaceability properties with the role specification.
Thus, the correct behavior of the collaborations must be producedby the sub-communities of governance, engineering and collabora-tion life-cycle control in interaction.
In order to ensure correctness of the collaborations, we have iden-tified a number of complex and even dynamic reference points forcollaborations. The elements in these reference points include aspectsdetermined by the ODP reference model viewpoints:
• business network models provide control flows and structure of thecollaborations, according to the enterprise viewpoint rules;
• the business network models also include definitions of acceptableand required information flows, which needs to be transformed toinvariants suitable for monitoring; this matches the basics of infor-mation viewpoint specifications;
• the computational viewpoint matches with service governanceusing service offer information;
• the engineering viewpoint specification rules help us to identify thecompulsory communication platform requirements that are presentat each service offer and population request; and finally,
• the technology viewpoint specification identifies the vocabulary weneed to declare in service type definitions in our repositories.
In this context we apply the ODP reference point definitions as fol-lows. First, the programmatic reference points are related to the tradi-tional standards conformance criteria: is the piece of softwarebehaving according to the specification? The perceptual referencepoints take into account interaction with humans and influence of or-ganizational affects in association with the system. For example, theability to change an organization-wide strategy or policy forms sucha perceptual reference point. Further interworking reference pointscover what we have earlier referred to by interoperability levelswhile supporting collaboration: the aspiration is to support not onlyexchange of information but interpretation of the exchanges as pro-posals, commitments, requests and responses. The interchange refer-ence points would thus become a subset of interworking referencepoints, except for criteria for inhibiting use of data considered private.
The ecosystem infrastructure services provide for the establish-ment of these reference points, monitoring their fulfillment, reportingof failures, deciding on the actions to be taken after a failure isdetected, and collecting improvement information for the ecosystem.We have chosen to view the ecosystem infrastructure functions as thecomputational platform for the Pilarcos ecosystem. As we place theconformance requirements on these services on the enterprise, infor-mation and computational viewpoints only, we do not consider theseservices as an engineering solution, as they are distributed in nature,and we are only focusing on their externally observable behavior.
While the collaboration life-cycle management community is re-stricted by these reference points, the two other communities havean essential role on defining these reference points. First of all, the en-gineering community provides all the model and type specificationsrequired for controlling the collaborations. Furthermore, the gover-nance community provides the metamodels and rules that thesemodels and specifications have to fulfill before being accepted as
part of the ecosystem. A family of verification and validation toolsmust be used to root out collaboration types or technical solutionsthat are known to cause problems. In this family of tools, we alsoneed to incorporate a feedback loop that provides experience of thecompleted (either successful or failing) collaborations; taking into ac-count the dynamicity caused by each ecosystem member,preparation-time testing or verification is no more sufficient. Indetecting failures and collecting experience, the subjectivity of asser-tions by the autonomous partners must be adjusted to.
This structuring to three communities interacting through theknowledge-base within the ecosystem infrastructure services can berecalled from Sections 4.3.1 and 4.3.2. Section 2.2 also provided anoverview of the actors involved. A non-ODP motivation on the samephenomenon is given elsewhere [37].
The specification involves interesting correspondence rules due tothe need for aligning business-oriented enterprise viewpoint con-cepts in the collaboration control process and computing-related con-cepts in the other communities. An example of this is the definitionsof business service and eContract later. In the case of business service,the necessary connections to other communities' objects have beenimplemented as a comprises-of relationship. In the case of the eCon-tract, different parts of the required information are produced by dif-ferent actors and communities. Thus we have used life-cycle phasesto control the process; in ODP terms, the information viewpoint dy-namic schema provides tools for this.
In the following, only the key concepts and services in the ecosys-tem are discussed, as the focus of the discussion is on identifying thecomplex reference points in the collaboration management activities.An example on the use ODP reference model on specifying the Pilar-cos collaboration control community has been published before [38].
4.2. Key concepts
The key concepts present in the Pilarcos ecosystem architectureand in inter-enterprise collaborations include business service,eContract and business network model, BNM.
A business service comprises of a computational service, monitorand governing rules. A business service is always administered by asingle authority; in the case of subcontracting, the responsibilityand policy changing rights stay with the principal partner, althoughcomputation can be outsourced. A computational service is abusiness-relevant collection of software modules. Their behavior isrestricted by the monitor according to the policies set by the enter-prise providing the business service. In this way, the software ele-ments do not need to consider the business strategies or policies,but remain reusable. It should be noted that part of the governingrules are public as well as part of the eContract, while others are pri-vate and known only to the provider of the business service.
The single authority administering the business service is hereconsidered typically to be an enterprise or an organization. The ad-ministration must be considered to be an independent, legally re-sponsible party in the business-level contracts into which theservice can become involved.
The business service concept builds on the ODP concepts of intro-ducing enterprise viewpoint objects to a community instead of utiliz-ing templates, as well as the organizational and accountability rulesdiscussed in Sections 3.1 and 3.2 [29, clauses 6.5,7.10].
The separation of computational and business services differenti-ates programmatic reference points for the result artefacts of soft-ware engineering processes from the interworking and interchangereference points related to the enterprise viewpoint actor denotinga “business service as provided by an enterprise”.
Because the business service decomposition includes enterprisepolicies that can be modified dynamically, even at collaborationtime, the conformance point becomes dynamically adjustable at oper-ational time. Although the dynamism of the reference point makes it
harder to test, however, the improvement of adjustability to environ-ment needs supports our aspirations towards an adaptive, complexsystem behavior.
The eContract governs the inter-enterprise collaboration that isformed between business services [1]. The eContract governs the col-laboration membership, behavior and breach management. Charac-teristic for the Pilarcos architecture is that the eContract addressesmultiple business services, but is negotiated and committed betweenseveral enterprises. The eContract captures external business process-es and selections made between alternative behaviors in it at thebusiness-level, but also complements this information with technicaland semantic requirements for interoperability between the service-providing service elements. The eContract structure is outlined inFig. 3.
The eContract is structured according to the roles defined in theselected business network model (BNM). The services playing parts inthe collaboration are picked from the service offers available as di-rected by the initiator of the collaboration and as dictated in the busi-ness network model selected by the initiator.
The structure for an eContract is provided by a business networkmodel which is a direct mapping to the ODP concept of communitythat is used for describing the collaboration of several services. TheODP enterprise language specifies a community as a configuration
reference to the business network model (BNM);
current epoch information;
process for changing epochs;
for each role
– assignment rules that specify the requirements on
service type;
nonfunctional aspects;
restrictions on identity, participation in other collab-orations, etc;
– conformance rules that are used for determining confor-mance to the role which the assigned component is in therole; similar as above;
for each interaction relationship between roles
– channel requirements
– locations of the channel endpoints
– QoS agreement
– security agreement
– information presentation formats
for each policy that governs the choices between alternative be-haviour patterns in the business network model (BNM)
– acceptable values or value ranges;
references to alternative breach recovery processes;
objective of the collaboration (rules that can be used for vari-ous non-deterministic choices in the collaboration; for example,what kind of attributes are more attractive when selecting a newmember, available info for these rules is in service offers and inthe business network model and in policy values of this collabo-ration)
***
Fig. 3. Collaboration contract information.
of enterprise objects with a contract on their collective behavior [29,clause 5.1.1]. The community specification includes
• a set of roles; the role specification gives requirements and restric-tions for the behavior of an object;
• rules for assigning enterprise objects to roles; the policy rules canaddress individual objects or relationships between objects, andcan make restrictions on behavioral and non-behavioral propertiesof the potential objects;
• policies that apply to roles; policy values act as selectors for alterna-tive behaviors for the objects — and thus also for the community;
• description of behavior that changes the structure or the membersof the community during its lifetime.
Each role [4, clause 9.14] in the community specification denotes apossible behavior. The behavior descriptions are refined with policystatements indicating which parts of the behavior are prohibited, per-mitted or obliged to take place and under what conditions.
A role can be populated by an object that represents another com-munity. In this way, larger systems can be composed of subservices.Functional composition is better supported by inclusion of multiplecommunity specifications into a system specification and definitionof the relationships between communities.
A community specification may be divided into several epochs,each epoch [4, clause 10.5] presenting a different set of services sup-ported by the community. For instance, a service might have a config-uration phase and an operational phase; during the configurationphase only a management interface is available, but during the oper-ational phase the actual service interfaces are also available.
For the purposes of the Pilarcos architecture, we have connectedthe role behavior to a service behavior. Thus, assignment rules are di-rectly related to import requests from the trading service for suitableservice offers from potential members of the collaboration. This is inline with the current trend of service-oriented computing where thedefinition of abstract service, service discovery, and semantic compo-sition of services are topical [39,40].
To summarize the relationships of the basic concepts, Fig. 4 illus-trates the general approach to governance of business serviceswhile in-volved in a collaboration. Each enterprise has a private set of enterprisepolicies governing the services it provides. Each business service is sup-ported by a constellation of software elements, and the constellation isguarded by amonitor. Themonitor is responsible for running restrictingrules from two sources, namely the eContract and the enterprise policy.Enterprise agents implement the necessary negotiation, control andmanagement protocols between themselves. For example, when abreach is detected as a monitor detects a message contradicting itsrules, it sends a notification to the local agent, which in turn may re-quest a breach recovery process to be started among the partners.
It should be noted that the basic concepts also incorporate non-functional properties associated with a) inter-enterprise collabora-tion (i.e., business network) as a whole (in a recursive view, thecollaboration itself can be viewed as a business service); b) the busi-ness service in a role in that collaboration; and c) the communicationchannel between the business services; and the computational ser-vices implementing the business service.
The associated categories of nonfunctional properties we namecollaborative, extra-functional, and contractual, as shown in Fig. 3[41]. The collaborative aspects address the pragmatic interoperabilityissues, i.e., processes and policies, andmethods of decision-making oncollaborations, e.g. risk, business value, trust and reputation. Again,there is need to define policies that are commonly understandablebut dependent on all business domains involved. The extra-functional properties of services address issues relevant for managingthe dependability of a business service. The detailed structure of thiscategory is dependent on the assumed computing platform for thebusiness applications, because the aspects represent such features ofthe services that are expected to be dynamically managed. The
Fig. 4. Governance of business services in collaborations.
contractual aspects depend on the assumed communication platform:e.g. distribution transparency, privacy-preservation, transactionality.
The eContract captures perceptual and interworking referencepoint criteria from all ODP viewpoints for the collaboration operationduration. It holds enterprise viewpoint information about the busi-ness network model in use, the status change processes in respectof epochs, membership data, and agreements on the processes for re-solving breaches. It holds computational viewpoint information suchas the shared progress information and computational interfaces forrenegotiations. It holds information viewpoint invariants in theform of policies modifying business process behavior variations,trust decisions and privacy-preservation rules.
These reference points that are different for each individual collabo-ration should not be confused with the reference points of the ecosys-tem infrastructure services and being a member of the ecosystem. Atthat level, the eContract interworking reference points involve repre-sentation of the business network model, and protocols to exchangemessages with the eContract agent through its interfaces, for example.Likewise, the perceptual reference points would include requirementson the use of renegotiation protocols and potential membershipchanges, policy changes or collaboration termination announcements.These are permanent properties of the infrastructure.
4.3. Ecosystem infrastructure services
The ecosystem infrastructure comprises of two parts, global infra-structure services for ecosystem support and local support agents pri-vately representing the involved enterprises. The global infrastructureservices capture the ecosystem shared knowledge-base that is essentialfor the overall consistency of the ecosystem behavior. This structure canbe recalled from Fig. 2. In the followingwe first discuss the services sup-ported by enterprises finding their market as infrastructure service pro-viders in Section 4.3.1, then the local agents in the followingSection 4.3.2, go into more detail about the knowledge repositories inSection 4.3.3, and finally discuss the interplay between remote andlocal agents in Section 4.3.4. The order reflects the tasks of a) collabora-tion life-cycle management (Sections 4.3.1 and 4.3.2), b) the evolutionof the ecosystem knowledge-bases (Sections 4.3.1 and 4.3.3), andc) the ecosystem and collaboration consistency regulation enforcement(Sections 4.3.3 and 4.3.4).
4.3.1. Global infrastructure servicesIn the collaboration establishment phase, service discovery and
selection is supported by a populator agent. The initiator of the
collaboration selects a model from the public business networkmodel repository and invokes the populator agent to find matchingservice offers from the trading service for each of the roles [2,14].The populator then performs a static interoperability checking,which ensures that the service offers fit the model of the collabora-tion, and have terms that are compatible with other offers being se-lected into the proposed collaboration. If a firstly suggested set ofservice offers fails the interoperability test, a new proposal is formeduntil the check succeeds, the offer combinations are exhausted or theamount of resources bound to the search are consumed. The popula-tor finally returns a contract proposal that ensures that the set of ser-vices it proposes do match to the roles for their service types, are notdenied to work together by regulations, and are interoperable ontechnical, semantic and pragmatic levels.
As service discovery and selection is separate from contract nego-tiations, it can be done without access to sensitive information; thismakes it possible to have this task implemented as a third-party ser-vice [2].
In comparison with other service offer repositories (Universal De-scription and Discovery Service: UDDI [42], ODP trading function[31]) the fundamental difference is the populator service providinga multi-partner matching instead of a client–server setup, and alsochecks not only technical and semantic interoperability but alsotakes into account pragmatic interoperability aspects. The pragmaticaspects include views to business network models, acceptable rolecombinations and environment contract information (i.e., require-ments of the communication channel properties).
The information base utilized by the populator agent is based onODP trading function. The structuring rules of service offers in Pilarcosare captured in Fig. 5. The structure is more detailed than can befound in the ODP trading function standard, which requires interfacetype name, interface reference, and some attributes as name-valuepairs. What is to be noted here is that the service offer captures as-pects from all five viewpoints, either as descriptions of the serviceto be provided or as a requirement to be fulfilled by the environmentin the subsequent contract. This structure differs from OWL-S andUDDI based solutions by not addressing the groundings (access de-tails) or the actual location of services. These locating aspects areonly captured by the eContract formed according to the offers; thegrounding aspects are considered private for each enterprise. Onlythe interoperability-related features are required.
By capturing all viewpoint aspects into the service offer, we ad-dress the interoperability ensuring challenge. Making metainforma-tion available in such a structured way, we use the interface
service offer := ((interface syntax) (interface protocol) (information el format) (nonfunct aspects)*)* (policies) (platform requirements) (channel requirements)
matching mechanisms of the trading service to match all relevant as-pects of interoperability at the same time. This of course applies onlyfor static analysis; for policies subject to further changes, for example,only dynamic monitoring can catch mismatches.
Automated eContract negotiation supports the agreement phase ofthe collaboration [2]. While the initial service selection is based onpublic information, the needs for privacy of decision-making on theenterprises' commitments are incorporated into a negotiation phase.In the negotiation phase each suggested collaborating party canagree to join the collaboration, or refrain. Population and negotiationphases are repeated as necessary.
The negotiation cycle ensures privacy of decision-making for eachparticipant. In routine cases, it is possible for the enterprises' agent toprovide an automated response to the collaboration proposals: an ex-plicit meta-policy guides the agent to pick routine rejections or com-mitments. Other situations can be recognized, for example, byuncertainty of the trustworthiness of the peers, uncertainty of thestrategic benefit of the collaboration, or uncertainty of the acceptabil-ity of negative reputation effects caused by a refusal.
At the end of a successful negotiation phase, the eContract isformed. The eContract captures the business network model, playersin each role, requirements for communication channels between ser-vices, and requirements for nonfunctional properties of the collabora-tion as well as policies providing invariants the collaborative behaviorshould hold.
The contract enactment and control phase is jointly supported by alogical eContract agent that is physically replicated to the computingsystems of each collaboration member. The eContract provides inter-faces for renegotiation, epoch changes, progressing to defined mile-stones in the business processes, and declaring detected breaches.
The eContract is the key agent also at the collaboration terminationphase when feedback on the success of the collaboration is collectedfor business process improvement, service improvement, ecosystemimprovement and for partners' service reputation information feeds.Part of the information is relevant to be produced from the sharedstate information, while most of the data is best produced by thelocal monitors at each enterprise.
The populator agents, negotiation protocols between local enter-prise agents and the eContract agents rely on infrastructure repositoriesholding a consistent and secured interoperability knowledge-base. This
is further discussed in subsection 4.3.3. Further, the infrastructureagents rely on a lower-level platform functionality of persistent identitymanagement. The eContract also provides interfacing for decision-making support that combines information available in the eContract,ecosystem knowledge repositories and locally at the enterprise.
The reference points on the ecosystem infrastructure involve theiruse only and are relevant as criteria for being able to act as a memberof the ecosystem and connect to the main services.
4.3.2. Local support agentsThe local support agents subjectively represent the enterprise, and
provide a local interface to the ecosystem infrastructure services forthe local business services. The essential tasks at which enterprisesneed their agents to control the collaboration contract or collabora-tion behavior include i) contract negotiation, ii) monitoring duringcollaboration operation, and iii) experience reporting when the col-laboration terminates either having reached its purpose or terminat-ing prematurely due to breaches.
A contract negotiator agent represents an enterprise and is respon-sible for running collaboration management protocols on behalf ofthe enterprise delegating rights to it. The agent provides interfacesfor application software or administrative interfaces to initiate collab-oration establishment, or for responding to suggestions from otherenterprises.
The contract negotiator is aware of enterprise policies that governall negotiations and commitments, and all services. Where the con-tract negotiator is not able to make a decision (metapolicies denythe right from it) on whether to accept or reject a proposal, it passesthe proposal on for human intervention — and the decision-makingsupport system information is made available in an expert supportsystem style [43,11].
Both for the automated decision-making and for the support ofhuman intervention, we propose to use an expert system to gatherthe relevant knowledge and to feed governing policies to the enter-prise system, i.e., the relevant nonfunctional properties of the collab-oration and its contributing services [43].
The decision-making is governed by enterprise policies [43,11] re-lated to
• strategic policies indicating what type of collaborations or whichpartners are of interest and worth investing the resources to collab-orate with;
• reputation-based trust that weights the anticipated risk and tolerat-ed risk level [11]; and
• privacy-preservation that may overrule otherwise acceptable col-laborations due to high privacy costs involved.
In Pilarcos, trust is defined as the extent to which one party is will-ing to participate in a given action with a given partner in a given sit-uation, considering the risks and incentives involved. Trust decisionsare subjective evaluations made by the trustor, i.e. trusting party, tar-geting a given trustee and a given action.
For risk evaluation we use four standard assets shared betweenorganizations: monetary, reputation, control and satisfaction. Themonetary asset represents money and other artefacts in the enter-prise that have a well-defined monetary value. The reputation assetrepresents the trustor's good reputation. The control asset is a jointrepresentation for the trustor's security, privacy and general desiredlevels of self-protection. The satisfaction asset represents the fulfill-ment of the trustor's expectations of the trustee's participation inthe action, such as the quality of the service the trustee provides orits efficiency in fulfilling its end of the agreement.
A trust decision is based on a comparison of the uncontrollablerisks that allowing the action would cause, and the willingness to ac-cept them, i.e., risk tolerance. Both are built by evaluating a lower-level factor, reputation and importance, respectively. The risk evalua-tion is expressed as probabilities of different outcomes, estimating
how the partner will behave in the future. This estimate is based onearlier experience on the outcomes of earlier collaboration with thetrustee. First-hand experiences and experiences shared by thirdparties form the trustee's reputation, which is the trustor's subjectiveperception of how trustworthy the trustee is, based on currentlyavailable information. Risk tolerance builds on the business impor-tance of allowing the action: different kinds of benefits may be real-ized by a positive decision alone, such as building a partnership,helping the inter-enterprise collaboration towards realizing itsgoals, and not triggering compensation clauses in the contract.
Privacy we define as the right of subjects to determine themselvesfor whom, for what purpose, to what extent, and how informationabout them or information held by them is communicated to others[44]. A subject is a person, social group organization or organizationalgroup. Privacy control is the set of actions by which a subject makesdecisions on refraining or involving in information exchange or shar-ing, and taking actions on detected privacy violations. Privacy viola-tion is circumstances where information is held or used in a waythat breaches the privacy declaration by the information-owning sub-ject. Privacy declaration is an expression created by the protected in-formation owner that gathers together rules on to whom, for whatpurpose, to what extent and how information can be made available.
For privacy preservation, in the contract establishment phase con-cludes with a negotiation phase, in which each potential partner isable to make commitment decisions privately. In the negotiationphase, the partners-to-be are already known, so decisions on reveal-ing private information during the negotiation can be done explicitly.For privacy preservation, the binding mechanisms, however, bringadded value by providing room for third party components. This pro-vides a practical declarative method for incorporating into communi-cation channels tools for anonymization and avoidance of identity-revealing accumulation of information from the use of severalservices.
Although trust and privacy are closely related, the decision-making processes on the issues are separate and parallel. Trust deci-sions weight expected benefits against anticipated losses in a specificbusiness case; privacy decisions guard access to private information,metainformation and behavior patterns considering the subject as amember of the ecosystem.
Monitoring supports the enactment and control phase of the col-laboration in particular [45]. During the operation of the business net-work each member service monitors the acceptability of the behavior(messaging) it can assess directly. The monitors receive rules fromeContract and from their local policy repositories. The rules derivedfrom these two sources can be contradictory. In the negotiationphase only those policies are checked that are explicated both in theeContract and in the enterprise policies; moreover, the enterprisepolicies can change during the collaboration without consulting thecollaboration peers.
The breaches can mean failing to fulfill an obligation, or failing toprovide the agreed quality level of the service; more formally, failingto provide the level of dependability expected. The concept of depend-ability, in terms of fulfilling the contracted aspects, can be concretizedon two fields. There are general properties that can be set as servicelevel expectations for any service, such as availability, timeliness,and privacy-preservation, or interaction relationship, such as non-repudiation and immutability. In addition there are properties thatare relevant for individual service types, each requiring a definitionof value domain and metrics for defining the service levels relevantfor the property. For example, reputation information (recommenda-tion) can have a credibility property associated to it, determining howcompletely a recommendation from that source is assumed truthful.Another example is the traditional QoS levels with different metricsfor data bandwidth and jitter in transfer.
At detected breach situations, decisions are needed onwhether theevent is serious enough for terminating or leaving the collaboration.
The same type of knowledge about the operational environment canbe used, and again the expert system can make automated decisionsor redirect the request for human intervention.
When an essential breach against the eContract is detected by oneof the collaboration members, the eContract agent is notified. TheeContract agent then starts recovery steps that involve terminatingthe collaboration, or changing the faulty member to a new one, for ex-ample. The recovery capabilities are dependent on the business net-work model, and therefore, the breach recovery process is definedas part of the business network model itself.
We assume services to be active agents instead of requiring aworkflow engine to control the running of the business process.Thus monitoring is done by each collaborator to protect local re-sources, keep track of the progress of the collaboration, and to ensurethat partners follow the collaboration model. The business processmodel and service provision terms set by the negotiated eContractform the specification of correct behavior in the collaboration,which becomes relatively straightforward to monitor.
There are two practical limitations to how powerful the monitor-ing can be made in inter-enterprise collaboration. First, given the au-tonomy of participants, there can be no all-seeing trusted third partymonitoring all that goes on in the collaboration. Second, monitoringmust generally be non-invasive, i.e. it can only observe the messagessent by the technical service, not the internal state of the service.
As a result, business network models must specifically supportmonitoring by demanding sufficient information to be included inthe messages sent between services. If a specific collaboration typerequires a notary to act as a witness to specific activities, for example,it must be included as an actor in the business network model itself,and the model must direct any message traffic in need of observingthrough the notary actor. The strict separation of policy monitoringand enforcement from the technical service application is a necessity,as the service can participate simultaneously in multiple collabora-tions with different shared policies. On the other hand, message-based monitoring also avoids the high costs of inserting sensors intothe code of legacy applications.
Finally, while it is relatively straightforward to monitor for con-tract and policy compliance, policy-abiding but “suspicious” behavioris more difficult to capture. Anomaly detection approaches sufferfrom false alarms and therefore would be best used under human su-pervision [46].
When terminating the collaboration, experience reporting is re-quired. It has two roles. It supports the evaluation phase of the collabo-ration, although it also connects to the monitoring service during theenactment of the collaboration [47,11]. Moreover, the experiencereporting forms the core of social control in the open service ecosystem.As contract violations are detected by monitors, they are published toother actors as well: it is important to create a direct reputation impactto privacy and data security violations in order to limit the damage thatmisbehaving actors can achieve in other collaborations.
The storage, processing and reporting of globally shared reputationinformation is a challenging problem, as it requires support for evalu-ating the credibility of experience reports [48]. False reports do notonly affect the targeted service, but also inhibit the other actors' abilityto assess its behavior, reducing the social control impact of reputation.
The local involvement in eContract negotiation, local decision-making support, local monitoring of eContract and enterprise policyrules during the collaboration all together provide a perceptional ref-erence point for each enterprise independently.
The experience reporting from all parties provides a referencepoint for ecosystem level membership that relies on a democraticmeasure.
4.3.3. Interoperability knowledge repositoriesThe metainformation needed for governing the collaboration and
ecosystem life-cycles is held in public repositories by the ecosystem
infrastructure services. This metainformation includes business net-work models, available services, reputation, and furthermore, servicetype information to form a shared ontology or vocabulary for theother categories of items. Each metainformation category is separate-ly produced in business network and service modeling processes, andservice production processes. The artefacts to the repositories areproduced by either service-oriented, model-driven software produc-tion or wrapping of legacy applications, or business network modeldesign process steps.
The fundamental reasons for using controlled repositories for stor-ing these categories of metainformation are threefold:
• the need for consistent metainformation to ensure correctness andcoherence of collaborations, and thus, the need to ensure coherencebetween business network models, service types and service offers;
• the need to allow new concepts to be included to the ecosystem;and
• the need to restrict publication of metainformation to traceableparties for business accountability reasons.
For consistency enforcement, the ecosystem repositories are gov-erned by four ontology metamodels [10,49]:
• a domain ontology metamodel that defines basic ecosystem con-cepts like collaboration, service, and contract;
• a methodology metamodel that defines phases of service engineer-ing processes and especially the produced artefacts;
• a domain reference metamodel that captures the infrastructure ele-ments by defining the operational-time support functions and arte-facts manipulated;
• a knowledge management metamodel that defines language onstoring each knowledge item and relationship.
The ontology metamodels are interlinked so that a basic conceptcan be connected to its representation format in a methodology andan operational-time infrastructure function, and has a technical stor-age representation. Thus, the design and production time artefactsalso become artefacts at the operational time.
Once the ontology metamodels are in place, the ecosystemknowledge-base can take in published artefacts. Jointly, the metain-formation repositories form an ontology forest where the businessnetwork models form roots. The service types created can be insertedinto the name space of the first business network model they are usedin, to differentiate them from other similarly named types in otherapplication domains.
When designers and analyzers try to enter information items andmodels to the repositories, the corresponding metamodel layers willbe used to study whether the suggestion is correct. If not, the de-signers can be given advice on how to improve the proposal. The de-signers may also study existing artefacts in the repositories, assesstheir relationships and create relationship links between the arte-facts. For these relationships, similar modeling layers exist, andthus, at this phase too, advice on analysts may be provided.
For the business network model creation, we have taken a some-what different approach that is utilized for example in virtual organi-zation breeding environments. In them, the establishment ofcollaborations starts by negotiation of the joint objectives and goals,and collaborative definition of the joint processes, and definition ofthe methods of connecting individual computing elements to a coher-ent whole. This phase is supported by breeding environments whereselection of partners, learning about their capabilities, and designingthe joint business network model takes place. In this process the setof functionality is determined, as well as a set of business policiesthat must be adopted.
Although all this is necessary for the collaboration establishment,it is not necessary to perform the whole process independently foreach collaboration. Neither is it necessary to repeat the whole processwhen partners have wishes to make changes to the collaboration
goals, processes, or supporting applications or computing platforms.The business network models can be collaboratively designed, veri-fied and validated for their suitability.
Because we have separated the business network model designphase from the collaboration establishment phase, can the commit-ment phase be more automatic. These models also provide a commonvocabulary for enterprises to use at the collaboration negotiations:the pragmatic interoperability (processes and policies) can be testedalthough the partners do not necessarily have a joint history in thebreeding environment that would enforce interoperability.
The business network models must be verified and validated care-fully before being accepted to the repository. The engineering meth-odology used must declare the authority for submitting the modelto a business network model repository on behalf of the designingteam; we assume a team here, because the business network modeldesign requires expertise from multiple domains, such as businessbest practices, associated regulation systems, enterprise and processmodeling, market situation and room for new process innovations,and access to the feedback from past collaborations and their experi-ence. Because business network models are compositions of businessprocesses, many of the existing business process or protocol verifica-tion tools can be used to check for well-formedness, aliveness, free-ness from deadlock and other process properties. Furthermore, theinvolved information flows must be considered carefully to detectprivacy-threatening exchange of information, excess exchange of in-formation causing bad performance and privacy-threatening cumula-tion of information to roles.
Service type definitions form a basic vocabulary for declaring busi-ness network models and publishing service offers. The type defini-tions can be reused in multiple collaborations, too, thus creatingopportunities for business services to be used in cross-domain busi-ness networks.
For creating interoperability within the model base, the relation-ship assertions between models (BNMs or service types) across ad-ministrative domain repositories are important. The goal is not tocreate an environment where interoperability is granted betweenall "semantically similar" business networkmodels, but to allow grad-ual capturing of assertions where designers have taken the effort tocreate such an assertion. Once the assertion is done, and potentiallysome transformer elements to be used in the communication chan-nels are associated to the relationship, it is imperative that the re-ferred models do not change any more. When a new version of amodel is created, it will be entered as a new model that is competingfor the attention of designers and users with the old one. Assertionsabout relationships need to be created anew, because between repos-itories and administrative domains, there cannot be any coherent in-heritance hierarchy as it is possible within a single administrativedomain.
For the dynamic enhancement of the ontology frame with new con-cepts it is necessary to have sufficient rules at the upper metamodellevels to allow declaration of new language concepts and new rela-tionships between same meta-level concepts. Examples of enhance-ment needs include introduction of new non-functional propertieson services or communication types, or new regulatory rules overthe whole ecosystem.
For business accountability the repositories must control the publi-cation of offers or models strictly. This can be enlightened with a fewexamples: First, for service offers, the submitter must be identifiablefor the repository provider, even if the repository itself provides ano-nymity of the provider for the clientele. Second, service types and re-lationships between them must be immutable, in order to keep theinserted assertions correct, even in cases where independent reposi-tories are involved. Third, the reputation information collectorsmust be able to identify the experience report sources, although theidentities were hidden from the reputation information stream. Theaspiration is to provide traceability so that breaches against the
Fig. 6. Overview of the reflective management by contracts.
basic protocols and obligations of the ecosystem partners can beacted against.
The benefits for collaborations from the existence of these reposi-tories are associated to the correctness of the collaboration behavior.As eContract captures the reference points for the collaborative be-havior, the validity of the business network model that dictates theeContract structure is essential. The processes of controlling the busi-ness network model registration through the metamodel criteria, re-quired verification and validation steps before registering, andrequirement of the publisher being traceable all support this. Thebusiness network model may also predefine invariants for the collab-oration behavior through required policies in the collaboration.
As the service type relationship assertions can declare equality, sub-typing or replaceability properties, the type spaces can also be en-hanced over several repositories. The transformation elementspotentially associated with the relationships allow automatic commu-nication channel configuration across the domains. Both features thuswiden the service marketplace available and automate some otherwisecumbersome integration tasks.
4.3.4. Interplay of local agents and ecosystem infrastructureIn Sections 4.3.1 and 4.3.2 we have seen that each collaboration
life-cycle step sets responsibilities for both infrastructure servicesand enterprises' local agents. The interplay of the local and sharedeContract agent has been organized using the reflection model to-gether with a multi-agent system model.
A reflective system is a system that can reason about its ownstructure, behavior and state, and furthermore, can act upon itself.For reasoning and action triggering, the system includes a causallyconnected metalevel model of its own characteristics, making it ableto detect changes in itself or its environment, make decisions basedon that information, and change its own status or create interactionwith its environment. To quote the original definition [50]: “We de-fine computational reflection to be the behavior exhibited by a reflec-tive system, where a reflective system is a computational systemwhich is about itself in a causally connected way”. The concept hassuccessfully been applied on context sensitive and adaptive applica-tions, or rather, on the middleware level that supports such applica-tions: reflective middleware [51].
Fig. 6 illustrates the situation as follows. Here, the topmost model“system model” refers to an eContract after it has been establishedand committed to by all parties. This model, i.e. contract, can be chan-ged by a) human administrators at the involved enterprises request-ing so through their expert systems, or b) asynchronous event arisingfrom the underlying system, i.e. any of the services themselvesdetecting a situation requiring attention. An attention requiringevent is such that does not conform to the criteria set in the contract(either by a service itself detecting a failure or someone else in thebusiness network detecting a breach). This is normal in business, soit should not be considered as faulty behavior of the supporting soft-ware either. The event can thus be handled by the contract (agent)automatically or the decision can be forwarded for human interven-tion (necessary to control the amount of automation in presence ofbusiness and legal consequences of actions).
Viewing the managed system itself, the situation becomes morecomplicated, as the business services involved are not under the con-trol of a single authority, but belong to separate, independent admin-istrative domains. Thus, the willingness to perform actions, capabilityand implementation of the actions, and representation of the informa-tion related to the expected actionsmay differ significantly. We do notsuggest harmonization of the system and platform level, since one ofthe main goals of the architecture is to allow evolution — also on thistechnical level.
We can require the causal connection to be held between theeContract and the business network structures and criteria, but can-not assume that the causal connection would be completely unified.
Therefore, the solution has two parts. First, for each role in the con-tract there is a causal connection with the supporting business serviceat the providing enterprise. Second, the contract agent forms ashared-vocabulary messaging environment for the agents represent-ing participating enterprises. These enterprise agents are responsiblefor keeping their local services in synchrony with the committed con-tract status; here we use the reflective model again to allow a varietyof techniques to be utilized locally. Between themselves the enter-prise agents need to use protocols familiar from multi-agent systemsor speech act theories: definitions and declarations, requests, sugges-tions, commitments, and opinions.
In summary, the eContract object comprises of the collaborationmetamodel and operations changing it. The base-level real systemto be controlled with the eContract is represented by the local enter-prise level agents. Especially, the eContract is distributed to all part-ners. At each partner, the local eContract copy can be utilized forreflectively control the local services in their participation in thatcollaboration.
5. Discussion
Earlier, we have shown how the ODP concepts have been utilizedin the building of the Pilarcos ecosystem architecture. The Pilarcosecosystem characteristics provide an example of how the businessand computing facilities can be aligned in a systematic, dynamic envi-ronment where consistency, correctness and acceptability of collabo-rations can be controlled better than in an ad-hoc manner. On onehand, these characteristics could not have been achieved withoutthe dynamic, type- and model-based concepts and computationalfunctions indicated by the ODP reference model basic definitions.On the other hand, the basic functions have been added to, as thebasic computing function set was not as such sufficient for our pur-poses. Still, the ODP reference model provides all necessary facilitiesfor specifying these enhancements — and actually calling for newstandards into the ODP family for various specific purposes.
This section will briefly summarize the main conceptual and func-tional differences between the Pilarcos ecosystem architecture, ECO-LEAD [17] virtual organization breeding environment, SOA/SOC andWeb Services technologies, and ODP reference model, in order togive a more detailed view of the scope of each approach. We also dis-cuss the interplay of Pilarcos and ODP reference model.
5.1. Comparing goals, concepts and infrastructure functions
Both Pilarcos and ECOLEAD aim for supporting inter-enterprisecollaborations, but the scope of the systems differ.
The Pilarcos approach provides an architecture for open serviceecosystems where correctness and acceptability of inter-enterprisecollaborations can be collectively managed. The correctness require-ments are set by ecosystem members by defining business networkmodels, policies and service definitions that are dynamically utilizedas complex conformance reference points. Failures to conform tothese reference points trigger pre-committed recovery behavior.
The Pilarcos ecosystem architecture is based on a self-reflectivestructure that support, on one hand, the collaboration life-cycles,and on the other hand, the evolution of the ecosystem. For the collab-oration life-cycle management, new simple protocols have been in-troduced between enterprise-representing agents, eContract agents,and infrastructure services. These protocols create a managementframework that is able to make commitments across enterpriseboundaries; the information exchanged in this framework is suffi-cient for each participant to interpret requests, suggestions, commit-ments, failure complaints and policy statements. For the ecosystemconsistency management, the key role is possessed by the metamo-dels that regulate the infrastructure repositories and the relationshipsbetween items in different repositories. Furthermore, reputationflows in the ecosystem for an important feedback aspect, as thereputation-based trust management concept facilitates the scalabilityof the ecosystem.
Table 1Conceptual comparison.
Pilarcos ODP RM SOC
Business service Service, enterprise viewpoint object WeCollaboration, business network Community ComeContract Contractual context, liaison The
con
Business network model, acomposition of businessprocesses
Community type Abs
concepts of type and templateseparated (utilizes the ODPbasic terms); repositoriessupport multiple type systems,types or relationships can beannotated with domain-specifictemplates
Concepts of type and templateseparated;
A sitem
Administrative domain forbusiness: enterprise ororganization that is acontractually responsible unit;technical domain: within anadministrative domain ofbusiness a technicallyhomogenous domain
Administrative domain N/A
eContract federations;ecosystem federations
bX> federation N/A
Open service ecosystem A number ODP systems and theirjoint environment
WS
Technical interoperability, Interworking (technicalinteroperability) through sharedcommunication platform;
Pragmatic interoperability Shared goals and joint behavioralcontractual context, whether fixedor dynamic, is not defined; use ofunified BPMs (orchestration,choreographies)
N/Aesta
Collaboration Shared goals and joint behavioralcontractual context
Enacho
Business network model (BNM),composition of businessprocesses
Community type Joinspe
Enterprise policy Enterprise policy N/APolicies in eContracts Liaisons and failures N/A
In contrast, the ECOLEAD approach provides an architecture for virtu-al organization breeding environments (VBE) where trusted enterprisescan address new business opportunities together. For each opportunity,a coordinator is selected to form a group of competent parties and tolead a design of business processes for the occasion. The breeding envi-ronment provides computer-aided tools formanaging the breeding envi-ronment membership, knowledge-based on the trustworthiness,competences and values relevant for the member enterprises.
The ECOLEAD model addresses concepts of contract, but as themodel's aim is not to automate the breeding environment activities,concepts such as pragmatic interoperability and policies are not rele-vant. In addition, the realization of ECOLEAD services are based onWeb Services technologies, thus restricting the discussion on tem-plates rather than types. These interpretations of corresponding con-cepts to Pilarcos and the ODP reference model are listed in Table 1.
TheWeb Services stack limits itself to the computational and engi-neering solutions only. There is no natural counterpart for the ODPenterprise viewpoint type of discussion; a composite service can itselfbe considered as a counterpart of a contractual context. In Table 1 thisis reflected by no applicable concepts to match the ODP enterpriseviewpoint concepts of federations and policies, the Pilarcos conceptof pragmatic interoperability, and the fixed choice of a technologyplatform.
/WS ECOLEAD
b service Role in business process, Web serviceposed service, service choreography Virtual enterprise, virtual organizationcomposite service itself can besidered as a contractual context.
Virtual enterprise is associated withcontract that defines legalresponsibilities
The relationship between concepts of Pilarcos and the ODP refer-ence model is rather straightforward. In Table 1 some key conceptsof the ODP reference model are shown as the basis for the definitionof the related Pilarcos specialization: types, domains, contractual be-havior, and federations.
The essential concepts utilized in Pilarcos from those characteristicto the ODP reference model include the differentiation of types andtemplates, autonomy preservation and liaisons that are negotiableand needing distinct establishment and termination phases. These dif-ferentiations of type and template concepts aremissing fromWeb Ser-vices and virtual organization breeding environment approaches.
It should be remembered that the ODP reference model provides aframework to be used for specifying a distributed system in general,while the Pilarcos architecture aims for a runtime and developmentenvironment that pays special attention to the correctness of the col-laborative behavior viewed through the identified reference points.
In terms of the infrastructure functions envisioned in each ofthese approaches, the attention is drawn to the following aspects(see Table 2):
• all approaches identify a repository for discovery of services, butPilarcos provides an enhanced matching service for multi-partneractivities;
• all approaches provide a way of expressing service types, but thedifference is in the choice of actual denotational language or meta-level requirements on the languages accepted; further, the storagerequirements for these type descriptions differ;
• Web Services and ECOLEAD approaches expect business processesto be enacted by a similarly selected process engine by all partners,while Pilarcos expects business services to be active agents on theirown; the ODP reference model provides tools to define the systemin either way;
• trust management solutions differ; and• engineering of communication channels is dynamic in Pilarcos andthe ODP reference model, but static in Web Services and ECOLEAD.
The service discovery and selection functionality in SOA/WS isperformed by UDDI service, and it has relevantly the same functional-ity as the ODP trading function. Both take publication of service offersand provide service requestors an interface for queries based on ser-vice types and other properties. The query responses provide
Table 2Infrastructure function comparison.
Pilarcos ODP RM
Collaboration support knowledgerepositories and agents forruntime environment includethe ODP-trader within thepopulator agent, the servicetype repository, BNM repository,reputation flow, enterpriserepresenting agents forcontracting, eContract agent,private decision support system
Computational functions includeODP-trader, type repository,node management and securityfunctions
Trading, population tradingService type repository type repository, MOFReputation-based trustmanagement
N/A
Metainformation repositorymetamodels
MOF
N/A (business services areagents making initiatives)
Interactions in a liaison can beperformed by a method of choice
Binding BindingBinding type Binding typeChannel Dependent on the engineering and
technology choices on each platform
sufficient information for the requestor to create a binding to the se-lected service utilizing the platform binding services.
While the ODP trading function has rather similar functionality toUDDI, it, however, requires a type repository to be used to definestructure and semantics for the offers. This solution allows protectionof the consistency and trustworthiness of the offers. The type defini-tions cannot be changed after they have been stored into the reposi-tory, and therefore, it is safe to create assertions between typedescriptions to state in which cases a service of one type can bereplaced with a service of another type. Such assertions were not us-able if there were no trusted control over the immutability of theoriginal definitions.
In Pilarcos, theODP trading function has been used as a basic service,but in the populator service enhanced to take awhole business networkmodel and populate all peer roles simultaneously, making multi-wayinteroperability matching. Furthermore, the matching based on publicinformation is followed by an explicit, private decision-making phasethat concludes with the commitment and contract creation for the col-laboration. This private decision-making phase and explicit contractualcontext is in line with the ODP reference model. Moreover, Pilarcos re-quires all metainformation to be stored into controlled, trusted reposi-tories where assertions about type replaceability can be controlledand binding types can be supplemented with technology-specific com-munication channel architectures.
In Pilarcos, the operational phase of a collaboration is governed bythe separate eContract agent and by local, subjective monitoring ateach enterprise. As the regulations governing collaborative behaviorare considered to be independently declared at each administrativedomain, the collaborating partners from different domains mayhave contractual discrepancies with each other. Because regulatorysystems are changing and international collaborations cause mis-matches, it is important that the runtime support system is able to de-tect breaches from each partner's point of view separately. Therefore,in Pilarcos the business services are expected to be active agents, andthe business network models are utilized as regulations to be moni-tored by each collaboration partner by themselves.
In Pilarcos, the bindings between business services are configureddynamically according to the templates available from the type re-pository. For each communication channel the selected transparen-cies (transaction transparency or any of the ODP transparencies)and nonfunctional properties of the channel (e.g. non-repudiation
SOC/WS ECOLEAD
Global facilities for integrationsupport include UDDI, distributedBPM engines, transactioncoordination protocols, security,identity federation
Partner registry with partner capabilityinformation and trust classification,virtual enterprise registry,
UDDI UDDIWSDL descriptions published WSDL descriptions publishedN/A certification process leading to a trust
classification by the virtual organizationbreeding environment coordinator
N/A; WS higher level ontologies ontologies selected by VBE coordinator
supported by a trusted third party) determine a different architecture[52,53].
In contrast to these solutions, most SOA or Web Services solutionsenact business processes with a special distributed process engine,and therefore, no separate monitoring is needed. The communicationchannels are predefined by the structure of the selected ESB. ECO-LEAD utilizes this platform too.
Again, the ODP reference model provides facilities to specify eitherbehavior, but also supports by MOF (meta object facility) a hierarchyof metamodels specifying a part of the concepts also used in Pilarcos.In Pilarcos, the MOF style of metamodeling hierarchy is used more ex-tensively, as was described in Section 4.3.3.
While the ODP reference model and Web Services technologiesprovide no direct solution for trust management needs, ECOLEADand Pilarcos provide very different approaches. As explained inSection 4.3.2, Pilarcos calculates an expected future trustworthinessestimate for a business service based on the experience informationgenerated by itself and those ecosystem members who have had ear-lier collaborations involving that specific service. This is then com-pared to the tolerance of uncertainty the enterprise has at that time.Aspects considered in this balancing include monetary, reputation,satisfaction and control risks in the ecosystem. In contrast to this,ECOLEAD has a more static approach where each enterprise goesthrough an evaluation process on an elaborative list of properties in-cluding its capabilities, financial status, organizational competence,known breaches on the market and available resources. Based onthe results of this evaluation, the virtual organization breeding envi-ronment coordinator may grant the enterprise with a role in the vir-tual organization breeding environment. Depending on theconsidered trustworthiness of the enterprise it may be allowed toparticipate virtual enterprises, coordinate them, or even to view theVBE coordination information. The evaluation process is repeatedfrom time to time.
5.2. Interplay between Pilarcos and the ODP reference model
The interplay between Pilarcos and the ODP reference model hasthree interesting aspects:
• the ODP reference model is sufficient as a generic framework for thedesign of a complex, adaptive system;
• new application areas require specialized concepts and functions asintroduced in Pilarcos; and
• the ODP reference model has proven efficient in the design ofPilarcos.
5.2.1. Sufficiency of the ODP reference modelAs a result of modeling the Pilarcos system with the ODP concepts
it was seen that the ODP reference model has expressive powerenough to specify this kind of environment [38]. Furthermore, theODP reference model has provided tools for identifying the referencepoint framework to cover collaborations as complex, adaptive sys-tems, as seen in this paper. To evaluate this claim, and in order tostudy the feasibility of the Pilarcos solution itself, Pilarcos ecosystemsolutions have been analyzed with a number of independentmethodologies.
To start with, as the CINCO group has roots in distributed systems,constructive methodology is always present: creating prototypes foreach service and gaining experience on the feasibility of the approachin that way, making performance measurements of the critical ele-ments, and utilizing the measurement data for analytical models ofthe behavior patterns in the whole system looking for problemspots. Most of the measurements have been published either as stu-dent work or otherwise in Finnish.
Beyond that, the daily working practices resemble those of archi-tecture evaluation methodologies (e.g. ATAM [54]). Within the
group itself, expertise from different domains of computer scienceand software engineering has been applied for studying the potentialfailure points of the architecture and scenarios important for thefunctionality and system quality of both at the independent partnerside and at the ecosystem scope. The interaction with companies –
that is regular in projects funded by TEKES (Finnish technology devel-opment centre) – has given us opportunities to view the present chal-lenges in companies (telecom, integration solution developers,networked business coordinators). The approaches taken have beenexposed for open criticism by company experts; company-initiateduse scenarios and threat scenarios have been addressed. The casesare, however, private for the companies, but have covered system in-tegration ((e.g. [55]) styles, for example. Further, collaboration net-works have given insight into new domains of the application areaof inter-enterprise computing such as networked business and busi-ness strategies (e.g. [56] in FiFear), and enterprise architecture andenterprise modeling (e.g. TOGAF [22] and GERAM, CIMOSA inINTEROP VLAB).
The basic architecture now comprises of the collaboration andproduction life-cycles that are further refined with aspects such astrust management, privacy-preservation and nonfunctional propertygovernance. Each of these aspects have similarly been required tohave a well-formed process flow with clear triggers (potentiallyfrom multiple sources), shared artefacts with the other processes,and clear post-conditions. What differs from the traditional state-machine-type formalisms is that special care has been paid to under-standing the most relevant classes of imperfect terminations, and tonew supporting processes being triggered while the main process isrunning. The disciplines applied include, for example, formal methodsfor modeling complex systems and analyzing them (e.g. [57,58]), andrequiring well-formedness of processes leading from one consistentstate to another and understanding how independent actors canhave different understandings of the present state and triggers in itfor further activities. Therefore we have ensured that each processhas clear preconditions and post-conditions and a locally determinis-tic behavior; for the global system, an apparently non-deterministicbehavior occurs, due to the simultaneous running of several processesaffecting each other and the fact that there are human interventionsteps in the processes. The formalizations of these are being pub-lished (e.g. [49]).
Like other related research, we have studied the architecture as amulti-agent system (e.g. [59]); each of the enterprises is to be repre-sented by their dedicated, subjective agent, we also require agents torepresent the contracts governing the collaborations created. The se-mantics of the protocols designed match the multi-agent languagepatterns and speech act elements (declarations, expressions of inten-tions and preferences, commitments, especially).
Finally, one of our special interests has been security threat analy-sis [46] (following principles of [60], for example) in the areas of trustmanagement [12] and privacy preservation.
5.2.2. Enhancing the ODP model for service ecosystemsThe additional concepts introduced in Pilarcos include business
service, collaboration (i.e. business network), computational service,and monitors. These are all concepts built according to the ODP con-cepts and appear in the enterprise viewpoint specification of thePilarcos system itself. The ODP communities and objects havegrown into business networks and services; the ODP system interact-ing with its environment has been formalized by the ecosystem. Fur-ther, the ODP enterprise language specification with roles,interactions, policies and assignment rules is now denoted by theterm business network model and have become more associatedwith business processes and choreography languages that are rele-vant concepts in the SOC, Web Services and ECOLEAD frames.
As Pilarcos contributes to the alignedmanagement of business andcomputing solutions, it is necessary that many of these concepts
include components of both business and technology concerns. Toname an example, interoperability management has been expandedwith the concept of pragmatic interoperability in order to capturethe strategic business-level reasons that guide decision-makingabout collaborations within an enterprise.
Further additions to the computational environment that is visiblethrough the ODP engineering and computational viewpoints include
• populator (built on top of the ODP trading function),• service type repository to create a shared vocabulary domain, tocreate mappings between types, and capturing templates from dif-ferent technology domains under the scope of a shared type (builtas a conceptual enhancement from the ODP type repository and fol-lowing layered metamodel principles of MOF),
• business network model repository (utilizing MOF principles againbut missing from the ODP reference model),
• reputation flows (missing from ODP reference model),• private decision-making support functions (related to the ODP ref-erence model concepts of policies in enterprise viewpoint, adminis-trative domains and federations)
• breach management (related to the ODP concepts on failures),• eContract (related to the ODP concepts on liaisons and contractualcontexts)
Since ODP provides a generic reference model, the application do-main specific concepts and supporting functions should not beexpected to be part of it. The application domain that Pilarcos ad-dresses is rather generic as well, but restricted to networked businesssupport; however, the same concepts are applicable to expert net-works, media distribution, and even social networks but with lesseremphasis on automatable behavior criteria. The additional conceptsand protocols are thus application-domain specific but fundamentallyplatform-independent.
5.2.3. Efficiency of the ODP reference modelOne of the structuring elements for the work has been to apply the
ODP reference model means for evaluating system completeness, cor-rectness and especially coherence to the architecture. This is not onlyfor evaluating the architecture, but to ensure that the ecosystem archi-tecture is instrumented with facilities for itself to evaluate the coher-ence and correctness of operational inter-enterprise collaborations.
The use of the ODP reference model has led to identification ofconcept relationships and supporting processes that otherwise havenot become visible in the discussion about company needs, for exam-ple. An important key to the whole Pilarcos design is to rely on type-based knowledge-bases and processes, instead of leaning on the tem-plates directly as we have seen in most of the related work. The use ofthe ODP viewpoints has also helped in minimizing the complexity ofor risks embedded in the model. To name an example, the designchoice done on the complex relationships between ecosystem sub-community objects (such as the relationship between business net-work model, eContract and business network, recall Fig. 4) confirmedthe suitability of separating the business network model design to adevelopment and management activity on its own, despite the initialfeeling of unnecessary complications. Indeed, the actors involved inbusiness network modeling and business network negotiation forma potentially quite different set of parties.
6. Conclusion
The experience in developing Pilarcos architecture and relatedprototype implementations has taken place in interaction with theODP standards work. Thus it is natural that the ODP facilities haveproven to be sufficient and efficient for specifying the Pilarcos ecosys-tems. Furthermore, we can note that the ODP facilities are sufficientfor any adaptive, complex system needs. Depending on the applica-tion area some additional concepts and requirements must be
added to the generic frame. In the case of service ecosystems, wehave added concepts for eContracts, reputation-based trust manage-ment, privacy-preservation and business network model repositories,to name the most important. We have also worked on a more elabo-rate framework of nonfunctional properties ranging from businesslevel to technology of communication platforms.
As the networked business is still becoming more dependent onthe aligned computing solutions, it would be important to extendthe ODP standards family with frameworks of eContracts, trust man-agement (independent of being based on reputation or certifications),and privacy-preservation functions. The earlier work on QoS aspectsshould be revitalized to address a framework of nonfunctional prop-erties to match the needs of eContracting. Similarly to specific stan-dards on CORBA interfaces for example, specific standards on thesenew topics should get their mappings to popular techniques oftoday, including Web Services. Similarly to specific standards for theUML profile for enterprise language, for example, specific standardsfor the design and verification methods on the eContract patternsand nonfunctional properties should get their methodologies in thepopular technical environments.
Acknowledgment
Thiswork is part ofmy research group activities (cinco.cs.helsinki.fi)at the Department of Computer science at the University of Helsinki.
References
[1] L. Kutvonen, T. Ruokolainen, S. Ruohomaa, J. Metso, Service-oriented middlewarefor managing inter-enterprise collaborations, Global Implications of Modern En-terprise Information Systems: Technologies and Applications, Advances in Enter-prise Information Systems (AEIS), IGI Global, 2008, pp. 209–241.
[2] L. Kutvonen, J. Metso, S. Ruohomaa, From trading to eCommunity management:responding to social and contractual challenges, Information Systems Frontiers(ISF)— Special Issue on Enterprise Services Computing: Evolution and Challenges9 (2–3) (2007) 181–194.
[3] ITU-T Rec. X.902 | ISO/IEC 10746–2: Information Technology — Open DistributedProcessing — Foundations, 2010.
[4] ITU-T Rec. X.903 | ISO/IEC 10746–3: Information Technology — Open DistributedProcessing — Architecture, 2010.
[5] D. Schmidt, Model-driven engineering, IEEE Computer 39 (2) (2006).[6] Z. Stojanovic, A. Dahanayake (Eds.), Service-Oriented Software System Engineering:
Challenges and Practices, Idea Group Publishing, 2005.[7] W.-T. Tsai, X. Wei, R.P. adn Jen-Yao Chung, Q. Huang, Y. Chen, Service-oriented
system engineering (SOSE) and its applications to embedded system develop-ment, Service Oriented Computing and Applications 1 (1) (2007) 3–17.
[8] T. Margaria, B. Steffen, Service engineering: linking business and it, Computer 39(10) (2006) 45–55.
[9] M.P. Papazoglou, W.-J. van den Heuvel, Business process development life cyclemethodology, Communications of the ACM 50 (10) (2007) 79–85.
[10] T. Ruokolainen, L. Kutvonen, Managing interoperability knowledge in open serviceecosystems, Proceedings of the 13th Enterprise Distributed Object Computing Con-ference Workshops, EDOCW, IEEE, Auckland, New Zealand, 2009, pp. 203–211.
[11] S. Ruohomaa, L. Kutvonen, Making multi-dimensional trust decisions oninter-enterprise collaborations, Proceedings of the Third International Conferenceon Availability, Security and Reliability (ARES 2008), IEEE Computer Society, Bar-celona, Spain, 2008, pp. 873–880.
[12] S. Ruohomaa, L. Kutvonen, Trust and distrust in adaptive inter-enterprise collab-oration management, Journal of Theoretical and Applied Electronic CommerceResearch, Special Issue on Trust and Trust Management 5 (2) (2010) 118–136.
[13] J. Metso, L. Kutvonen, Managing virtual organizations with contracts, Workshopon Contract Architectures and Languages (CoALa2005), Enschede, The Nether-lands, 2005.
[14] T. Ruokolainen, L. Kutvonen, Service typing in collaborative systems, in: G.Doumeingts, J. Mueller, G. Morel, B. Vallespir (Eds.), Enterprise Interoperability:New Challenges and Approaches, Springer, 2007, pp. 343–354.
[15] T. Ruokolainen, L. Kutvonen, Addressing autonomy and interoperability in breed-ing environments, in: L. Camarinha-Matos, H. Afsarmanesh, M. Ollus (Eds.), Net-work-Centric Collaboration and Supporting Frameworks, Vol. 224 of IFIPInternational Federation for Information Processing, Springer, Helsinki, Finland,2006, pp. 481–488.
[16] E. Fehr, U. Fischbacher, The nature of human altruism, Nature 425 (2003).[17] L.M. Camarinha-Matos, H. Afsarmanesh, Virtual enterprise modeling and support
[18] R.J. Rabelo, S. Gusmeroli, C. Arana, T. Nagellen, The ECOLEAD ICT infrastructure forcollaborative networked organizations, Network-Centric Collaboration and Sup-porting Frameworks, Vol. 224, Springer, 2006, pp. 451–460.
[19] S. Msanjila, H. Afsarmanesh, HICI: an approach for identifying trust elements inthe case of technological trust perspective in VBEs, 2nd International Conferenceon Availability, Reliability and Security, 2007, pp. 757–764.
[20] N. Mehandjiev, P. Grefen (Eds.), Dynamic Business Process Formation for InstantVirtual Enterprises, Springer, 2010.
[21] J.A. Zachman, A framework for information system architecture, IBM SystemsJournal 26 (3) (1987) 276–292.
[22] The Open Group Architecture Forum, TOGAF 9: The Open Group ArchitectureFramework, The Open Group, 2008.
[23] L. Kutvonen, Using the ODP reference model for enterprise architecture, Proceed-ings of WODPEC2007, 2007.
[24] M.P. Papazoglou, P. Traverso, S. Dustdar, F. Leymann, Service-oriented comput-ing: a research roadmap, International Journal of Cooperative Information Sys-tems 17 (2) (2008) 223–255.
[25] W3C, Web services architecture, http://www.w3.org/TR/ws-arch/2004.[26] ITU-T Rec. X.901 | ISO/IEC 10746–1: information technology — open distributed
processing — Overview, 1998.[27] P. Linington, Z. Milosevic, A. Tanaka, A. Vallecillo, Building Enterprise Systems
with ODP: An Introduction to Open Distributed Processing, Chapman and Hall,2011.
[28] J. Bubenko, From information algebra to enterprise modelling and ontologies — ahistorical perspective on modelling for information systems, Conceptual Model-ling in Information Systems Engineering, 2007, pp. 1–18.
[29] ITU-T Rec. X.911 | ISO/IEC 15414: information technology— open distributed pro-cessing — Enterprise language, 2006.
[30] ITU-T Rec. X.906 | ISO/IEC 19793: information technology— open distributed pro-cessing — use of UML for ODP system specifications, 2010.
[31] ITU-T Rec. X.950 | ISO/IEC 13235–1: Information Technology — Open DistributedProcessing — Trading Function: Specification, 1998.
[32] ITU-T Rec. X.910 | ISO/IEC 14771: Information Technology — Open DistributedProcessing — Naming Framework, 1999.
[33] ITU-T Rec. X.960 | ISO/IEC 14769: Information Technology — Open DistributedProcessing — Type Repository Function, 2001.
[34] ITU-T Rec. X.930 | ISO/IEC 14753: Information Technology — Open DistributedProcessing — Interface References and Binding, 1999.
[35] ITU-T Rec. X.931 | ISO/IEC 14752: Information technology - open distributed pro-cessing – protocol support for computational interactions, 2000.
[36] ISO/IEC 19502: Information technology - Open distributed processing – Meta Ob-ject Facility (MOF), 2005.
[37] T. Ruokolainen, S. Ruohomaa, L. Kutvonen, Solving service ecosystem governance,Workshops Proceedings of the 15th IEEE International Enterprise Distributed Ob-ject Computing Conference, EDOCW 2011, Helsinki, Finland, August 29 - Septem-ber 2, 2011, IEEE Computer Society, 2011, pp. 18–25.
[38] L. Kutvonen, What applying of the ODP viewpoints teaches us about tool-chains,10th IEEE International Enterprise Distributed Object Computing ConferenceWorkshops (EDOCW'06), IEEE Computer Society, Hong Kong, 2006, p. 35.
[39] M.P. Papazouglou, W.-J. van den Heuvel, Service-Oriented Computing: Sta-te-of-the-Art and Open Research Issues, IEEE Computer 40 (11) (2007).
[40] M.P. Papazoglou, D. Georgakopoulos, Service oriented computing, Communica-tions of the ACM 46 (10) (2003).
[41] T. Ruokolainen, L. Kutvonen, Managing non-functional properties ofinter-enterprise business service delivery, Non Functional Properties and ServiceLevel Agreements in Service Oriented Computing Workshop (NFPSLA-SOC)(co-located with the 5th International Conference on Service Oriented Comput-ing, ICSOC 2007), Vienna, Austria, 2007.
[42] T. Bellwood, L. Clément, D. Ehnebuske, A. Hately, M. Hondo, Y.L. Husband, K.Januszewski, S. Lee, B. McKee, J. Munter, C. von Riegen, UDDI Version 3.0. UDDISpec Technical Committee Specification, 19 July 2002, UDDI.org, Jul. 2002.
[43] L. Kutvonen, S. Ruohomaa, J. Metso, Automating decisions for inter-enterprisecollaboration management, Pervasive Collaborative Networks. IFIP TC 5 WG 5.5Ninth Working Conference on Virtual Enterprises, September 8–10, 2008, Poz-nan, Poland, no. 283 in IFIP, Springer, Poznan, Poland, 2008, pp. 127–134.
[44] Y. Shen, M. Miettinen, P. Moen, L. Kutvonen, Privacy preservation approach in ser-vice ecosystems, Workshops Proceedings of the 15th IEEE International Enter-prise Distributed Object Computing Conference, EDOCW 2011, Helsinki, Finland,August 29 - September 2, 2011, IEEE Computer Society, 2011, pp. 283–292.
[45] L. Kutvonen, J. Metso, T. Ruokolainen, Inter-enterprise collaboration managementin dynamic business networks, On the Move to Meaningful Internet Systems2005: CoopIS, DOA, and ODBASE: OTM Confederated International Conferences,CoopIS, DOA, and ODBASE, Vol. 3760 of Lecture Notes in Computer Science,Agia Napa, Cyprus, 2005, pp. 593–611.
[46] L. Viljanen, Trust and Mistrust Management in Enterprise Systems, Department ofComputer Science, University of Helsinki. Licentiate thesis C-2011-.
[47] S. Ruohomaa, L. Viljanen, L. Kutvonen, Guarding enterprise collaborations withtrust decisions — the TuBE approach, Interoperability for Enterprise Softwareand Applications. Proceedings of the Workshops and the Doctoral Symposiumof the Second IFAC/IFIP I-ESA International Conference: EI2N, WSI, IS-TSPQ2006, ISTE Ltd., Bordeaux, France, 2006, pp. 237–248.
[48] S. Ruohomaa, L. Kutvonen, E. Koutrouli, Reputation management survey, Pro-ceedings of the 2nd International Conference on Availability, Reliability and Secu-rity (ARES 2007), IEEE Computer Society, Vienna, Austria, 2007, pp. 103–111.
[49] T. Ruokolainen, Modelling framework for interoperability management in collab-orative computing environments, Department of Computer Science, University ofHelsinki. Licentiate thesis C-2009-9.
[50] P. Maes, Computational reflection, Ph.D. thesis, Vrije Universiteit Brussel (1987).[51] G. Coulson, What is reflective middleware? IEEE Distributed Systems Online,
http://www.imamu.edu.sa/dcontent/ITTopics/java/rmarticle1.pdf.[52] L. Kutvonen, T. Ruokolainen, J. Metso, Interoperability middleware for federated
business services in web-Pilarcos, International Journal of Enterprise InformationSystems, Special issue on Interoperability of Enterprise Systems and Applications3 (1) (2007) 1–21.
[53] T. Ruokolainen, L. Kutvonen, Service ecosystem framework for managing NFPs inservice and collaboration life cycles, in: S. Reiff-Marganiec, M. Tilly (Eds.), Hand-book of Research on Non-Functional Properties for Service-Oriented Systems: Fu-ture Directions, 2011.
[54] P. Clements, R. Kazman, M. Klein, Evaluating Software Architectures: Methodsand Case Studies, Addison Wesley, 2002.
[55] D.S. Linthicum, Next Generation Application Integration: from Simple Informa-tion to Web Services, Addison-Wesley, 2003.
[56] J. Heikkila, M. Heikkila, The Role of Business Models in Developing Business Net-works, 2008.
[57] D. Harel, M. Politi, Modeling Reactive Systems with Statecharts: The STATEMATEApproach, McGraw-Hill, 1998.
[58] C. Ramamoorthy, G. Ho, Performance Evaluation of Asynchronous Concurrent SystemsUsing Petri Nets, IEEE Transactions on software Engineering 6 (5) (1980) 440–449.
[59] M. Wooldridge, An Introduction to Multiagent Systems, Wiley, 2002.[60] E.G. Amoroso, Fundamentals of Computer Security Technology, Prentice-Hall
International Inc., 1994
Lea Kutvonen is an affiliate professor at the University ofHelsinki, Department of Computer Science, where sheleads the Collaborative and Interoperable Computing Group(CINCO). Her research interests lie in open service ecosys-tems, i.e., mature environments and methods for inter-enterprise collaboration for networked business. This involvesalignment of infrastructure services for collaborationmanage-ment, service-oriented software engineering, and governanceat enterprise and ecosystem levels. She has been activelyinvolved in the ODP standardization work, on the basic re-ference model and many of the function standards.
