1. EA framework service description Swedish Defence Materiel Administration Examples & technical approach Enterprice Architecture By Peder Blomqvist

2. Framework service description
This framework for service description contains rules for how a service including messages, protocols, properties and achievements shall be described and documented

3. Model
The meta-model of the basic concepts is shown in the following diagram:
Note: Any dependency between class service operation and a message format definition package has been suppressed in this version, may have to be added in future versions.
In addition to the documentation with the associated templates, modeling efforts should be done to describe a service. The structure of this model is described in this section. For details, see design rules defined for each element.
To explain how the modeling shall be performed, a meta-model is used. This meta-model contains UML classes that represent concepts that will be captured in a model of the service description. In the actual model of a specific service, UML classes will not be used to represent all of the specific concepts; instead the meta-model will explain what types of UML elements and stereotypes that will be used. The explanation of the type of UML element that will be used in the specific model is done through stereotypes on the meta-model classes.

4. Diagrams and relations
In addition to the basic concepts, diagrams are used to describe specific aspects of the basic concepts. These diagrams and the relations to basic concepts are shown in the following figure:
The figure shows that the UML diagram types may be used whenever needed to explain specific aspects of the service description. In addition to these diagrams, the service overview diagram is defined below.
Each of the classes in the meta-model diagrams corresponds to model elements in the service description. The stereotypes of the classes in the meta-model diagram describe what type of UML model element that should be used. These model elements are described in sections below.

5. Service Description Package
The service metadata is used for administration and service management. The service metadata is specified for the service definition package, e g in terms of UML tagged values on this package.
The service metadata includes
Identity
Version Number
Quality of service

6. Service
Classes stereotyped with the word Service represent the services.
The purpose of the UML class that represents the service is to link all of the information related to a service. Each of these related pieces of information is described in separate sections of this document.
Services may contain activity diagrams and/or state diagrams showing interesting aspects of the service. The state diagrams can, for example, be used to describe the life-cycle of a specific service.

7. Service Attributes/Properties
The properties are divided in groups, roughly related to the relevance to various group during the service lifecycle.
Business/Functional properties (the functional, business designer):
·     Reference to the specification of achievement is one service attribute.
·     Attributes for the classification of the service, e.g. according to LOVNETP
·        Modes of interoperation
One way usage
Request/reply
Publish/subscribe
Transaction
Conversation (two way dialog)
Events
Streaming information
Message queue/service bus
Exceptions
Performance attributes for the service
System Engineering/Implementation/Operational attributes:
Information security mechanism
Communication binding
Quality of service provisions and measures

8. Service interface
In the general case, the services provide two interfaces to the outside world, the producer interface and the consumer interface. These interfaces represent roles that actual consumers and producers will play when the service is instantiated.

9. Relationship
The relationship between a service and its corresponding service interfaces is a UML realize relationship. The reason for this is that the service interfaces defines the contract for the service. These UML realize relationships are stereotyped with <<producer>> and <<consumer>> as shown in the following diagram.
Note: The producer interface is mandatory, while the consumer interface is optional, as defined by the service specification.

10. Service interface
The service interfaces may have operations. These operations mean that any system element that will play the role of producer or consumer in a service realization will be forced to provide these operations, as these operations will be called when the service is fulfilled.
In addition to operations, the Service Interfaces may also have attributes. These attributes mean that any system element that will play the role of producer or consumer in a service realization will be forced to keep track of the information that is specified by the attributes.
The following figure shows how attributes and operations are indicated on a service interface. The two examples are shown in icon format and decoration format, and the attributes and operations are shown by the examples ‘An attribute’ and ‘An operation’.
Note: For services presented directly to users, a definition of the way the information in the operations are presented to the operator has to be included. Present method for service description is not fully applicable for the definition of services directed towards the operator. This topic will be addressed in the forthcoming usability work.

