Top Banner
Service Oriented Architecture Collaboration Semantics (SOA CS) V 0.1
93
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: SOA Collaboration Semantics

Service Oriented Architecture Collaboration Semantics(SOA CS)

V 0.1

October 2005

Page 2: SOA Collaboration Semantics

Semantion Inc.

Table of Contents

1.0 INTRODUCTION....................................................................................................................................1

2.0 SOA INFORMATION MODEL.............................................................................................................1

3.0 COLLABORATION PROTOCOLS......................................................................................................2

4.0 COLLABORATIVE PROCESS INFORMATION DOCUMENT (CPID)........................................2

5.0 COMMUNICATION BETWEEN THE GATEWAY AND THE FEDERATION MANAGER......4

6.0 GATEWAY INTERFACE......................................................................................................................4

7.0 PORTAL INTERFACE...........................................................................................................................5

7.1. PROFILE..................................................................................................................................................67.2 COLLABORATIVE PROCESS.....................................................................................................................67.3 MONITORING AND REPORTING...............................................................................................................77.4 SOA FEDERATION ADMINISTRATION.....................................................................................................7

8.0 FEDERATION REGISTRY AND PROCESS FLOW REGISTRY...................................................7

9.0 FEDERATION MANAGER PROTOCOL AND INTERFACE.........................................................8

9.1 FEDERATION MANAGER METHODS.........................................................................................................99.1.1 auditCommunication.....................................................................................................................109.1.2 authenticateSubject........................................................................................................................109.1.3 contentTransformation..................................................................................................................109.1.4 contentValidation..........................................................................................................................119.1.5 createAssociation..........................................................................................................................119.1.6 createVersion.................................................................................................................................119.1.7 delegateAgent................................................................................................................................119.1.8 deployCPID...................................................................................................................................129.1.9 findInitiatorByCPFlow..................................................................................................................129.1.10 findInfoReferenceByType............................................................................................................129.1.11 findProfileByFederate.................................................................................................................129.1.12 findProtocolByAgent...................................................................................................................139.1.13 getContent....................................................................................................................................139.1.14 getContentElement......................................................................................................................139.1.15 getContentElementAttribute........................................................................................................139.1.16 getFederate..................................................................................................................................139.1.17 getMessageRequestType..............................................................................................................149.1.18 getMessageType..........................................................................................................................149.1.19 registerFederate..........................................................................................................................149.1.20 removeObjects.............................................................................................................................149.1.21 sendMail......................................................................................................................................149.1.22 sendMessage................................................................................................................................159.1.23 setReference.................................................................................................................................159.1.24 subjectAuthorized........................................................................................................................159.1.25 submitCollaborationProfile.........................................................................................................159.1.26 submitCPID.................................................................................................................................169.1.27 submitDocument..........................................................................................................................16

Service Oriented Architecture Collaboration Semantics V0.1

Page 3: SOA Collaboration Semantics

Semantion Inc.

9.1.28 submitObjects..............................................................................................................................169.1.29 submitQuery................................................................................................................................179.1.30 updateAgentDelegation...............................................................................................................179.1.31 updateCPID.................................................................................................................................179.1.32 updateObjects..............................................................................................................................17

10.0 AGENT INTERFACE MANAGER...................................................................................................18

10.1 AGENT INTERFACE MANAGER METHODS...........................................................................................1910.1.1 createAssociation........................................................................................................................1910.1.2 delegateAgent..............................................................................................................................1910.1.3 escalateAgent...............................................................................................................................1910.1.4 findProtocolByAgent...................................................................................................................2010.1.5 invokeAgent.................................................................................................................................2010.1.6 monitorAgent...............................................................................................................................2010.1.7 removeObjects.............................................................................................................................2110.1.8 sendMessage................................................................................................................................2110.1.9 submitObjects..............................................................................................................................2110.1.10 submitQuery..............................................................................................................................2110.1.11 updateAgentDelegation.............................................................................................................2210.1.12 updateObjects............................................................................................................................22

11.0 FLOW CONTROLLER MANAGER PROTOCOL AND INTERFACE......................................22

11.1 FLOW CONTROLLER MANAGER METHODS.........................................................................................2511.1.1 checkArguments...........................................................................................................................2511.1.2 createAssociation........................................................................................................................2511.1.3 createStage..................................................................................................................................2611.1.4 deployCPID.................................................................................................................................2611.1.5 findActivityByParent....................................................................................................................2711.1.6 findArgumentByRule....................................................................................................................2711.1.7 findChoiceByParent....................................................................................................................2711.1.8 findByInput..................................................................................................................................2811.1.9 findByOutput................................................................................................................................2811.1.10 findDecisionByParent................................................................................................................2811.1.11 findEventByParent.....................................................................................................................2811.1.12 findInputByParent.....................................................................................................................2911.1.13 findOutputByParent...................................................................................................................2911.1.14 findMatrix..................................................................................................................................2911.1.15 findMatrixByInput.....................................................................................................................3011.1.16 findProtocolByAgent.................................................................................................................3011.1.17 findStageByParent.....................................................................................................................3011.1.18 getArgumentValue.....................................................................................................................3011.1.19 getContent..................................................................................................................................3111.1.20 getContentElement....................................................................................................................3111.1.21 getContentElementAttribute......................................................................................................3111.1.22 getRuleContent..........................................................................................................................3111.1.23 removeObjects...........................................................................................................................3111.1.24 resetReference...........................................................................................................................3211.1.25 sendMessage..............................................................................................................................3211.1.26 setReference...............................................................................................................................3211.1.27 submitObjects............................................................................................................................3311.1.28 submitQuery..............................................................................................................................3311.1.29 updateAgentDelegation.............................................................................................................3311.1.30 updateCPID...............................................................................................................................3311.1.31 updateObjects............................................................................................................................34

12.0 ACTIVITY MANAGER PROTOCOL AND INTERFACE............................................................34

Service Oriented Architecture Collaboration Semantics V0.1

Page 4: SOA Collaboration Semantics

Semantion Inc.

12.1 ACTIVITY MANAGER METHODS.........................................................................................................3612.1.1 createAssociation........................................................................................................................3612.1.2 createStage..................................................................................................................................3712.1.3 getPredecessor............................................................................................................................3712.1.4 getRole.........................................................................................................................................3712.1.5 getSuccessor................................................................................................................................3812.1.6 outputsAvailable..........................................................................................................................3812.1.7 sendMessage................................................................................................................................3812.1.8 setPredecessor.............................................................................................................................3812.1.9 setSuccessor.................................................................................................................................39

13.0 DECISION MANAGER PROTOCOL AND INTERFACE............................................................39

13.1 DECISION MANAGER METHODS..........................................................................................................4113.1.1 createAssociation........................................................................................................................4113.1.2 createStage..................................................................................................................................4213.1.3 getPredecessor............................................................................................................................4213.1.4 getRole.........................................................................................................................................4213.1.5 getSuccessor................................................................................................................................4313.1.6 outputsAvailable..........................................................................................................................4313.1.7 sendMessage................................................................................................................................4313.1.8 setPredecessor.............................................................................................................................4313.1.9 setSuccessor.................................................................................................................................44

14.0 EVENT MANAGER............................................................................................................................44

14.1 EVENT MANAGER METHODS..............................................................................................................4714.1.1 createAssociation........................................................................................................................4714.1.2 createProcedureConfirmation.....................................................................................................4814.1.3 createStage..................................................................................................................................4814.1.4 getAction......................................................................................................................................4814.1.5 getActionStatus............................................................................................................................4914.1.6 getActionType..............................................................................................................................4914.1.7 getMessage..................................................................................................................................4914.1.8 getPredecessor............................................................................................................................4914.1.9 getPublisher.................................................................................................................................4914.1.10 getSubscriber.............................................................................................................................5014.1.11 getSuccessor..............................................................................................................................5014.1.12 getTriggerType..........................................................................................................................5014.1.13 sendMessage..............................................................................................................................5014.1.14 setPredecessor...........................................................................................................................5014.1.15 setPublisher...............................................................................................................................5114.1.16 setSubscriber.............................................................................................................................5114.1.17 setSuccessor...............................................................................................................................51

15.0 SECURITY PROVIDER.....................................................................................................................51

15.1 COLLABORATIVE PROCESS FLOW SECURITY MANAGER METHODS...................................................5315.1.1 findPolicyByResource..................................................................................................................5315.1.2 findProfileByFederate.................................................................................................................5315.1.3 getPolicyFromLPAD...................................................................................................................5415.1.4 getRemotePolicy..........................................................................................................................5415.1.5 sendMessage................................................................................................................................54

15.2 FEDERATION IDENTITY MANAGER METHODS....................................................................................5415.2.1 authenticateSubject......................................................................................................................5415.2.2 sendMessage................................................................................................................................55

15.3 FEDERATION SECURITY POLICY MANAGER METHODS......................................................................5515.3.1 sendMessage................................................................................................................................55

Service Oriented Architecture Collaboration Semantics V0.1

Page 5: SOA Collaboration Semantics

Semantion Inc.

15.3.2 subjectAuthorized........................................................................................................................5515.4 SOA SECURITY BINDING....................................................................................................................5515.5 STANDARD SECURITY COMPONENTS..................................................................................................56

15.5.1 SSL...............................................................................................................................................5615.5.2 Web Services Security..................................................................................................................5715.5.3 SAML...........................................................................................................................................5715.5.3.1 SAML Applications...................................................................................................................5815.5.4 XACML........................................................................................................................................5815.5.5 XCBF...........................................................................................................................................59

16.0 References..............................................................................................................................................60

Service Oriented Architecture Collaboration Semantics V0.1

Page 6: SOA Collaboration Semantics

Semantion Inc.

1.0 Introduction

SOA Collaboration Semantics (CS) defines protocols and interfaces with methods required for the collaboration data (SOA Information Model) manipulations and interactions between SOA architectural components defined in Run-time SOA [RTSOA].

First, SOA Information Model (IM), Collaborative Process Information Document (CPID) and collaboration protocols will be introduced. Protocols and interfaces for each SOA Federation component, the Gateway interface, and the Portal interface sets of forms will follow. Finally, the Security Provider, its interface, methods and security standards bindings will be presented.

The Run-time SOA [RTSOA] specification and the SOA Information Model [SOAIM] specification should be read prior to reading this specification.

The SOA Collaboration Semantics specification is based on the Federated Enterprise Reference Architecture (FERA) [FERA].

2.0 SOA Information Model

The SOA Information Model (IM) provides support for the SOA Collaboration Semantics (CS). The SOA IM is used to manage both business context and business content. The SOA Collaboration Semantics defines all interfaces with methods/functions required for the collaboration data (SOA IM) manipulations and interactions between SOA architectural components.

In SOA IM, a CollaborativeProcess is a root entity that represents a business process. It includes CollaborativeProcessFlows, CPRoles, Rules, and Metrics.

A CollaborativeProcessFlow is a set of correlated Activities, Events and Decisions that represent collaboration between roles belonging to (autonomous) business entities. Each flow instance has the instance number and goes through Stages. Sequences are used if the specific order of executions is required.

An Activity is a task or an operation performed by a role. A role can be assigned to a federate (a person, or a system) or to a local SOA Federation agent. Each Activity has one or more inputs and it produces one or more outputs. Since an output of one Activity can be an input for another Activity, both inputs and outputs are modeled using the InputOutput entity. A Matrix is assigned to each Activity’s input and it controls the use of the input during the execution of the Activity.

A Decision is a specific activity in the CollaborativeProcessFlow that makes choices. Decisions are supplied with specific inputs called Criteria and possible outputs called Choices. While an Activity is expected to produce all its declared outputs, a Decision is expected to produce a subset of the Choices.

An Agent is an entity that performs an activity or makes a decision according to some predefined procedure or logic that may also include business Rules. A business Rule is a logic encapsulated as an expression with sets of Arguments defining a domain of interest for the rule.

When a role performing an Activity or a Decision is assigned to a person then the person can use an application running on a System or a Device or the person can directly perform an Activity or a Decision accessing the SOA Federation via the Portal interface.

Service Oriented Architecture Collaboration Semantics V0.1 1

Page 7: SOA Collaboration Semantics

Semantion Inc.

An Event represents a node (progression point in time) in a CollaborativeProcessFlow of a specific interest to participants. It represents that something happens during the CollaborativeProcessFlow. Events can trigger alerts or insertion of the business logic from another CollaborativeProcessFlow. Events can be organized into Clusters or combine to form compound Events. They progress through Stages in the life cycle whereby each Stage change has a meaning to the participants. Events can take place in the federated context or in each of the systems that are federated. A Trigger is a condition that creates an Event. It could be an output of an Activity, result of the execution of a Rule or a Metric reaching a value, or just the fact that another Event has happened. Triggers link Events with other elements in the collaborative process orchestration. An Action is a consequence of an Event taking place. It can be an alert message, insertion of a flow, compensation within a flow, link to another flow or termination of a flow, or another trigger (flow trigger). One Event can have more Actions. Other collaborative process elements (Users, Organizations) can subscribe to or publish Events.

Each CollaborativeProcessFlow has a set of CPRoles that play in it. Each participant (User, Organization, Agent) in the collaboration is assigned to a CPRole. CPRoles perform Activities and Decisions.

A Metric is information that contains quantifiable value defining specific performance variables and their states during the collaboration.

The SOA Collaboration Semantics includes documents and/or Messages and MessageRequests flows. The content of the documents is referenced by InformationalReferences and ChoiceReferences while the content of Messages is referenced by the MessageContent. An AgentModelReference is a reference entity that represents a document containing an Agent model.

3.0 Collaboration Protocols

Collaboration protocols between the SOA Federation and federates can be handled either with ebXML Collaboration Protocol Profile and Agreement (CPPA), Web Services Choreography Description Language (WS-CDL) or Web Services Description Language (WSDL). The ebXML CPPA is recommended if more complete protocol specification with both technical and legal details is needed. Otherwise, either CPPA, WS-CDL or WSDL can be used. The SOA IM and the SOA CS do not have any dependences related to the selected protocols.

When CPPA is used, each participant (federate) has its own Collaboration Protocol Profile (CPP) and Collaboration Protocol Agreement (CPA) shared with the SOA Federation. CPA governs external collaboration referencing Collaborative Process Information Document (CPID), ebXML Business Process Specification Schema (BPSS) document and other specifications and documents needed to handle external collaboration between the federate and the SOA Federation. The SOA Federation has its own CPP and a separate CPA for each federate.

When WS-CDL or WSDL is used, each federate and the SOA Federation has its own WS-CDL or WSDL respectively and it specifies information needed for the collaboration.

4.0 Collaborative Process Information Document (CPID)

Each collaborative process has its own Collaborative Process Information Document (CPID) [SOAIM].

Service Oriented Architecture Collaboration Semantics V0.1 2

Page 8: SOA Collaboration Semantics

Semantion Inc.

CPID is an XML document that contains SOA IM for a collaborative process. It can be written in a standard registry language such as OASIS ebXML Registry or OASIS UDDI.

