1. Service Identification
Provide descriptive details of services identification attributes
|Service Name||Enter service name|
|Service Description||Enter service description|
|Service Version||Enter service version|
|Service Location||Enter service location|
|Service Contact||Contact Name||Enter service contact name|
|Business Sub System||Enter service business system|
|Location||Enter the service contact location|
|Phone Number||Enter service contact phone number|
|Enter service email|
|Service Owner||Enter service owner|
|Service Type||Enter service type|
|Service Dependency||Enter all dependent service|
Service identification table -- Additional information:
Service name: The service must have a fully distinguished name which uniquely identifies it within its given name space according to the service taxonomy naming approach.
version: Service version provides an extension to the service name such as 1.00, 2.32. Initial version of a service should be decided based on organizational policy for versioning.
Service location: Service location uniquely identifies the service in service provider's domain, major and or minor sub system.
Service contact: A service's contact is a person (or a reference to a specific role) that acts as a central point of contact for all matters relating to the service. The contact may not necessarily be the service owner since this may be a technical resource. The contact information will include the contact's name and contact details: e-mail address, phone number, etc.
Service owner: The ultimate owner of the service, this ownership should be associated with respect the service provider business sub system.
Service type: Services may be categorized with a service type based on service taxonomy approach. The service type may be used by consumers to help them quickly locate and/or understand a service. Service type is usually drawn from a hierarchical categorization system based on technical and business views of the services. Service may be categorized in taxonomy as Business services, Application services and Infrastructure services. A business service is composed of multiple application services and infrastructure services provide the supporting requirement of application services. Please see the service taxonomy specification for more details.
Service dependency: A service such as business service is composed of multiple services to assure the reusability and loose coupling principles of service oriented architecture. Service dependency provides a top down list of services that a given service depends upon during run time execution. Please see the service taxonomy specification for more details.
Service description: A human readable description of the service. It may include references to other documents.
2. Service Functional Requirements
Document the functional requirements.
|Service Version||Functional Identifier||Details||Information Model Data Objects||Data Object Owners|
|Service version to which the requirement applies||Unique functional identifier||List individual functional objective and business data objects associated with each functional objectives||For each service function list the data objects||For each data object list the unique owner including namespace|
Service functional requirements table - Additional information:
Functional objective: A concrete service provided through the service entity. A service entity's services can be implemented through different operations of the service. Each functional objective of a service has to be explicitly explained in the context of the service exposed and non-exposed functionalities.
Information model data objects: In order to meet the functional objective of a service, the application components of a service act on data objects provided as parts of the service information model. Each data object should have a unique owner associated with a namespace.
3. Service Change Log
Describe changes that are made to the service or reference change control documents.
|Requested By||Enter the contact details of the person or organization that requested the change.|
|Service Name||Enter name of the service on which change was requested.|
|Request Date||Enter the date of the change request.|
|Approval Date||Enter the date the change request was approved.|
|Production Change Date||Enter the date on which the change was applied to the service and released for production.|
|Change Control Reference||Enter a unique reference number assigned to the approved change.|
|Approved By||Enter the change request approval person's name.|
|Change Description||Enter the description of the change request.|
4. Service Provider-Side Information
The provider side (along with the identification side) contains all of the information an actual or potential consumer of the service needs.
|Enter name||Enter type||Enter description|
|Information (Data)||Name||Type||Associated Operation|
|Enter name||Enter type||Enter associated operation|
|Behavior||Service Behavior Type||Method name||Method Behavior Type|
|Enter method name||Enter method behavior type|
|Enter service behavior type||Enter method name||Enter method behavior type|
|Enter name||Enter type||Enter description|
|Enter name||Enter type||Enter description|
|Enterprise Pattern Usage||Enter names of the enterprise patterns.|
|Security Requirements||Identification and Authentication||Enter identification and authentication requirements|
|Authorization||Enter authorization requirements|
|Integrity||Enter integrity requirements|
|Non repudiation||Enter non repudiation requirements|
|Confidentiality||Enter confidentiality requirements|
|Privacy||Enter privacy requirements|
Service provider-side information table - Additional information:
Service interface: Service interface defines how to use service operations. The Service Interface should be named based upon the service taxonomy naming approach.
Service interface type: Each service interface should be associated with a type such as inbound (Import), outbound (Export), and abstract. Type defines the direction in which a given service moves the business data based on the associated information model. Type should be defined based on the business system own the service.
- Inbound (Import): Business data flowing into a business system through the interface using the associated information model. Interface implementation method/operation describes how to process the incoming data.
- Outbound (Export): Business data flow out of a business system through the interface using the associated information model. Interface implementation method describe how to format the data according to the associated information model.
- Abstract: Actual purpose is unknown however it can be used in intermediate data exchanges such as a node in a business process.
Service interface mode: Mode of an interface decides the mode in which service clients access the service operation via the interface. Mode can be synchronous or asynchronous.
- Synchronous: Service consumer resource used to access the service operation via the interface will be locked until service fulfills the service operation call.
- Asynchronous: Service consumer resources used to call the service operation via service interface will be released as soon the call is completed. Once the service provider completes the requested operation, response generated will be delivered via call back mechanism.
Service operation: Operation is the entity of the service which fulfills the task on a transaction context. Service operation should be named based upon the service taxonomy naming approach.
Service operation type: Type of a service operation can be business oriented or management oriented. Technically business and management operations are the same except for the fact that management service is used in the management of services related activities.
Interface information model: Each service interface should be associated with an information model for request, response, and fault conditions of the exposed operation based on the type of interface.
- Information model type: Type of an information model that defines the context on which it is used with an interface such as request, response, and fault.
- Request: An information model composed of atomic and (or) composite data type so that a service consumer can prepare the request message to invoke a service operation via the interface.
- Response: An information model composed of atomic and or composite data types so that a service provider can send the response for an operation invocation request from a service client.
- Fault: An information model composed of atomic and (or) composite data types so that a service provider can communicate the fault condition to the service requester in case of an exception during a service operation invocation via the service interface.
Service behaviors: The behavior describes what a service operation does. For each service operation provide the behavior description in human readable format.
Behavior type: Type of a service operation is controlled by the characteristics of the operation.
- Stateless: An operation which does not maintain a state A.
- Stateful: An operation which maintains state. A stateful operation is implemented by using work flow and or choreography mechanism.
If a given service has at least one stateful operation, the overall service behavior will be stateful.
If a given service has no stateful operations at all, the overall service behavior will be stateless.
Service events: Service events may or may not be part of a service specification. Some time service layer management framework should be capable to capture all major service events as part of the service run time policy. If there are consumer driven policies around the service events it should be part of the service specification.
Service policies: List all major service policies applicable to the business and run time aspects of the service here.
Policy type: A policy type of a service can be static or dynamic in nature.
- Static policies: A policy which is pre-build into the service and easy to configure without a change request.
- Dynamic policies: A policy which is dynamic in nature, being controlled by the run time behavior, a change in dynamic policies need change request.
Security Identification and Authentication: Verifying the identity of a service consumer, often as a prerequisite to allowing access to resources in a service or application infrastructure. Provide a human readable description of the service user identification and authentication requirement.
Authorization: The permission to use a service resource, granted, directly or indirectly, by a service provider. Provide a human readable description of the service authentication requirement.
Integrity: The property that data has not been altered in an unauthorized manner while in storage, during processing, or in transit. Provide a human readable description of the service data integrity requirement.
Non-repudiation: Assurance that the service consumer is provided with proof of delivery and the service provider is provided with proof of the sender's identity so neither can later deny having processed the information. Provide human readable details of the non repudiation security requirement of the service.
Confidentiality: Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information. Provide human readable description of the confidentiality requirement of the service security.
Privacy: Restricting access to consumer or relying party information in accordance with Federal law and organization policy. Provide human readable description of the privacy requirement of the service security.
Note: Service security features explained here is the human readable interpretation of the security requirement explained in business functional analysis.
5. Service Dependency Information
The dependency section describes the services upon which this service depends to provide its service.
|Dependent Service||Contract||Specification||Operations||Mapping Specification|
|Enter the dependent service||Enter the service usage contract specification location||Enter dependent service specification location||Enter dependent service operations||Enter message mapping specification|
Service dependency information table - Additional information:
Dependent service: A service being used in a supporting role to fulfill the functionalities of the major service specified in the specification document.
Contract: A service level contract between a major service and supporting service.
Specification: Service specification of the supporting service.
Operations: Operations being used from supporting service in the context of major service.
Mapping specification: Specify the message mapping details for a service dependency in case services having different message layout and or format.
6. Service Assets
List the documents and other assets related to this service. These would typically be added into the Repository.
|Enter the service resource location||Enter resource version||Enter resource type|
About the Author
Shaji Nair is a senior SOA solution architect with HP's consulting and integration practice. He can be reached at email@example.com.
This was first published in March 2008