EFSOC Framework Overview and Infrastructure Services

(1)

EFSOC Framework Overview

and

Infrastructure Services

Infolab Technical Report Series

INFOLAB-TR-13

Kees Leune

(2)

4 Access Control Service 18 4.1 Operation Descriptions . . . 18 4.1.1 requestAuthorization Operation . . . 18 4.1.2 newRoleType Operation . . . 19 4.1.3 newSubject Operation . . . 19 4.1.4 newRoleAssignment Operation . . . 20 4.1.5 addAuthorizedEventMonitor Operation . . . 20 4.1.6 addAuthorizedEventGenerator Operation . . . 21 4.2 Event Types . . . 22 4.2.1 NewRoleTypeEvent . . . 22 4.2.2 NewSubjectEvent . . . 22 4.2.3 NewRoleAssignmentEvent . . . 23 4.2.4 RequestAuthorizationEvent . . . 24 4.2.5 AddAuthorizedEventMonitorEvent . . . 25 4.2.6 AddAuthorizedEventGeneratorEvent . . . 25

5 Business Process Service 27 5.1 Operation Descriptions . . . 27 5.1.1 addService Operation . . . 27 5.1.2 addBusinessProcess . . . 28 5.2 Event Types . . . 28 5.2.1 NewService Event . . . 28 5.2.2 NewBusinessProcess Event . . . 29

(3)

A WSDL specifications 31

A.1 Event Service . . . 31

A.2 Access Control Service . . . 32

B XML Schema definitions 34 B.1 Meta model definitions . . . 34

B.2 Event Service definitions . . . 35

B.3 Access Control Service Definitions . . . 35

B.4 Business Process Service Definitions . . . 36

C EBNF specifications 38 C.1 Business Process Definition . . . 38

D Screenshots 41 D.1 Business process definitions . . . 42

D.1.1 Process specification . . . 42

D.1.2 Role Assignment . . . 43

D.2 Service definition . . . 44

(4)

Chapter 1

Introduction

The EFSOC framework is an event-driven framework for service oriented computing. Using the framework, organizations will be able to conceptually model service invocations. Modeling service invocations enables an

organization to quickly determine what the impact on its business process will be when certain services are used, thus enabling the organization to rapidly respond to changing business practices.

In addition to conceptually describing business processes and service

invocations, the EFSOC framework offers support for run-time enactment of business process and service orchestration.

The framework is supported by a web-based specification tool1_.

In this document, we will present an overview of the framework and its metamodel, followed by specification of the infrastructure services. We will also relate out work to existing standardization and industry initiatives.

1.1 Notational Conventions

The keywords ”MUST”, ”MUST NOT”, ”REQUIRED”, ”SHALL”, ”SHALL NOT”, ”SHOULD”, ”SHOULD NOT”, ”RECOMMENDED”, ”MAY”, and ”OPTIONAL” in this document are to be interpreted as described in RFC 2119 [RFC 2119].

This document uses namespace prefixes througout; they are listed in table 1.1. Note that the choice of any namespace prefix is arbitrary and not semantically

(5)

Prefix Namespace Notes

wsdl http://www.w3.org/2003/06/wsdl WSDL 1.2 specification http http://www.w3.org/2003/06/wsdl/http HTTP bindings for

WSDL 1.2

xs http://www.w3.org/2001/XMLSchema XML Schema specifica-tion

bpws http://schemas.xmlsoap.org/ws/2003/03/business-process/ BPEL4WS specification

Table 1.1: Prefixes and namepsaces used in this document.

(6)

Chapter 2

EFSOC Framework and

Metamodel

Figure 2.1: The EFSOC framework

EFSOC is a multi-tiered framework for service-oriented computing as shown in figure 2.1. The figure uses UML notation to represent that the framework consists of a number of tiers, each of which may contain any number of infrastructure services and any number of elements elements. All

infrastructure services are regular services, which allows us to describe and publish them clearly in a standard format, such as WSDL.

The core assumption of our approach is that all all services, business processes and actors play a certain role in achieving business goals and that

coordination between subjects takes place by exchanging events. This is represented in the metamodel by the relationship between event type and subject and by the relationship between subject and role type.

(7)

