EFSOC Framework Overview and Infrastructure Services

Transcription

1 EFSOC Framework Overview and Infrastructure Services Infolab Technical Report Series INFOLAB-TR-13 Kees Leune Id: infraserv.tex,v /10/23 10:36:08 kees Exp 1

2 Contents 1 Introduction Notational Conventions EFSOC Framework and Metamodel The Event Tier The Access Control Tier The Business Process Tier Event Service Operation Descriptions RegisterEventMonitor Operation SendEvent Operation Event Types RegisterEventMonitor Event Access Control Service Operation Descriptions requestauthorization Operation newroletype Operation newsubject Operation newroleassignment Operation addauthorizedeventmonitor Operation addauthorizedeventgenerator Operation Event Types NewRoleTypeEvent NewSubjectEvent NewRoleAssignmentEvent RequestAuthorizationEvent AddAuthorizedEventMonitorEvent AddAuthorizedEventGeneratorEvent Business Process Service Operation Descriptions addservice Operation addbusinessprocess Event Types NewService Event NewBusinessProcess Event

3 A WSDL specifications 31 A.1 Event Service A.2 Access Control Service B XML Schema definitions 34 B.1 Meta model definitions B.2 Event Service definitions B.3 Access Control Service Definitions B.4 Business Process Service Definitions C EBNF specifications 38 C.1 Business Process Definition D Screenshots 41 D.1 Business process definitions D.1.1 Process specification D.1.2 Role Assignment D.2 Service definition D.3 Event Permissions

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 tool 1. 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 1 A working prototype is available at kees/phd-kees/ 4

5 Prefix Namespace Notes wsdl WSDL 1.2 specification http HTTP bindings for WSDL 1.2 xs XML Schema specification bpws BPEL4WS specification Table 1.1: Prefixes and namepsaces used in this document. significant. 5

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. 6

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 The Event Tier The event tier comprises two main elements: subjects and events and one infrastructure service: the event service. 7

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 8

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 9

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 10

11 EM is 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 define RA 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 RS as 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 11

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 BP as the set of all business processes, OS as the set of all operational services, AC as the set of all actors. 12

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 that SV = 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 BO as 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; vbos is 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. 13

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. The RegisterEventMonitor operation is triggered by a RegisterEventMonitor event and is used to register a resource to receive events of a certain type. Resources may call the sendevent operation to send events. 3.1 Operation Descriptions RegisterEventMonitor Operation Description: Register a new event handler for an event type. Header: RegisterEventMonitor(string eventtype, anyuri eventhandler) eventhandler must be an URI of an endpoint that is called when an event of type eventtype is sent via the sendevent operation. Event types may be registered multiple times. Use Case Diagram: 14

15 Handles Events: RegisterEventMonitorEvent SendEvent Operation Description: Send an event. Header: SendEvent(Event e) When the type of event e has been registered through the RegisterEventMonitor operation, each event handler is called. The event e is passed verbatim. When the access control service has registered the authorizationrequestevent event 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: 15

16 Handles events: None. This is a special service. 3.2 Event Types RegisterEventMonitor Event Description: A RegisterEventMonitorEvent is generated when a subject wants to monitors events of a certain event type Generators: Any Definition: <efsoc:efsoc targetnamespace = " xmlns:efsoc = " xmlns:xs = " <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> 16

17 Example: <event type="registereventmonitorevent"> <body> <eventtype>checkcreditevent</eventtype> <operation> </body> </event> 17

18 Chapter 4 Access Control Service 4.1 Operation Descriptions requestauthorization Operation requestauthorization is 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 AuthorizationResponseEvent event. The caller is expected to have registered a handler for this event type. NOTE: define authorizationresponsevent! Use Case Diagram: 18

19 Handles events: RequestAuthorizationEvent 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 newsubject Operation Registers a new subject with the access control service. Header: newsubject(string username, string fullname) 19

20 Each subject may only be registered once. Usernames are unique. Use Case Diagram: Handles events: NewSubjectEvent 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 addauthorizedeventmonitor Operation To register an authorized event monitor. 20

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 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: AddAuthorizedEventGeneratorEvent 21

22 4.2 Event Types NewRoleTypeEvent A NewRoleTypeEvent is generated when a new role type must be added to the database. When the Access Control Service receives a NewRoleTypeEvent, 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> NewSubjectEvent A NewSubjectEvent is generated when a new subject be added to the database. Generators: Any 22

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> NewRoleAssignmentEvent A NewRoleAssignmentEvent is 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" </efsoc:body> </efsoc:eventtype> type="xs:string"/> Example: 23

24 <event type="newroleassignmentevent"> <body> <roletype>salesrepresentative</roletype> <subject>1029</subject> </body> </event> RequestAuthorizationEvent RequestAuthorizationEvent is 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> 24

25 4.2.5 AddAuthorizedEventMonitorEvent An AddAuthorizedEventMonitorEvent is 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" </efsoc:body> </efsoc:eventtype> type="xs:string"/> Example: <event type="addauthorizedeventmonitorevent"> <body> <eventtype>checkcredit</eventtype> <roletype>creditservicerole</roletype> </body> </event> AddAuthorizedEventGeneratorEvent An AddAuthorizedEventMonitorEvent is generated when a subject wants to authorize roletypes to generate certain events. Generators: all Definition: <efsoc:eventtype name="addauthorizedeventgeneratorevent"> 25

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> 26

