SOA Collaboration Semantics

299 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
299
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

SOA Collaboration Semantics

  1. 1. Service Oriented Architecture Collaboration Semantics (SOA CS) V 0.1 October 2005
  2. 2. 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....................................................................................................................................................6 7.2 COLLABORATIVE PROCESS............................................................................................................................6 7.3 MONITORING AND REPORTING.......................................................................................................................7 7.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..............................................................................................................10 9.1.1 auditCommunication.....................................................................................................................10 9.1.2 authenticateSubject.......................................................................................................................10 9.1.3 contentTransformation..................................................................................................................10 9.1.4 contentValidation..........................................................................................................................11 9.1.5 createAssociation..........................................................................................................................11 9.1.6 createVersion................................................................................................................................11 9.1.7 delegateAgent................................................................................................................................11 9.1.8 deployCPID...................................................................................................................................12 9.1.9 findInitiatorByCPFlow..................................................................................................................12 9.1.10 findInfoReferenceByType............................................................................................................12 9.1.11 findProfileByFederate.................................................................................................................12 9.1.12 findProtocolByAgent...................................................................................................................13 9.1.13 getContent...................................................................................................................................13 9.1.14 getContentElement......................................................................................................................13 9.1.15 getContentElementAttribute........................................................................................................13 9.1.16 getFederate..................................................................................................................................13 9.1.17 getMessageRequestType..............................................................................................................14 9.1.18 getMessageType..........................................................................................................................14 9.1.19 registerFederate..........................................................................................................................14 9.1.20 removeObjects.............................................................................................................................14 9.1.21 sendMail......................................................................................................................................14 9.1.22 sendMessage................................................................................................................................15 9.1.23 setReference................................................................................................................................15 9.1.24 subjectAuthorized........................................................................................................................15 9.1.25 submitCollaborationProfile........................................................................................................15 9.1.26 submitCPID.................................................................................................................................16 9.1.27 submitDocument..........................................................................................................................16 Service Oriented Architecture Collaboration Semantics V0.1
  3. 3. Semantion Inc. 9.1.28 submitObjects..............................................................................................................................16 9.1.29 submitQuery................................................................................................................................17 9.1.30 updateAgentDelegation...............................................................................................................17 9.1.31 updateCPID.................................................................................................................................17 9.1.32 updateObjects..............................................................................................................................17 10.0 AGENT INTERFACE MANAGER...................................................................................................18 10.1 AGENT INTERFACE MANAGER METHODS....................................................................................................19 10.1.1 createAssociation........................................................................................................................19 10.1.2 delegateAgent..............................................................................................................................19 10.1.3 escalateAgent..............................................................................................................................19 10.1.4 findProtocolByAgent...................................................................................................................20 10.1.5 invokeAgent.................................................................................................................................20 10.1.6 monitorAgent...............................................................................................................................20 10.1.7 removeObjects.............................................................................................................................21 10.1.8 sendMessage................................................................................................................................21 10.1.9 submitObjects..............................................................................................................................21 10.1.10 submitQuery..............................................................................................................................21 10.1.11 updateAgentDelegation.............................................................................................................22 10.1.12 updateObjects............................................................................................................................22 11.0 FLOW CONTROLLER MANAGER PROTOCOL AND INTERFACE......................................22 11.1 FLOW CONTROLLER MANAGER METHODS..................................................................................................25 11.1.1 checkArguments..........................................................................................................................25 11.1.2 createAssociation........................................................................................................................25 11.1.3 createStage..................................................................................................................................26 11.1.4 deployCPID.................................................................................................................................26 11.1.5 findActivityByParent...................................................................................................................27 11.1.6 findArgumentByRule...................................................................................................................27 11.1.7 findChoiceByParent....................................................................................................................27 11.1.8 findByInput..................................................................................................................................28 11.1.9 findByOutput...............................................................................................................................28 11.1.10 findDecisionByParent...............................................................................................................28 11.1.11 findEventByParent....................................................................................................................29 11.1.12 findInputByParent.....................................................................................................................29 11.1.13 findOutputByParent..................................................................................................................29 11.1.14 findMatrix..................................................................................................................................29 11.1.15 findMatrixByInput.....................................................................................................................30 11.1.16 findProtocolByAgent.................................................................................................................30 11.1.17 findStageByParent.....................................................................................................................30 11.1.18 getArgumentValue.....................................................................................................................30 11.1.19 getContent.................................................................................................................................31 11.1.20 getContentElement....................................................................................................................31 11.1.21 getContentElementAttribute......................................................................................................31 11.1.22 getRuleContent..........................................................................................................................31 11.1.23 removeObjects...........................................................................................................................31 11.1.24 resetReference...........................................................................................................................32 11.1.25 sendMessage..............................................................................................................................32 11.1.26 setReference..............................................................................................................................32 11.1.27 submitObjects............................................................................................................................33 11.1.28 submitQuery..............................................................................................................................33 11.1.29 updateAgentDelegation.............................................................................................................33 11.1.30 updateCPID...............................................................................................................................33 11.1.31 updateObjects............................................................................................................................34 12.0 ACTIVITY MANAGER PROTOCOL AND INTERFACE............................................................34 Service Oriented Architecture Collaboration Semantics V0.1
  4. 4. Semantion Inc. 12.1 ACTIVITY MANAGER METHODS................................................................................................................36 12.1.1 createAssociation........................................................................................................................36 12.1.2 createStage..................................................................................................................................37 12.1.3 getPredecessor............................................................................................................................37 12.1.4 getRole.........................................................................................................................................37 12.1.5 getSuccessor................................................................................................................................38 12.1.6 outputsAvailable..........................................................................................................................38 12.1.7 sendMessage................................................................................................................................38 12.1.8 setPredecessor.............................................................................................................................38 12.1.9 setSuccessor................................................................................................................................39 13.0 DECISION MANAGER PROTOCOL AND INTERFACE............................................................39 13.1 DECISION MANAGER METHODS................................................................................................................41 13.1.1 createAssociation........................................................................................................................42 13.1.2 createStage..................................................................................................................................42 13.1.3 getPredecessor............................................................................................................................42 13.1.4 getRole.........................................................................................................................................43 13.1.5 getSuccessor................................................................................................................................43 13.1.6 outputsAvailable..........................................................................................................................43 13.1.7 sendMessage................................................................................................................................43 13.1.8 setPredecessor.............................................................................................................................43 13.1.9 setSuccessor................................................................................................................................44 14.0 EVENT MANAGER............................................................................................................................44 14.1 EVENT MANAGER METHODS....................................................................................................................47 14.1.1 createAssociation........................................................................................................................47 14.1.2 createProcedureConfirmation....................................................................................................48 14.1.3 createStage..................................................................................................................................48 14.1.4 getAction......................................................................................................................................48 14.1.5 getActionStatus............................................................................................................................49 14.1.6 getActionType..............................................................................................................................49 14.1.7 getMessage..................................................................................................................................49 14.1.8 getPredecessor............................................................................................................................49 14.1.9 getPublisher................................................................................................................................50 14.1.10 getSubscriber.............................................................................................................................50 14.1.11 getSuccessor..............................................................................................................................50 14.1.12 getTriggerType..........................................................................................................................50 14.1.13 sendMessage..............................................................................................................................50 14.1.14 setPredecessor...........................................................................................................................51 14.1.15 setPublisher...............................................................................................................................51 14.1.16 setSubscriber.............................................................................................................................51 14.1.17 setSuccessor..............................................................................................................................51 15.0 SECURITY PROVIDER.....................................................................................................................52 15.1 COLLABORATIVE PROCESS FLOW SECURITY MANAGER METHODS .................................................................53 15.1.1 findPolicyByResource.................................................................................................................53 15.1.2 findProfileByFederate.................................................................................................................53 15.1.3 getPolicyFromLPAD...................................................................................................................54 15.1.4 getRemotePolicy..........................................................................................................................54 15.1.5 sendMessage................................................................................................................................54 15.2 FEDERATION IDENTITY MANAGER METHODS...............................................................................................54 15.2.1 authenticateSubject.....................................................................................................................55 15.2.2 sendMessage................................................................................................................................55 15.3 FEDERATION SECURITY POLICY MANAGER METHODS...................................................................................55 15.3.1 sendMessage................................................................................................................................55 Service Oriented Architecture Collaboration Semantics V0.1
  5. 5. Semantion Inc. 15.3.2 subjectAuthorized........................................................................................................................55 15.4 SOA SECURITY BINDING.........................................................................................................................56 15.5 STANDARD SECURITY COMPONENTS...........................................................................................................56 15.5.1 SSL ..............................................................................................................................................56 15.5.2 Web Services Security.................................................................................................................57 15.5.3 SAML...........................................................................................................................................57 15.5.3.1 SAML Applications...................................................................................................................58 15.5.4 XACML........................................................................................................................................58 15.5.5 XCBF...........................................................................................................................................59 16.0 REFERENCES.....................................................................................................................................60 Service Oriented Architecture Collaboration Semantics V0.1
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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 Engine o OASIS ebXML Business Process Specification Scheme (BPSS) [EBBPSS] o OASIS ebXML Collaboration Protocol Profile and Agreement (CPPA) [EBCPPA] • Web Services Collaborative Engine o 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
  11. 11. 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
  12. 12. 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
  13. 13. 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 Request o Federation Registry Request with attachment(s) o Federation Registry Request without attachment(s) o Process Flow Registry Request • Registry Response o 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 Service Oriented Architecture Collaboration Semantics V0.1 8
  14. 14. Semantion Inc. 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 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. Service Oriented Architecture Collaboration Semantics V0.1 9
  15. 15. Semantion Inc. 9.1 Federation Manager Methods 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 Required audit This argument provides an String Yes XML form of an audit that will be created. 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 Required subject Subject’s identity and its Subject Yes security related attributes (e.g., password or digital certificate). 9.1.3 contentTransformation The contentTransformation transforms an XML document to another format. Argument Description Data Type Required id An id of a document. String256 Yes fromFormat A format which document String256 Yes will be transformed from. If the document’s format is known from its content, this argument is not mandatory. toFormat A format which document String256 Yes will be transformed to. This argument is not mandatory if the rule argument is provided. rule A reference to a rule if the String256 No rule is used to transform the format of the document. Service Oriented Architecture Collaboration Semantics V0.1 10
  16. 16. Semantion Inc. 9.1.4 contentValidation The contentValidation validates the content of an XML document. Argument Description Data Type Required id A document id. String256 Yes rule A reference to a rule if the String256 No rule is used to validate the document format. 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 Required association This argument provides an String Yes XML form of the Association that will be created with all required elements and attributes. 9.1.6 createVersion The createVersion creates new version of the specified document. Argument Description Data Type Required id A document id. String256 Yes version New document version. If String8 No this argument is not specified, the next default version value will be generated. 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 Required delegateAgent This argument provides an String Yes XML form of the delegateAgent request. Service Oriented Architecture Collaboration Semantics V0.1 11
  17. 17. 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 Required cpid This argument provides an id String256 Yes of a CPID that will be deployed. version This argument provides a String256 No 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. 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 Required collaborativeProcessFlow The id of a collaborative String256 Yes process flow which initiator will be returned. 9.1.10 findInfoReferenceByType The findInfoReferenceByType returns all informational references with a specified type Argument Description Data Type Required type The type of the informational String256 Yes reference. 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 Required federate The id of a federate which String256 Yes profile will be returned. Service Oriented Architecture Collaboration Semantics V0.1 12
  18. 18. Semantion Inc. 9.1.12 findProtocolByAgent The findProtocolByAgent returns a protocol associated with an agent. Argument Description Data Type Required agent This argument provides an id String256 Yes of an SOA IM Agent entity which protocol will be retrieved. 9.1.13 getContent The getContent returns the content of an XML document. Argument Description Data Type Required id A document id. String256 Yes 9.1.14 getContentElement The getContentElement returns the value of an XML document element. Argument Description Data Type Required id A document id. String256 Yes element 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 Required id A document id. String256 Yes element An XML element. String256 Yes attribute 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 Required federate The id of the federate which String256 Yes will be returned. Service Oriented Architecture Collaboration Semantics V0.1 13
  19. 19. Semantion Inc. 9.1.17 getMessageRequestType The getMessageRequestType returns the type of a message request. Argument Description Data Type Required messageRequest The content of the XML String Yes message request. 9.1.18 getMessageType The getMessageType returns the type of a message. Argument Description Data Type Required message The content of an XML String Yes message. 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 Required federate A federate related String Yes informational details in an XML form. 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 Required request An XML request that String Yes contains a list of SOA IM objects’ ids that will be removed from the Federation Registry and/or the Process Flow Registry. 9.1.21 sendMail Service Oriented Architecture Collaboration Semantics V0.1 14
  20. 20. Semantion Inc. The sendMail sends an email note to a Federate. Argument Description Data Type Required addressList A list of email addresses String256 Yes which the note will be sent to. subject An email note’s subject. String256 Yes note 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 Required message An XML-based message. String Yes destination A destination which this String256 Yes message will be sent to (the Flow Controller Manager, the Agent Interface Manager, the Federation Registry, the Security Provider, or the Gateway interface). 9.1.23 setReference The setReference sets the value attribute of the informational reference. Argument Description Data Type Required id The id of the informational String256 Yes reference. value A URL value (document’s String256 Yes reference) 9.1.24 subjectAuthorized The subjectAuthorized checks if the already authenticated subject is authorized for the submitted request. Argument Description Data Type Required id Subject’s identity (principal). String256 Yes request An XML request. String Yes 9.1.25 submitCollaborationProfile Service Oriented Architecture Collaboration Semantics V0.1 15
  21. 21. 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 Required profile The id of the collaboration String256 Yes profile. content An XML content of the String Yes profile. CPPA, WSDL and WS-CDL are examples of collaboration profiles that are supported. 9.1.26 submitCPID The submitCPID stores CPID and CPIDStartInfo document in the Federation Registry. Argument Description Data Type Required content The CPID or the String Yes CPIDStartInfo XML content. type The type of the document String256 Yes (CPID or CPIDStartInfo). 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 Required document A document’s content in any Content Yes digital format. 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 Required request An XML request that String Yes contains SOA IM objects that will be submitted to the Federation Registry and/or the Process Flow Registry. Service Oriented Architecture Collaboration Semantics V0.1 16
  22. 22. 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 Required request An XML query request that String Yes belongs to the Federation Registry and/or the Process Flow Registry. 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 Required agentEntities A list of agent related entities String Yes in an XML form. 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 Required cpid This argument provides the id String256 Yes of the CPID that will be updated. updateRequest This argument provides an String Yes XML request that contains all new and/or modified collaborative entities that will be submitted. 9.1.32 updateObjects Service Oriented Architecture Collaboration Semantics V0.1 17
  23. 23. 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 Required request An XML request that String Yes contains a list of SOA IM objects that will be updated in the Federation Registry and/or the Process Flow Registry. 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
  24. 24. 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 Required association This argument provides an String Yes XML form of the Association that will be created with all required elements and attributes. 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 Required delegateAgent This argument provides an String Yes XML form of the delegateAgent request. 10.1.3 escalateAgent Service Oriented Architecture Collaboration Semantics V0.1 19
  25. 25. 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 Required agent The id of an agent that is not String256 Yes available. 10.1.4 findProtocolByAgent The findProtocolByAgent returns a protocol associated with an agent. Argument Description Data Type Required agent This argument provides an id String256 Yes of the SOA IM Agent entity which protocol will be retrieved. 10.1.5 invokeAgent The invokeAgent sends a message with an agent request to the Agent Framework. Argument Description Data Type Required agentRequest This argument provides an String Yes XML form of the agent request. protocol This argument provides an String Yes XML form of a protocol for the communication with the Agent Framework. 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 Required agentList This argument provides a list Set Yes of ids for agents that will be monitored. pollingPeriod A period of time for which String256 No Service Oriented Architecture Collaboration Semantics V0.1 20
  26. 26. 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 Required request An XML request that String Yes contains a list of SOA IM objects’ ids that will be removed from the Federation Registry and/or the Process Flow Registry. 10.1.8 sendMessage The sendMessage sends a message to the Federation Manager or the Agent Framework. Argument Description Data Type Required message An XML-based message. String Yes destination A destination which this String256 Yes message will be sent to. 10.1.9 submitObjects The submitObjects sends a message with a SubmitObjects request to the Federation Manager. Argument Description Data Type Required request A SubmitObjects request that String Yes will be submitted to the Federation Manger. 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
  27. 27. Semantion Inc. Argument Description Data Type Required request An XML-based query request String Yes that will be submitted to the Federation Manager 10.1.11 updateAgentDelegation The updateAgentDelegation sends a message with an UpdateAgentDelegation request to the Federation Manager. Argument Description Data Type Required agentEntities A list of agent related entities String Yes in an XML form. 10.1.12 updateObjects The updateObjects sends a message with an UpdateObjects request to the Federation Manager. Argument Description Data Type Required request An UpdateObjects request String Yes that will be submitted to the Federation Manager. 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
  28. 28. 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: Service Oriented Architecture Collaboration Semantics V0.1 23
  29. 29. Semantion Inc. • 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 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 Service Oriented Architecture Collaboration Semantics V0.1 24
  30. 30. Semantion Inc. 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 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 Required rule This argument provides an id String256 Yes of the SOA IM Rule entity which arguments will be retrieved. 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 Required association This argument provides an String Yes XML form of the Association that will be created with all required elements and attributes. Service Oriented Architecture Collaboration Semantics V0.1 25
  31. 31. Semantion Inc. 11.1.3 createStage The createStage creates a Stage entity for a collaborative process flow. 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 Required stage This argument provides a String Yes stage in an XML form. 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 Required cpid This argument String256 Yes provides an id of a CPID that will be deployed. collaborativeProcessFlowList This argument Set No 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 Service Oriented Architecture Collaboration Semantics V0.1 26
  32. 32. Semantion Inc. collaborative process flows and their related entities will be deployed. version This argument String256 No 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. 11.1.5 findActivityByParent The findActivityByParent returns all activities related to either a collaborative process or a collaborative process flow. Argument Description Data Type Required collaborativeEntity This argument provides an id String256 Yes of the collaborative entity which activities will be retrieved. The collaborative entity can be either a collaborative process or a collaborative process flow. 11.1.6 findArgumentByRule The findArgumentByRule returns the list of arguments used in a rule. Argument Description Data Type Required rule This argument provides an id String256 Yes of the SOA IM Rule entity which arguments will be retrieved. 11.1.7 findChoiceByParent The findChoiceByParent returns choices associated with a decision. Argument Description Data Type Required decision This argument provides an id String256 Yes of a decision which choices Service Oriented Architecture Collaboration Semantics V0.1 27
  33. 33. Semantion Inc. will be retrieved. 11.1.8 findByInput The findByInput returns collaborative entities associated with a specified input. Argument Description Data Type Required input This argument provides the String256 Yes input’s id. type This argument provides the String256 Yes type of the returned collaborative entities and its value can be Activity, Decision, Trigger or All. 11.1.9 findByOutput The findByOutput returns a collaborative entity that creates a specified output. Argument Description Data Type Required output This argument provides the String256 Yes output’s id. type This argument provides the String256 Yes type of the returned collaborative entities and its value can be Activity, Decision, Trigger or All. 11.1.10 findDecisionByParent The findDecisionByParent returns all decisions related to either a collaborative process or a collaborative process flow. Argument Description Data Type Required collaborativeEntity This argument provides an id String256 Yes of the collaborative entity which decisions will be retrieved. The collaborative entity can be either a collaborative process or a collaborative process flow. Service Oriented Architecture Collaboration Semantics V0.1 28

×