Figure 2.2: The EFSOC meta model

The EFSOC metamodel contains three tiers: the event tier, the access control tier and the business process tier. The event tier provides event relay facilities, the access control tier provides access control facilities to the event relay service and the business process service provides the interface to business processes and services.

Each of the tiers can be represented from structural perspective, where it is clear which infrastructure services and elements belong to the particular tier. Figure 2.3 shows the event tier from such a perspective. However, for a complete model, this way of representing the model will be couter-productive and might confuse more than it conveys. Therefore, we have chosen to use a more functional representation of the model, which is shown in figure 2.2.

2.1 The Event Tier

The event tier comprises two main elements: subjects and events and one infrastructure service: the event service.

(8)

Figure 2.3: Structural perspective of the event tier

A subject can be either a resource or a service, and is capable of playing a certain role in the context of a business process. Subjects thus need not be necessarily human actors, but also can be implemented using an (autonomous) web-service.

In accordance with findings of (Luckham, 2002), we identify two categories of subjects: event generators and event monitors. An event generator pertains to a subject that is capable of autonomously producing an event, possibly triggered by an incoming event, internal state change or internal business policy. An event monitor on the other hand side, refers to an independent subject that registers incoming and outgoing events between subjects.

Events can be simply perceived as occurrences that happen over time, and independently from each other. Events represent a specific capability that is carried out by a service, and are capable of carrying information themselves, e.g., a request product event can be parameterized with a product identifier, date and quantity.

Events are publicized (or generated) by calling the event service. The event service will consult the access control service to determine whether or not the process or service was allowed to generate the event.

Processes and services may register to monitor certain events. On event subscription, an access control check will be performed. If the access control service allows the subscription to take place, events may receive event

(9)

Figure 2.4: Structural perspective of the access control tier

instances. Note that subsequent access control checks are performed when actual event instances are about to be relayed.

Each event that is generated or monitored is logged in an event log. Each line is stamped with a date/time and a line id. Checksums of line ids are stored independently to assure non-repudiation.

We define

• SU as the set of all subjects

• ET as the set of all event types

2.2 The Access Control Tier

To reduce the risk of interacting with potentially unknown service providers, any approach that focusses on service integration in business processes must have strong security measures to make sure that all communication between provider and consumer is adequately safeguarded against unauthorized disclosure or manipulation. Not only must the communication be safe, once messages have been safely relayed from the service provider to the service

(10)

consumer (or vice versa), there must also be an adequate access control system in place that enforces that each service provider can only interact with

business processes in exactly the way it needs to do to deliver its service.

The access control tier deals with allocating roles to subjects. A role factors cohesive behavior of subjects into some type, e.g., the subjects John Doe and Mary Dolittle both are specialized in advising clients about car insurances. The linkage between a subject and a role type is typified using a role

assignment. In role-based access control, permissions are associated with roles and roles are assigned to users (Sandhu et al., 1996).

We refine the definition of a subject to make explicit that any infrastructure service is considered as a subject.

The definitions of the the SU can now be refined to

• IS is the set of all infrastructure services,

• SU =IS

Each subject may be assigned to one or more role types. A role type represents the function that a certain element fulfills in completing a business process.

We define the the set of role types as

• RT is the set of all role types;

Role types can be organized into role hierarchies, that are capable of indicate that one role is contained in another role. It has been proven that this containment relationship is irreflexive, a-symmetric and transitive (Jansen, 1998). Role type hierarchies play are an important means to substitute role instances and support the administration of access control privileges and constraints . Using role hierarchies, a role can be refined into another role that possesses stricter access control properties.

We represent a role hierarchy as

• RR ⊆ RT × RT

Previously, we stated that all events must originate from an authorized event generator and may only be sent to authorized event monitors. This is represented by

(11)

• EMis the set of all authorized event monitors. EM ⊆ ET × RT;

• EG is the set of all authorized event generators. EG ⊆ ET × RT.

As role types can be assigned to subjects, they are a pivotal concept in our approach. We defineRA as the set of all role assignments, so that

• RA ⊆ RT × SU

Having these basic sets available to us, we can now define a number of contstraints on role assignment and role sessions:

• subject: RA → SU ;

• roletype: RA → RT

