Service Layer Modeling improvements Aurelijus Morkevicius 1 Definition

#1 Definition of the contract • There needs to be a way to capture

#1 Proposal • Service Contract should have a derived tag to collect all exchanges

#2 Service Consumers • Existing Consumes relationship between Service Specification and Operational Activity are

#3 Use of Services in the Resources Domain • There needs to be a

#3 Proposal The question is if it is data only? What about energy, people,

#3 Use of Services in the Resources Domain • Another way to solve the

#4 Service Exchange • Breaking the pattern • Multiple requests by user community

#5 Service Capability • Service Capability to replace Capability in the Service Domain. •

#5 Need for Service Architecture • Just like Operational Architecture and Resource Architecture, the

#6 Introduction of Service Agent concept • Service Agent to implement performer and to

Notes • We decided to introduce Capabilities at almost every domain. Starting from Capability

Slides: 26

Download presentation

Service Layer Modeling improvements Aurelijus Morkevicius

#1 Definition of the contract • There needs to be a way to capture a need for a contract in the operational connectivity diagram • Contract is context specific so it cannot be port • Contract is collection of operational exchanges which makes operational connector to be the closest concept • Possible solutions; • Add tag to operational connector to associate it with the contract. Contract would be a class (disconnected from the existing service model). • Solve this by having special type of exchange composed of other exchanges (limitation is that the exchange cannot be bidirectional). • Add contract as a subtype of rule (UML constraint) which would constrain either exchanges or the connector. In case of exchange we loose context specific use. • What are the characteristics we need to define for the contract? SLA

#1 Proposal • Service Contract should have a derived tag to collect all exchanges from all constrained connectors • Service contract is implemented by Service Specification?

#1 Proposal (2)

#2 Service Consumers • Existing Consumes relationship between Service Specification and Operational Activity are causing some issues. • We connect structure with behavior of different domains and break the pattern • Relationship is facing wrong direction causing circular references in the model repository. • Who can consume services in the operational domain? • • Operational Activity (Operational Activity link to Service Function only) Operational Performer? Operational Role and the Connector. Contract can solve this question. Derived tag needed to collect consumers for the contract.

#3 Use of Services in the Resources Domain • There needs to be a way to show service use in the Resources domain. • One of the ways to solve the problem is to allow service interfaces to type resource ports. • This would require Data Elements to be used in the Service Domain to keep consistency. (Currently Information Elements are used). • There is a possibility to add Service Data Element as a subtype of Data Element which could contain Data Elements as parts. • The question is if it is data only? What about energy, people, etc. We need all types of resources • Is Service Signal concept needed? Yes

#3 Proposal The question is if it is data only? What about energy, people, etc. We need all types of resources

#3 Use of Services in the Resources Domain • Another way to solve the problem is to improve traceability between service and resource layer. • This would not require Data Elements to be used in the Service Domain. • This would require to have implements relationships between participants and resources, service interfaces and resource interfaces, service exchanges and resource exchanges.

#4 Service Exchange • Breaking the pattern • Multiple requests by user community

#5 Service Capability • Service Capability to replace Capability in the Service Domain. • Link from Service Capability to Capability • Link from Feature (Resource Capability) to Service Capability and Strategic Capability (Exhibits? Containment, Composition, Implements? ) • Feature, Competence, Service Capability should replace Capability? • Requirements Row to include Features and Service Capabilities?

#5 Proposal Services Traceability

#5 Need for Service Architecture • Just like Operational Architecture and Resource Architecture, the concept of Service Architecture is needed. • Provide context for services to collaborate • Version • Provide traceability to the specific Enterprise Phase (related to above)

#5 Proposal

#6 Introduction of Service Agent concept • Service Agent to implement performer and to be implemented by the resource. • How to relate service agent with Service spec. ?

Services View Specifications

Services Taxonomy

Services Structure

Services Connectivity

Services Processes

Services Interaction Scenarios

Services States

Services Information?

Services Constraints

Services Roadmap

Services Traceability

Notes • We decided to introduce Capabilities at almost every domain. Starting from Capability (exhibited by operational), Core Competence, Services Capability (service specification), Resource Capability (resources), Competence (human resourses only). • Services will be able to exchange all types of resources (not only data) • Service Signal needs to be added. Must be compatible to the resources signal. • Requirements will become the first row in the grid (we have separate issue in JIRA) • Relationship between different types of Capabilities has not been decided yet. • Security Architecture element will be added to the spec. Separate issue will be raised on JIRA.