By using standard formats and meta-data as defined by SOA IM, CPID can be generated from a business process definition in a visual modeling tool. CPID contains a complete information model of a collaborative process. Submitting the content of this document to a standard registry will generate the collaborative process information model that together with SOA CS enables full open standard-based support for collaborative processes of any type and complexity.

The CPID processing is divided between the Federation Manager and the Flow Controller Manager. Each CPID deployed instance has a CPID document associated with the start event of the first started collaborative process flow included in the collaborative process represented by the CPID. The CPID instance is deployed for the first time when all required inputs needed for the start event of the first collaborative process flow are confirmed. At this point, the Federation Manager deploys the collaborative process and all its related entities except the collaborative process flows and their related entities. The collaborative process or the collaborative process flow related entities are the entities that are associated with the collaborative process or the collaborative process flow, respectively. The SOA IM document [SOAIM] contains all details needed to get the list of all collaborative process and collaborative process flow related entities. The Federation Manager deploys the collaborative process and all its related entities once. If the new CPID version is available and if it is not currently used, the Federation Manager will check if all collaborative process flows are finished and if it is the case it will re-deploy the collaborative process part of the CPID.

The Flow Controller Manager deploys the collaborative process flow when inputs for its start event’s trigger become available (confirmed). The Flow Controller Manager also deploys all entities related to the collaborative process flow. The SOA IM document [SOAIM] contains all details needed to get the list of all collaborative process flow related entities. If the new CPID version is available and if it is not currently used, the Flow Controller Manager will check if the collaborative process flow is finished and if it is the case it will re-deploy the collaborative process flow part of the CPID.

After an initial SOA Federation startup, two options can be used to handle inputs before the CPID documents are deployed. If one of these options is not implemented, the SOA Federation will not be able to handle CPID deployments and execution of collaborative (business) processes. Currently, the CPID and any other SOA document is represented using the ebXML Registry ExtrinsicObject meta-data. When the UDDI support becomes available it will be represented in the UDDI format as well. As an ExtrinsicObject, any SOA document has the contentLocator slot [EBRS] which value specifies a document’s location (URL) after the document is stored in the Federation Registry. The CPID document requires an additional attribute defined by the deployAtSystemStart slot. This attribute can have value Yes or No. The Yes value specifies that the entire CPID will be deployed as soon as the SOA Federation and the Gateway are started. The No value forces another option that associates each CPID with inputs that initiate it when they become available. These inputs belong to the triggers that create collaborative process flows’ start events. Every time when CPID document is stored in the repository (submitCPID) the Federation Manager will create, store and deploy another document referred as CPIDStartInfo that contains all start events, their inputs and informational references associated with the inputs. The Federation Manager also associates the CPIDStartInfo document with the CPID using the IsCPIDStartInfoFor association type. When all inputs for any of the start events are confirmed, the CPID will be deployed. It means that the Federation Manager will deploy (deployCPID) all collaborative process related entities and after that send a message (sendMessage) to the Flow Controller Manager to deploy (deployCPID) a collaborative process flow(s) and all its related collaborative entities. The already deployed inputs and start events, that caused the CPID to be deployed, will be re-used.

Collaborative entities can be added to the CPID, removed from it or be updated. There are two possible ways to do this:

Update the current CPID, register its new version and re-deploy the entire CPID or its part(s) when conditions are met.

Service Oriented Architecture Collaboration Semantics V0.1 3

Page 9: SOA Collaboration Semantics

Semantion Inc.

Submit one or more new collaborative entities and/or modified collaborative entities to the Federation Manager (updateCPID) that will re-direct this request to the Federation Registry and/or the Flow Controller Manager for the entity submission in the Process Flow Registry. These entities must be submitted with the id of the CPID they belong to.

The first option should be applied when the collaborative process, related to the CPID, is not currently running. However, if the collaborative process is running and dynamic (run-time) change needs to be done, the second option should be used. With this run-time option, when the Federation Manager receives the request, based on the entity type it will submit the request to either the Federation Registry or the Flow Controller Manager for the entity submission to the Process Flow Registry.

Two rules can be applied when the CPID run-time changes take place:

If the CPID change contains collaborative entities without bindings to the outside changeable information (e.g., Cluster, CPRole, etc.), the CPID change can be executed immediately.

If the CPID change contains collaborative entities with bindings to the outside changeable information which content can be dynamically created or modified during the collaboration, the change will not be deployed if the affected collaborative entity is currently active. For example, if an action instance is currently running, the action and any entity related to it cannot be modified.

5.0 Communication Between the Gateway and the Federation Manager

The Gateway and the Federation Manager can all run on the same machine or they can be distributed on as many machines as needed to support high load requirements when many federates communicate with SOA Federation during the execution of collaborative processes.

SOAP XML-based messaging communication [SOAP] must be supported at least. It provides an open communications interface so that the components developed from different vendors can communicate without any additional communication interface requirements. The Web Services Interoperability (WS-I) profiles [WSI] provide implementation guidelines for how related Web Services specifications should be used together for best interoperability.

SOAP is an appropriate communication solution between the distributed components but for the components running on the same machine SOAP can create a communicational overhead. To be able to maximize communication interoperability and performance between the SOA Federation components and between the Gateway and the Federation Manager, this specification specifies:

Protocols with XML-based requests and responses and Interfaces with methods

so that the both ways of the communication can be standardized in the most efficient way enabled with today’s standards and technologies.

6.0 Gateway Interface

The Gateway Interface defines a communication between the Gateway and the Federation Manager.

Service Oriented Architecture Collaboration Semantics V0.1 4

Page 10: SOA Collaboration Semantics

Semantion Inc.

The Gateway has a role of the external collaborative engine. It provides external collaborations between the SOA Federation and federates. Two types of collaborative engines are supported: ebXML Collaborative Engine and Web Services Collaborative Engine. This specification references the following already available standard specifications for the two types of the collaborative engines:

ebXML Collaborative Engineo OASIS ebXML Business Process Specification Scheme (BPSS) [EBBPSS]o OASIS ebXML Collaboration Protocol Profile and Agreement (CPPA) [EBCPPA]

Web Services Collaborative Engineo W3C Web Services Choreography (WS-Choreography) [WSCHOR]o OASIS Web Services Business Process Execution Language (WSBPEL) [WSBPEL]o W3C Web Services Choreography Description Language (WS-CDL) [WSCDL]o W3C Web Services Description Language (WSDL) [WSDL]o W3C XML Schema Definition (XSD) [XSD]

The Gateway interface specifies interactions between the collaborative engine and the Federation Manager. These interactions are requests, responses and business documents sent to and received from the Federation Manager. Any message exchange between the Gateway and the Federation Manager contains:

A request or a response An optional one or more business documents

The following request types and response types are supported:

ebXML Registry UDDI Other requests and responses defined in this specification also needed to support execution of

collaborative processes.

Any format of business documents attached to the messages is supported.

SOAP is the main protocol for exchanging messages with requests/responses and attached documents between the Gateway and the Federation Manager. If the Gateway and the Federation Manager are distributed over an unsecured network, SOAP should be extended with WS-Security and WS-Reliability or ebXML Messaging can be used instead.

If both the Gateway and the Federation Manager are running on the same machine, instead of communicating with the Federation Manager via SOAP, the Gateway can use the Federation Manager Interface and its methods to support information exchanges. This API-based approach in the inter-process communication between the Gateway and the Federation Manager running on the same machine will increase communication performance between them. Ideally, both ways of communication should be supported at least.

7.0 Portal Interface

The Portal interface enables people to communicate with SOA Federation via either personal computers and/or handheld wireless devices. HTTP, HTTPS, and SOAP are protocols for communications with the Portal interface.

Service Oriented Architecture Collaboration Semantics V0.1 5

Page 11: SOA Collaboration Semantics

Semantion Inc.

The most common portal forms needed for submissions and retrievals of federates’ and collaborative processes’ information are defined. All these forms must provide SOA IM [SOAIM] based information creation, access and modifications. It means that all information entered or retrieved via these forms must be supported by SOA IM. This requirement guaranties portability for Portal forms defined in this document. The SOA Federation Portal interface implementations can also add as many other forms as needed to support broader SOA Federation Portal interface if needed.

Different access levels should be defined for each form. An SOA Federation administrator have full access to all forms while federates have access to specific forms and their sections. For example, a person responsible for a federate should be able to enter and view information about the federate only. An additional privilege enabling the person to view profiles of other federates in the same community of interest may be granted as well.

The following sections specify form sets that support four key SOA Federation Portal interface activities:

Creation of federates’ profiles Collaborative processes publishing, deployment and update Monitoring and reporting SOA Federation administration

Each form set can include any number of forms needed to provide support for the form set’s functional requirements specified.

7.1. Profile

The Profile form set is used to:

Register federates and enter federates security information Query federates information Submit and retrieve documents

Federates are participants that perform activities and make decisions during the collaborative process execution. They can be people and/or systems. Systems can be simple as a basic web service or they can be complex SOA systems with many federates and a sophisticated SOA Federation. Both standard-based and proprietary systems are supported as long as they are able to communicate via SOA communication protocols through the Gateway interface.

This form can also be used to enter security information (e.g., username/password, digital certificate, etc.) required for a federate to communicate with the SOA Federation.

7.2 Collaborative Process

The Collaborative Process form set is used to:

Publish CPID Update CPID Deploy CPID elements in real-time during the collaborative process execution Update CPID elements in real-time during the collaborative process execution View details of collaborative process elements Query any collaborative process element or set of elements Submit and retrieve documents

Service Oriented Architecture Collaboration Semantics V0.1 6

Page 12: SOA Collaboration Semantics

Semantion Inc.

As listed features suggest, this form set supports the collaborative process information management.

7.3 Monitoring and Reporting

The Monitoring and Reporting form set enables the SOA Federation monitoring and reporting. The SOA Federation monitoring and reporting can be very broad but the following monitoring and reporting features should be supported at least:

Collaborative processes and all their related entities statuses Performance monitoring

The SOA Federation hardware platform(s) monitoring (memory, CPU, I/O) The Federation Registry and the Process Flow Registry database monitoring Network monitoring

Collaborative processes report Escalated collaborative elements report Collaborative patterns report Problem reports

The SOA Federation performance monitoring can use third party tools specialized in hardware, network, and database monitoring.

7.4 SOA Federation Administration

The SOA Federation Administration form set provides an administration interface required for basic SOA Federation administrative tasks such as:

SOA Federation Configuration SOA Federation startup SOA Federation components startup (Federation Manager, Federation Registry, Flow Controller

Manager, etc.) SOA Federation shutdown SOA Federation components shutdown Federation Registry and Process Flow Registry backup SOA Federation backup Federation Registry and Process Flow Registry restore and recovery SOA Federation restore and recovery

Third party tools for backup, restore and recovery can be used. The SOA Federation configuration provides support for the overall SOA Federation and also SOA Federation components configuration. Some parts of the configuration can be implementation specific.

8.0 Federation Registry and Process Flow Registry

The Federation Registry stores, version-controls, queries and maintains collaborative meta-data and content that include collaborative participants (federates) profiles, gateway profile, security profiles, business process specifications, collaborative documents, business artifacts and web services information.

Service Oriented Architecture Collaboration Semantics V0.1 7

Page 13: SOA Collaboration Semantics

Semantion Inc.

The Process Flow Registry manages all collaborative process flow informational entities: CollaborativeProcessFlow, Activity, Decision, Event, InputOutput, etc.. These entities, explained in [SOAIM], can also be stored and managed in the Federation Registry in which case the implementation of the Process Flow Registry is not needed.

Either ebXML Registry [EBRIM,EBRS] or UDDI [UDDI] can be used as a Federation Registry. The current release of the SOA IM and SOA CS specifications formalizes the use of the ebXML Registry. SOA IM and SOA CS are completely neutral specifications that do not depend on a language (ebXML Registry or UDDI and/or any other) used to formalize and implement their format.

9.0 Federation Manager Protocol and Interface

The Federation Manager is a central coordinator between federates and the SOA Federation. The Federation Manager

Manages all requests and responses from and to the federates. Uses Security Provider services to perform all needed security authentications and authorizations. Manages and queries meta-data and content stored in the Federation Registry and Process Flow

Registry. Communicates with and provides necessary information for the Agent Interface Manager that

manages the interface with the Agent Framework. Communicates with and provides necessary information for the Flow Controller Manager that

together with the Activity Manager, the Decision Manager and the Event Manager provides full collaborative process flow support.

The Federation Manager receives and sends XML messages and attached business documents if they are sent along with the messages. The Federation Manager can receive or send two types of messages:

Standard Non-standard

The standard message types are:

Registry Requesto Federation Registry Request with attachment(s)o Federation Registry Request without attachment(s)o Process Flow Registry Request

Registry Responseo Federation Registry Response with attachment(s)o Federation Registry Response without attachment(s)o Process Flow Registry Response

Agent Interface Request Agent Interface Response Flow Controller Request Flow Controller Response Security Request Security Response MessageRequest

The message with a Federation Registry request contains either an ebXML Registry request or a UDDI request. This message is with or without attached documents. If one or more documents are attached they

Service Oriented Architecture Collaboration Semantics V0.1 8

Page 14: SOA Collaboration Semantics

Semantion Inc.

are stored (submitDocument) in the Federation Registry. When these documents are stored, the Federation Manager verifies if there are any informational references (findInfoReferenceByType) with the type of the documents received. If it is the case, the Federation Manager updates the value attribute (setReference) of the associated informational references with the URLs of the received documents. As soon as the value attribute gets the assigned value, the Federation Manager sends a notification (informationalReferenceConfirmed) to the Flow Controller Manager that the informational reference is confirmed and available. When a document content is later needed, it will be accessed (getContent) via the HTTP binding using the URL assigned to the informational reference value attribute.

The message with a Federation Registry response contains either an ebXML Registry response or a UDDI response. This message can come with or without attached documents.

The message with a Process Flow Registry request contains either an ebXML Registry request or a UDDI request.

The message with a Process Flow Registry response contains either an ebXML Registry response or a UDDI response.

The message with an Agent Interface request or response contains information needed for communication between the Federation Manager and the Agent Interface Manager.

The message with a Flow Controller request or response contains information needed for communication between the Federation Manager and the Flow Controller Manager.

The message with a security request contains a Security Provider request. The Federation Manager uses these messages to provide security information needed for the Security Provider to perform authentication and authorization tasks.

The message with a security response contains a Security Provider response.

The message with a MessageRequest type belongs to the MessageRequest SOA IM entity that represents any pre-defined message request used during the collaborations. When the Federation Manager receives this message type (getMessageType), it will retrieve the request type from the message (getMessageRequestType) to find out what message request needs to be served and send a notification to the Flow Controller Manager to coordinate further execution with either the Event Manager, the Activity Manager or the Decision Manager depending on the collaborative entity that needs to be executed (event, activity, or decision) based on its association with the received message request.

The non-standard message types are message types supported by federates. The non-standard message types are any message types used in the message exchanges between the federates and the SOA Federation that do not belong to the standard message types previously defined.