A role assignment as such does not entitle the subject to any privileges. Instead, a role assignment must be explicitly activated, which results in a role session. Each role session is associated with exactly one role assignment.

We now define

• RSas the set of all role sessions, and

• assignment: RS → RA

2.3 The Business Process Tier

A business process consists of one or more related activities that produce a business requirement. Activities are atomic units of work that execute like transactions, i.e. when an activity gets interrupted while executing, it may be recovered to the point where it started. Business processes may publish their (external) interface in the form of an operational service.

Business processes operate independently of eachother. However, there may be many reasons why processes, or process isntances, running in parallel have a need to share information or synchronize their activities. This may be achieved by monitoring and generating events that are related to (virtual) business objects. For example, which the loanProcess is executing, it may need to consult another process. This may be achieved by monitoring events that

(12)

Figure 2.5: Structural perspective of the business process tier

are generated by a business object that is shared. In line with established terminology (omg, 2003), we call this process choreography.

Process instances are created when the event service monitors an event that is registered to initiate a business process. The business process service will create a context in which the process instance will execute and start execution of the process definition.

Business process may be terminated for a large variety of reasons. There may be (unexpected) runtime exceptions such as services being unavailable due to a variety of reasons, but also changing security consideration which mean that running processes may not be allowed to continue processing. We propose a system of active security, by which we mean that access control takes place throughout process execution and not only when the process starts. In other words, if a process starts, but during its execution certain permissions are revoked that the process needs to operate, that process must terminate cleanly. Finally, a process may also terminate because it has reached on or more predefined termination points, such as a product or a service that has been delivered.

We define

• BPas the set of all business processes,

• OS as the set of all operational services,

(13)

Business processes are intiated by one or more events that they monitor and, as part of their run time behaviour, can also generate events. Based on this knowledge, we refine the definition of a subject to include operational services and business processes.

• SV is the set of all services, so thatSV =OS ∪ IS • SU =SV ∪ BP

Regular business processes and services may not interact directly with a business object. Access to a business objects is provided subsidiary through a virtual business objects (VBO). The purpose of VBOs is to hide the internal implementations of a business object in terms of enterprise back-end services and operations. For instance, business objects are exposed to services via their interface, and thus VBOs act as technology neutral wrappers of resources such as existing information systems of legacy applications.

We define

• BOas the set of all business objects;

• VS as the set of al virtual business object services. As a virtual business object service is a special kind of operational service,VS ⊆ OS;

• vbosis a mapping between resources and virtual business services.

vbos⊆ VS × BO.

The interface of virtual object services must be considered like any other operational service. Business processes may not invoke operational services directly. Instead, a process will generate one or more events which may be monitored by a service.

(14)

Chapter 3

Event Service

The Event Service provides all event relay functionality of the EFSOC

framework. The event service offers two operations: 1) Register Event Monitor and 2) Send Event. TheRegisterEventMonitoroperation is triggered by a

RegisterEventMonitorevent and is used to register a resource to receive events of a certain type. Resources may call thesendEventoperation to send events.

3.1 Operation Descriptions

3.1.1 RegisterEventMonitor Operation

Description: Register a new event handler for an event type.

Header: RegisterEventMonitor(string eventtype, anyURI eventHandler)

eventHandlermust be an URI of an endpoint that is called when an event of typeeventtypeis sent via the sendEventoperation.

Event types may be registered multiple times.

(15)

Handles Events:

• RegisterEventMonitorEvent

3.1.2 SendEvent Operation

Description: Send an event.

Header: SendEvent(Event e)

When the type of event ehas been registered through the

RegisterEventMonitoroperation, each event handler is called. The eventeis passed verbatim.

When the access control service has registered the

authorizationRequestEventevent type, calling this operation will result in two invocations of the access control service. Upon receiving the event from the sender, an authorization request will be sent to check whether or not the sender was allowed to generate the event. If the proper authorization was obtained, a second check will be sent to check if the receiver of the event (i.e. the registerar of the event handler for the corresponding event type) is authorized. These two checks can be executed in parallel. When both

authorization have been received, the event handler will be called and the data in the event will be passed verbatim.

Use case diagram when the Access Control Service has not registered the authorization event type:

Use case diagram when the Access Control Service has registered the authorization event type:

(16)

Handles events:

• None. This is a special service.

3.2 Event Types

3.2.1 RegisterEventMonitor Event

Description: ARegisterEventMonitorEventis generated when a subject wants to monitors events of a certain event type

Generators: • Any Definition: <efsoc:efsoc targetNamespace = "http://www.pronir.nl/efsoc/eventservice.xsd" xmlns:efsoc = "http://www.pronir.nl/efsoc/efsoc.xsd" xmlns:xs = "http://www.w3.org/2001/XMLSchema"> <efsoc:eventtype name="RegisterEventMonitorEvent"> <efsoc:body>

<xs:element name="eventtype" type="xs:string"/> <xs:element name="operation" type="xs:AnyURI"/> </efsoc:body>

</efsoc:eventtype> </efsoc:efsoc>

(17)

Example: <event type="RegisterEventMonitorEvent"> <body> <eventtype>checkCreditEvent</eventtype> <operation>http://www.pronir.nl/creditcheck.php</operation> </body> </event>

(18)

Chapter 4

Access Control Service

4.1 Operation Descriptions

4.1.1 requestAuthorization Operation

requestAuthorizationis an operation that is called to determine whether or not a subject will be granted permission to send or receive a certain event.