11. Service Interface Attributes
Service interface attributes (or properties) contain information about things that are specific for a producer implementation of a service. A consumer may in the same way have attributes, which the producer can request to find out properties related to the consumer. The attributes are the only way two implementations of a service may differ seen from the service description viewpoint (the implementation is typically different).
Attributes may be read-only. In some cases they can be writeable, i.e. the consumer can set producer attributes and it can even be possible for the producer to in some cases set consumer attributes. The attributes can be retrieved both by the producer and the consumer, through the operations provided through the service interface. Operations provided can be query, read and modify.
Attributes shall have well defined ranges or list of possible values according to the datatype definition in the service description language used for interaction with the service itself or the service repository. Attributes are available in two ways:
They can be published in service repositories and in service catalogues.
They are available through methods in the interfaces, Get methods for reading and for writeable attributes Set methods.
A DRP Service Design shall give the directives and advices concerning the selection and the definition of service interface attributes. The DRP Service Design has not been elaborated yet.

12. Relationship to information exchange model
As a result of the execution of operations on the service interfaces, information is exchanged between the producer and the consumer of the service. This information should be in a format, defined in some information exchange model.
This relationship is shown in the model of the service in the following way:
The service interface has a dependency to the information entity class. This way we are able to use this dependency to get control over changes and reuse. If the information definition is changed, we can follow the dependency backwards to the service interface to see if this service interface needs to be changed also. We can also follow the dependency relationship forward from the service interface to the information entity class to see that we cannot reuse the service interface (or the service) without also having access to the information definition.
If there is a relationship between a service interface and an information entity class, a corresponding relationship from the owning packages of the service interface and information entity class must also be defined.

13. Protocol
The protocols describe modes of interaction between the producer and consumer of a service. For one service, there may be more than one protocol, if there is more than one mode of interaction specified. The producer must implement all protocols defined, while it may be sufficient for the consumer to support one protocol if this is explicitly allowed for.
Note: Subclasses shall be used to implement new versions of a service. The service subclass shall implement all its parent protocols. Lifecycle management of services, e.g. removal of old versions, is an issue for the configuration management and not the service description.

14. The relationship between the protocol and its service is a UML dependency as shown in the following figure:
The protocols contain UML diagrams showing how the flow of messages between the producer, consumer and also showing a possible state-machine of the protocol. These diagrams may be sequence diagrams, collaboration diagrams, activity diagrams and/or state diagrams.
For each protocol, multiple flows may be defined. There is one basic flow that covers the way the protocol is designed to work, but there may be many variations of this flow, and those are covered in alternate flows. This corresponds to the idea of multiple flows in a use-case. If sequence or collaboration diagrams are used to describe the interaction, one diagram per non-trivial flow is needed. If, on the other hand, activity diagrams are used to describe the interaction, all flows may be combined into one activity diagram showing the whole picture.

15. Service Generalizations
The UML concept of Generalizations may be used between services. The generalization between two services means that the child service[1] inherits everything that is defined by the parent service. For services this means that service attributes, service interface descriptions, protocols and achievements are inherited if they are defined by the parent service.
The child service may or may not extend what is inherited from the parent service. The following diagram shows a few examples of how this can be done:
In the diagram above, we see that the parent service defines an achievement, a protocol and two service interfaces.
The non-extending child service specializes the parent service, but does not extend or redefine any of the inherited things. This can be seen from the diagram because it does not have any extra descriptions. This means that the non-extending child service has the same descriptions of achievement, protocol and service interfaces as the parent service.
The extending child service extends the producer service interface. This can be seen from the diagram because the extending child service defines its own producer interface (in the same way as a redefinition) but the producer serviced interface inherits from the producer service interface of the parent service. This means that the extending child service uses the extended producer which contains all of the descriptions of service interface attributes and operations from the parent producer but also extends this with some of its own.

16. Service Overview Diagram
The service description package shall contain one UML class diagram that shows the service and its associated protocols, service interfaces and achievements.
An example of such a diagram is shown below:

17. Service Group
A Service group represents, as implied by its name, a group of services. The service group concept may be used to simplify models and for management purposes. For example, the service group concept may be used if one system produces or consumes many services. In this case it would not be easy to handle a model that shows all of these connections between all of the services and the system. Instead we can create a service group that groups the services and indicate that the system produces or consumes the whole service group. The semantics of having a system producing or consuming a service group would be exactly the same as having the system producing or consuming all of the services inside the group.
Please note that the purpose of the groups is to make the modeling easier and the models better structured. The process must be to decide on system boundaries first, independently on any service groups, and thereafter grouping services into suitable groups. We do not want the situation where the boundaries of service groups control where the boundaries of systems are.