The communication auditing (auditCommunication) between the Federation Manager and the Security Provider is mandatory. The auditing of communications between the Federation Manager and other SOA Federation managers or the Federation Manager and the Gateway is optional.

Each federate needs to be registered (registerFederate) and its collaboration profile submitted to the Federation Registry (submitCollaborationProfile) before it starts its participation in a collaborative process.

9.1 Federation Manager Methods

Service Oriented Architecture Collaboration Semantics V0.1 9

Page 15: SOA Collaboration Semantics

Semantion Inc.

This section explains the Federation Manager methods. Each Federation Manager method returns a Federation Manager response defined in the Federation Manager XML Schema document [FMXMLS].

9.1.1 auditCommunication

The auditCommunication audits a communication between the Federation Manager and another SOA Federation manager or between the Federation Manager and the Gateway. The auditing of the communication between the Federation Manager and the Security Provider is mandatory.

Argument Description Data Type Requiredaudit This argument provides an

XML form of an audit that will be created.

String Yes

9.1.2 authenticateSubject

The authenticateSubject authenticates the source of the request. A subject can be a person or a service. This method submits the subject with its credentials (e.g., username/password pair or a digital certificate) to the Security Provider for the authentication.

Argument Description Data Type Requiredsubject Subject’s identity and its

security related attributes (e.g., password or digital certificate).

Subject Yes

9.1.3 contentTransformation

The contentTransformation transforms an XML document to another format.

Argument Description Data Type Requiredid An id of a document. String256 YesfromFormat A format which document

will be transformed from. If the document’s format is known from its content, this argument is not mandatory.

String256 Yes

toFormat A format which document will be transformed to. This argument is not mandatory if the rule argument is provided.

String256 Yes

rule A reference to a rule if the rule is used to transform the format of the document.

String256 No

Service Oriented Architecture Collaboration Semantics V0.1 10

Page 16: SOA Collaboration Semantics

Semantion Inc.

9.1.4 contentValidation

The contentValidation validates the content of an XML document.

Argument Description Data Type Requiredid A document id. String256 Yesrule A reference to a rule if the

rule is used to validate the document format.

String256 No

9.1.5 createAssociation

The createAssociation creates an association between the two collaborative entities. The types of associations between collaborative entities are defined in [SOAIM].

Argument Description Data Type Requiredassociation This argument provides an

XML form of the Association that will be created with all required elements and attributes.

String Yes

9.1.6 createVersion

The createVersion creates new version of the specified document.

Argument Description Data Type Requiredid A document id. String256 Yesversion New document version. If

this argument is not specified, the next default version value will be generated.

String8 No

9.1.7 delegateAgent

The delegateAgent creates an SOA IM Agent entity and all other related entities and associations specified. The agent entities are: Agent, Arguments, ModelReference, Protocol, and Rule. All of them are defined in [SOAIM].

Argument Description Data Type RequireddelegateAgent This argument provides an

XML form of the delegateAgent request.

String Yes

Service Oriented Architecture Collaboration Semantics V0.1 11

Page 17: SOA Collaboration Semantics

Semantion Inc.

9.1.8 deployCPID

The deployCPID deploys the CPID part related to the collaborative process in the Process Flow Registry. As soon as the CPID is deployed the collaborative process execution can start.

Argument Description Data Type Requiredcpid This argument provides an id

of a CPID that will be deployed.

String256 Yes

version This argument provides a CPID version that will be used to deploy the CPID. If the value for this argument is not specified, the latest CPID version will be used.

String256 No

9.1.9 findInitiatorByCPFlow

The findInitiatorByCPFlow returns an initiator for a collaborative process flow. The initiator is a federate that provides an input or inputs that will cause the start event of the collaborative process flow to be created.

Argument Description Data Type RequiredcollaborativeProcessFlow The id of a collaborative

process flow which initiator will be returned.

String256 Yes

9.1.10 findInfoReferenceByType

The findInfoReferenceByType returns all informational references with a specified type

Argument Description Data Type Requiredtype The type of the informational

reference.String256 Yes

9.1.11 findProfileByFederate

The findProfileByFederate returns a federate’s profile. The profile is created of all federate related entities stored in the Federation Registry.

Argument Description Data Type Requiredfederate The id of a federate which

profile will be returned. String256 Yes

Service Oriented Architecture Collaboration Semantics V0.1 12

Page 18: SOA Collaboration Semantics

Semantion Inc.

9.1.12 findProtocolByAgent

The findProtocolByAgent returns a protocol associated with an agent.

Argument Description Data Type Requiredagent This argument provides an id

of an SOA IM Agent entity which protocol will be retrieved.

String256 Yes

9.1.13 getContent

The getContent returns the content of an XML document.

Argument Description Data Type Requiredid A document id. String256 Yes

9.1.14 getContentElement

The getContentElement returns the value of an XML document element.

Argument Description Data Type Requiredid A document id. String256 Yeselement An XML element String256 Yes

9.1.15 getContentElementAttribute

The getContentElementAttribute returns the value of an XML document element’s attribute.

Argument Description Data Type Requiredid A document id. String256 Yeselement An XML element. String256 Yesattribute An XML element’s attribute String256 Yes

9.1.16 getFederate

The getFederate returns a federate. The federate can be a person or a system.

Argument Description Data Type Requiredfederate The id of the federate which

will be returned. String256 Yes

Service Oriented Architecture Collaboration Semantics V0.1 13

Page 19: SOA Collaboration Semantics

Semantion Inc.

9.1.17 getMessageRequestType

The getMessageRequestType returns the type of a message request.

Argument Description Data Type RequiredmessageRequest The content of the XML

message request.String Yes

9.1.18 getMessageType

The getMessageType returns the type of a message.

Argument Description Data Type Requiredmessage The content of an XML

message.String Yes

9.1.19 registerFederate

Federates can be people or systems. The registerFederate registers information about a federate. If the federate is an initiator for a collaborative process the CPID must be associated with it. The federate belongs to either the SOA IM System or User entity. The User’s contact information like telephone numbers and email addresses can also be included in the federate argument.

Argument Description Data Type Requiredfederate A federate related

informational details in an XML form.

String Yes

9.1.20 removeObjects

The removeObjects removes a list of objects from the Federation Registry. If the Federation Registry and the Process Flow Registry are separate registries, a RemoveObjects request with a list of objects that belong to the Process Flow Registry will be submitted to the Flow Controller Manager.

Argument Description Data Type Requiredrequest An XML request that

contains a list of SOA IM objects’ ids that will be removed from the Federation Registry and/or the Process Flow Registry.

String Yes

9.1.21 sendMail

Service Oriented Architecture Collaboration Semantics V0.1 14

Page 20: SOA Collaboration Semantics

Semantion Inc.

The sendMail sends an email note to a Federate.

Argument Description Data Type RequiredaddressList A list of email addresses

which the note will be sent to.String256 Yes

subject An email note’s subject. String256 Yesnote The content of the note String Yes

9.1.22 sendMessage

The sendMessage sends a message to other SOA Federation managers and components: The Flow Controller Manager, the Agent Interface Manager, the Federation Registry, the Security Provider, or the Gateway interface.

Argument Description Data Type Requiredmessage An XML-based message. String Yesdestination A destination which this

message will be sent to (the Flow Controller Manager, the Agent Interface Manager, the Federation Registry, the Security Provider, or the Gateway interface).

String256 Yes

9.1.23 setReference

The setReference sets the value attribute of the informational reference.

Argument Description Data Type Requiredid The id of the informational

reference.String256 Yes

value A URL value (document’s reference)

String256 Yes

9.1.24 subjectAuthorized

The subjectAuthorized checks if the already authenticated subject is authorized for the submitted request.

Argument Description Data Type Requiredid Subject’s identity (principal). String256 Yesrequest An XML request. String Yes

9.1.25 submitCollaborationProfile

Service Oriented Architecture Collaboration Semantics V0.1 15

Page 21: SOA Collaboration Semantics

Semantion Inc.

The submitCollaborationProfile submits a collaboration profile to the Federation Registry. The profile belongs to a federate that is a system.

Argument Description Data Type Requiredprofile The id of the collaboration

profile.String256 Yes

content An XML content of the profile. CPPA, WSDL and WS-CDL are examples of collaboration profiles that are supported.

String Yes

9.1.26 submitCPID

The submitCPID stores CPID and CPIDStartInfo document in the Federation Registry.

Argument Description Data Type Requiredcontent The CPID or the

CPIDStartInfo XML content.String Yes

type The type of the document (CPID or CPIDStartInfo).

String256 Yes

9.1.27 submitDocument

The submitDocument stores business document in the repository and sets up its content locator with a value that represents a URL needed to reference the document.

Argument Description Data Type Requireddocument A document’s content in any

digital format.Content Yes

9.1.28 submitObjects

The submitObjects submits a list of objects to the Federation Registry. If the Federation Registry and the Process Flow Registry are separate registries, a SubmitObjects request with a list of objects that belong to the Process Flow Registry will be submitted to the Flow Controller Manager.

Argument Description Data Type Requiredrequest An XML request that

contains SOA IM objects that will be submitted to the Federation Registry and/or the Process Flow Registry.

String Yes

Service Oriented Architecture Collaboration Semantics V0.1 16

Page 22: SOA Collaboration Semantics

Semantion Inc.

9.1.29 submitQuery

The submitQuery submits a query to the Federation Registry. If the Federation Registry and the Process Flow Registry are separate registries, a SubmitQuery request that belongs to the Process Flow Registry will be submitted to the Flow Controller Manager.

Argument Description Data Type Requiredrequest An XML query request that

belongs to the Federation Registry and/or the Process Flow Registry.

String Yes

9.1.30 updateAgentDelegation

The updateAgentDelegation updates an agent delegation in the Federation Registry. If the provided entities already exist they will be updated. Otherwise, they will be created in the registry with the agent related associations explained in [SOAIM]. If the agent related entities belong to the Process Flow Registry, an UpdateAgentDelegation request that contains the Process Flow Registry related entities will be submitted to the Flow Controller Manager.

Argument Description Data Type RequiredagentEntities A list of agent related entities

in an XML form.String Yes

9.1.31 updateCPID

The updateCPID updates the specified CPID. If the updateRequest argument contains Federation Registry related collaborative entities only, these entities will be deployed/re-deployed in the Federation Registry. The CPID content will also be updated and versioned. If the updateRequest argument also contains the Process Flow Registry related collaborative entities (e.g., Activity, Decision, etc.), a message with the updateCPID request that contains the Process Flow Registry related entities only will be sent to the Flow Controller Manager to process the request and deploy/re-deploy the entities in the Process Flow Registry. The update CPID processing logic is explained in Section 4.0.

Argument Description Data Type Requiredcpid This argument provides the id

of the CPID that will be updated.

String256 Yes

updateRequest This argument provides an XML request that contains all new and/or modified collaborative entities that will be submitted.

String Yes

9.1.32 updateObjects

Service Oriented Architecture Collaboration Semantics V0.1 17

Page 23: SOA Collaboration Semantics

Semantion Inc.

The updateObjects updates a list of objects in the Federation Registry. If the Federation Registry and the Process Flow Registry are separate registries, an UpdateObjects request with a list of objects that belong to the Process Flow Registry will be submitted to the Flow Controller Manager.

Argument Description Data Type Requiredrequest An XML request that

contains a list of SOA IM objects that will be updated in the Federation Registry and/or the Process Flow Registry.

String Yes

10.0 Agent Interface Manager

The Agent Interface Manager manages agents’ related information and the interface with the Agent Framework. It directly communicates with the Federation Manager and the Agent Framework.

The agent delegation (delegateAgent) creates all SOA IM agent entities. These entities include:

Agent Arguments ModelReference Protocol Rule

[SOAIM] contains details about all these entities.

The interface with the Agent Framework includes:

Agent invocation (invokeAgent) Agent monitoring (monitorAgent) and Agent escalation (escalateAgent)

The Agent Interface Manager never communicates directly with agents. All communications are performed via the Agent Framework.

The agent invocation sends an agent request to the Agent Framework. The agent request includes the following SOA IM entities:

Agent Rule associated with the agent Arguments that are referenced in the rule or used as agent’s inputs

The agent can have more than one rule associated with it. The agent’s universal identifier, all arguments with values, and optionally rule’s universal identifier and rule’s content are included in the request.

When the Agent Interface Manager receives an agent request from the Federation Manager, it first retrieves a protocol (findProtocolByAgent) for communication with the agent (e.g., WSDL, CPA, etc.). The Agent Interface Manager uses the content of the protocol to communicate with the Agent Framework. It sends a message with the agent request (invokeAgent) to the Agent Framework. When the Agent Framework

Service Oriented Architecture Collaboration Semantics V0.1 18

Page 24: SOA Collaboration Semantics

Semantion Inc.

receives a response from the agent, it sends a message with the agent response to the Agent Interface Manager which sends the message to the Federation Manager.

The agent monitoring service and the agent escalation service monitor local SOA Federation agents and perform escalations when agents are not available. The agent monitoring send a request to the Agent Framework to start a monitoring on a specified agent. The agent escalation sends an alert message to the Federation Manager when the agent is not available. If the alert belongs to the agent supporting the SOA Federation the alert message will be sent to the SOA Federation administrators. If the alert message belongs to the agent that process an activity or a decision or a trigger included in a collaborative process executing on the SOA Federation, the alert will be sent to an individual(s) and/or an organization(s) responsible for the agent.

10.1 Agent Interface Manager Methods

This section explains the Agent Interface Manager methods. Each Agent Interface Manager method returns an Agent Interface Manager response defined in the Agent Interface Manager XML Schema document [AIMXMLS].

10.1.1 createAssociation

The createAssociation creates an association between the two collaborative entities. The types of associations between collaborative entities are defined in [SOAIM].

Argument Description Data Type Requiredassociation This argument provides an

XML form of the Association that will be created with all required elements and attributes.

String Yes

10.1.2 delegateAgent

The delegateAgent sends a message to the Federation Manager with a request to create an SOA IM Agent entity and all other related entities and associations specified. The agent entities are: Agent, Arguments, ModelReference, Protocol, and Rule. All these entities are defined in [SOAIM]. This method can be called as many times as needed to provide all required agent information.

Argument Description Data Type RequireddelegateAgent This argument provides an

XML form of the delegateAgent request.

String Yes

10.1.3 escalateAgent

Service Oriented Architecture Collaboration Semantics V0.1 19

Page 25: SOA Collaboration Semantics

Semantion Inc.

The escalateAgent sends a message to the Federation Manager with an alert for an individual(s) responsible for the agent execution. The agent escalation takes place when the Agent Framework reports that the agent is unavailable or when the Agent Interface Manager cannot communicate with the Agent Framework in which case the individuals responsible for execution of all agents in the agent framework will be alerted.

Argument Description Data Type Requiredagent The id of an agent that is not

available.String256 Yes

10.1.4 findProtocolByAgent