Header: requestAuthorization(string subject, string eventtype, enumeration action

Allowed actions are:

sender to check authorized sender

receiver to check authorized receiver

The authorization decision will be returned to the caller through an

AuthorizationResponseEventevent. The caller is expected to have registered a handler for this event type.

NOTE: define authorizationresponsevent!

(19)

Handles events:

• RequestAuthorizationEvent

4.1.2 newRoleType Operation

To register a new role type with the access control service.

Header:

newRoleType(string roletype)

Role type names are unique and can only be registered once.

Use Case Diagram:

Handles events:

• NewRoleTypeEvent

4.1.3 newSubject Operation

Registers a new subject with the access control service.

Header:

(20)

Each subject may only be registered once. Usernames are unique.

Use Case Diagram:

Handles events:

• NewSubjectEvent

4.1.4 newRoleAssignment Operation

To associate a role type with a subject.

Header:

newRoleAssignment(string roletype, string username)

Subject may be assigned to multiple roles and a role may be assigned to multiple subjects.

Use Case Diagram:

Handles events:

• NewRoleAssignmentEvent

4.1.5 addAuthorizedEventMonitor Operation

To register an authorized event monitor.

(21)

Header:

addAuthorizedEventMonitor(string eventtype, string roletype)

Each event type may be monitored by multiple role types and each role type may monitor multiple events.

Use Case Diagram:

Handles events:

• AddAuthorizedEventMonitorEvent

4.1.6 addAuthorizedEventGenerator Operation

To register an authorized event generator.

Header:

addAuthorizedEventGenerator(string eventtype, string roletype)

Each event type may be generated by multiple role types and each role type may generate multiple events.

Use Case Diagram:

Handles events:

(22)

4.2 Event Types

4.2.1 NewRoleTypeEvent

ANewRoleTypeEventis generated when a new role type must be added to the database. When the Access Control Service receives aNewRoleTypeEvent, it will create a new role type in its database. When the role type already exists, nothing will be done.

Generators: • Any Definition: <efsoc:eventtype name="NewRoleTypeEvent"> <efsoc:body> <xs:element name="roletype"> <xs:complexType>

<xs:attribute name="name" type="xs:string"/> </xs:complexType> </xs:element> </efsoc:body> </efsoc:eventtype> Example: <event type="newRoleTypeEvent"> <body> <roletype>salesRepresentative</roletype> </body> </event>

4.2.2 NewSubjectEvent

ANewSubjectEventis generated when a new subject be added to the database.

Generators:

(23)

Definition:

<efsoc:eventtype name="NewSubjectEvent"> <efsoc:body>

<xs:element name="username" type="xs:string"/> <xs:element name="fullname" type="xs:string"/> </efsoc:body> </efsoc:eventtype> Example: <event type="newSubjectEvent"> <body> <username>kees</username> <fullname>Kees Leune</fullname> </body> </event>

4.2.3 NewRoleAssignmentEvent

ANewRoleAssignmentEventis generated when a subject is assigned to a roletype. Both the subject’s id (element subject) as well as the roletype must be predefined. When the Access Control Service receives a

NewRoleAssignmentEvent, it will create a new role assignment. If an

association between subject and roletype already existed, nothing will be done.

Generators:

• Any

Definition:

<efsoc:eventtype name="NewRoleAssignmentEvent"> <efsoc:body>

<xs:element name="roletype" type="xs:string"/> <xs:element name="subject" type="xs:string"/> </efsoc:body>

</efsoc:eventtype>

(24)

<event type="newRoleAssignmentEvent"> <body> <roletype>salesRepresentative</roletype> <subject>1029</subject> </body> </event>

4.2.4 RequestAuthorizationEvent

RequestAuthorizationEventis generated when the Event Service receives or sends an event from or to a subject.

Generators:

• EventService

Definition:

<efsoc:eventtype name="RequestAuthorizationEvent"> <efsoc:body>

<xs:element name="eventtype" type="xs:string"/> <xs:element name="subject" type="xs:string"/> <xs:simpleType name="authorizationaction"> <xs:restriction base="xs:string"> <xs:enumeration value="sender"/> <xs:enumeration value="receiver"/> </xs:restriction> </xs:simpleType> </efsoc:body> </efsoc:eventtype> Example: <event type="RequestAuthorizationEvent"> <body> <subject>1029</subject> <eventtype>checkCreditEvent</eventtype> <action>sender</action> </body> </event>

(25)

4.2.5 AddAuthorizedEventMonitorEvent

An AddAuthorizedEventMonitorEventis generated when a service wants to authorize roletypes to monitor certain events.

Generators:

• all

Definition

<efsoc:eventtype name="AddAuthorizedEventMonitorEvent"> <efsoc:body>

<xs:element name="eventtype" type="xs:string"/> <xs:element name="roletype" type="xs:string"/> </efsoc:body> </efsoc:eventtype> Example: <event type="AddAuthorizedEventMonitorEvent"> <body> <eventtype>checkCredit</eventtype> <roletype>creditservicerole</roletype> </body> </event>

4.2.6 AddAuthorizedEventGeneratorEvent

An AddAuthorizedEventMonitorEventis generated when a subject wants to authorize roletypes to generate certain events.

Generators:

• all

Definition:

(26)

<efsoc:body>

<xs:element name="eventtype" type="xs:string"/> <xs:element name="roletype" type="xs:string"/> </efsoc:body> </efsoc:eventtype> Example: <event type="AddAuthorizedEventGeneratorEvent"> <body> <eventtype>checkCredit</eventtype> <roletype>salesRepresentative</roletype> </body> </event>

(27)

Chapter 5

Business Process Service

5.1 Operation Descriptions

5.1.1 addService Operation

Description: addServiceregisters a service with EFSOC. Before a service can be assigned to a business process, its interface must be known.

Header: addService(wsdl serviceDescription)

serviceDescriptionmust be a full WSDL document, including bindings and service definition.

Use Case Diagram:

Note that this represents the fact that a user sends an event to the business process service by calling the sendEventmethod of the event service, which will in turn determine whether the subject was authorized to send the event and if the business process service is allowed to receive it.

(28)

Handles Events:

• NewServiceEvent

5.1.2 addBusinessProcess

Description: addBusinessProcessregisters a business process with EFSOC.

Header: addBusinessProcess(processDescription)

Use Case Diagram:

Handles Events:

• NewBusinessProcessEvent

5.2 Event Types

5.2.1 NewService Event

ANewServiceEventis generated when a subject introduces a new service to the framework.

Generators:

• Any

Definition:

(29)

<efsoc:body>

<xs:element name="ServiceDescription type="wsdl:definitions">

<xs:complexType>

<xs:attribute name="name" type="xs:string"/> </xs:complexType> </xs:element> </efsoc:body> </efsoc:eventtype> Example: <event type="NewServiceEvent"> <body> <serviceDescription name="demoService"> <wsdl:interface name="demoInterface"> [ ... ] </wsdl:interface> <wsdl:binding name="demoHTTPbinding" interface="demoInterface"> [ ... ] </wsdl:binding> <wsdl:service name="demoService" interface="demoInterface"> [ ... ] </wsdl:service> </serviceDescription> </body> </event>

5.2.2 NewBusinessProcess Event

ANewBusinessProcessEventis generated when a subject introduces a new business process to the framework.

Generators:

• Any

Definition:

(30)

<efsoc:body>

<xs:element name="BusinessProcessDescription type="xs:string"> </xs:element> </efsoc:body> </efsoc:eventtype> Example: <efsoc:event type="NewBusinessProcessEvent"> <efsoc:body> <BusinessProcessDescription name="demoProcess"> businessProcess loanProcess (loanRequestEventType startevent) {

property string risklevel;

property string loanResponse;

property boolean requestApproval;

/* do a risk assessement if the load is larger than 10000 */ sequence

{

if (startevent.request > 10000) {

event riskAssessmentRequestEventType riskAssessmentRequestEvent; riskAssessmentRequestEvent.subject = sender(startevent);

riskAssessmentRequestEvent.amount = startevent.request; send riskAssessmentRequestEvent;

synchronize on risklevel;

if (risklevel == "high") loanResponse = "no"; } requestApproval = "yes"; } } </BusinessProcessDescription> </efsoc:body> </efsoc:event>