18. Service Group Diagram
To show what services are contained in a service group, a service group diagram may be used. This diagram would show UML aggregate relationships between a service group and the services that it contains. An example service group diagram is shown below:

19. Achievement Description Package
Achievements are stored in a UML package that is separate from the service description package. The reason for this is that achievements may be shared between services.

20. Achievement
Achievements represent the result of the execution of a service.
The achievements may be shared between services, I e several services may have the same achievement, but perform it in different ways.
The actual achievement will appear when an actual consumer and an actual producer collaborate in a service.
Achievements may have attributes. These attributes represent a set of information that will be provided with specific values when the service is executed. The attribute values may be limited by the achievement itself, by the combination of the achievement with a specific service and/or by the combination of specific producers and consumers with a service that in turn is combined with the achievement.

21. Achievements are related to services by means of UML dependencies as indicated in the following figure.
An achievement may be an aggregate of several sub achievements, but it shall be the purpose of the service to generate all these achievements. Selection between different possible achievements shall be made by the application, not from within the service in order to make the service as reusable and implementable as possible.

22. Service utilization package : Session
Session is a conceptual framework for establishing the connection between the consumer and the producer, including authorization, communication binding, security mechanisms etc.
One session can handle the full use of a service. Optionally, a session containing more than one service is allowed. In this case the session should establish authorization to use a set of services rather than a single service.
Sessions are part of the infrastructure and implementation rather than the definition of services from a business viewpoint, but may have to be considered while defining the granularity of a service. A producer may e.g. offer a selection of basic services that the consumer is assumed to assess from within a single session.
The actual implementation of the session framework depends upon the selection of the underpinning technology for implementing the service concept and the required security mechanisms.

23. Session attributes Examples on possible session attributes are:
·  Session id
·  Credentials or authorization information for a set of services
·  Log
·  Accounting
·  Security mechanism
Communication binding

24. Service description language
The Service description language shall describe the service interface provided to a service consumer through a collection of information that describes the interaction with a service, the protocols used and the address to the service. The service description language is described in a generic way addressing the architecture level of the service concept. Implementing a service oriented architecture in a specific technology requires an adaptation of the generic service description to the prevalent language for the specific technology selected, e.g. WSDL for Webservices and IDL for CORBA.

25. Service description language

26. Example
Two examples are given. First a simple service example to explain the basic concepts of the service description and then an example to show a service generalization
A simple example of a service is given. The example is about taxi transportation. The service overview diagram is shown below:
From the service overview diagram we can see that the service is the taxi service itself.
The achievement in this service is some sort of transportation. It is necessary to separate the service and the achievement because there may be many other services providing this achievement, e.g. shipping, airplane services, bus services etc. The transportation achievement has some attributes indicating what is actually achieved, in this example some load is moved from a position to another position. The taxi service puts some limitations on the values of these attributes, as the taxi service cannot do all kinds of transportations.
The service interfaces shows us who are involved in the taxi service. In this case it is a taxi company and a taxi customer. We can see some attributes of these interfaces, meaning that taxi companies must keep track of its safety record to be allowed to perform taxi services, and the taxi customer must have some payment ability in order to be allowed to use the taxi service.

27. Example
There are two protocols defined in the service overview diagram, since there are two ways of interacting in a taxi service. The first one is a preordered taxi service, where the customer calls ahead and orders a taxi, and the other one is the unplanned protocol where a customer stops a taxi on the street.
Inside these protocols, we find sequence diagrams showing us how the interaction between the producer and consumer is supposed to happen. The diagram for the preordered taxi is shown below

28. Example
A corresponding sequence diagram can also be found in the protocol for the unplanned taxi:

29. Service generalization example
To show an example of a service generalization, we look at some general services provided by all warfighters. For this example we say that the warfighters may provide the services of Moving, Taking terrain and Holding terrain. The difference between these services is the achievements produced, but the protocol and service interfaces are much the same (at least on a high level). Therefore we may introduce a general service called Perform warfighter task, as indicated by the following diagram:
The achievements are omitted from the diagram above.
The diagram above means that the services Move, Take and Hold abide by the Standard operating procedure protocol and the service interfaces of Warfighter commander and Warfighter.

30. The standard operating procedure includes a sequence diagram as indicated by the following diagram

31. Metadata of the framework