27 Chapter 5 Business Process Service 5.1 Operation Descriptions addservice Operation Description: addservice registers a service with EFSOC. Before a service can be assigned to a business process, its interface must be known. Header: addservice(wsdl servicedescription) servicedescription must 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 sendevent method 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. 27

28 Handles Events: NewServiceEvent addbusinessprocess Description: addbusinessprocess registers a business process with EFSOC. Header: addbusinessprocess(processdescription) Use Case Diagram: Handles Events: NewBusinessProcessEvent 5.2 Event Types NewService Event A NewServiceEvent is generated when a subject introduces a new service to the framework. Generators: Any Definition: <efsoc:eventtype name="newserviceevent"> 28

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> NewBusinessProcess Event A NewBusinessProcessEvent is generated when a subject introduces a new business process to the framework. Generators: Any Definition: <efsoc:eventtype name="newbusinessprocessevent"> 29

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 */ 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 = } requestapproval = "yes"; } } </BusinessProcessDescription> </efsoc:body> </efsoc:event> "no"; 30

31 Appendix A WSDL specifications A.1 Event Service <?xml version="1.0"?> <!-- - eventservice.wsdl - (C) 2003 Kees Leune <kees@uvt.nl> - $Id: wsdl.tex,v /08/20 12:19:15 kees Exp $ --> <wsdl:definitions xmlns:wsdl = " xmlns:http = " xmlns:xsd = " <wsdl:types> <xsd:import namespace=" </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> 31

32 <wsdl:interface name="eventinterface"> <wsdl:operation name="registereventmonitor" pattern=" <wsdl:input message="registereventmonitormsg"/> </wsdl:operation> <wsdl:operation name="sendeventop" pattern=" <wsdl:input message="sendeventmsg"/> </wsdl:operation> </wsdl:interface> </wsdl:definitions> A.2 Access Control Service <?xml version="1.0"?> <wsdl:definitions xmlns:wsdl = " xmlns:http = " xmlns:xs = " xmlns:efsoc = " <wsdl:types> <ws:import namespace=" </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> 32

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=" <wsdl:input message="authrequestinmsg"/> <wsdl:output message="authresponseoutmsg"/> </wsdl:operation> <wsdl:operation name="newroletype" pattern=" <wsdl:input message="newroletypeinmsg"/> </wsdl:operation> <wsdl:operation name="newsubject" pattern=" <wsdl:input message="newsubjectinmsg"/> </wsdl:operation> <wsdl:operation name="newroleassignment" pattern=" <wsdl:input message="newroleassignmentinmsg"/> </wsdl:operation> <wsdl:operation name="addauthorizedeventmonitor" pattern=" <wsdl:input message="addautheventmoninmsg"/> </wsdl:operation> <wsdl:operation name="addauthorizedeventgenerator" pattern=" <wsdl:input message="addautheventgeninmsg"/> </wsdl:operation> </wsdl:interface> </wsdl:definitions> 33

34 Appendix B XML Schema definitions B.1 Meta model definitions <?xml version="1.0"?> <xs:schema targetnamespace=" xmlns:xs = " <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"> <!-- hoe voeg ik hier een instantie van de body toe? --> <xs:attribute name="type" type="xs:string"/> </xs:complextype> </xs:schema> 34

35 B.2 Event Service definitions <?xml version="1.0"?> <efsoc:efsoc targetnamespace = " xmlns:efsoc = " xmlns:xs = " <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> B.3 Access Control Service Definitions <?xml version="1.0"?> <efsoc:efsoc targetnamespace = " xmlns:efsoc = " xmlns:xs = " <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> 35

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" </efsoc:body> </efsoc:eventtype> type="xs:string"/> <efsoc:eventtype name="addauthorizedeventgeneratorevent"> <efsoc:body> <xs:element name="eventtype" type="xs:string"/> <xs:element name="roletype" </efsoc:body> </efsoc:eventtype> </efsoc:efsoc} type="xs:string"/> B.4 Business Process Service Definitions <?xml version="1.0"?> <efsoc:efsoc targetnamespace = " xmlns:efsoc = " xmlns:xs = " <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> 36

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> </efsoc:eventtype> </efsoc:efsoc> 37

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 38

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: 39

40 "send" eventname ";" expression: testingexpression functioncall propertyname literalexpression functioncall: identifier "(" propertyname ")" testingexpression: expression test expression test: MORETHAN LESSTHAN EQUIV MORETHANEQUIV LESSTHANEQUIV NOTEQUAL literalexpression: stringliteral numberliteral stringliteral: STRING numberliteral: INTEGER FLOAT 40

41 41

42 Appendix D Screenshots D.1 Business process definitions D.1.1 Process specification 42

43 D.1.2 Role Assignment 43

44 D.2 Service definition 44

45 D.3 Event Permissions 45

46 Bibliography (2003). Business process definition metamodel. Request for proposal, OMG. Jansen, W. (1998). Inheritance properties of role hierarchies. In 21st 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 access control models. IEEE Computer. 46