(31)

Appendix A

WSDL specifications

A.1 Event Service

<?xml version="1.0"?>

<!--- eventservice.wsdl

- $Id: wsdl.tex,v 1.1 2003/08/20 12:19:15 kees Exp $ --> <wsdl:definitions xmlns:wsdl = "http://www.w3.org/2003/06/wsdl/" xmlns:http = "http://www.w3.org/2003/06/wsdl/http" xmlns:xsd = "http://www.w3.org/2001/XMLSchema"> <wsdl:types> <xsd:import namespace="http://www.pronir.nl/efsoc/eventtype.xsd"/> </wsdl:types> <wsdl:message name="RegisterEventMonitorMsg"> <wsdl:part name="eventtype" type="xsd:string"/> <wsdl:part name="operation" type="xsd:string"/> </wsdl:message>

<wsdl:message name="SendEventMsg">

<wsdl:part name="sender" type="xsd:string"/> <wsdl:part name="event" type="xsd:string"/> </wsdl:message>

(32)

<wsdl:interface name="EventInterface"> <wsdl:operation name="registerEventMonitor" pattern="http://www.w3.org/2003/06/wsdl/in-only"> <wsdl:input message="registerEventMonitorMsg"/> </wsdl:operation> <wsdl:operation name="sendEventOp" pattern="http://www.w3.org/2003/06/wsdl/in-only"> <wsdl:input message="sendEventMsg"/> </wsdl:operation> </wsdl:interface> </wsdl:definitions>

A.2 Access Control Service

<?xml version="1.0"?> <wsdl:definitions xmlns:wsdl = "http://www.w3.org/2003/06/wsdl" xmlns:http = "http://www.w3.org/2003/06/wsdl/html" xmlns:xs = "http://www.w3.org/2001/XMLSchema" xmlns:efsoc = "http://www.pronir.nl/efsoc/accesscontrol.xsd"> <wsdl:types> <ws:import namespace="http://www.pronir.nl/efsoc/accesscontrol.xsd"> </wsdl:types> <wsdl:message name="AuthRequestInMsg">

<wsdl:part name="event" type="efsoc:RequestAuthorizationEvent"/> </wsdl:message>

<wsdl:message name="AuthResponseOutMsg">

<wsdl:part name="event" type="efsoc:AuthorizationResponseEvent"/> </wsdl:message>

<wsdl:message name="NewRoleTypeInMsg">

<wsdl:part name="event" type="efsoc:NewRoleTypeEvent"/> </wsdl:message>

<wsdl:message name="NewSubjectInMsg">

<wsdl:part name="event" type="efsoc:NewSubjectEvent"/> </wsdl:message>

(33)

<wsdl:message name="NewRoleAssignmentInMsg">

<wsdl:part name="event" type="efsoc:NewRoleAssignmentEvent"/> </wsdl:message>

<wsdl:message name="AddAuthEventMonInMsg">