The findProtocolByAgent returns a protocol associated with an agent.

Argument Description Data Type Requiredagent This argument provides an id

of the SOA IM Agent entity which protocol will be retrieved.

String256 Yes

10.1.5 invokeAgent

The invokeAgent sends a message with an agent request to the Agent Framework.

Argument Description Data Type RequiredagentRequest This argument provides an

XML form of the agent request.

String Yes

protocol This argument provides an XML form of a protocol for the communication with the Agent Framework.

String Yes

10.1.6 monitorAgent

The monitorAgent sends a request to the Agent Framework to start the monitoring of agents. If a polling period is specified, the Agent Interface Manager will send an agent status request to the Agent Framework after each period of time specified by the pollingPeriod.

Argument Description Data Type RequiredagentList This argument provides a list

of ids for agents that will be monitored.

Set Yes

pollingPeriod A period of time for which String256 No

Service Oriented Architecture Collaboration Semantics V0.1 20

Page 26: SOA Collaboration Semantics

Semantion Inc.

the status of the agent will be requested from the Agent Framework. If the value for this attribute is not provided the polling period is unlimited. The value for this attribute is specified using the XSD duration format (e.g., PT1H means one hour, PT1M one minute or P1D one day).

10.1.7 removeObjects

The removeObjects sends a message with a RemoveObjects request to the Federation Manager.

Argument Description Data Type Requiredrequest An XML request that

contains a list of SOA IM objects’ ids that will be removed from the Federation Registry and/or the Process Flow Registry.

String Yes

10.1.8 sendMessage

The sendMessage sends a message to the Federation Manager or the Agent Framework.

Argument Description Data Type Requiredmessage An XML-based message. String Yesdestination A destination which this

message will be sent to.String256 Yes

10.1.9 submitObjects

The submitObjects sends a message with a SubmitObjects request to the Federation Manager.

Argument Description Data Type Requiredrequest A SubmitObjects request that

will be submitted to the Federation Manger.

String Yes

10.1.10 submitQuery

The submitQuery sends a message with a SubmitQuery request to the Federation Manager.

Service Oriented Architecture Collaboration Semantics V0.1 21

Page 27: SOA Collaboration Semantics

Semantion Inc.

Argument Description Data Type Requiredrequest An XML-based query request

that will be submitted to the Federation Manager

String Yes

10.1.11 updateAgentDelegation

The updateAgentDelegation sends a message with an UpdateAgentDelegation request to the Federation Manager.

Argument Description Data Type RequiredagentEntities A list of agent related entities

in an XML form.String Yes

10.1.12 updateObjects

The updateObjects sends a message with an UpdateObjects request to the Federation Manager.

Argument Description Data Type Requiredrequest An UpdateObjects request

that will be submitted to the Federation Manager.

String Yes

11.0 Flow Controller Manager Protocol and Interface

The Flow Controller Manager manages collaborative process flows and availability of inputs, outputs, criteria and choices for collaborative processes’ activities, decisions, and events’ triggers.

Each activity or a decision or a trigger can have one or more inputs. Formally, a decision’s input is referred to as criteria.

Different combinations of inputs can be required. An activity or a decision or a trigger cannot start before some of them or all of them are confirmed available. The combination of inputs needed to start an activity or a decision or to trigger an event is specified by the SOA IM Matrix entity. Some inputs related to business documents may have more than one version.

In some collaborative processes, activities, decisions and events can be executed in specific orders defined by the SOA IM Sequence entity. A predecessor collaborative entity if needed and a successor collaborative entity if needed are defined for each collaborative entity.

A collaborative process can have four possible collaborative process flow combinations related to the collaborative process flows’ Start stage:

Only one collaborative process flow initially starts More than one collaborative process flow can initially start at the same time

Service Oriented Architecture Collaboration Semantics V0.1 22

Page 28: SOA Collaboration Semantics

Semantion Inc.

One collaborative process flow calls (starts) another collaborative process flow One or more start events from different collaborative process flows can be clustered with other

events and the cluster specifies when the collaborative process flow(s) will start initially.

The new collaborative process flow instance cannot start until the current collaborative process flow instance is finished.

Each collaborative process flow has an initiator (findInitiatorByCPFlow). It is a federate that provides an input or inputs that will cause the start event of the first instance of the initial collaborative process flow to be created. When this input or inputs are received, their originator (federate) will be known at that time.

The federates that are the initiators will also have a CPID associated with them using the “IsCPIDOf” association type. At this point, the Federation Manager deploys the collaborative process part of the CPID and also sends a message to the Flow Controller Manager to deploy the collaborative process flow part of the CPID that is associated with the originator. Only the collaborative process flows associated with the available inputs will be deployed. The latest version of the CPID is deployed by default. Using the version argument in the deployCPID, a specific version of the CPID can be deployed as well. The CPID meta-data is formatted by the ebXML Registry. A CPID document is represented by the ebXML Registry ExtrinsicObject. Only the administrator that registered the CPID can change the CPID. The administrator can also grant the CPID modification privileges to another administrator as well.

At the same time the CPID will get associated with the initial collaborative process flow’s start event with the association type “IsCPIDfor”. When another input of the same type is received and if it belongs to the initiator that previously sent the input of the same type (the start event is already associated with the CPID), the CPID will not be redeployed and the current CPID deployment will be used if the same CPID version is referenced.

After the CPID deployment, when an input or inputs are received, the Federation Manager will confirm these inputs by assigning input documents’ URLs to the value attribute of the SOA IM InformationalReference entities (setReference) related to the inputs. When an input or inputs are confirmed, the Federation Manager will send a message (sendMessage) to the Flow Controller Manager about the inputs with confirmed references. The Flow Controller Manager will call the findByInput method to retrieve all activities, decisions and triggers which this input is related to. Based on associations between matrix and inputs/criteria, the Flow Controller Manager will call findMatrix for each corresponding activity or a decision or a trigger to find out what types of inputs are required. Based on that information the Flow Controller Manager will send a message to the Activity Manager or the Decision Manager or the Event Manager to start the activity or the decision or fire the event’s trigger respectively if all needed inputs are available. If inputs or criteria are versioned, the Flow Controller Manager will keep a list of all versioned inputs and criteria and their collaborative entities (activities, decisions and events). When the specific version of an input is needed, it will be retrieved from the list and used in the collaborative process execution.

For any activity or a decision, three types of inputs are available:

Non-versioned inputs Versioned inputs Multi-instance inputs

The non-version inputs are inputs that have a single version all the time. There are no any special considerations regarding the processing of collaborative entities related to these inputs.

For versioned inputs, when more than one version of an input is received, the following options are available:

If none of the outputs are confirmed, an activity or a decision will be stopped and a stage with value End and the endCause attribute value Compensation will be created and associated with the

Service Oriented Architecture Collaboration Semantics V0.1 23

Page 29: SOA Collaboration Semantics

Semantion Inc.

activity or the decision. The new instance of the activity or the decision will be created. The new version of the input will be taken and a stage with value Start will be created and associated with the activity or the decision. The ActiveInputs entity will be created and associated with the new activity instance using the IsActiveInputsOf association type. The new version of the input will be associated with the ActiveInputs entity using the IsInputIn association type.

If some outputs are already created, the current activity instance or the current decision instance will continue its processing. The new activity instance or the new decision instance will be created with all related collaborative entities. A stage with value Start will be created and associated with the new activity instance or the new decision instance. An ActiveInputs entity will be created as well and the new version of the input will be associated with it. The ActiveInputs will be associated with the Activity or the Decision instance. All new versions of the input will be associated with this ActiveInputs until a condition to start new activity instance or new decision instance is met.

An input for an activity or a decision can have more than one instance. For example, an activity can receive more instances of the same input. When an input is multi-instance, the iType attribute of the SOA IM Matrix entity, that belongs to the input, has value Multiple. If the activity or the decision currently have more than one instance, the new instance of the input will be added to the ActiveInputs of the oldest activity or decision instance. The oldest activity or decision instance is the instance that started first. If the iType attribute value is Single, the new activity or the new decision instance will start and a stage with value Start will be created and associated with the new instance. An ActiveInputs entity will also be created and the new input instance associated with it using the IsInputIn association type.

A multi-instance inputs are supported for the collaborative process flow start event’s information type triggers as well. Every new instance of the input will create the trigger that will cause the creation of the related collaborative process flow instance if the collaborative process flow instance is not currently running. However, if the collaborative process flow instance is already running it will not be interrupted and the input’s instance will be provided for any other collaborative entity that needs it in the current collaborative process flow instance.

As soon as all collaborative entities related to the confirmed inputs and criteria are started, the Flow Controller Manager will immediately reset references (resetReference) for these inputs. For example, let us assume that that all inputs for an activity A are available. The Flow Controller Manager will send a message to the Activity Manager to start the activity A. The message will contain the StartCollaborativeEntity request with the activity’s ID as the request’s attribute. For example,

<StartCollaborativeEntity id= “urn:uuid:57c8f4f9-09dc-11da-9de0-000cf1cda5c6” >

When any of the inputs become available, the Flow Controller Manager also

Updates metrics associated with any of the elements contained in the input documents Checks the availability of all arguments (checkArguments) used in the rules associated with triggers

As soon as all rule’s arguments become available, the Flow Controller Manager uses:

Rule’s id to retrieve the rule content (getRuleContent) from the Federation Registry Arguments’ ids to retrieve arguments’ values (getArgumentValue) from the Process Flow

Registry

Based on this information the Flow Controller Manager creates an agent request that contains all required inputs for the agent. The Flow Controller Manager then sends a message that contains the agent request to the Federation Manager. If the agent is running on a federate, the Federation Manager will communicate with the agent via the Gateway Collaborative Engine using the protocol associated with the agent (findProtocolByAgent) and the rule and arguments specified in the request. For locally running agents, the Federation Manager sends a message with the agent request to the Agent Interface Manager that directly

Service Oriented Architecture Collaboration Semantics V0.1 24

Page 30: SOA Collaboration Semantics

Semantion Inc.

communicates with the Agent Framework using the protocol associated with the agent (findProtocolByAgent). The standard protocol should be used and it may be the Web Services Description Language (WSDL), or Web Services Choreography Description Language (WS-CDL), or ebXML Collaborative Protocol Profile and Agreement (CPPA). After receiving a confirmation and a result (agent response) from either the federate or the Agent Interface Manager, that the execution of the rule associated with the trigger has been completed, the Federation Manager will send a message with the agent response to the Flow Controller Manager. The agent response contains the agent’s id, the rule’s id if the rule is used, and the resulted value.

When a sequence is associated with either an activity or a decision or an event’s action, its successor (getSuccessor) will be the next collaborative entity to be executed if all its inputs are available.

11.1 Flow Controller Manager Methods

This section explains the Flow Controller Manager methods. Each Flow Controller Manager method returns a Flow Controller Manager response defined in the Flow Controller Manager XML Schema document [FMXMLS].

11.1.1 checkArguments

The checkArguments checks if all arguments associated with a specified rule are available.

Argument Description Data Type Requiredrule This argument provides an id

of the SOA IM Rule entity which arguments will be retrieved.

String256 Yes

11.1.2 createAssociation

The createAssociation creates an association between the two collaborative entities. The types of associations between collaborative entities are defined in [SOAIM].

Argument Description Data Type Requiredassociation This argument provides an

XML form of the Association that will be created with all required elements and attributes.

String Yes

11.1.3 createStage

The createStage creates a Stage entity for a collaborative process flow.

Service Oriented Architecture Collaboration Semantics V0.1 25

Page 31: SOA Collaboration Semantics

Semantion Inc.

The value attribute of the Stage entity can have the following values:

Start, Progress, Escalated, or End

Each Stage SOA IM entity has the startTime and the endTime attribute. The startTime is the time when the Stage was created. The endTime is the time when the current Stage was finished and new Stage created.

When the start event of the collaborative process flow is created, the Flow Controller Manager will create the Start stage and associate it with the collaborative process flow. When all outputs of the start event are confirmed then the Progress stage is created and associated with the collaborative process flow. Finally, when the collaborative process flow ends (its end event is finished), the End stage is created and associated with the collaborative process flow. If the collaborative process flow is not completed in timeToComplete seconds since its stage with Start value was created, the Escalated stage will be created and associated with the collaborative process flow. The escalated collaborative process flow can be moved from the escalated stage to its previous stage (Start or Progress) by either an owner (a user who created the collaborative process flow) or an administrator or an agent.

Argument Description Data Type Requiredstage This argument provides a

stage in an XML form. String Yes

11.1.4 deployCPID

The deployCPID deploys the CPID part related to the collaborative process flow(s) in the Process Flow Registry. As soon as the CPID is deployed the collaborative process execution can start.

Argument Description Data Type Requiredcpid This argument

provides an id of a CPID that will be deployed.

String256 Yes

collaborativeProcessFlowList This argument provides a list of ids for the collaborative process flows that will be deployed. All collaborative entities related to the collaborative process flows will also be deployed. If the value for this argument is not specified, all collaborative process flows and their related entities will be deployed.

Set No

Service Oriented Architecture Collaboration Semantics V0.1 26

Page 32: SOA Collaboration Semantics

Semantion Inc.

version This argument provides a CPID version that will be used to deploy the CPID. If the value for this argument is not specified, the latest CPID version will be used.

String256 No

11.1.5 findActivityByParent

The findActivityByParent returns all activities related to either a collaborative process or a collaborative process flow.

Argument Description Data Type RequiredcollaborativeEntity This argument provides an id

of the collaborative entity which activities will be retrieved. The collaborative entity can be either a collaborative process or a collaborative process flow.

String256 Yes

11.1.6 findArgumentByRule

The findArgumentByRule returns the list of arguments used in a rule.

Argument Description Data Type Requiredrule This argument provides an id

of the SOA IM Rule entity which arguments will be retrieved.

String256 Yes

11.1.7 findChoiceByParent

The findChoiceByParent returns choices associated with a decision.

Argument Description Data Type Requireddecision This argument provides an id

of a decision which choices will be retrieved.

String256 Yes

Service Oriented Architecture Collaboration Semantics V0.1 27

Page 33: SOA Collaboration Semantics

Semantion Inc.

11.1.8 findByInput

The findByInput returns collaborative entities associated with a specified input.

Argument Description Data Type Requiredinput This argument provides the

input’s id.String256 Yes

type This argument provides the type of the returned collaborative entities and its value can be Activity, Decision, Trigger or All.

String256 Yes

11.1.9 findByOutput

The findByOutput returns a collaborative entity that creates a specified output.

Argument Description Data Type Requiredoutput This argument provides the

output’s id.String256 Yes

type This argument provides the type of the returned collaborative entities and its value can be Activity, Decision, Trigger or All.

String256 Yes

11.1.10 findDecisionByParent

The findDecisionByParent returns all decisions related to either a collaborative process or a collaborative process flow.

Argument Description Data Type RequiredcollaborativeEntity This argument provides an id

of the collaborative entity which decisions will be retrieved. The collaborative entity can be either a collaborative process or a collaborative process flow.

