Design Rules for Swiss eGovernment Version 1.0 Willy Müller, Beat Schmid, Christoph Schroth, Till Janner
Federal Strategy Unit for IT (FSUIT) 3003 Bern, Switzerland
[email protected] University of St. Gallen, MCM Institute 9000 St. Gallen, Switzerland {beat.schmid, christoph.schroth, till.janner}@unisg.ch
Table of Contents
Introduction ..................................................................................................................3 Foundations of the Architecture Framework...........................................................11 Physical Component ..................................................................................................20 Logical Component ....................................................................................................26 Organizational Component .......................................................................................34 Conclusion ..................................................................................................................39 References ...................................................................................................................40 Appendix: The St. Gallen Media Reference Model .................................................45
2
Glossary of Acronyms Acronym
Definition
ACC
Aggregate Core Component
ASCC
Association Core Component
BCC
Basic Core Component
BPEL
Business Process Execution Language
BPM
Business Process Management
B2B
Business-To-Business
CCTS
Core Component Technical Specification
CDT
Core Data Type
EBS
Event Bus Schweiz
EDA
Event-Driven Architecture
ESB
Enterprise Service Bus
HERA
Helvetic eGovernment Reference Architecture
HTTP
Hypertext Transfer Protocol
IAM
Identity and Access Management
IAP
Interaction Pattern
IM
Interaction Module
MAS
Multi Agent System
MRM
St. Gallen Media Reference Model
NDR
Naming and Design Rules
SEAC
Swiss eGovernment Architecture Community
SOA
Service-Oriented Architecture
SOAP
Simple Object Access Protocol
UBL
Universal Business Language
UCM
Unified Context Methodology
UDDI
Universal Description, Discovery, and Integration
WSDL
Web Services Description Language
XML
Extensible Markup Language
3
Introduction This paper argues for a set of general design rules which shall constitute a foundation for the activities pursued by the Swiss e-Government Architecture Community (SEAC)1. The focus thereby lies on electronic interoperation across the boundaries of companies and governmental institutions 2. It shall motivate members of the SEAC to propose amendments or extensions towards a comprehensive, common understanding. Today, Service-Oriented Architectures (SOAs) have already become an acknowledged architectural style underlying the implementation of crossorganizational electronic interaction. The widely accepted normative OASIS Reference Model for SOA3 defines SOA as “…a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations”. The central concept of the SOA Reference Model is the existence of services which provide access to capabilities by well-defined interfaces to be exercised following a service contract with constraints and policies. This enables a loose coupling of services (thereby minimizing mutual dependencies) and complies with the information-hiding principle. Services are provided by entities, the service providers, and are to be used by others, the service consumers. Services may be composed (some also refer to it as orchestration) on the basis of other, existing services, thereby adhering to the principles of reuse, and recursivity. The
(EFD, 2008; Müller, 2007) (Buxmann, Diefenbach, & Hess, 2008; Grau, Wolf, Kramer, & Hess, 2007; Picot, Dietl, & Franck, 2002; Picot, Reichwald, & Wigand, 2001) 3 (MacKenzie, 2007) 1 2
service composition builds the foundation for flexible and agile Business Process Management (BPM). Figure 1 illustrates the fundamental concepts of SOA4: On the lowest level (“services and infrastructure”), organizations offer dedicated service interfaces (black circles) and make them retrievable via registry mechanisms. The services behind such service interfaces may be composed of a number of other internal services (symbolized as small gray circles), complying with the principle of information hiding. However the services & infrastructure layer concentrates on a set of common components enabling the communication between the organizations’ service interfaces.
Organization WS-Interf.
WS-Interf.
Information Object
Language ---------
SOA System C
SOA System B
SOA System A
Services & Infrastructure
Registry
Figure 1: Basic Service-Oriented Architecture (SOA)5
4 5
(Schroth & Janner, 2007) (Schroth & Janner, 2007)
2
In addition to this infrastructural or service level, a common understanding of the exchanged messages needs to be ensured, i.e. the language used, its syntax and semantics6. As illustrated on the second level in Figure 1, information objects sent from one service to the other need to be subject to a shared standard. On the third level, service providers and consumers obey certain obligations and rights, i.e. roles, and are orchestrated according to a given structural as well as process-oriented organization.
Service * 1
Service Interface 1 1..*
Operation * 1..* *
Data Type *
Figure 2: WSDL service definition7
The concept of supporting loosely coupled, business-aligned and networked services can be realized with the help of numerous different technologies. Since a few years, the Web services stack8 (see Figure 3) has been widely acknowledged as one of the most promising toolsets that provides a uniform, systemindependent way for interlinking potentially dispersed software applications in a flexible way. In its role as modular “plumbing […] for information systems to
(Schroth, Janner, & Stuhec, 2007b; Schroth, Pemptroad et al., 2007) The service interface provides information regarding address and syntax of input and output messages, while the data types specify the semantics of the information objects. 8 (Alonso, Casati, Kuno, & Machiraju, 2004; Kaye, 2003; Krafcik, Banke, & Slama, 2006; McAfee, 2005; Papazoglou & van den Heuvel, 2006; O. Zimmermann, Schlimm, Waller, & Prestel, 2005) 6 7
3
interact without human involvement”9, the stack addresses service interface descriptions (WSDL), message transfer protocols (SOAP), the structuring of registries which are required for making services retrievable (UDDI), as well as service composition (BPEL) : The Web Service Description Language (WSDL) thereby defines an XML format for the interface description. According to WSDL, each service is described by a service interface (see Figure 2). Each service interface offers a set of defined operations. In this context, operations represent the abstract definition of the smallest discrete usable functionality of a service. These operations define the data type of the service (data types in Figure 2 – often not explicitly specified). The input and output parameters of operations are defined by the data types of the input and output messages. Besides this, a WSDL service interface also provides detailed information about how and where service functionality is available (binding section of a WSDL file), protocols, transmission formats and endpoint information.
Figure 3: The Web services stack10
(McAfee, 2005) From a lecture conducted by Dr. Roland Ritsch at the University of Applied Sciences St. Gallen (FHSG) 9
10
4
SOAP is used to specify the data format of the messages to be sent between service provider and requester whereby HTTP is the most used data transfer protocol. The Universal Description, Discovery, and Integration (UDDI) standard is leveraged to define publicly available registries that are needed for search and identification of services. The Business Process Execution Language (BPEL) is widely accepted as a standard for composing different services according to a specific business process from the perspective of one participant. Based on the general architectural style of SOA and technical standards such as the Web Services stack, IT service infrastructures for cross-organizational electronic interaction may be realized today. However, such infrastructures are still prevailingly being setup as stand-alone island solutions for highly specific purposes11. The frustration of organizations in building and supporting numerous single-purpose portals and electronic business communities grows: Both the organization and implementation do not allow for sufficient flexibility, extensibility, decentralized management and operational efficiency. Integration costs remain high. Figure 4 illustrates the issues today’s B2B communities are facing: Agents electronically interact inside the boundaries of their respective corporate spheres that may be built following the SOA architectural style. On the left side of Figure 4, for example, three agents offer services (service systems A, B, and C). As argued above, the interaction between these services is governed by a common language (see the second layer) and a previously negotiated organizational logic (third level). The combination of technical services and infrastructure, a common language, and an organizational model is referred to as electronic business
(Lheureux, Biscotti, Malinverno, White, & Kenney, 2007; Lheureux & Malinverno, 2006, 2007; White, Wilson, & Lheureux, 2007) 11
5
medium12. A structuring framework for the design and analysis of electronic business media forms the St. Gallen Media Reference Model (MRM)13. In this context, a medium is defined as enabler of interaction, i.e. it allows for exchange, particularly the communicative exchange between agents. We refer to a set of agents interacting via a dedicated medium as interaction module (IM). In accordance with this definition, Figure 4 depicts two IMs (IMA and IMB).14 In today’s globally networked service economy, there is a growing need for efficient and agile service interaction that also spans across the boundaries of companies. However, significant silo walls still exist on all three above mentioned layers. In case an agent participating in the interaction module shown on left side of Figure 4 (e.g., SOA system C) intends to interact with an agent within the IM on the right side (e.g., SOA system E), significant interoperability issues emerge. The interaction within the IM on the right side may follow completely different organizational design concepts, may be based on a totally different “language”, and may rely on different standards concerning service interfaces and message exchange infrastructure.
(Lechner & Schmid, 2000; Schmid, 1997; Schmid & Lechner, 2000; Schmid, Lechner, Klose, & Schubert, 1999) 13 See Appendix for further details 14 To illustrate the definition of media, agents, and IMs: The SEDEX platform, for example, represents an electronic business medium which allows a specific set of agents in the resident data management context (e.g., the resident data management offices and certain federal agencies) to interact with each other. The defined number of agents and their medium is then referred to as interaction module. 12
6
Interaction Module A
Adaptation
Organization
Interaction Module B
Organization WS-Interf.
WS-Interf.
Information
Object
Object
Language
SOA System C Services & Infrastructure
WS-Interf.
WS-Interf.
Information
Language ----SOA ----System A Registry
SOA System B SOA System F Services & Infrastructure
----SOA ----System D
SOA System E
Registry
Figure 4: Single- purpose, hard-wired, and mutually unconnected interaction modules
In order to enable interoperability across the boundaries of companies or public authorities and to break down these silo walls, measures need to be taken on all three above mentioned layers. In case interaction modules have grown according to completely different requirements and are thus implemented as proprietary island solutions, adapters are required that cover all three levels. Such adapters first of all physically connect the different media, e.g. via the Internet (infrastructure) and on the service level (e.g., via a SOAP-based client-server connection). They also mediate between the different “languages” (layer two) and between the different organizational logics (layer one). This is the well known integration problem, which may be very costly unless the two systems to be integrated follow similar design rules, and the designs of the different layers are available in an explicit form. The definition of such generic design rules is at the heart of this paper. Based on such rules, interoperability between different IMs and their respective electronic business media can be increased significantly. By complying with these rules, architects (in the Swiss public sector and also beyond) are provided with a methodology to design interaction modules which implement heterogeneous, individual requirements and are still easily interoperable with other modules which adhere to the same generic design rules.
7
The design rules must allow for the evolution of a multiplicity of media for different communities of agents, on different levels, as country, cantons, municipalities, and different tasks. They should allow for a recursive architecture of the whole system, for reorganization and evolution, and interoperability in a generic and straight forward way. Thereby modularity is a key design element, i.e. to enable the systematic decomposition of interaction scenarios into mutually independent, yet interoperable interaction modules (IMs)15. This document will elaborate on the fundamentals of these design rules16 and will thereby cover the technical, the logical, and the organizational layer as argued above:
On a technical level the agents have to be connected physically in order to allow for their interaction, especially for the communication between them. Existing platforms and standards for the implementation of crossorganizational business relationships can mostly be considered as proprietary island solutions.17 But more and more the Internet and its services become the platform for business interaction. In this paper, we argue for an extended version of the Event-Bus Schweiz18 standard which allows for the setup of a federated event bus infrastructure. This system of loosely coupled bus media shall act similar to a cross-organizational operating system. We call this layer C-component according to the MRM(C for channel system).
(Collm et al., 2008; Schroth, 2008b, 2008c, 2008d, 2008e; Schroth & Janner, 2008a, 2008b; Schroth & Schmid, 2008) 16 (Collm et al., 2008; Schmid & Schroth, 2008, 2009; Schmid, Schroth, Miche, & Janner, 2009; Schroth, 2008b, 2008c; Schroth & Janner, 2008a, 2008b; Schroth, Pemptroad et al., 2007; Schroth & Schmid, 2008, 2009; Schroth & Siebeck, 2009) 17 (Lheureux et al., 2007; Lheureux & Malinverno, 2006, 2007; White et al., 2007) 18 (Müller, 2007) 15
8
The second “language” level defines the types of the objects of interaction, i.e. the objects, on which the agents act, and which they exchange. Here, a plethora of different, industry-specific standards today exist which enable and at the same time often prevent from cross-domain interoperability. Today, “mapping experts” and “data consultants” are forced to understand every syntactic and semantic detail of proprietary application interfaces in order to seamlessly interconnect them. A novel approach is required which provides modular semantic building blocks that act as common basis for modelling different information objects.19 Even more importantly: There shall be common design rules for the structuring of this layer. In line with the MRM we call this layer L-component (L for language, or logic). It provides the common ‘logical space’ of the community of interacting agents.
On an organizational level, the types of the interacting agents have to be defined explicitly through the introduction of role descriptions. In addition to this, the procedures of interaction must be defined, be it in a declarative way as rules, or procedurally as traditional processes. Existing methods for modelling cross-organizational interoperation dominantly follow a processoriented approach. This document argues for a novel modular method that considers both structural as well as process-oriented organization. We call this part O-component (the organizational component) which is as well based on the definition of the MRM. Summing up, a comprehensive approach is required for the modular organization and implementation of electronic interaction a cross-organizational (Gionis, Charalabidis et al., 2007; Janner et al., 2008; Janner, Schmidt, Schroth, & Stuhec, 2006; Schroth, Janner, & Stuhec, 2007a, 2007b; Schroth, Pemptroad et al., 2007) 19
9
boundaries which today mostly relies on proprietary and unconnected island solutions. In this paper, we therefore outline the fundaments of an architecture framework that provides service-oriented architects an open, comprehensive methodology for designing and building cross-organizational IT infrastructures, which allow for the integration into other such platforms built following the same general design rules.
10
Foundations of the Architecture Framework In this first section, we give an overview over the main elements of the proposed architecture. We follow and augment the initial design rules for the eGovernment architecture proposed by the ISB20. The interaction module (IM)21, its constituents and design represent the central building block of our proposed architecture framework. An IM encompasses a set of agents that mutually interact via a shared medium. Media are thereby defined as follows22: They are enablers of interaction, i.e. they allow for exchange, particularly the communicative exchange between agents, by not only providing the physical means, but also a common understanding of the objects involved, as well as a common social world, i.e. a common organization. With other words: Media provide a set of agents a common physical space, a common logical, or interpretative23 space, and a common social, or institutional24 space. In this way, media transform an unconnected set of agents into a community of agents. In the computer science context, one may prefer the term Multi Agent System (MAS). Thus, an IM can also be referred to as MAS, with an explicitly designed medium for interaction. Each medium requires a physical component that enables the technical interconnection between the agents. Our architecture framework follows the two widely acknowledged, complementary styles of Service-oriented Architecture (SOA)25 and Event-Driven Architecture (EDA)26. Figure 5 illustrates the basic Informatikstrategieorgang Bund (ISB) (Müller, 2007) The term IM has already been briefly introduced above. 22 (Lechner & Schmid, 2000; Schmid, 1997; Schmid & Lechner, 2000; Schmid, Lechner, Klose, & Schubert, 1999) 23 Quelle aus (interpretativer) Soziologie 24 Quelle aus Sozialwissenschaften zum Begriff der Institution. 25 (Alonso, Casati, Kuno, & Machiraju, 2004; Krafcik, Banke, & Slama, 2006) 26 (Chandy, 2007) 20 21
11
notion of an Event-Driven Architecture (EDA) and its core building block, the event bus (often also referred to as Enterprise Service Bus). The gray arrow in the middle of this figure symbolizes this event bus component which builds a homogeneous integration layer for the interaction of services. The details of such a bus will be explained more thoroughly below.
Figure 5: Event-driven Architecture (EDA)27
The notion of event buses can easily be transferred back to our model of a basic SOA. As shown in Figure 6, an event bus can be employed as physical component enabling the technical interaction among agents. The agents and the services they expose are illustrated as small rectangles in this case which are connected to a bus medium.
27
(IBM, 2004)
12
Organization WS-Interf.
WS-Interf.
Information Object
Language
---------
Services & Infrastructure Figure 6: Basic SOA with an event bus as physical component
Based on this three-level model of a SOA, the following paragraphs will introduce a novel model of interaction modules (IMs) and its key constituents. As shown in Figure 7, agents (symbolized as rectangles) are connected to a medium (symbolized as large rectangle). The medium and the connected agents together represent an IM. In the centre of the medium, the above explained event bus allows for the physical interconnection between the agents (the C-component) 28. It ensures a reliable and secure message transfer and provides services related to routing, encryption, decryption, and many more. As will be explained in the following chapter of this document, we thereby rely on and augment the promising Event Bus Switzerland specification.29
As briefly introduced above, the medium of an interaction module consists of: an O-component that represents the organizational aspects; an L-component that defines the language to use; a Ccomponent for the physical data exchange 29 (Müller, 2007) 28
13
Interaction Module
Agent
Agent
Medium
O-Component Structural and processoriented organization
L-Component ---------
---------
C-Component: Bus Medium
---------
---------
Agent
---------
Information Object
Adapter
---------
Common „language“ (semantics and syntax)
Agent
Agent/ Interaction Module
Figure 7: Interaction module and its three constituents C-, L-, and O-component
As representatives of the second (“language”) and the third (“organizational”) level in Figure 6, two database symbols are introduced in Figure 7. The information objects belonging to the L-component of the medium are represented as data in the physical world (layer one in Figure 6). The related syntactical and semantic information as well as logical rules are made available in the database for the L-component (see the red database symbol on the right side in Figure 7) Similarly, the agents are bound to explicitly defined role descriptions as illustrated on the third level in Figure 6. This information is again made explicit through a database representing the O-Component of the medium (see the blue database symbol on the left side of Figure 7). 30
Tasks are defined as operations related to specific information objects (illustrated by document symbols in Figure 7).
30
14
Agent
L-Component O-Component C-Component Event Bus Figure 8: Adapters represent the organizational, semantic, and technical interface
Adapters (see Figure 8) represent one more central building block required for the design of an interaction module: They play a crucial role for the seamless interconnection between agents and the (event bus-based) medium as they fulfil three major functions (see Figure 9): First, they are of utmost importance to make all the information explicit that agents need to connect themselves to an event bus that implements a certain organization, defines a commonly acknowledged language and relies on a set of technical standards. As opposed to existing approaches, we thus foresee an adapter that covers all three components of a medium: Adapters connect agents physically to the bus infrastructure of a given medium. Adapters make the information collected in the L-component database explicit. This information comprises syntactical information such as formats, and semantic information, as well as logical rules. On an organizational level, adapters make role descriptions (e.g. service provider, service consumer) explicit to agents connecting to the respective medium.
15
Summing up, the first important function of adapters is to provide unambiguous interfaces between media and agents, covering the C-, the L-, and the Ocomponent.
Make relevant design information explicit
Translate between different designs
Enable information hiding
• Connect agents physically to the bus infrastructure • Syntactical information such as formats, and semantic information, as well as logical rules • Role descriptions (concerning structural and process-oriented organization)
• Seamless mediation between different design rules, concerning the C-, the L-, and the O-component • Mediation only possible if all relevant information has been made explicit (see first adapter function as described above) • Adapters specify what is published and thus visible to the outside and what not • One interaction module may hide internal details and act as single agent within another IAM (recursivity) • The principle of information hiding allows for complexity reduction and increases agility
Figure 9: Adapters make design information explicit, translate between designs, and enable information hiding
Besides mere interface functionality, adapters assume a second important role: In case an agent implements design rules which are different from those employed in the medium, the adapters needs to mediate/translate between the two. In such cases, adapters allow for the seamless mediation between different transmission protocols, information object formats and types, as well as organisational standards. As opposed to most existing adapter concepts which focus on the mere mediation between different data formats or technical transmission protocols, the adapter modules proposed here cover all three layers, the organizational31, the semantic 32, and the infrastructural33 levels. On the topmost level, adapters are required to mediate between different structural and process-oriented organizations. Existing standards such as Universal Description Discovery and Integration (UDDI, agent and service registry), the UN/CEFACT Modeling Methodology (UMM), the Business Process Execution Language (BPEL) or the Business Process Modeling Notation (BPMN) represent only a small selection of standards that may be employed by agents for the design of their interaction and which may require adaptation. 32 On the second (the semantic) level, a vast amount of highly heterogeneous standards exist. The Web Ontology Language (OWL), the UN/CEFACT Core Component Technical Specification (CCTS, meta-model for specifying semantics of information objects), as well as vertical industry standards such as RosettaNet Business Document, ACORD, CIDX, HL7, Papinet, PIDX, and SWIFT induce the need for adaptation. 31
16
Interaction Module
Agent
Agent
Medium
OComponent
CComponent
Agent
---------
-----------------
---------
---------
LComponent
Agent Interaction Module Medium
Information Object
Adapter
Agent/ Interaction Module
Figure 10: Recursive system of IMs, interconnected through adapters
Apart from interfacing and mediating functionality, adapters also allow for information hiding; they specify what is published and visible to the outside and what not. Figure 10 illustrates this third important feature: Four agents are first of all connected to a certain medium (the medium symbolized through a large arrow). According to the previously explained characteristics, the adapters On the infrastructural level, numerous different standards exist as well: the Web Service Description Language (WSDL), SOAP Service Description Language (SSDL), Really Simple Syndication (RSS) as well as meta-standards such as Web Services Interoperability (WS-I), the Hybrid OWL-S Web Service Matchmaker (OWLS-MX, for organizing service discovery artifacts), as well as protocol HTTP, Java Messaging Service (JMS), architectural styles such as the Representational State Transfer REST, as well as standards for technical message formats such as Simple Object Access Protocol (SOAP) or ebXML Message Service (ebMS) 33
17
now ensure a proper physical connection to the bus medium, as well as security and other attributes related to mere connectivity. They also guarantee correct interpretation of data according to syntactical and semantic rules governing the information objects. Finally, the adapters ensure that agents act in accordance with the specified roles they have to play.
Interaction Module A
Adaptation
Organization
Interaction Module B
Organization WS-Interf.
WS-Interf.
WS-Interf. Information Object
Language
Object Language
--------Services & Infrastructure
WS-Interf. Information
--------Services & Infrastructure
Figure 11: Adapter components required to mediate between different interaction modules
The fourth agent connected to the lower right side of the bus medium (Figure 10) can internally again be organized as further interaction module, featuring a medium that connects a set of agents. With the help of the adapter, the interaction module on the lower right side of the figure can hide internal details concerning the physical infrastructure (C-component), the common language (Lcomponent), and the organization (O-Component) and act as single agent within the super-ordinate interaction module. Figure 10 visualizes this bridging function of adapters, which allows for recursivity of our architecture, and allows IMs to act as well-defined agent in other IMs, hiding the internal structure as a MAS. Figure 11 illustrates the adapter concept based on the three-layered notion for the Service oriented architectures (compare Figure 1).
18
The goal of this strategy paper is to propose a novel architecture framework34 that incorporates the aforementioned basic design principles and provides architects in Switzerland a common foundation for organizing and implementing IT service infrastructures for cross-organizational electronic interoperation.
34
(Greunz, 2003; Schroth & Schmid, 2008; TheOpenGroup, 2007; TOGAF, 2008)
19
Physical Component The architecture framework does not only regard IT service infrastructures for cross-organizational electronic interaction from a merely organizational, but also from a technical viewpoint. The two complementary architectural styles of Service-Oriented Architectures (SOAs)35 and Event-Driven Architectures (EDAs)36 shall thereby act as general underpinnings. As discussed above, the employment of a SOA on the basis of the Web services stack already represents a promising approach to the implementation
of
cross-organizational
electronic
business
relationships.
However, Web services alone are not sufficient to ensure a truly loose coupling: Despite of an encapsulation of application logic with standardized (e.g., WSDLbased) interfaces, an IT service infrastructure may remain complex and hardly manageable. In fact, in addition to the standardized services, an event bus is required which forms a unified platform for connecting service consumers and service providers. It aims to avoid the proliferation of numerous point-to-point connections with proprietary application interfaces at both ends. In other words, an event bus shall shield the complexity of service interconnections by providing a homogeneous integration layer. An EDA (with the event bus at its core) allows for numerous different communication patterns between distributed entities such as one-way notification, request/response, notification/confirmation and others on the basis of events rather than prescribing users to adhere to only the request/response pattern as in the case of a traditional SOA. Stakeholders connected to a message bus may create and disseminate events (technically represented as messages of (Alonso et al., 2004; Arsanjani, 2004; Bieberstein, Bose, Walker, & Lynch, 2005; Krafcik et al., 2006; Sanz, Nayak, & Becker, 2006; Zimmermann, 2004) 36 (Chandy, 2007) 35
20
pre-defined formats) as well as react on received events by triggering internal actions and responding with an adequate answer message. The address register (implemented as a separate module) encapsulates the addressing schemes and acts as basis for the routing of messages from one service to the other over the bus. The following figure (Figure 12) depicts this situation and illustrates the integrating role an event bus plays.
Figure 12: Event-driven Architecture (EDA)37
The central benefits resulting from the employment of such a bus medium are38: To provide means for reducing the number of interfaces between the different connected systems to enable a higher flexibility and easier management of them. To enable enterprises and organizational networks to separate information processing and transmission between the stakeholders from the execution of the business logic inherent to the connected applications.
37 38
(IBM, 2004) (Schroth & Janner, 2008a, 2008b)
21
To enable a fast and simplified integration of new services/ applications. Via an adapter concept which can be regarded as the single interface to an event-bus environment, new systems only have to implement and connect to the adapter interface enabling them to communicate directly to other connected systems. They do not have to care about other systems’ specific characteristics (e.g. regarding technical protocols, physical addresses, etc.).
Figure 13: The Event Bus Schweiz39
The technical layer of our architecture framework generally relies on the concept of Event-Driven Architectures as described above. In specific, it builds on and extends the Event-Bus Schweiz (EBS) (see Figure 13) specification40. The EBS standard establishes a set of design guidelines for building a federated system of numerous event buses (referred to as EBS sub-buses; “Teilbus” in German) which support interoperability across their boundaries. In other words, the standard first of all allows a particular business community to design and build a 39 40
(Müller, 2007) (Müller, 2007)
22
dedicated event bus which builds the integration layer for interconnecting their respective application interfaces (the yellow-coloured sub-busses in Figure 13). The EBS standard goes beyond this conventional characteristic: provided that different business communities comply with the minimal EBS standard (which encompasses specifications for message formats and service interfaces) when building their sub-buses, messages can also be exchanged across the borders of these buses. In the exemplary scenario depicted in Figure 13, an agent connected to a cantonal bus (“Kantone” level in Figure 13) may seamlessly interact with an agent connected to a bus installed at the federal level. Summing up: while the EBS standard allows for building event buses incorporating heterogeneous and individual
requirements,
it
also
ensures
cross-bus
interoperability
by
establishing a set of publicly known design guidelines that all event buses need to comply with. In short, the physical component of the architecture framework proposed in this paper relies on and extends the Event Bus Switzerland specification. For each of the interaction modules constituting a given interaction scenario, a sub-bus is foreseen that implements the structural and process-oriented organization of interaction and also ensures that exchanged messages comply with a commonly agreed standard. Each of those sub-buses therefore provides a set of defined services (also see Figure 14) which support all four phases of the above described MRM:41 For the support of the information phase, services need to exist which allow agents to obtain comprehensive knowledge about the organizational as well as technical conventions established within the respective interaction module. During the signalling phase, services are required that enable agents to signal each other the respective intentions with respect to their later interaction. These services are, as argued above, based on the EBS specification but extend it as explained in the following 41
23
Negotiation services support a stepwise specification of the exact conditions, i.e., the rules governing the interaction. Finally, a further set of services are important to monitor and control the actual execution of interaction.
Coordination Services Semantic Services OperationalServices
C-Component: Bus Medium
Figure 14: Physical component of the architecture framework, based on the EBS standard42
The HERA project43, for example, provides an exemplary implementation of all these services in order to support the full lifecycle of cross-company interaction in the field of corporate tax declaration processing.44 An Identity & Access Management (IAM) service allows agents to authenticate themselves and inform themselves regarding the rights and obligations associated with roles they are authorized to assume. With the help of a comprehensive modelling service (which follows the notion of model-driven development), agents may signal intentions to each other and finally negotiate the actual contractual agreements with respect to their later interaction. Regarding the services supporting the execution phase, we propose the use and extension of the services defined by the “Event-Bus Schweiz (EBS)” standard. Again, a number of publications address possible extensions of these services (Müller, 2007) (HERA, 2008) 44 (Collm et al., 2008; Schroth, 2008b, 2008c; Schroth & Janner, 2008a, 2008b) 42 43
24
and shows their application in diverse case studies.45 The most relevant services (Coordination Services, Semantic Services, and Operational Services) are briefly described in the following: Coordination Services o Contract Structure Service: This service implements the structural organization within each bus medium: It specifies the agents connected to the bus, their roles, and the tasks they are authorized to perform within their respective IM o Task Structure Service: This service implements the process-oriented organization established within the respective IM. For each of the allowed tasks, it documents precedence relationships to other tasks. Rather than following an explicit, rigid process modelling approach, we propose a more declarative, flexible design that relies on the definition of pre-and post-conditions for the execution of the tasks. Semantic Services: We foresee the deployment of an Object Catalogue Service which specifies all the information object schemata which may be exchanged via the bus medium. It basically represents an amended version of the EBS-based Event Catalogue Service. Operational Services: These correspond to the services defined by the Event-Bus Schweiz specification. Services for security, exception handling, error handling, operational purposes, and for routing belong to this category which merely ensure the safe and reliable message transport.
(Collm et al., 2008; HERA, 2008; Schmid & Schroth, 2008; Schmid, Schroth, & Janner, 2007; Schroth, 2008b, 2008c; Schroth & Janner, 2008a, 2008b; Schroth & Schmid, 2008, 2009) 45
25
Logical Component The above discussed organizational as well as the physical components are of paramount
importance
for
the
design
and
implementation
of
cross-
organizational electronic interaction. However, the mere reliance on an agile infrastructure and a modular concept for its organization alone are not sufficient for a comprehensive architecture framework: With the help of Web services, for example, particularities of heterogeneous applications can be encapsulated and made publicly available as uniform interfaces, thereby eliminating the need for huge application integration efforts.46 One challenge of cross-organizational interoperability that has still to be addressed, however, is that of semantic integration.
Figure 15: Proprietary data standards47, often deteriorating cross-organizational interoperability
46 47
(Schroth, Janner, & Stuhec, 2007b) Graphic taken from a presentation of Gunther Stuhec, SAP AG
26
Philip Merrick, former chairman and CEO of webMethods, has described this issue in the following way48: ”...there’s a whole other layer to deal with, what I call the semantic integration problem. Web services are great but they standardize pure connectivity between applications. The applications still have highly varied data models, extremely different ideas of what business processes should look like”. According to Roger Sippl, co-founder and chairman of Above All Software49, the establishment of a common understanding of business semantics is one of the major ”silo walls” that need to be taken down on the way to true enterprise application interoperability. Today, a plethora of different, mostly domain-specific standards for the modelling and physical representation of business information exist (see Figure 15):
RosettaNet
Business
Document
(electronic
components,
and
telecommunications industry), ACORD (insurance industry), CIDX (chemical industry), HL7 (healthcare industry), Papinet (paper and forest industry), PIDX (oil and gas industry), SWIFT (financial industry), or the Swiss standard for exchanging geo-data (INTERLIS)50 represent only a small selection of these.51 For this reason, our architecture framework foresees a modular, core-componentbased modelling approach which relies on existing standards such as the OASIS Universal Business Language (UBL)52, the UN/CEFACT Core Component Technical Specification (CCTS) 53, and, on a technical level, the W3C XML schema54. Figure 16 illustrates the basic principles underlying the approach: Based on libraries comprising modular semantic building blocks, business
(Wainewright, 2003) (Sippl, 2006) 50 http://www.interlis.ch/ 51 (Schroth, Janner, & Stuhec, 2007a) 52 (OASIS, 2006) 53 (UN/CEFACT, 2003, 2006a) 54 (W3C, 2004a, 2004b, 2004c) 48 49
27
documents can be flexibly assembled for the exchange between agents. The business documents can be seen as information objects as described above. The following paragraphs provide more detailed explanation of the most central concepts:
Structural and Process-Oriented Organization Core Component Library WS-Interf.
WS-Interf.
CCTS based business documents
CCTS Compliant, Modular Business Data MSG2 SOA System A SOA System C
MSG1
SOA System B
SOA Infrastructure
Figure 16: Modular business information modelling55
As illustrated in Figure 17, four abstract entities constitute the nucleus of the information object modelling approach: First, generic core components need to be defined which act as reusable, modular building blocks for the assembly of whole generic business documents. These generic (context-neutral) document descriptions encapsulate the organization of overall documents (e.g., order, invoice) shared by one or more instantiations which are referred to as specific business documents. Specific business documents, in turn, are constituted of specific core components, i.e. the context-specific instantiations of their generic counterparts, the generic core components.56 The mechanism by which specific
55 56
(Schroth, Janner, & Stuhec, 2007b) (Schroth, Pemptroad et al., 2007)
28
documents and core components are derived corresponds to the mechanism of “restriction inheritance”57. Only those information object constituents are selected that are relevant in a given context. As mentioned above, the approach builds upon and extends the UN/CEFACT CCTS standard which foresees each information object to be composed of a set of building blocks, which are- in their most generic form- referred to as core components.
Generic Business Document
Restriction Inheritance
Is part of Generic Core Component
Specific Business Document
Is part of Restriction Inheritance
Specific Core Component
Figure 17: Information object modelling entities58
The following paragraphs elaborate on the detailed design of generic and specific business documents as well as their constituents (the core components): As illustrated on the right side of Figure 18, the most fundamental components are called Core Data Types (CDTs). The UN/CEFACT has established 21 of these CDTs (e.g., Amount, Binary Object, Code, Date, Date Time, Duration, Graphic, Identifier, etc.) which can be considered as atomic classifiers of pieces of information. The CDTs are used to define the allowed values for the Basic Core Components (BCCs), which represent basic information objects which cannot be split apart into different modules (e.g. ID Number or Street Name). Different BCCs can then be aggregated into an Aggregate Core Component (ACC), a super-ordinate module encapsulating its constituent core components. In order to allow for truly nested hierarchies of information modules, Association Core Components (ASCCs) exist which are composed of two ore more core 57 58
(Meyer, 1996) (Schroth, Pemptroad et al., 2007)
29
components and can be included into a super-ordinate ACC themselves (Figure 18). A comprehensive Purchase Order Document can be modelled as ACC consisting of a number of ASCCs and BCCs. An address field may be organized as ASCC module as it comprises a set of subordinate modules such as Street Name, Postal Codes, etc. The Purchase Order ID Number, on the other hand, represents a BCC as it cannot be decomposed further.
Specific
Generic
Purchase Order
ABIE Aggregated in
Aggregated in
ASBIE
Specifies restrictions on
ACC Aggregated in
Specifies restrictions on
Aggregated in
ASCC
ID Number
Address Specifies restrictions on
BBIE
BCC
Defines value for
Defines value for Business Data Type
Specifies restrictions on
Core Data Type Identifier
Figure 18: Generic and specific core components59
All the generic core component modelling entities are context-sensitive and can be translated into specific Business Information Entities (BIEs) as illustrated in Figure 18: As part of every core component module, a set of context parameter categories is defined. The underlying methodology has been developed (and is still subject to amendments) as the Unified Context Methodology (UCM)60. Parameter categories such as country or concerned industry as well as related values can be specified for each core component. Within the context-agnostic generic realm all core components (independent of their hierarchy level)
59 60
(Schroth, Pemptroad et al., 2007) (UN/CEFACT, 2008)
30
comprise the full set of subordinate components. When “contextualizing” them, restrictions are imposed on each of them: The generic address core component, for example, features a wide set of subordinate components such as diverse kinds of street identifiers, postal codes, names and others. Depending on the country of a user, the component (which can be considered as generic template) can be restricted to those components which are specifically relevant in this country’s context. Figure 19 illustrates the full “lifecycle” of our modelling approach. Based on a graphical modelling environment, users may document the constituents of the information objects they desire to exchange. In a second step, these so far unstructured data models are transferred into formalized models which may draw on pre-existing core component libraries such as UBL.61 In case several context-specific instantiations of one document type exist, the specific, structured business document models are transferred into generic documents by building the superset and documenting the context annotations. 62 These steps can be repeated by the stakeholders of a specific business community until a comprehensive library of information object models has been completed (see the middle of Figure 19). For the actual usage of the information objects, stakeholders may select generic documents from the library, apply the contextualization mechanism and translate the so far technology-agnostic models into a technical representation63 which can be used during run-time. This component-based information object modelling approach64 is new as it spans the bridge between unstructured modelling of data and core-component(OASIS, 2006) Context-specific invoice documents, for example, can be aggregated into one generic superset model. The aggregation of context-specific information objects into context-neutral generic business documents facilitates the establishment of a library of consolidated data models. 63 (Janner et al., 2008; Schroth, Janner, & Stuhec, 2007a, 2007b; Schroth, Pemptroad et al., 2007) 64 (Christ, Schroth, & Janner, 2007; Frenzel, Schroth, & Samsonowa, 2007; Gionis, Charalabidis et al., 2007; Janner, Lampathaki, Mouzakitis, Schroth, & Scheper, 2006; Janner, Schmidt et al., 2006; Mouzakitis, Lampathaki, Schroth, Scheper, & Janner, 2007; Schmid et al., 2007; Schroth et al., 61 62
31
based, formal representations and also because it integrates contextual information in order to allow for deriving tailor-made business information documents from generic information objects.
Library Usage
Information Object Library
Library Building/ Modelling
Selection of Generic Business Document
Unstructured Business Documents
Specific Structured Business Documents (may be based on libraries, e.g. UBL Common Library)
Context-specific restrictions
Generic Business Documents and their Generic Core Components (relational meta-description) including contextual annotations
Generic Structured Business Documents
Generation of XML Schema Business Documents
Figure 19: Library building and usage lifecycle
The approach has been published in a number of conference proceedings and journal articles; it ranges from (tool-supported65) graphical data models to the technical representation of the business documents such as XML schema documents designed in compliance with the UN/CEFACT66 XML schema Naming and Design Rules (NDR)67. The proposed approach incorporates the principle of modularity as it builds upon a number of semantic building blocks which can be assembled to whole business documents according to a clearly specified
methodology.
It
facilitates
cross-organizational
interoperability
(through homogeneously defined data components) while leaving significant design freedom to all involved stakeholders: Based on standardized document
2006; Schroth, Janner, Stage, & Mayer, 2007; Schroth, Janner, & Stuhec, 2007b; Schroth, Pemptroad et al., 2007) 65 (Schroth, Pemptroad et al., 2007) 66 United Nations Centre for Trade Facilitation and Electronic Commerce 67 (UN/CEFACT, 2006b)
32
templates68, context-specific derivatives can be created which fulfil heterogeneous requirements. For a detailed specification of the methodology and its benefits, please refer to the related publications69. While the above-mentioned modelling approach is the way to go, there are a number of real- life problems that require further investigations: Semantic and syntactical definitions in a cross- organizational context are often defines as part of a hard and time-consuming process of negotiation. Real implementation projects may not have the time to wait for the results. As a consequence, we will be confronted with a set of conflicting definitions. A component-based approach may lead to plenty of interdependencies. A change in a base specification may introduce changes in a number of depending object definitions, interface definitions and software modules. We therefore need concepts, tools and processes to allow for incremental definition, effective cross-organizational release management and handling of conflicting definitions. The SEAC shall address parts of these challenges in order to allow for flexible, crossorganizational electronic interaction.
The UBL Common Library and the Business Document Library, for example, provide a huge number of pre-determined business document models. 69 (Gionis, Charalabidis et al., 2007; Gionis, Mouzakitis et al., 2007; Janner et al., 2008; Janner, Lampathaki et al., 2006; Janner, Schmidt et al., 2006; Lampathaki et al., 2008; Mouzakitis et al., 2007; Schroth, Janner, & Stuhec, 2007a, 2007b; Schroth, Pemptroad et al., 2007) 68
33
Organizational Component Based on the fundamental notion of media and agents, this section elaborates on the organizational viewpoint of the aforementioned modular architecture framework. Figure 20 illustrates a modular, exemplary scenario comprising a set of agents, media, and IMs which shall help to explain the most fundamental organizational concepts.
Interaction Module
Agent
Agent
Medium
OComponent
LComponent
CComponent
Agent
Agent Interaction Module Medium
Information Object
Adapter
Agent/ Interaction Module
Figure 20: Modular, recursive system of interaction modules
34
Fist of all, as already introduced above, interaction modules (IMs) form the fundamental unit of our framework. Interaction scenarios between a number of agents are often rather complex as diverse research projects have shown.70 In order to reduce the complexity, to allow for a decentralized management, and to ensure later flexibility, interaction scenarios have to be split apart (decomposed) into mutually independent, yet interoperable modules71. In the course of his dissertation, Christoph Schroth has developed a method for the systematic definition and decoupling of such interaction modules on the basis of arbitrary, given interaction scenarios. As shown in Figure 20, one central characteristic of the proposed organizational modelling approach is its recursivity: Each agent can internally be organized as further IM, encompassing a further medium and agents. The internal organization may be fully or partly hidden from the outside world, i.e. from the super-ordinate modules. Each IM comprises a medium (symbolized by a rectangle encircling an arrow and two cylinders) and a number of agents (symbolized by rectangles).
Interaction Scenario is part of
Interaction Module is part of
Interaction Pattern is part of
Task
Figure 21: Tasks, IAPs, IMs, and interaction scenarios
70 71
(HERA, 2008; HSG, 2008) (Collm et al., 2008; Schroth, 2008b, 2008c; Schroth & Janner, 2008a, 2008b)
35
Within each of these modules, the interaction is specified based on fine-granular tasks which are assembled into interaction patterns (IAPs). A number of publications elaborate on a detailed modelling methodology for the specification of tasks, IAPs, and IMs.72 The discussed modelling entities are governed by the following relationships: Tasks are assembled as parts of one-way or two-way interaction patterns (IAPs). IAPs represent the fundamental unit for modelling behavioural aspects of interaction and are executed within clearly defined spheres, the interaction modules. IMs, in turn, constitute an overall interaction scenario. Figure 2273 illustrates the central modelling entities for specifying an IAP: In the case of a one-way IAP, a sending role sends an information object to a receiving role. In case of a two-way IAP, a requesting role sends an information object to a responding role which acts upon the reception of the object and sends a defined information object back.
Interaction Pattern Requesting/ Sending Role
Task
Responding/ Receiving Role
Information Object
Success Failure
Information Object
Task
Figure 22: Interaction Pattern
(Collm et al., 2008; Schmid & Schroth, 2008; Schroth, 2008b, 2008c, 2008e, 2008f; Schroth & Janner, 2008a, 2008b; Schroth, Miche, & Bohnert, 2009; Schroth & Schmid, 2008, 2009) 73 Adapted from the UMM Business Transaction View 72
36
The employment of modular interaction patterns represents a paradigmatic move away from creating interconnected designs and modelling tightly integrated flows of interdependent tasks, related messages, performance parameters and constraints. With the help of interaction patterns, the structural and process-oriented organization within a scenario can be decomposed (split) into its constituent building blocks: Patterns are defined of which each addresses an atomic piece of interaction between agents (either one-way or two-way). They contain information about who is in a position to use them (organizational constraints) as well as at which point of time (relying on information about preceding patterns) they may be triggered. Details about the involved information objects as well as performance parameters for further specifying the actual interaction are part of these modules’ hidden information (encapsulated) and are thus not visible to other interaction patterns. Second, all these detailed specifications within each of the modules are again split into sub-modules to increase organizational flexibility. The information objects, for example, are modelled as separate modules in order to allow for reuse as well as individual adaptability. In this way, a certain information object may be used by different agents as part of diverse interaction patterns. Design Rules for Decoupling: Interaction modules should be as loosely coupled as possible. In this context, the degree of coupling refers to the number of mutual interdependencies of design information. If, for example, tasks conducted by agents in module A do not require any input from tasks performed by agents in module B (and vice versa), the two modules are fully decoupled. In many cases, however, a full decoupling is neither possible nor desirable.
37
In general,
interdependencies between different
modules
need
to
be
incorporated in the form of design rules74. Design rules can be considered as “privileged” design information which is visible to two or more modules and allows them to interact seamlessly. Design rules specify the structural organization, the process-oriented organization governing the interaction of the modules as well as the information objects exchanged between them75. The publications cited above also treat the aspect of design rules and their role in the context of our architecture framework. The coordination of interaction modules within an interaction scenario can also be described via explicit business processes. Particular advantages of such an approach are as following: explicit business processes are more understandable for the business staff (which is very important because we are going to build a social-technical system) explicit business processes are a good base for error handling (e.g. via explicit transaction boundaries) explicit business processes allow predicting the execution time of a particular process instance thus enabling SLA explicit business processes are a key part of the Switzerland’s eGovernment strategy76 Modern BPM methods, technologies and methodologies77 allow process-oriented solutions to easily evolve – services and processes can be quickly adapted for new needs and properly re-assembled.
(Armstrong, 2006; Baldwin & Clark, 1997, 2000; Parnas, 1972; Schilling, 2000) (Schroth, 2008a) 76 Switzerland’s eGovernment strategy www.isb.admin.ch 77 An overview can be found in “Improving enterprise BPM systems”, www.improving-BPMsystems.com 74 75
38
Conclusion The basic architectural principles discussed above will allow improving mainly four performance indicators: Management of complexity: Through the clear separation of collaboration scenarios into mutually independent, yet interoperable interaction modules, complexity can be reduced significantly. Structural and process-oriented organization of agent interaction can be modelled autonomously for each module and can then be implemented through the orchestration of services without affecting other modules. Parallelization/ decentralized design evolution: The establishment of design rules which ensure interoperability between different interaction modules but leave considerable design freedom to module owners facilitates a Swiss-wide, decentralized design evolution. Groups of business partners are thus in a position to model and build tailor-made electronic media which are still interoperable with other, already existing platforms. Consideration of defined zones of responsibility and visibility: The systematic splitting apart of scenarios into interaction modules simplifies the consideration of legally prescribed as well as economically motivated spheres of responsibility and visibility. Accommodation of uncertainty: The consistently modular design allows for an unprecedented degree of agility: Modules can be added, excluded, split apart, substituted, inverted (made visible and usable to a larger number of other modules) and ported (made accessible to a system which follows a different set of design rules with the help of adapter modules) without requiring large redesign efforts in other modules.
39
References Alonso, G., Casati, F., Kuno, H., & Machiraju, V. (2004). Web Services Concepts, Architectures and Applications. Berlin, Germany: Springer. Armstrong, D. J. (2006). The Quarks of Object-Oriented Development. Communications of the ACM, 49(2), 123-128. Arsanjani, A. (2004). Service-oriented modeling and architecture. from http://www128.ibm.com/developerworks.com/webservices/library/ws-soa-design1/ Baldwin, C. Y., & Clark, K. B. (1997). Managing in an age of modularity. Harvard Business Review, 75(5), 84-93. Baldwin, C. Y., & Clark, K. B. (2000). Design Rules. Vol. 1: The Power of Modularity. Cambridge, MA, USA: The MIT Press. Bieberstein, N., Bose, S., Walker, L., & Lynch, A. (2005). Impact of service-oriented architectures on enterprise systems, organizational structures, and individuals. IBM Systems Journal, 44, 691-708. Buxmann, P., Diefenbach, H., & Hess, T. (2008). Die Software-Industrie. Ökonomische Prinzipien, Strategien, Perspektiven. Berlin, Germany: Springer. Chandy, K. M. (2007). Event-Driven Applications: Costs, Benefits and Design Approaches. Christ, O., Schroth, C., & Janner, T. (2007). A Hybrid Framework for Automated and Adapative eBusiness Platforms. Paper presented at the The 15th European Conference on Information Systems (ECIS 2007), St. Gallen, Switzerland. Collm, A., Hristova, R., Janner, T., Reimer, U., Ritsch, R., & Schroth, C. (2008). HERA: A Serviceoriented Approach to Cross-organisational E-Government Processes. eGov Präsenz, 1. EFD. (2008). Schweizerische Eidgenossenschaft. Informatikstrategieorgan Bund ISB. from http://www.isb.admin.ch/ Frenzel, P., Schroth, C., & Samsonowa, T. (2007). The Enterprise Interoperability Center– An Institutional Framework Facilitating Enterprise Interoperability. Paper presented at the 15th European Conference on Information Systems (ECIS 2007), St. Gallen, Switzerland. Gionis, G., Charalabidis, Y., Janner, T., Schroth, C., Koussouris, S., & Askounis, D. (2007). Enabling Cross-Organizational Interoperability: A Hybrid e-Business Architecture. In J. M. R. J. Gonçalves, K. Mertins, M. Zelm (Ed.), Enterprise Interoperability II. New Challenges and Approaches. London: Springer. Gionis, G., Mouzakitis, S., Janner, T., Schroth, C., Koussouris, S., & Askounis, D. (2007). Implementing Next Generation e-Business Platforms for Heterogeneous SME Environments. Paper presented at the 11th Panhellenic Conference on Informatics (PCI 2007), Patras, Greece. Grau, C., Wolf, C. M., Kramer, F., & Hess, T. (2007). Modularisierung in der Medienproduktion: Drei Fallbeispiele im Vergleich. Munich, Germany: Ludwig-Maximilians-Unversität (LMU). Greunz, M. (2003). An Architecture Framework for Service-Oriented Business Media. Unpublished Ph.D. Thesis, University of St. Gallen, St. Gallen, Switzerland. HERA. (2008). HERA: Helvetic E-Government Reference Architecture. from http://www.heraproject.ch HSG. (2008). Service-orientierte Architekturen im e-Government der Schweiz. from http://www.alexandria.unisg.ch/Projekte/Person/S/Christoph_Schroth/43040 IBM. (2004). Patterns: Implementing an SOA Using an Enterprise Service Bus: IBM.
40
Janner, T., Lampathaki, F., Hoyer, V., Mouzakitis, S., Charalabidis, Y., & Schroth, C. (2008). A Core Component-based Modelling Approach for Achieving e-Business Semantics Interoperability. Journal of Theoretical and Applied Electronic Commerce Research (JTAER). Janner, T., Lampathaki, F., Mouzakitis, S., Schroth, C., & Scheper, U. (2006). Interoperability Enhancement in Business to Government: Extending the Scope of UBL. Paper presented at the 6th International Conference on Practical Aspects of Knowledge Management PAKM 2006, Workshop: Enterprise Software Application Interoperability for Businesses and Governments, Vienna, Austria. Janner, T., Schmidt, A., Schroth, C., & Stuhec, G. (2006). From EDI to UN/CEFACT: An Evolutionary Path Towards a Next Generation e-Business Framework. Paper presented at the The 5th International Conference on e-Business 2006 (NCEB 2006), Bangkok, Thailand. Krafcik, D., Banke, K., & Slama, D. (2006). Enterprise SOA. Service-Oriented Architecture Best Practices (Vol. Edition 5). Upper Saddle River, NJ, USA: Prentice Hall PTR. Lampathaki, F., Mouzakitis, S., Janner, T., Schroth, C., Askounis, D., & Hoyer, V. (2008). Achieving Cross-Country Electronic Documents Interoperability with the help of a CCTS-based Modelling Framework. The electronic Journal for E-Commerce Tools & Applications (eJETA), 2(3). Lechner, U., & Schmid, B. F. (2000). Communities and Media - Towards a Reconstruction of Communities on Media. Paper presented at the Hawaiian Int. Conf. on System Sciences (HICSS 2000), Hawaii, USA. Lheureux, B. J., Biscotti, F., Malinverno, P., White, A., & Kenney, L. F. (2007). Taxonomy and Definitons for the Multienterprise/B2B Infrastructure Market. USA. Lheureux, B. J., & Malinverno, P. (2006). Magic Quadrant for Integration Service Providers, 1Q06. USA. Lheureux, B. J., & Malinverno, P. (2007). Spider Diagram Ratings Highlight Strengths and Challenges of Vendors in the B2B Infrastructure Market. USA. MacKenzie, M. e. a. (2007). OASIS - Reference Model for Service Oriented Architecture 1.0: OASIS. Meyer, B. (1996). The many faces of inheritance: a taxonomy of taxonomy. Computer, 29(5), 105108. Mouzakitis, S., Lampathaki, F., Schroth, C., Scheper, U., & Janner, T. (2007). Towards a common repository for governmental data: A modelling framework and real world application. In R. J. Gonçalves, J. Müller, K. Mertins & M. Zelm (Eds.), Enterprise Interoperability II. New Challenges and Approaches London: Springer. Müller, W. (2007). Event Bus Schweiz. Konzept und Architektur, Version 1.5. Bern, Switzerland: Eidgenössiches Finanzdepartement (EFD), Informatikstrategieorgan Bund (ISB). OASIS. (2006). OASIS Universal Business Language (UBL): Organization for the Advancement of Structured Information Standards. Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12), 1035-1058. Picot, A., Dietl, H., & Franck, E. (2002). Organisation-Eine ökonomische Perspektive. Stuttgart, Germany: Schäffer-Pöschel. Picot, A., Reichwald, R., & Wigand, R. T. (2001). Die Grenzenlose Unternehmung: Information, Organisation und Management. Lehrbuch zur Unternehmensführung im Informationszeitalter, 4.vollst. überarb. u. erw. Aufl. Wiesbaden, Germany: Gabler Verlag. Sanz, J., Nayak, N., & Becker, V. (2006). Business Services as a Modeling Approach for Smart Business Networks. Yorktown Hights: IBM Research Division Almaden Research Center. Schilling, M. A. (2000). Towards a General Modular Systems Theory and Its Application to Interfirm Product Modularity. In R. Garud, A. Kumaraswamy & R. N. Langlois (Eds.),
41
Managing in the Modular Age: Architectures, Networks, and Organizations: New Perspectives on Architectures, Networks, and Organizations (pp. 172-203). USA: Blackwell Publ. Schmid-Isler, S. (2004). Konzepte von Beat F. Schmid. Ein Überblick 1997-2003. St. Gallen, Switzerland: Hochschule St. Gallen, Institut für Medienund Kommunikationsmanagement. Schmid, B. F. (1997). The Concept of Media. Paper presented at the Fourth Research Symposium on Electronic Markets: Negotiation and Settlement in Electronic markets, Rotterdam, The Netherlands. Schmid, B. F. (1999). Elektronische Märkte - Merkmale, Organisation und Potentiale. In M. Sauter & H. A. (Eds.), Handbuch Electronic Commerce (pp. 31-48): Franz Vahlen Verlag,. Schmid, B. F., & Lechner, U. (2000). Communities and Media. Paper presented at the 33rd Hawaiian International Conference on System Sciences (HICSS 2000). Schmid, B. F., Lechner, U., Klose, M., & Schubert, P. (1999). Ein Referenzmodell für Gemeinschaften und Medien. In M. Englien & J. Homann (Eds.), Virtuelle Organisation und neue Medien (pp. 125-150). Lohmar: Eul Verlag. Schmid, B. F., & Schroth, C. (2008). Organizing as Programming: A Reference Model for CrossOrganizational Collaboration. Paper presented at the 9th IBIMA Conference on Information Management in Modern Organizations, Marrakech, Morocco. Schmid, B. F., & Schroth, C. (2009). Internet der Dienste. In T. Schildhauer (Ed.), Tagungsband des E12 Gipfels "Internet of Services" (pp. 3). Berlin, Germany: Institute of Electronic Business e.V. . Schmid, B. F., Schroth, C., & Janner, T. (2007). A Hybrid Architecture for Highly Adaptive and Automated e-Business Platforms. Paper presented at the Proceedings of the 2007 IEEE International Conference on Services Computing (SCC 2007), Salt Lake City, Utah, USA. Schmid, B. F., Schroth, C., Miche, M., & Janner, T. (2009). Valuating Modular Architectures for Cross-Company Electronic Interaction. Communications of the IBIMA (CIBIMA) 13. Schroth, C. (2008a). Global industrialisation of information-intensive services: a reference architecture for electronic business media. Int. J. Product Lifecycle Management (IJPLM). Schroth, C. (2008b). HERA Architecture: Enabling Seamless Cross-Organizational Collaboration for Swiss Public Administration. Paper presented at the Internationales Rechtsinformatik Symposion 2008, Salzburg, Austria. Schroth, C. (2008c). HERA: Ein modularer Ansatz für organisationsübergreifende, elektronische Interaktion. Schroth, C. (2008d). Loosening the Hierarchy of Cross-Company Electronic Collaboration. In R. Kaschek, C. Kop, C. Steinberger & G. Fliedl (Eds.), Proceedings of the 2nd International United Information Systems Conference: Information Systems and e-Business Technologies (pp. 567-578). London: Springer. Schroth, C. (2008e). A Modular Reference Architecture Framework for Seamless CrossOrganizational Interoperation. In E. Schweighofer, A. Geist, G. Heindl & C. Szücs (Eds.), Komplexitätsgrenzen der Rechtsinformatik: Tagungsband des 11. Internationalen Rechtsinformatik Symposions IRIS 2008: Boorberg Schroth, C. (2008f). A Service-oriented Reference Architecture for Organizing Cross-Company Collaboration. In K. Mertins, R. Ruggaber, K. Popplewell & X. Xu (Eds.), Enterprise Interoperability III: New Challenges and Industrial Approaches (pp. 71-83). London: Springer. Schroth, C., Gionis, G., Charalabidis, Y., Janner, T., Koussouris, S., & Askounis, D. (2006). A Hybrid Architecture for Enabling Electronic Transactions Among Enterprises and Governmental Bodies. Paper presented at the 6th International Conference on Practical Aspects of
42
Knowledge Management PAKM 2006, Workshop: Enterprise Software Application Interoperability for Businesses and Governments, Vienna, Austria. Schroth, C., & Janner, T. (2007). Web 2.0 and SOA: Converging Concepts Enabling the Internet of Services. IEEE IT Professional, 9(3), 36-41. Schroth, C., & Janner, T. (2008a). HERA Deliverable D5.1: HERA Service-oriented Reference Architecture. St. Gallen, Switzerland: CTI Swiss Confederation’s innovation promotion agency (grant number 8617.1.). Schroth, C., & Janner, T. (2008b). HERA Deliverable D5.2: HERA Generic Services Adapter: CTI Swiss Confederation’s innovation promotion agency (grant number 8617.1.). Schroth, C., Janner, T., Stage, A., & Mayer, P. (2007). A Holistic Architecture for Collaborative and Highly Automatized e-Business Platforms. Paper presented at the SECOND INTERNATIONAL WORKSHOP ON SERVICES ENGINEERING, in conjunction with the The 23rd International Conference on Data Engineering (ICDE 2007), Istanbul, Turkey. Schroth, C., Janner, T., & Stuhec, G. (2007a). UN/CEFACT e-Business framework: Closing the semantic gap of Service-Oriented Architectures. 3rd International Conference on Interoperability for Enterprise Software and Applications (I-ESA 2007). Schroth, C., Janner, T., & Stuhec, G. (2007b). UN/CEFACT Service-Oriented Architecture: Enabling Both Semantic And Application Interoperability. Paper presented at the Symposium "Communication in Distributed Systems" (KiVS), Workshop: Service-Oriented Architectures und Service-Oriented Computing, Bern, Switzerland. Schroth, C., Miche, M., & Bohnert, T. M. (2009). Backend Service Extensions for Vehicular Communications: Use Cases, Analysis and Architecture (submitted). Paper presented at the IEEE International Conference on Communications, Dresden, Germany. Schroth, C., Pemptroad, G., & Janner, T. (2007). CCTS-based Business Information Modelling for Increasing Cross-Organizational Interoperability. In R. J. Gonçalves, J. Müller, K. Mertins & M. Zelm (Eds.), Enterprise Interoperability II. New Challenges and Approaches. London: Springer. Schroth, C., & Schmid, B. F. (2008). A Modular Reference Architecture Framework for Electronic Cross-Organizational Interoperation. In Proceedings of the Seventh international EGOV conference 2008 (EGOV 2008). London: Springer. Schroth, C., & Schmid, B. F. (2009). Reference Architecture for Cross-Company Electronic Collaboration. International Journal of e-Collaboration, 5(2), 75-91. Schroth, C., & Siebeck, R. (2009). Characteristics of cross-organizational electronic interaction and supporting IT service infrastructures : Technical Report. St. Gallen, Switzerland: MCM Institute. Sippl, R. (2006). Breaking down the Silo walls - Realizing the vision of SOA. 2008, from http://www.soahub.com/Architecture/breaking_down_silo_walls.aspx TheOpenGroup. (2007). The Open Group Architecture Framework Version 8.1.1 "Enterprise Edition". TOGAF. (2008). The Open Group. from http://www.opengroup.org/architecture/togaf8-doc/arch/ UN/CEFACT. (2003). UN/CEFACT Core Components Technical Specification, Part 8 of the ebXML Framework, Version 2.01: UN/CEFACT. UN/CEFACT. (2006a). UN/CEFACT Core Component Library (UN/CCL), version 1.0: UN/CEFACT. UN/CEFACT. (2006b). UN/CEFACT XML Naming and Design Rules, Version 2.0: UN/CEFACT. UN/CEFACT. (2008). Techniques and Methodologies Group. from http://www.unstandards.org:8080/display/public/Techniques+and+Methodologies+Grou p W3C. (2004a). ML schema Part 1: Structures (Second Edition): W3C.
43
W3C. (2004b). XML schema Part 0: Primer (Second Edition). W3C. (2004c). XML schema Part 2: Datatypes (Second Edition): W3C. Wainewright, P. (2003). Semantic integration. from http://www.looselycoupled.com White, A., Wilson, D., & Lheureux, B. J. (2007). The Emergence of the Multienterprise Business Process Platform. USA. Zimmermann, O. e. a. (2004). Elements of Service-Oriented Analysis and Design. from http://www.www-128.ibm.com/developerworks/library/wssoad1/
44
Appendix A: Design Rules for Swiss eGovernment and TOGAF The Open Group Architecture Framework (TOGAFTM) is a freely usable framework — a detailed method and a set of supporting tools — for developing an enterprise architecture. It is developed and maintained by members of The Open Group78. In the concepts of TOGAF the Design Rules for Swiss eGovernment define a high level foundation architecture for Swiss eGovernment on which more specific architectures can be built. As such it is a first coarsely grained reference model for the target architecture of the system eGovernment Switzerland.
Appendix B: The St. Gallen Media Reference Model In this section, a brief overview of the St. Gallen Media Reference Model (MRM) is provided. As shown in Figure 23, it provides a structuring framework for the design and analysis of electronic business media. It combines the three above mentioned
components
with
four
distinct,
fine-granular
architectural
viewpoints: The community viewpoint is devoted to the architectural aspects that concern the structural organization of agent interaction; the process viewpoint concerns the process-oriented organizational aspects. The services viewpoint deals with the services and their interfaces that are required for the implementation of the “ideas” modelled within the two organizational viewpoints. The infrastructure viewpoint finally focuses on the actual production system, i.e. the technical framework required for running the above mentioned services.
78
For detailed information see: http://www.opengroup.org/togaf/
45
Process Viewpoint
Process-oriented Organization
Service Viewpoint
Services/ Interfaces
Infrastructure Viewpoint
Channel/ Service Platform
L-Component
Structural Organization
C-Component
Community Viewpoint
O-Component
Layers
Phases
Inform
Signal
Negotiate
Execute
Figure 23: St. Gallen Media Reference Model79
In addition to the four viewpoints, four phases (see Figure 23) exist which shall be discussed in the following: The information phase allows agents who interact via a medium to build as well as to adapt their knowledge through the exchange of information. The signalization phase comprises the mutual notification about intentions, while the negotiation phase takes care of contracting activities. The execution phase is about settlement and the actual execution of the previously contracted activities80.
79 80
(Schmid et al., 1999; Schroth & Schmid, 2008) (Schmid-Isler, 2004; Schmid, 1999; Schmid et al., 1999; Schroth & Schmid, 2008, 2009)
46