<wsdl:part name="event" type="AddAuthorizedEventMonitorEvent"/> </wsdl:message>

<wsdl:message name="AddAuthEventGenInMsg">

<wsdl:part name="event" type="AddAuthorizedEventGeneratorEvent"/> </wsdl:message> <wsdl:interface name="accessControlInterface"> <wsdl:operation name="requestAuthorization" pattern="http://www.w3.org/2003/06/wsdl/in-out"> <wsdl:input message="AuthRequestInMsg"/> <wsdl:output message="AuthResponseOutMsg"/> </wsdl:operation> <wsdl:operation name="newRoleType" pattern="http://www.w3.org/2003/06/wsdl/in-only"> <wsdl:input message="NewRoleTypeInMsg"/> </wsdl:operation> <wsdl:operation name="newSubject" pattern="http://www.w3.org/2003/06/wsdl/in-only"> <wsdl:input message="NewSubjectInMsg"/> </wsdl:operation> <wsdl:operation name="newRoleAssignment" pattern="http://www.w3.org/2003/06/wsdl/in-only"> <wsdl:input message="NewRoleAssignmentInMsg"/> </wsdl:operation> <wsdl:operation name="addAuthorizedEventMonitor" pattern="http://www.w3.org/2003/06/wsdl/in-only"> <wsdl:input message="AddAuthEventMonInMsg"/> </wsdl:operation> <wsdl:operation name="addAuthorizedEventGenerator" pattern="http://www.w3.org/2003/06/wsdl/in-only"> <wsdl:input message="AddAuthEventGenInMsg"/> </wsdl:operation> </wsdl:interface> </wsdl:definitions>

(34)

Appendix B

XML Schema definitions

B.1 Meta model definitions

<?xml version="1.0"?> <xs:schema targetNamespace="http://www.pronir.nl/efsoc/efsoc.xsd" xmlns:xs = "http://www.w3.org/2001/XMLSchema"> <xs:element name="efsoc"> <xs:complexType> <xs:sequence>

<xs:element name="eventtype" minoccurs="0" type="EventType" maxoccurs="unbounded"/>

<xs:element name="event" minoccurs="0" type="Event" maxoccurs="unbounded"/>

</xs:complexType> </xs:element>

<xs:complexType name="EventType"> <xs:sequence>

<xs:element name="body" type="xs:schema"/> </xs:sequence>

<xs:attribute name="name" type="xs:string/"> </xs:complexType>

<xs:compleType name="Event">

<xs:attribute name="type" type="xs:string"/>

</xs:complexType> </xs:schema>

(35)

B.2 Event Service definitions

<?xml version="1.0"?> <efsoc:efsoc targetNamespace = "http://www.pronir.nl/efsoc/eventservice.xsd" xmlns:efsoc = "http://www.pronir.nl/efsoc/efsoc.xsd" xmlns:xs = "http://www.w3.org/2001/XMLSchema"> <efsoc:eventtype name="RegisterEventMonitorEvent"> <efsoc:body>

<xs:element name="eventtype" type="xs:string"/> <xs:element name="operation" type="xs:AnyURI"/> </efsoc:body>

B.3 Access Control Service Definitions

<?xml version="1.0"?> <efsoc:efsoc targetNamespace = "http://www.pronir.nl/efsoc/accesscontrol.xsd" xmlns:efsoc = "http://www.pronir.nl/efsoc/efsoc.xsd" xmlns:xs = "http://www.w3.org/2001/XMLSchema"> <efsoc:eventtype name="NewRoleTypeEvent"> <efsoc:body> <xs:element name="roletype"> <xs:complexType>

<xs:attribute name="name" type="xs:string"/> </xs:complexType> </xs:element> </efsoc:body> </efsoc:eventtype> <efsoc:eventtype name="NewSubjectEvent"> <efsoc:body>

<xs:element name="username" type="xs:string"/> <xs:element name="fullname" type="xs:string"/> </efsoc:body>

</efsoc:eventtype>

<efsoc:eventtype name="NewRoleAssignmentEvent"> <efsoc:body>

<xs:element name="roletype" type="xs:string"/> <xs:element name="subject" type="xs:string"/> </efsoc:body>

(36)

</efsoc:eventtype>