String256 Yes

11.1.11 findEventByParent

The findEventByParent returns all events related to either a collaborative process or a collaborative process flow.

Service Oriented Architecture Collaboration Semantics V0.1 28

Page 34: SOA Collaboration Semantics

Semantion Inc.

Argument Description Data Type RequiredcollaborativeEntity This argument provides an id

of the collaborative entity which events will be retrieved. The collaborative entity can be either a collaborative process or a collaborative process flow.

String256 Yes

11.1.12 findInputByParent

The findInputByParent returns inputs associated with a collaborative entity.

Argument Description Data Type RequiredcollaborativeEntity This argument provides an id

of the collaborative entity which inputs will be retrieved. The collaborative entity can be either an activity or a decision or an event’s trigger.

String256 Yes

11.1.13 findOutputByParent

The findOutputByParent returns outputs associated with an activity.

Argument Description Data Type Requiredactivity This argument provides an id

of an activity which outputs will be retrieved.

String256 Yes

11.1.14 findMatrix

The findMetrix returns matrixes currently associated with a collaborative entity.

Argument Description Data Type RequiredcollaborativeEntity This argument provides an id

of the collaborative entity which matrixes will be retrieved. The collaborative entity can be either an activity or a decision or an event’s trigger.

String256 Yes

Service Oriented Architecture Collaboration Semantics V0.1 29

Page 35: SOA Collaboration Semantics

Semantion Inc.

11.1.15 findMatrixByInput

The findMetrixByInput returns a matrix currently associated with an input.

Argument Description Data Type RequiredinputOutput This argument provides an id

of an SOA IM InputOutput entity which matrix will be retrieved.

String256 Yes

11.1.16 findProtocolByAgent

The findProtocolByAgent returns a protocol associated with an agent.

Argument Description Data Type Requiredagent This argument provides an id

of the SOA IM Agent entity which protocol will be retrieved.

String256 Yes

11.1.17 findStageByParent

The findStageByParent returns the Stage currently associated with a collaborative entity.

Argument Description Data Type RequiredcollaborativeEntity This argument provides an id

of the collaborative entity which stage will be retrieved. The collaborative entity can be either a collaborative process flow or an activity or a decision or an event.

String256 Yes

11.1.18 getArgumentValue

The getArgumentVale returns the vale of an argument.

Argument Description Data Type Requiredargument This argument provides an id

of an SOA IM Argument entity which value will be retrieved.

String256 Yes

Service Oriented Architecture Collaboration Semantics V0.1 30

Page 36: SOA Collaboration Semantics

Semantion Inc.

11.1.19 getContent

The getContent sends a message to the Federation Manager to get the content of an XML document.

Argument Description Data Type Requiredid A document id. String256 Yes

11.1.20 getContentElement

The getContentElement returns the value of an XML document element.

Argument Description Data Type Requiredid A document id. String256 Yeselement An XML element String256 Yes

11.1.21 getContentElementAttribute

The getContentElementAttribute returns the value of an XML document element’s attribute.

Argument Description Data Type Requiredid A document id. String256 Yeselement An XML element. String256 Yesattribute An XML element’s attribute String256 Yes

11.1.22 getRuleContent

The getRuleContent gets the content of the rule.

Argument Description Data Type Requiredrule This argument provides an id

of a rule which content will be retrieved in an XML form.

String256 Yes

11.1.23 removeObjects

The removeObjects removes a list of objects from the Process Flow Registry. If the Federation Registry and the Process Flow Registry are separate registries, a RemoveObjects request with a list of objects that belong to the Federation Registry will be submitted to the Federation Manager.

Argument Description Data Type Requiredrequest An XML request that

contains a list of the SOA IM objects’ ids that will be

String Yes

Service Oriented Architecture Collaboration Semantics V0.1 31

Page 37: SOA Collaboration Semantics

Semantion Inc.

removed from the Process Flow Registry and/or Federation Registry.

11.1.24 resetReference

The resetReference resets references associated with specified inputs, outputs, criteria or choices. A reference is reset when the value attribute of an InformationalReference or a ChoiceReference SOA IM entity is unset.

Argument Description Data Type RequiredcollaborativeEntities This argument provides a list

of the collaborative entities which references will be reset. The collaborative entities can be inputs, outputs, criteria and/or choices.

Set Yes

11.1.25 sendMessage

The sendMessage sends a message to either the Federation Manager, the Process Flow Registry, the Activity Manager, the Decision Manager, or the Event Manager.

Argument Description Data Type Requiredmessage An XML-based message that

contains a request, a response or another information that will be sent to either the Federation Manager, the Process Flow Registry, the Activity Manager, the Decision Manager, or the Event Manager

String Yes

destination A destination which this message will be sent to (the Federation Manager, the Process Flow Registry, the Activity Manager, the Decision Manager, or the Event Manager)

String256 Yes

11.1.26 setReference

The setReference sets the value attribute of the informational references.

Argument Description Data Type Required

Service Oriented Architecture Collaboration Semantics V0.1 32

Page 38: SOA Collaboration Semantics

Semantion Inc.

id The id of the informational reference.

String256 Yes

value A URL value (document’s reference)

String256 Yes

11.1.27 submitObjects

The submitObjects submits a list of objects to the Process Flow Registry. If the Federation Registry and the Process Flow Registry are separate registries, a SubmitObjects request with a list of objects that belong to the Federation Registry will be submitted to the Federation Manager.

Argument Description Data Type Requiredrequest An XML request that

contains SOA IM objects that will be submitted to the Process Flow Registry and/or the Federation Registry.

String Yes

11.1.28 submitQuery

The submitQuery submits a query to the Process Flow Registry. If the Federation Registry and the Process Flow Registry are separate registries, a SubmitQuery request that belongs to the Federation Registry will be submitted to the Federation Manager.

Argument Description Data Type Requiredrequest An XML-based query

request.String Yes

11.1.29 updateAgentDelegation

The updateAgentDelegation updates an agent delegation in the Process Flow Registry. If the provided entities already exist they will be updated. Otherwise, they will be created in the registry with the agent related associations explained in [SOAIM].

Argument Description Data Type RequiredagentEntities A list of agent related entities

in an XML form.String Yes

11.1.30 updateCPID

The updateCPID updates the specified CPID. The updateRequest argument contains the Process Flow Registry related entities only. These entities will be deployed/re-deployed in the Process Flow Registry if the related CPID is already deployed. The CPID content will also be updated and versioned. The update CPID processing logic is explained in Section 4.0.

Service Oriented Architecture Collaboration Semantics V0.1 33

Page 39: SOA Collaboration Semantics

Semantion Inc.

Argument Description Data Type Requiredcpid This argument provides the id

of the CPID that will be updated.

String256 Yes

updateRequest This argument provides an XML request that contains all new and/or modified collaborative entities that will be submitted.

String Yes

11.1.31 updateObjects

The updateObjects updates a list of objects in the Process Flow Registry. If the Federation Registry and the Process Flow Registry are separate registries, an UpdateObjects request that belongs to the Federation Registry will be submitted to the Federation Manager.

Argument Description Data Type Requiredrequest An XML request that

contains a list of the SOA IM objects that will be updated in the Process Flow Registry and/or the Federation Registry.

String Yes

12.0 Activity Manager Protocol and Interface

The Activity Manager manages execution of activities. It communicates with the Flow Controller Manager and the Process Flow Registry.

When the Activity Manager receives the StartCollaborativeEntity request, it creates an SOA IM Stage (createStage) with value Start in the Process Flow Registry and associates the Stage with the Activity specified in the StartCollaborativeEntity request. Based on the timeToComplete attribute specified in the SOA IM Activity entity, the Activity Manager will change the Activity’s stage to Escalated if the activity is not completed in timeToComplete seconds since its stage with Start value was created. The escalated activity can be moved from the escalated stage to its previous stage (Start or Progress) by either an owner (a user who created the activity) or an administrator or an agent.

The Activity Manager checks what role performs the Activity (findRoleByCollaborativeEtity). If more than one role can perform the activity, or more than one agent, user and/or service with assigned role can perform the activity then the resourceAssignmentType of the Activity SOA IM entity must have value Rule or Admin.

If the Rule value is specified for the resourceAssignemntType then the resourceAssignment attribute of the Activity entity will have the value equals to the ID of the rule that will be used to specify the performer of the activity. A message with the ResolveResourceAssignment request will be sent to the Flow Controller Manager. The ResolveResourceAssignment request contains the rule id that will be used to select the activity performer. When the Flow Controller Manager receives this request it will send it to the

Service Oriented Architecture Collaboration Semantics V0.1 34

Page 40: SOA Collaboration Semantics

Semantion Inc.

Federation Manager that will select an agent information related to the rule from the Federation Registry. The Federation Manager uses:

Rule’s id to retrieve the rule content (getRuleContent) from the Federation Registry Arguments’ ids to retrieve arguments’ values (getArgumentValue) from the Process Flow

Registry

Based on this information the Federation Manager creates an agent request that contains all required inputs for the agent. The Federation Manager sends a message with the agent request to the Agent Interface Manager that directly communicates with the Agent Framework using the protocol (findProtocolByAgent) associated with the agent. The agent supports a rule engine that will execute the rule. The execution of the rule selects the activity performer that will be in the agent response. The Agent Interface Manager will send a message with the agent response to the Federation Manager.

If the Admin value is specified for the resourceAssignemntType then the resourceAssignment attribute of the Activity entity will have the value equals to the ID of the SOA Federation administrator. A message with the ResolveResourceAssignment request will be sent to the Flow Controller Manager that will submit the request to the Federation Manager. The ResolveResourceAssignment request contains the administrator’s id and a list of resources that can perform the activity. The Federation Manager will get the administrator’s profile from the Federation Registry. The Federation Manager will also create the AdminResourceAssignment request that contains the list of all performers who can perform the activity and use an email address specified in the administrator’s profile to send an email with the AdminResourceAssignment request to the administrator. The message body that will be sent by the email have the following format:

Activity ID: <activity ID>Activity Name: <activity name><performer_1 name> ID: <performer_1 ID>…<performer_n name> ID: <performer_n ID> Based on this request the administrator will select a performer of the activity and send an email with the following message body to the Federation Manager:

Activity ID: <activity ID>Activity Name: <activity name>Performer ID: <performer ID>

If the performer is an agent, the Activity Manager will send a message with the PerformActivity request to the Flow Controller Manager that will submit the message to the Federation Manager. The PerformActivity request contains the activity’s inputs’ ids, agent’s id and the id of the protocol needed to communicate with the agent. The Activity Manager retrieves this information from the Process Flow Registry before creating and sending the PerformActivity request to the Flow Controller Manager. If the agent is managed by a local Agent Framework, the communication with the agent is provided by the Agent Interface Manager that directly communicates with the Agent Framework that manages the agent. If the agent is running on a federate, the Federation Manager will communicate with the agent via the Gateway Collaborative Engine using the protocol associated with the agent and inputs specified in the PerformActivity request. Even for locally running agents the protocol is needed to get information to communicate with the Agent Framework managing the agent and to provide inputs for the agent. After receiving a confirmation from either the federate or the Agent Interface Manager that the execution of the activity has been started, the Federation Manager will send a message to the Flow Controller Manager with the CollaborativeEntityStarted response. The Flow Controller Manager will send the response to the Activity Manager. The Activity Manager will create the SOA IM Stage entity with value Progress and associate it with the activity. As soon as the activity’s outputs become available the activity is completed and the stage with value End will be created and associated with the activity.

Service Oriented Architecture Collaboration Semantics V0.1 35

Page 41: SOA Collaboration Semantics

Semantion Inc.

If the performer is a service, the Activity Manager will send a message with the PerformActivity request to the Flow Controller Manager that will submit the message to the Federation Manager. The Federation Manager will communicate with the service via the Gateway Collaborative Engine using the protocol associated with the service and inputs specified in the PerformActivity request. After receiving a message with the CollaborativeEntityStarted response from the federate (where the service is running) the Federation Manager will send a message to the Flow Controller Manager. The Flow Controller Manager will send the message to the Activity Manager. The Activity Manager will create the SOA IM Stage entity with value Progress and associate it with the activity. As soon as the activity’s outputs become available the activity is completed and the stage with value End will be created and associated with the activity.

If the performer is a user, the Activity Manager will send a message with the PerformActivity request to the Flow Controller Manager that will submit the message to the Federation Manager. The Federation Manager will communicate with the user via email using the profile (findProfileByFederate) associated with the user and inputs specified in the PerformActivity request. The Federation Manager will create the message body that will contain the PerformActivity request in the following format:

Activity ID: <activity ID>Activity Name: <activity name><input_1 name>: <input_1 value>…<input_n name>: <input_n value>

After receiving an email confirmation from the user that the execution of the activity has been started in the form:

Activity ID: <activity ID>Activity Name: <activity name>Start Date and Time: <DD MON,YYYY> at <HH:MM:SS>

the Federation Manager will send a message with the CollaborativeEntityStarted response to the Flow Controller Manager. The Flow Controller Manager will send the message to the Activity Manager. The Activity Manager will create an SOA IM Stage entity with value Progress and associate it with the activity. As soon as the activity’s outputs become available (outputsAvailable) the activity is completed and a stage with value End will be created and associated with the activity.

12.1 Activity Manager Methods

This section explains the Activity Manager methods. Each Activity Manager method returns an Activity Manager response defined in the Activity Manager XML Schema document [AMXMLS].

12.1.1 createAssociation

The createAssociation creates an association between the two collaborative entities. The types of associations between the collaborative entities are defined in [SOAIM].

Argument Description Data Type Requiredassociation This argument provides an

XML form of the Association that will be created with all required elements and

String Yes

Service Oriented Architecture Collaboration Semantics V0.1 36

Page 42: SOA Collaboration Semantics

Semantion Inc.

attributes.

12.1.2 createStage

The createStage creates a Stage entity for an activity.

The value attribute of the Stage entity can have the following values:

Start, Progress, Escalated, or End

Each Stage SOA IM entity has the startTime and the endTime attribute. The startTime is the time when the Stage was created. The endTime is the time when the current Stage was finished and new Stage created.

When the Activity Manager receives the StartCollaborativeEntity request, the Activity Manager will create the Start stage and associate it with the activity. When the start of the activity is confirmed then the Progress stage is created and associated with the activity. Finally, when the activity is finished the End stage is created and associated with the activity. If the activity is not completed in timeToComplete seconds since its stage with Start value was created, the Escalated stage will be created and associated with the activity. The escalated activity can be moved from the escalated stage to its previous stage (Start or Progress) by either an owner (a user who created the activity) or an administrator or an agent.

Argument Description Data Type Requiredstage This argument provides a

stage in an XML form. String Yes

12.1.3 getPredecessor

The getPredecessor returns an activity’s predecessor if the activity is associated with a sequence and if the activity has the predecessor.

Argument Description Data Type Requiredactivity This argument provides an id

of the activity.String256 Yes

12.1.4 getRole

