EGOS LLCCCSDS

14/06 - 2006

Question

Question; Why a Service Viewpoint?

Short Answer; Because a service viewpoint provides a useful additional level of abstraction to the system model, simplifying standardization of functional interfaces.

Long Answer…

Early phase of conceptual design. Not cut in stone yet. Please Comment!

What We Want

System developers and maintainers want a modular system, based on a generic framework. Well isolated components, acting as black box providers of functionality (services).

Generic, standardized service access approach, which can be specialized for any type of service.

SOA and RM-ODP

IBM Layered Service Model.

Service API

Transfer API

Levels of Standardizations

1. Service Agreement. Contract regarding information exchanged. Gateways typically needed.

2. API Standardization. Interchangeable API’s.

3. Wire Protocol. Different API’s function together.

4. Transfer Layer Standardization. Interchangeable transfer layers.

SrviceAPIimplementation

ServiceAPI

TransferLayerImplementation

TranferAPI

SrviceAPIimplementation

ServiceAPI

TransferLayerImplementation

TranferAPI

1

2

3

4

EGOS; 1-4.

Services and Operations

Service concepts following WSDL.

A service is provided through a service interface, providing a set of service operations. Each operation is among other characterised by a Message Exchange Pattern (MEP), defining the flow of messages when the operation is executed.

A service endpoint (service object) is the realization of a service interface. The endpoint binds the service interface to a specific technology and implementation, and provides the service.

A service operation maps to one or more functional interfaces. The functional interfaces are the point where the messages are exchanged between functional components.

First source of confusion; there are two types of operations

• Service operations, used to access a service. Focus on What.

• Functional operations, used to transfer the messages of the service. Focus on How.

Close correspondence, i.e. the message of a service operation is exchanged using one or more functional operations.

Message Exchange Patterns

A Message Exchange Pattern (MEP) defines a standard template for messages exchanged between two entities, i.e. the sequence of the messages exchange. A MEP contains one or more messages flowing in any direction and any sequence between components. A MEP can therefore be seen as a basic generic procedure specificity on for the interaction with a provider.

Second source of confusion; MEP’s should not be confused with design patterns. A MEP only defines the sequence of exchange, not the architecture of the involved entities. There is therefore no architectural constrains within a MEP.

For EGOS 3 MEPs have been identified

• Datagram (in). Best effort data delivery.

• Submit (in, out). Guaranteed data delivery.

• Request-Response (in, out, out). Data query based on filter.

Message Exchange Patterns

In principle all MEP’s can be seen as build on the Datagram MEP. The Request-Response can be seen as build on a Submit, followed by a Datagram. However semantic information is lost.

The 3 basic operation MEP’s are the building block for defining the message exchange sequence of the complete service.

For example, a Event Distribution service might provide its service in a Publish-Subscribe pattern

• (in) filter message, (out) acknowledgment.

• (N*out) data messages.

• (in) stop message, (out) acknowledgment.

The service could provide the following interfaces to support this

• ‘Register:Submit (in, out)’.

• ‘Notify:Datagram (out)’.

• ‘Deregister:Submit (in, out)’.

Procedures and Automation

The operations can be choreographed using procedures. A procedure defines mainly the User side interaction.

A procedure executes the operations in a given order, typically based on the operation return status. The complete procedure can also be seen as having a MEP, being the sum of the operations.

For example a procedure could automate the invocation of the Event Distribution, by executing Register, then await the Provider Notifications, and finally Deregister. The procedure effectively have a Publisher-Subscriber MEP.

Messages

The concept of messages is of core importance. A message is a construct containing data, which is transferred through some mean between nodes. The message is specified using a platform independent format. Within the EGOS framework the EGOSMF will be used.

Each MEP is defined using a standard set of messages, where the same message is reused across MEP’s. The goal of the standard message format is to capture the information required to manage the messages.

The service specification, including the MEP specifications and sequence of data flows, are a Platform Independent Model (PIM). It neither assumes nor dictates any specific communication protocol.

While implementing a specific service endpoint, a technology mapping must be defined, mapping the PIM to a Platform Specific Model (PSM). The PSM will specify the actual communication protocol and exact format of the messages being exchanged.

EGOS identifies 9 standard messages. A specific service can specialise (extend) the messages, adding service specific information.

Functional Viewpoint

Based on the MEP, a Functional Viewpoint mapping can be defined. The mapping maps each MEP to one or more functional operations, used to actual exchange the messages. The two views are equivalent.

Notice that the functional viewpoint is still abstract, i.e. it is not a mapping to a technology.

The functional mapping defines the interface of the data exchange layer. Upon this layer, the service API can be build. The same service API may be implemented using two different mappings. This is illustrated below.

SLE Toolkit…

ServiceAPI

User

«interface»

Explicit

+ Request() : void+ ReceiveResponse() : void+ CollectResponse() : void

ChannelOne

«interface»

Implicit

+ get() : void+ set() : void

«abstract»

TCPIPchannel

«abstract»

CORBAchannel

«realize»«realize»

Functional Viewpointcd MEP to Function Interfaces

Functional Viewpoint (Component Diagram)

Functional Viewpoint (Analysis diagram)

Service Viewpoint

ConfigurationAccess UserManager

«serviceOperation»

Interface Identification::getConfigurationData

- Request: ConfigurationIdentifierMessage- Response: SourceDataEntryMessage

tagsmesagePattern = REQUEST-RESPONSE

«serviceObject»

Serv iceObjects::ConfigurationAccess

«operation»

ConfigurationAccess

+ ReceiveResponse() : void

«operation»

ConfigurationAccess

+ Request() : void+ CollectResponse() : void

ConfigurationAccess

ConfigurationAccessUserManager

«serviceRealize»

«realize»

«realize»«use»

«use»

Technology Viewpoint

The Functional Viewpoint is mapped to specific technologies and protocols.

Because a discreet set of functional operations exist to support the service operations, the interface can be standardized.

ServiceAPI

User

«interface»

Explicit

+ Request() : void+ ReceiveResponse() : void+ CollectResponse() : void

ChannelOne

«interface»

Implicit

+ get() : void+ set() : void

«abstract»

TCPIPchannel

«abstract»

CORBAchannel

«realize»«realize»

Service API and RM-ODP Channel

Price;

• Loss of the freedom (explicit data model) when using middleware such as CORBA, i.e. CORBA becomes a message bus.

Benefits;

• Allows the operation to carry a distinct meaning.

• Allows the use of standard templates for services.

• Simplifies automated testing.

• Simplifies the interfaces specification and implementation.

• Simplifies the understanding of interfaces.

• Can be implemented for all protocols, ‘adding’ an abstraction layer to TCP/IP and encapsulating the CORBA abstraction layer (see next slide).

• Follows the concepts from CCSDS very closely.

Data Model

Explicit Data Model (I.e. CORBA)Implicit Data Model (I.e. TCP/IP and IIOP)id Example

Distributor

«interface»

Connection

+ getMessage() : void+ setMessage() : void

Distributor

«interface»

Packet

+ register() : void+ retrievePerformanceData() : void+ sendPacket() : void

«interface»

Parameter

+ register() : void+ sendParameter() : void+ resetValidity() : void

«realize»

«realize»

«realize»

Message identifies the operation.

Message is interpreted by receiver and ‘multiplexed’ to the appropriate operation.

Message contains the parameters.

The operation invoked defines the operation type.

Operation contains the parameters.