<efsoc:eventtype name="RequestAuthorizationEvent"> <efsoc:body>

<xs:element name="eventtype" type="xs:string"/> <xs:element name="subject" type="xs:string"/> <xs:simpleType name="authorizationaction"> <xs:restriction base="xs:string"> <xs:enumeration value="sender"/> <xs:enumeration value="receiver"/> </xs:restriction> </xs:simpleType> </efsoc:body> </efsoc:eventtype> <efsoc:eventtype name="AddAuthorizedEventMonitorEvent"> <efsoc:body>

<xs:element name="eventtype" type="xs:string"/> <xs:element name="roletype" type="xs:string"/> </efsoc:body>

</efsoc:eventtype>

<efsoc:eventtype name="AddAuthorizedEventGeneratorEvent"> <efsoc:body>

<xs:element name="eventtype" type="xs:string"/> <xs:element name="roletype" type="xs:string"/> </efsoc:body>

</efsoc:eventtype> </efsoc:efsoc}

B.4 Business Process Service Definitions

<?xml version="1.0"?> <efsoc:efsoc targetNamespace = "http://www.pronir.nl/efsoc/accesscontrol.xsd" xmlns:efsoc = "http://www.pronir.nl/efsoc/efsoc.xsd" xmlns:xs = "http://www.w3.org/2001/XMLSchema"> <efsoc:eventtype name="NewServiceEvent"> <efsoc:body>

<xs:element name="ServiceDescription type="wsdl:definitions"> <xs:complexType>

<xs:attribute name="name" type="xs:string"/> </xs:complexType>

</xs:element> </efsoc:body> </efsoc:eventtype>

(37)

<efsoc:eventtype name="NewBusinessProcessEvent"> <efsoc:body>

<xs:element name="BusinessProcessDescription type="bpws:process"> <xs:complexType>

<xs:attribute name="name" type="xs:string"/> </xs:complexType> </xs:element> </efsoc:body> </efsoc:eventtype> <efsoc:eventtype name="NewServiceAssignmentEvent"> <efsoc:body>

<xs:element name="businessprocess type="xs:string"/> <xs:element name="service" type="xs:string"/> </efsoc:body>

(38)

Appendix C

EBNF specifications

C.1 Business Process Definition

businessprocess :

"businessProcess" identifier arglist "{ businessprocessdefinition "}" arglist: "(" parameter ")" parameter: eventtype eventname businessprocessdefinition: propertydefinitions sequencedefinitions propertydefinitions: | propertydefinition propertydefinitions propertydefinition:

"property" propertytype propertyname ";" propertytype: identifier propertyname: identifier identifier: word sequencedefinitions: | sequencedefinition sequencedefinitions

(39)

sequencedefinition: "sequence" "{" sequenceelements "}" sequenceelements: | sequenceelement sequenceelements sequenceelement: eventdefinition | propertydefinition | statement eventdefinitions: | eventdefinition eventdefinitions eventdefinition:

"event" eventtype eventname ";" eventtype: identifier eventname: identifier statements: | statement statements statement: | statementblock | ifstatement | synchronizestatement | assignmentstatement | sendstatement statementblock: "{" eventdefinitions statements "}" ifstatement: singleifstatement | nestedifstatement singleifstatement:

"if" "(" expression ")" statement nestedifstatement:

"if" "(" expression ")" statement "else" statement synchronizestatement:

"synchronize on" propertyname ";" assignmentstatement:

propertyname "=" expression ";" sendstatement:

(40)

"send" eventname ";" expression: testingexpression | functioncall | propertyname | literalexpression

(41)

(42)

Appendix D

Screenshots

D.1 Business process definitions

(43)

(44)

(45)

(46)

Bibliography

(2003). Business process definition metamodel. Request for proposal, OMG. Jansen, W. (1998). Inheritance properties of role hierarchies. In21st National

Information Systems Security Conference, Crystal City, Virginia.

Luckham, D. (2002). The Power of Events. An Introduction to Complex Event Processing in Distributed Enterprise Systems. Addison-Wesley Press. Sandhu, R., Coyne, E., Feinstein, H., and Youman, C. (1996). Role-based

EFSOC Framework Overview and Infrastructure Services