The getRole returns a list of roles (SOA IM CPRole entities) that perform an activity.

Argument Description Data Type Requiredactivity This argument provides an id

of an activity.String256 Yes

Service Oriented Architecture Collaboration Semantics V0.1 37

Page 43: SOA Collaboration Semantics

Semantion Inc.

12.1.5 getSuccessor

The getSuccessor returns an activity’s successor if the activity is associated with a sequence and if the activity has the successor.

Argument Description Data Type Requiredactivity This argument provides an id

of an activity.String256 Yes

12.1.6 outputsAvailable

The outputsAvailable checks if all activity’s outputs are available. The outputsAvailable returns the Boolean value true when all activity’s outputs are available.

Argument Description Data Type Requiredactivity This argument provides an id

of an activity.String256 Yes

12.1.7 sendMessage

The sendMessage sends a message to either the Flow Controller Manager or the Process Flow Registry.

Argument Description Data Type Requiredmessage An XML-based message that

contains a request, a response or another information that will be sent to either the Flow Controller Manager or the Process Flow Registry.

String Yes

destination A destination which this message will be sent to (the Flow Controller Manager or the Process Flow Registry)

String256 Yes

12.1.8 setPredecessor

The setPredecessor sets an activity’s predecessor in the sequence associated with it.

Argument Description Data Type RequiredcollaborativeEntity This argument provides an id

of the collaborative entity that is set up as the activity’s predecessor.

String256 Yes

Service Oriented Architecture Collaboration Semantics V0.1 38

Page 44: SOA Collaboration Semantics

Semantion Inc.

12.1.9 setSuccessor

The setSuccessor sets an activity’s successor in the sequence associated with it.

Argument Description Data Type RequiredcollaborativeEntity This argument provides an id

of the collaborative entity that is set up as the activity’s successor.

String256 Yes

13.0 Decision Manager Protocol and Interface

The Decision Manager manages executions of decisions. It communicates with the Flow Controller Manager and the Process Flow Registry.

When the Decision Manager receives the StartCollaborativeEntity request, it creates an SOA IM Stage (createStage) with value Start in the Process Flow Registry and associates the Stage with the Decision specified in the StartCollaborativeEntity request. Based on the timeToComplete attribute specified in the SOA IM Decision entity, the Decision Manager will change the Decision’s stage to Escalated if the decision is not completed in timeToComplete seconds since its stage with Start value was created. The escalated decision can be moved from the escalated stage to its previous stage (Start or Progress) by either an owner (a user who created the decision) or an administrator or an agent.

The Decision Manager checks what role performs the Decision (findRoleByCollaborativeEtity). If more than one role can perform the decision, or more than one agent, user and/or service with assigned role can perform the decision then the resourceAssignmentType of the Decision SOA IM entity must have value Rule or Admin.

If the Rule value is specified for the resourceAssignemntType then the resourceAssignment attribute of the Decision entity will have the value equals to the ID of the rule that will be used to specify the performer of the decision. A message with the ResolveResourceAssignment request will be sent to the Flow Controller Manager. The ResolveResourceAssignment request contains the rule id that will be used to select the decision performer. When the Flow Controller Manager receives this request it will send it to the Federation Manager that will select an agent information related to the rule from the Federation Registry. The Federation Manager uses:

Rule’s id to retrieve the rule content (getRuleContent) from the Federation Registry Arguments’ ids to retrieve arguments’ values (getArgumentValue) from the Process Flow

Registry

Based on this information the Federation Manager creates an agent request that contains all required inputs for the agent. The Federation Manager sends a message with the agent request to the Agent Interface Manager that directly communicates with the Agent Framework using a protocol (findProtocolByAgent) associated with the agent. The agent supports a rule engine that will execute the rule. The execution of the rule selects the decision performer that will be in the agent response. The Agent Interface Manager will send a message with the agent response to the Federation Manager.

If the Admin value is specified for the resourceAssignemntType then the resourceAssignment attribute of the Decision entity will have the value equals to the ID of the SOA Federation administrator. A message with the ResolveResourceAssignment request will be sent to the Flow Controller Manager that will submit the request to the Federation Manager. The ResolveResourceAssignment request contains the

Service Oriented Architecture Collaboration Semantics V0.1 39

Page 45: SOA Collaboration Semantics

Semantion Inc.

administrator’s id and a list of resources that can perform the decision. The Federation Manager will get the administrator’s profile from the Federation Registry. The Federation Manager will also create the AdminResourceAssignment request that contains the list of all performers who can perform the decision and use an email address specified in the administrator’s profile to send an email with the AdminResourceAssignment request to the administrator. The message body that will be sent by the email have the following format:

Decision ID: <decision ID>Decision Name: <decision name><performer_1 name> ID: <performer_1 ID>…<performer_n name> ID: <performer_n ID> Based on this request the administrator will select a performer of the decision and send an email with the following message body to the Federation Manager:

Decision ID: < decision ID>Decision Name: < decision name>Performer ID: <performer ID>

If the performer is an agent, the Decision Manager will send a message with the MakeDecision request to the Flow Controller Manager that will submit the message to the Federation Manager. The MakeDecision request contains the decision’s criteria ids, decision’s rule id, id of arguments used in the rule, agent’s id and the id of the protocol needed to communicate with the agent. The Decision Manager retrieves this information from the Process Flow Registry before creating and sending the MakeDecision request to the Flow Controller Manager. If the agent is managed by a local Agent Framework the communication with the agent is provided by the Agent Interface Manager that directly communicates with the Agent Framework that manages the agent. If the agent is running on a federate the Federation Manager will communicate with the agent via the Gateway Collaborative Engine using the protocol associated with the agent and inputs specified in the MakeDecision request. Even for locally running agents the protocol is needed to get information to communicate with the Agent Framework managing the agent and to provide inputs for the agent. While an agent providing execution support for an activity requires just the activity’s inputs, an agent providing an execution support for a decision requires decision’s criteria, a rule that will be used by the agent’s rule engine and arguments used in the rule to make the decision. After receiving a confirmation from either the federate or the Agent Interface Manager that the execution of the decision has been started the Federation Manager will send a message with the CollaborativeEntityStarted response to the Flow Controller Manager. The Flow Controller Manager will send the message with the response to the Decision Manager. The Decision Manager will create the SOA IM Stage entity with value Progress and associate it with the decision. As soon as the decision’s outputs become available the decision is completed and the stage with value End will be created and associated with the decision. There are three types of decision outputs (alternatives):

Binary Primary Derivative

The Binary outputs belong to a choice (e.g., Yes or No, True or False, etc.) and only a single output (choice) is generated based on a rule associated with the decision. The Primary type enables a selection of one or more outputs (but not all of them) from the provided inputs based on a rule associated with the decision. The Primary type outputs provide filtering. The Derivative type is like the Binary type with a difference that it can generate more than one output based on a rule associated with the decision.

If the performer is a service, the Decision Manager will send a message with the MakeDecision request to the Flow Controller Manager that will submit the message to the Federation Manager. The Federation Manager will communicate with the service via the Gateway Collaborative Engine using the protocol

Service Oriented Architecture Collaboration Semantics V0.1 40

Page 46: SOA Collaboration Semantics

Semantion Inc.

associated with the service, and criteria, rule and arguments specified in the MakeDecision request. After receiving a confirmation from the federate (where the service is running) that the execution of the decision has been started, the Federation Manager will send a message with the CollaborativeEntityStarted response to the Flow Controller Manager. The Flow Controller Manager will send the message with the response to the Decision Manager. The Decision Manager will create the SOA IM Stage entity with value Progress and associate it with the decision. As soon as the decision’s outputs become available the decision is completed and a stage with value End will be created and associated with the decision.

If the performer is a user, the Decision Manager will send a message with the MakeDecision request to the Flow Controller Manager that will submit the message to the Federation Manager. The Federation Manager will communicate with the user via email using the profile associated with the user (findProfileByFederate ) and inputs specified in the MakeDecision request. The Federation Manager will create the message body that will contain the MakeDecision request in the following format:

Decision ID: <decision ID>Decision Name: <decision name><criteria_1 name>: <criteria_1 value>…<criteria_n name>: <criteria_n value><argument_1 name>: <argument_1 value>….<argument_n name>: <argument_n value>Rule Content:<rule content>

The rule content is optional since the user can already be aware of the rule that has to be applied.

After receiving an email confirmation from the user that the execution of the decision has been started in the form:

Decision ID: < decision ID>Decision Name: < decision name>Start Date and Time: <DD MON,YYYY> at <HH:MM:SS>

the Federation Manager will send a message to the Flow Controller Manager with the CollaborativeEntityStarted response. The Flow Controller Manager will send the message with the response to the Decision Manager. The Decision Manager will create an SOA IM Stage entity with value Progress and associate it with the decision. As soon as the decision’s outputs become available (outputsAvailable) the decision is completed and a stage with value End will be created and associated with the decision.

13.1 Decision Manager Methods

This section explains the Decision Manager methods. Each Decision Manager method returns a Decision Manager response defined in the Decision Manager XML Schema document [DMXMLS].

13.1.1 createAssociation

The createAssociation creates an association between the two collaborative entities. The types of associations between collaborative entities are defined in [SOAIM].

Service Oriented Architecture Collaboration Semantics V0.1 41

Page 47: SOA Collaboration Semantics

Semantion Inc.

Argument Description Data Type Requiredassociation This argument provides an

XML form of the Association that will be created with all required elements and attributes.

String Yes

13.1.2 createStage

The createStage creates a Stage entity for a decision.

The value attribute of the Stage entity can have the following values:

Start, Progress, Escalated, or End

Each Stage SOA IM entity has the startTime and the endTime attribute. The startTime is the time when the Stage was created. The endTime is the time when the current Stage was finished and new Stage created.

When the Decision Manager receives the StartCollaborativeEntity request, the Decision Manager will create the Start stage and associate it with the decision. When the start of the decision is confirmed then the Progress stage is created and associated with the decision. Finally, when the decision is finished the End stage is created and associated with the decision. If the decision is not completed in timeToComplete seconds since its stage with Start value was created, the Escalated stage will be created and associated with the decision. The escalated decision can be moved from the escalated stage to its previous stage (Start or Progress) by either an owner (a user who created the decision) or an administrator or an agent.

Argument Description Data Type Requiredstage This argument provides a

stage in an XML form. String Yes

13.1.3 getPredecessor

The getPredecessor returns a decision’s predecessor if the decision is associated with a sequence and if the decision has the predecessor.

Argument Description Data Type Requireddecision This argument provides an id

of the decision.String256 Yes

13.1.4 getRole

The getRole returns a list of roles (SOA IM CPRole entities) that perform a decision.

Argument Description Data Type Required

Service Oriented Architecture Collaboration Semantics V0.1 42

Page 48: SOA Collaboration Semantics

Semantion Inc.

decision This argument provides an id of a decision.

String256 Yes

13.1.5 getSuccessor

The getSuccessor returns a decision’s successor if the decision is associated with a sequence and if the decision has the successor.

Argument Description Data Type Requireddecision This argument provides an id

of the decision.String256 Yes

13.1.6 outputsAvailable

The outputsAvailable checks if all decision’s outputs are available. The outputsAvailable returns the Boolean value true when all decision’s outputs are available.

Argument Description Data Type Requireddecision This argument provides an id

of the decision.String256 Yes

13.1.7 sendMessage

The sendMessage sends a message to either the Flow Controller Manager or the Process Flow Registry.

Argument Description Data Type Requiredmessage An XML-based message that

contains a request, a response or another information that will be sent to either the Flow Controller Manager or the Process Flow Registry.

String Yes

destination A destination which this message will be sent to (the Flow Controller Manager or the Process Flow Registry)

String256 Yes

13.1.8 setPredecessor

The setPredecessor sets a decision’s predecessor in the sequence associated with it.

Argument Description Data Type RequiredcollaborativeEntity This argument provides an id

of the collaborative entity that is set up as the decision’s

String256 Yes

Service Oriented Architecture Collaboration Semantics V0.1 43

Page 49: SOA Collaboration Semantics

Semantion Inc.

predecessor.

13.1.9 setSuccessor

The setSuccessor sets a decision’s successor in the sequence associated with it.

Argument Description Data Type RequiredcollaborativeEntity This argument provides an id

of the collaborative entity that is set up as the decision’s successor.

String256 Yes

14.0 Event Manager

The Event Manager manages events, triggers and actions. An event has a trigger that creates the event and one or more actions that represent the consequence(s) of the event. The Event Manager directly communicates with the Flow Controller Manager and the Process Flow Registry.

A trigger is a condition that creates an event. The trigger could be an output of an activity or a decision, a result of the execution of one or more rule or just a fact that another event has happened. There are four types of supported triggers:

Information Flow Message MessageRequest Rule

The trigger of type Information starts when all inputs or a combination of inputs associated with the trigger become available.

The trigger of type Flow is a result of an action from another event.

The trigger of type Message is a result of a received message associated with it.

The trigger of type MessageRequest is a result of a received message request associated with it.

The trigger of type Rule is a result of a processed rule associated with it.

When a trigger belongs to the a event of a collaborative process flow, the Event Manager will send a message to the Flow Controller Manager to create an SOA IM Stage (createStage) with value Start in the Process Flow Registry. The Flow Controller Manager will also associate the Stage with the CollaborativeProcessFlow SOA IM entity. When the start event’s action is confirmed, the Event Manager will send a message to the Flow Controller Manager to create an SOA IM Stage (createStage) with value Progress in the Process Flow Registry. The Flow Controller Manager will then associate the Stage with the CollaborativeProcessFlow entity. Based on the timeToComplete attribute specified in the SOA IM CollaborativeProcessFlow entity, the Flow Controller Manager will change the CollaborativeProcessFlow’s stage to Escalated if the collaborative process flow’s end event is not confirmed in timeToComplete

Service Oriented Architecture Collaboration Semantics V0.1 44

Page 50: SOA Collaboration Semantics

Semantion Inc.

seconds since its stage with Start value was created. The escalated collaborative process flow can be moved from the escalated stage to its previous stage (Start or Progress) by an SOA Federation administrator or an agent.

When the trigger is type Information, Flow, Message or MessageRequest, the Event Manager will receive a StartCollaborativeEntity request when it will create an SOA IM Stage (createStage) with value Start in the Process Flow Registry and will associate the Stage with the Event which the trigger belongs to. Based on the timeToComplete attribute specified in the SOA IM Event entity associated with the event, the Event Manager will change the Event’s stage to Escalated if the event’s actions are not confirmed in timeToComplete seconds since its stage with Start value was created. The escalated event can be moved from the escalated stage to its previous stage (Start) by either an owner (a user who created the event) or an administrator or an agent.

When the trigger is type Rule, the Event Manager will receive the CreateStage request from the Flow Controller Manager when the processing of the rule associated with the trigger gives the true Boolean value. The CreateStage request contains the stage with value Start and the id of the event which the trigger is associated with. Based on the timeToComplete attribute specified in the SOA IM Event entity associated with the event, the Event Manager will change the Event’s stage to Escalated if the event’s actions are not confirmed in timeToComplete seconds since its stage with Start value was created. The escalated event can be moved from the escalated stage to its previous stage (Start) by either an owner (a user who created the event entity) or an administrator or an agent.

The Event Manager is ready to start the action now. The action type can be:

Alert Compensation Link Insertion Termination TriggerFlow

If the action is type Alert, the Event Manager will retrieve the id of the message (getMessage) associated with the action and all event subscribers (getSubscriber) and send a message with the SendAlert request to the Flow Controller Manager that will submit the message to the Federation Manager. The Event Manager will also create an SOA IM ProcedureConfirmation entity with value Start and associate it with the action. The Federation Manager will retrieve the message content from the Federation Registry and send the alert message to the subscribers using the email addresses specified in their profiles (findProfileByFederate). After successfully sending the alert message to all subscribers, the Federation Manager will send a message with the AlertSent response to the Flow Controller Manager. The Flow Controller Manager will send a message with this response to the Event Manager.

If the action is type Compensation, it references a list of activities and/or decisions, or a trigger of the collaborative process flow’s start event which the current collaborative process flow will get back to. The inputs for each of the referenced collaborative entities will be reset and the collaborative entity (activity, decision) will be re-started when all inputs are confirmed. A stage entity with value Start will be associated with the collaborative entity. The Event Manager will also create an SOA IM ProcedureConfirmation entity with value Start and associate it with the action. If more than one collaborative entity is specified, the execution will switch to the next collaborative entity when the previous collaborative entity is finished. If the action references the trigger of the start event, the entire collaborative process flow will be stopped, all inputs reset and the collaborative process flow re-started when all conditions depending on the trigger type are met.

If the action is type Link, it will start an activity or a decision specified by its referenceList attribute. The activity or the decision must be from the same collaborative process flow. The Event Manager will send a message with the ConditionalStart request to the Flow Controller Manager. The Event Manager will also create an SOA IM ProcedureConfirmation entity with value Start and associate it with the action. The

Service Oriented Architecture Collaboration Semantics V0.1 45

Page 51: SOA Collaboration Semantics

Semantion Inc.

ConditionalStart request contains the id of the collaborative entity that will be started. The Flow Controller Manager uses findInputByParent method to get all inputs associated with the collaborative entity in the Process Flow Registry. If all inputs are available the Flow Controller Manager will send a message with the StartCollaborativeEntity request to the corresponding manager, the Activity Manager or the Decision Manager. If some of the required inputs are not available, the Flow Controller Manager will send a message with the InputsNotAvailable response to the Event Manager.

If the action is type Insertion, the action will start a collaborative process flow which start event’s id is specified by the action’s referenceList attribute. The Event Manager will create an SOA IM Stage (createStage) with value Start in the Process Flow Registry and will associate the Stage with the referenced Event. The Event Manager will also create an SOA IM ProcedureConfirmation entity with value Start and associate it with the action. Based on the timeToComplete attribute specified in the SOA IM Event entity associated with the event, the Event Manager will change the Event’s stage to Escalated if the event’s actions are not confirmed in timeToComplete seconds since its stage with Start value was created. The Event Manager will send a message to the Flow Controller Manager to create an SOA IM Stage (createStage) with value Start in the Process Flow Registry. The Flow Controller Manager will also associate the Stage with the CollaborativeProcessFlow . Based on the timeToComplete attribute specified in the SOA IM CollaborativeProcessFlow entity, the Flow Controller Manager will change the CollaborativeProcessFlow’s stage to Escalated if the collaborative process flow is not confirmed in timeToComplete seconds since its stage with the Start value was created.

If the action is type Termination, the action will terminate a collaborative process flow which id is specified by the action’s referenceList attribute. The Event Manager will send a message to the Flow Controller Manager with the createStage request that will contain the id of the collaborative process flow that will be terminated and the value attribute End. The Flow Controller Manager will also reset all inputs and criteria included in the collaborative process flow. The Event Manager will also create an SOA IM ProcedureConfirmation entity with value Start and associate it with the action.

If the action is type Trigger Flow, the action will start an event which id is specified by the action’s referenceList attribute. The Event Manager will create an SOA IM Stage (createStage) with value Start in the Process Flow Registry and will associate the Stage with the event. The Event Manager will also create an SOA IM ProcedureConfirmation entity with value Start and associate it with the action. Based on the timeToComplete attribute specified in the SOA IM Event entity associated with the event, the Event Manager will change the Event’s stage to Escalated if the event’s actions are not confirmed in timeToComplete seconds since its stage with Start value was created.

The Event Manager retrieves all event’s actions and checks their conformation statuses (getActionStatus). If the current confirmation statuses for all actions have value Start, the Event Manager will also create a Stage with value Confirmed and associate it with the event. The confirmed stage of the event means that the event’s actions started.

When any of the actions is finished, the Event Manager will create an SOA IM ProcedureConfirmation entity with value End and associate it with the action.

The Event Manager keeps retrieving all event’s actions and checking their confirmation statuses (getActionStatus). If all their confirmation statuses have value End the Event Manager will create an SOA IM Stage entity with value End and associate it with the event. Based on the timeToComplete attribute specified in the SOA IM Event entity associated with the event, the Event Manager will change the Event’s stage to Escalated if the event’s actions are not confirmed in timeToComplete seconds since its stage with Start value was created. The escalated event can be moved from the escalated stage to its previous stage (Start) by either an owner (a user who created the event) or an administrator or an agent.

Finally, an owner, a publisher, and subscribers of an event, and events clustering will be explained.

Each event has an owner, a publisher and optional subscribers. The owner is an administrator who created and registered the event. The type of the event’s trigger determines its publisher:

Service Oriented Architecture Collaboration Semantics V0.1 46

Page 52: SOA Collaboration Semantics

Semantion Inc.

Information – An activity or a decision that created inputs Flow - An event which action creates flow trigger Message – A federate who sent the message MessageRequest – A federate who sent the message Rule - An agent or an administrator who will be performing the rule.

The subscribers are federates that subscribe to the event’s action(s) with the alert type. They can use it to interpret their own logic within a collaborative process flow. They will receive the action’s alert message every time when it takes place.

An event can also be included in a cluster. The cluster consists of events from more than one collaborative process flow. This groups events into a common category of interest. For example, a cluster can be set up so that the event in one collaborative process flow cannot get into the End stage until the one or more events from other collaborative process flows get into the End stage. The cluster is modeled by the SOA IM Cluster entity that besides the id, name and description attributes contains the correlation, eventIdList, stageList and typeList attribute. The meaning of these attributes can be explained by the following table:

Even ID Type Stage Correlation Slave Stage1 Lead End2 Lead End3 Slave SET End4 Slave SET End

Table 1 – Cluster Example

According to the Table 1 the stage of the slave events will not be changed to End until the lead events’ stages change to End.

Clusters can be pre-defined and also dynamically created during a collaborative process. If more than one event has lead role then the slaves can get into the Start or End stages only. One slave event can be in more than one cluster. When all leads in any of clusters get into the defined stages, the slave event will get into the defined stage. When the lead event stage is not specified then all slave events are forced into the defined stage by the cluster.

14.1 Event Manager Methods

This section explains the Event Manager methods. Each Event Manager method returns an Event Manager response defined in the Event Manager XML Schema document [EMXMLS].

14.1.1 createAssociation

The createAssociation creates an association between the two collaborative entities. The types of associations between collaborative entities are defined in [SOAIM].

Argument Description Data Type Requiredassociation This argument provides an

XML form of the Association that will be created with all

String Yes

Service Oriented Architecture Collaboration Semantics V0.1 47

Page 53: SOA Collaboration Semantics

Semantion Inc.

required elements and attributes.

14.1.2 createProcedureConfirmation

The createProcedureConfirmation creates a ProcedureConfirmation entity for an action.

The value attribute of the ProcedureConfirmation entity can have value Start or End.

When an action starts it is associated with a ProcedureConfirmation with value Start. When the action is finished, it is associated with a ProcedureConfirmation with value End.

Argument Description Data Type RequiredprocedureConfirmation This argument provides a

ProcedureConfirmation in an XML form.

String Yes

14.1.3 createStage

The createStage creates a Stage entity for an event.

The value attribute of the Stage entity can have the following values:

Start, Confirmed, Escalated, or End

Each Stage SOA IM entity has the startTime and the endTime attribute. The startTime is the time when the Stage was created. The endTime is the time when the current Stage was finished and new Stage created.

Events start with the Start stage. Upon action being confirmed to take place, the Start Stage is finished and another Stage with value Confirmed is created. If there is no confirmation of the action after the predefined period of time (timeToComplete Action attribute), the new Stage with value Escalated is created. If the Action’s timeToComplete is not specified and if the action is completed or if the action is completed for the timeToComplete, the new Stage with value End is created.

Argument Description Data Type Requiredstage This argument provides a

stage in an XML form. String Yes

14.1.4 getAction

The getAction returns all actions associated with an event.

Argument Description Data Type Requiredevent This argument provides an

event’s id.String256 Yes

Service Oriented Architecture Collaboration Semantics V0.1 48

Page 54: SOA Collaboration Semantics

Semantion Inc.

14.1.5 getActionStatus

The getActionStatus returns action’s confirmation status.

Argument Description Data Type Requiredaction This argument provides an

action’s id.String256 Yes

14.1.6 getActionType

The getActionType returns the type of an action.

Argument Description Data Type Requiredaction This argument provides an id

of an action.String256 Yes

14.1.7 getMessage

The getMessage returns a message associated with an action.

Argument Description Data Type Requiredaction This argument provides an id

of an action.String256 Yes

14.1.8 getPredecessor

The getPredecessor returns an event’s predecessor if the event is associated with a sequence and if the event has the predecessor.

Argument Description Data Type Requiredevent This argument provides an id

of an event.String256 Yes

14.1.9 getPublisher

The getPublisher returns an event’s publisher

Argument Description Data Type Requiredevent This argument provides an id

of an event.String256 Yes

Service Oriented Architecture Collaboration Semantics V0.1 49

Page 55: SOA Collaboration Semantics

Semantion Inc.

14.1.10 getSubscriber

The getSubscriber returns a list of event’s subscribers.

Argument Description Data Type Requiredevent This argument provides an id

of an event.String256 Yes

14.1.11 getSuccessor

The getSuccessor returns an event’s successor if the event is associated with a sequence and if the event has the successor.

Argument Description Data Type Requiredevent This argument provides an id

of an event.String256 Yes

14.1.12 getTriggerType

The getTriggerType returns the type of a trigger.

Argument Description Data Type Requiredtrigger This argument provides an id

of a trigger.String256 Yes

14.1.13 sendMessage

The sendMessage sends a message to either the Flow Controller Manager or the Process Flow Registry.

Argument Description Data Type Requiredmessage An XML-based message that

contains a request, a response or another information that will be sent to either the Flow Controller Manager or the Process Flow Registry.

String Yes

destination A destination which this message will be sent to (the Flow Controller Manager or the Process Flow Registry)

String256 Yes

14.1.14 setPredecessor

Service Oriented Architecture Collaboration Semantics V0.1 50

Page 56: SOA Collaboration Semantics

Semantion Inc.

The setPredecessor sets an action’s predecessor in the sequence associated with it.

Argument Description Data Type RequiredcollaborativeEntity This argument provides an id

of a collaborative entity that is set up as an action’s predecessor.

String256 Yes

14.1.15 setPublisher

The setPublisher associates a publisher with an event.

Argument Description Data Type Requiredevent This argument provides an id

of an event.String256 Yes

publisher This argument provides an id of a publisher.

String256 Yes

14.1.16 setSubscriber

The setSubscriber associates a subscriber with an event.

Argument Description Data Type Requiredevent This argument provides an id

of an event.String256 Yes

subscriber This argument provides an id of a publisher.

String256 Yes

14.1.17 setSuccessor

The setSuccessor sets an action’s successor in the sequence associated with it.

Argument Description Data Type RequiredcollaborativeEntity This argument provides an id

of a collaborative entity that is set up as an action’s successor.

String256 Yes

15.0 Security Provider

The Security Provider is the main SOA security component that manages both authentication and authorization. The Security Provider has three managers:

The Collaborative Process (CP) Flow Security Manager

Service Oriented Architecture Collaboration Semantics V0.1 51

Page 57: SOA Collaboration Semantics

Semantion Inc.

The Federation Identity Manager The Federation Security Policy Manager

The CP Flow Security Manager manages and coordinates the Federation Identity Manager and the Federation Security Policy Manager. It directly communicates with the Federation Manager and the Federation Registry.

The Federation Identity Manager authenticates a user/system accessing the SOA Federation. The Federation Security Policy Manager performs authorization checkups based on security policies.

The core functionality of the Federation Identity Manager is based on the OASIS Security Assertion Markup Language (SAML) [SAML] while the core functionality of the Federation Security Policy Manager is based on the OASIS eXtensible Access Control Markup Language (XACML) [XACML].

The CP Flow Security Manager is configured to manage the Federation Identity Manager and the Federation Security Policy Manager.

The Figure 1 shows the Security Provider Architecture in the SOA Federation environment with the Federation Manager and the Federation Registry as components that also provide the SOA security support. As an example, two federates A and B are also presented and they are used to demonstrate how the Security Provider, the Federation Manager and the Federation Registry provide the overall SOA security support.

The Federation Manager receives a request from the Federate A. It notifies (authenticateSubject) the CP Flow Security Manager that a request is received with security details provided (username/password, or digital certificate, etc.). The CP Flow Security Manager sends a message with a request to the Federation Identity Manager to verify (authenticateSubject) the requestor’s identity. If this identity verification is passed the Federation Identity Manager sends a message with a response to the CP Flow Security Manager that the identity verification was successful. The CP Flow Security Manager sends a message to the Federation Manager that the federate A’s authentication was completed successfully. The CP Flow Security Manager based on the federate A’s request finds out what security policies are needed to perform the full authorization checkup. A security policy can be stored either locally or remotely in the federation. If it is stored locally, it is located in either the Federation Registry (findPolicyByResource) or in a local LPAD directory (getPolicyFromLPAD). If it is stored remotely, the CP Flow Security Manager sends a request (getRemotePolicy) to the Federation Manager. The Federation Manager sends a message with the request to a federate where the policy is located. When all needed policies are received, the Federation Manager submits them to the CP Flow Security Manager. The CP Flow Security Manager notifies Federation Security Policy Manager with a request to perform a complete authorization checkup (subjectAuthorized) using the provided security policies and a request from the Federate A. The authorization checkup result is sent back to the CP Flow Security Manager that notifies the Federation Manager.

Service Oriented Architecture Collaboration Semantics V0.1 52

Page 58: SOA Collaboration Semantics

Semantion Inc.

15.1 Collaborative Process Flow Security Manager Methods

This section explains the Collaborative Process Flow Security Manager methods. Each Collaborative Process Flow Security Manager method returns a Collaborative Process Flow Security Manager response defined in the Collaborative Process Flow Security Manager XML Schema document [CPFSMXMLS].

15.1.1 findPolicyByResource

The findPolicyByResource returns a security policy associated with a specified federation resource.

Argument Description Data Type Requiredresource The id of a federation

resource.String256 Yes

15.1.2 findProfileByFederate

The findProfileByFederate returns a profile associated with a specified federate.

Argument Description Data Type Requiredfederate The id of a federate. String256 Yes

Service Oriented Architecture Collaboration Semantics V0.1 53

Page 59: SOA Collaboration Semantics

Semantion Inc.

15.1.3 getPolicyFromLPAD

The getPolicyFromLPAD returns a security policy from an LPAD.

Argument Description Data Type Requiredresource The id of a federation

resource associated with a security policy.

String256 Yes

lpadURL The URL needed to access the LPAD.

String2000 Yes

15.1.4 getRemotePolicy

The getRemotePolicy returns a security policy located on the specified federate. This method sends a request to the Federation Manager to communicate with the remote federate and retrieve the security policy for the specified resource.

Argument Description Data Type Requiredresource The id of a federation

resource associated with the security policy.

String256 Yes

federate The id of a federate. String256 Yes

15.1.5 sendMessage

The sendMessage sends messages to the Federation Manager, the Federation Registry, the Federation Identity Manager, and the Federation Security Policy Manager.

Argument Description Data Type Requiredmessage An XML-based message. String Yesdestination A destination which this

message will be sent to.String256 Yes

15.2 Federation Identity Manager Methods

This section explains the Federation Identity Manager methods. Each Federation Identity Manager method returns a Federation Identity Manager response defined in the Federation Identity Manager XML Schema document [FIMXMLS].

Service Oriented Architecture Collaboration Semantics V0.1 54

Page 60: SOA Collaboration Semantics

Semantion Inc.

15.2.1 authenticateSubject

The authenticateSubject authenticates a subject. The subject can be a person or a service.

Argument Description Data Type Requiredsubject Subject’s identity and its

security related attributes (e.g., password or digital certificate).

Subject Yes

15.2.2 sendMessage

The sendMessage sends a message to the Collaborative Process Flow Security Manager.

Argument Description Data Type Requiredmessage An XML-based message. String Yes

15.3 Federation Security Policy Manager Methods

This section explains the Federation Security Policy Manager methods. Each Federation Security Policy Manager method returns a Federation Security Policy Manager response defined in the Federation Security Policy Manager XML Schema document [FSPMXMLS].

15.3.1 sendMessage

The sendMessage sends a message to the Collaborative Process Flow Security Manager.

Argument Description Data Type Requiredmessage An XML-based message. String Yes

15.3.2 subjectAuthorized

The subjectAuthorized checks if the already authenticated subject is authorized for the submitted request.

Argument Description Data Type Requiredid Subject’s identity (principal). String256 Yesrequest An XML request. String YespolicyList A list of security policies Set Yes

Service Oriented Architecture Collaboration Semantics V0.1 55

Page 61: SOA Collaboration Semantics

Semantion Inc.

15.4 SOA Security Binding

The Federation Manager, the Security Provider and the Federation Registry are the SOA Federation components that manage SOA security. The following table lists bindings between the SOA security levels and the SOA Federation components and security standards used:

Access to Federation SAML for federated identity management, Federation Manager, Security Provider

SSL for encrypted HTTP session communications, Portal

WS-Security for all highly-secured messaging communications over any common used protocols, Gateway, PortalOASIS XML Common Biometric Format (XCBF) for biometrics, Portal

Smart card, Portal

Access to Information XACML, Federation Manager, Federation Registry, Security Provider

Table 1 – SOA Security Binding

15.5 Standard Security Components

The standard-based SOA security components are:

Secure Socket Layer (SSL) OASIS Web Services Security OASIS Security Assertion Markup Language (SAML) OASIS eXtensible Access Control Markup Language (XACML) OASIS XML Common Biometric Format (XCBF)

15.5.1 SSL

SSL is a mature and widely accepted technology for the secured transport of information over the HTTP (HTTPS). SSL works by using a private key to encrypt data that is transferred over the SSL connection.

SSL is used to secure HTTP sessions between the SOA Federation and federates accessing the SOA Federation. Web browser, HTTP Binding (REST) and SOAP access can be secured using SSL.

It is important to mention that relying on HTTPS does not fully guarantee confidentiality or integrity of the content transferred over the HTTP. It might not be the critical concern for some communications between the SOA Federation and federates. But for critical communications that require more reliable security mechanisms we describe common SSL security issues below.

Service Oriented Architecture Collaboration Semantics V0.1 56

Page 62: SOA Collaboration Semantics

Semantion Inc.

One disadvantage is that authentication requires the end-user to verify that the certificatebeing presented by the server is correctly representing the server’s identity. An imposter can fool the user to accepting a bogus certificate what could create a secure communications channel with a hacker and expose the corporate network to a "man-in-the-middle" attack.

Public machines located for example in hotels, airports, etc., like Internet kiosks, are insecure because they are operated by an unknown third party and are subject to key stroke capture by hackers. For this reason, enterprises may choose to limit the applications accessible over SSL to non-sensitive corporate data.

The users of SSL technology should also be aware that some SSL implementations negotiate down to the lowest common denominator (40-bit encryption) and enterprises cannot guarantee the use of strong encryption for their remote users in those cases.

15.5.2 Web Services Security

Web Services (WS) Security is a set of standard security components for incorporating security information into SOAP messages.

The WS-Security specification provides a way to ensure authentication and integrity of SOAP messages.

WS-Security specifies the use of XML Digital Signature and XML Encryption standards within SOAP. It enables an application developer to insert a security token that identifies the original sender and optionally captures information about intermediate destinations of the XML message. The following security tokens can be used: SAML assertion, Public Key Infrastructure (PKI) certificate, IP address, password, etc.

There are several key advantages WS-Security has over SSL:

Transport-agnostic Security mechanisms that operate in end-to-end scenarios (across trust boundaries) as opposed to

point-to-point scenarios (SSL). More robust authentication and encryption support. Options for partial security applications on a transferred content instead of SSL complete security

application on the entire content.

15.5.3 SAML

Federation is a dominant movement in the identity management today. The most important aspect of this loosely coupled identity management layer is a standard-based federated identity management specification. OASIS Security Services (SAML) [SAML] is the specification that supports federated identity management.

SAML standardizes how security information is exchanged. SAML defines assertions about the authentication of a single principal (person, system, device, etc.) between multiple domains. This is critical for the SOA implementations that include many federates in different domains. Subjects have their authentications represented and validated in the same way across the entire federation. This is called the concept of the Federated Identity.

The SAML benefits are:

Service Oriented Architecture Collaboration Semantics V0.1 57

Page 63: SOA Collaboration Semantics

Semantion Inc.

Platform independent – SAML is a standard based security framework that is completely implementation undependable.

Improved secured online access – Users of the system need to authenticate at an identity provider and then access services and/or resources at service providers without additional authentication. This is a Single Sign-On (SSO) function of SAML.

Loose coupling of directories – User information does not need to be maintained and synchronized between directories.

Reduced administrative cost – The cost of maintaining account information is reduced by the use of SAML for federation between identity domains.

15.5.3.1 SAML Applications

Web Single Sign-On

In Web Single Sign-On, a user authenticates to one web site and is able to access resources at another web site without additional authentication. SAML enables Web SSO through the communication of an authentication assertion from the first site to the second which can log in the user as it had authenticated directly.

Securing Web Services

SOAP header blocks can use SAML assertions as security tokens in order to deliver security and identity information between web service transactions participants. The OASIS WS-Security Technical Committee specifies how SAML assertions should be packaged into the WS-Security <Security> element in an interoperable manner.

Attribute-based Authorization

The attribute-based authorization is used when the individual identity is either not important or should not be shared because of the privacy reasons. The identity information is not the authentication assertion but some other characteristic of the principal.

SAML supports interoperability between disparate security systems. It provides a framework for secure transactions across company boundaries. SAML does not standardize all aspects of the identity management. How identity information can be communicated form one security domain to another is the aspect of the identity management that SAML supports. Other aspects such as access control, etc., are address by other security standards presented in this document.

15.5.4 XACML

XACML is an XML based access control policy standard that describes both a policy language and an access control decision request/response language. Both these languages are encoded in XML.

Service Oriented Architecture Collaboration Semantics V0.1 58

Page 64: SOA Collaboration Semantics

Semantion Inc.

XACML policy language is used to express access control policies about who can do an action, on which resource and when. XACML policy language also has standard extensions for defining new functions, rule combining logic, data types, etc.

The request/response language provides query constructs that allow you to check if a given action should be allowed and interpret the result. The response includes an answer about whether the request should be allowed. The answer can have one of four values: Permit, Deny, Indeterminate (an error occurred or some required value was missing and decision cannot be made) or Not Applicable (the request cannot be answered by the XACML service).

XACML policies do not have to be bound to the systems they govern. They can be reused and applied across many different resources. XACML uses concept of Role Based Access Control (RBAC) which has advantages over traditional approaches.

When a request to access a protected resource is received, the resource protector which is called a Policy Enforcement Point (PEP), will form a request based on the requester’s attributes, the resource being accessed, the action and other information belonging to the request. The PEP will then send this request to a Policy Decision Point (PDP). The PDP processes the request, finds a policy that applies to the request, and generates an answer about whether the access should be granted. That answer is returned to the PEP which then allows or denies access to the requester. PEP and PDP might be included in a single application or they might be distributed across several servers.

XACML also requires XML policies repository and a tool for creating and maintaining XACML policies that are not so simple XML documents to write.

15.5.5 XCBF

Biometrics are automated methods that are used to prove an identity based on physiological or behavioral characteristics such as fingerprints, iris scans, hand geometry, DNA, etc..

OASIS XML Common Biometric Format (XCBF) specification defines a common set of secure XML encodings for the patron formats specified in the Common Biometric Exchange File Format (CBEFF) [CBEFF]. These XML encodings are based on the ASN.1 schema defined in ANSI X9.84 Biometric Information Management and Security [BIMS]. For security purposes, they make use of the Canonical XML Encoding Rules (CXER) for ASN.1 defined in ITU-T Rec. X.693, and rely on the security and processing requirements specified in the X9.96 XML Cryptographic Message Syntax (XCMS) [XCMS] and X9.73 Cryptographic Message Syntax (CMS) [CMS] standards.

This XCBF defines a set of cryptographic messages represented in XML markup that can be used for the secure collection, distribution, and processing, of biometric information. All of the cryptographic operations provided in XCBF are applied to a set of values of the ASN.1 type BiometricObject defined in the ANSI X9.84 standard.

The XCBF specification describes the process for translating between an X9.84 BiometricObject and a BioAPI-1.1 Biometric Information Record (BIR) [BIR]. The X9.84 schema is the same as the schema defined in the XCBF and provides a support for an XML markup representation of the binary values described in the X9.84 and BioAPI-1.1 standards. Once BIR format values are represented as values of BiometricObject type they can be secured using the techniques described in the XCBF.

Service Oriented Architecture Collaboration Semantics V0.1 59

Page 65: SOA Collaboration Semantics

Semantion Inc.

16.0 References

[AIMXMLS] SOA Agent Interface Manager XML Schema http://www.semantion.com/specs/soa/aimxmls.xsd

[AMXMLS] SOA Activity Manager XML Schema http://www.semantion.com/specs/soa/amxmls.xsd

[BIMS] ANSI X9.84:2003 Biometric Information Management and Security for The Financial Services Industry http://webstore.ansi.org/

[BIR] ANSI INCITS 358-2002 - Information technology - BioAPI Specification http://webstore.ansi.org/.

[CBEFF] Common Biometric Exchange File Format http://www.itl.nist.gov/div895/isis/bc/cbeff

[CPFSXMLS] SOA Collaborative Process Flow Security Manager XML Schema http://www.semantion.com/specs/soa/cpfsmxmls.xsd

[CMS] ANSI X9.73:2002 Cryptographic Message Syntax (CMS) http://webstore.ansi.org/

[DMXMLS] SOA Decision Manager XML Schema http://www.semantion.com/specs/soa/dmxmls.xsd

[EBBPSS] ebXML Business Process Specification Schema http://www.ebxml.org/specs

[EBCPPA] ebXML Collaboration Protocol Profile and Agreement Specification (CPPA) http://www.oasis-open.org/specs

[EBRIM] ebXML Registry Information Model Specification http://www.oasis-open.org/specs

[EBRS] ebXML Registry Services Specification http://www.oasis-open.org/specs

[EMXMLS] SOA Event Manager XML Schema http://www.semantion.com/specs/soa/emxmls.xsd

[FIMXMLS] SOA Federation Identity Manager XML Schema http://www.semantion.com/specs/soa/fimxmls.xsd

[FERA] Closing the Process/Technology Gap, FERA: Federated Enterprise Reference Architecture: A Framework for Loosely Coupled Business Process Integration http://www.cpd-associates.com/index.cfm?content=subpage&file=include_RPPage.cfm&ID=72404138&DOC=177813046

[FMXMLS] SOA Federation Manager XML Schema http://www.semantion.com/specs/soa/fmxmls.xsd

[FSPMXMLS] SOA Federation Security Policy Manager XML Schema

Service Oriented Architecture Collaboration Semantics V0.1 60

Page 66: SOA Collaboration Semantics

Semantion Inc.

http://www.semantion.com/specs/soa/fspmxmls.xsd

[RTSOA] Run-time Service Oriented Architecture (SOA) Specification http://www.semantion.com/specs/soa/Run-time_SOA_V0.2.doc

[SAML] Security Assertion Markup Language (SAML) http://www.oasis-open.org/specs [SOAIM] Service Oriented Architecture Information Model (SOA IM) Specification http://www.semantion.com/specs/soa/SOA_IM_V0.2.doc

[SOAP] W3C Simple Object Access Protocol (SOAP) http://www.w3.org/TR/SOAP

[UDDI] Universal Description, Discovery and Integration (UDDI) http://www.oasis-open.org/specs

[WSBPEL] Web Services Business Execution Language (WSBPEL) http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel

[WSCHOR] WS-Choreography http://www.w3.org/2002/ws/chor

[WSCDL] Web Services Choreography Description Language (WS-CDL) http://www.w3.org/TR/ws-cdl-10

[WSDL] Web Services Description Language (WSDL) http://www.w3.org/TR/wsdl

[WSI] Web Services Interoperability (WS-I) Profiles http://www.ws-i.org/deliverables/index.aspx

[XACML] eXtensible Access Control Markup Language (XACML) http://www.oasis-open.org/specs

[XCBF] OASIS XML Common Biometric Format http://www.semantion.com/specs/soa/aimxmls.xsd

[XSD] XML Schema http://www.w3.org/XML/Schema

[XCMS] ANSI X9.96:2003 (draft) XML Cryptographic Message Syntax (XCMS) http://webstore.ansi.org/

Service Oriented Architecture Collaboration Semantics V0.1 61