- 3 -
Contribution to the TeleManagement Forum
Submission Number: mTOP/methodology/MTOSI_ServiceDescriptionMetaModel/9 March 07
Submission Type: Contribution for consideration
Project Team: mTOP Methodology
TITLE: MTOSI Service Description Meta-Model
Authors: Francesco Caruso
Company: Telcordia Technologies
Contact: Francesco Caruso, , +1 732 699 3072
FILE NAME: MTOSI_ServiceDescriptionMetaModel.doc
Status: New þ Rejected o In Review o Revised o Accepted o
(üas appropriate)
Review Date: TBD
1 Contribution
Within mTOP SOA framework, the Service Description, often referred to as the Service Contract or NGOSS system contract, is pivotal, as it formally specifies the service obligations to its consumers and its provider. This document addresses the Service Description meta-model to be used in the design and documentation of mTOP services to be used within the MDA mTOP methodology to capture the essential information needed to generate the mTOP artifacts such as documentation (DDPs[1]), XSDs and WSDLs.
NOTICE: This contribution has been prepared to assist the TeleManagement Forum. This document is offered to the TM Forum as a basis for discussion and is not a binding proposal on Telcordia Technologies or any other company. The requirements are subject to change in form and numerical value after more study. Telcordia Technologies specifically reserve the right to add to, amend, or withdraw statements contained herein.
2 Expected Outcome
It is expected that this contribution will be discussed at an MTOSI methodology meeting and it will be agreed to be used as a starting point for the MDA proof of concept. Furthermore this document can be offered to OASIS as example of best practices in the industry.
3 IPR Declaration
Is there any IPR associated with this contribution NO
The author must declare any IPR that their company owns with respect to this contribution. Note that if the contribution is accepted by the team an IPR declaration form will be required. This may be downloaded from the TMF web site at: http://www.tmforum.org/browse.asp?catID=2211
4 Acknowledgments
This work would not have been possible without the guidance and support of Alex Levinson (Lockheed Martin) and Danny Thornton, (Lockheed Martin, OASIS SOA Technical Committee Member).
5 Review Comments
TBD
6 Introduction
A formal service specification is a pivotal element of a SOA framework as it decouples the service implementation from its consumers by clearly defining the contract the service provider needs to fulfill and the expectations and usage patterns a service consumer expects. This document focuses on the Service Description template, as a meta-model to be instantiated by the mTOP service designer to describe the services realizing the features described in the business agreement DDPs.
7 Service Description Structure
The Service Description represents the information needed in order to implement or use a business service. The purpose of the contract is to facilitate interaction and visibility between participants in service interactions. By providing structured descriptions, potential participants are able to construct systems that use services and offer compatible services. The Service Description does not simply focus on data exchange but rather addresses the entire range of functional and non-functional requirements.
The service description is present along the entire service lifecycle, from service concept development to service retirement and its level of detail grows as the service progresses within its lifecycle.
The Service Description is often referred to as a Service Contract[2] as it represents a binding contract between a service provider and service consumer.
Figure 1 depicts a UML representation of the Service Description meta-model.
Figure 1 - Service Description UML meta-model
The Service Description contains or refers to the following key elements.
· Identity & Provenance (Where) – This section identifies the Service across various classification dimensions such as: the Name, Domain, Functional area, and Sub-Business process.
· Functional Requirements (What) – The observable and measurable effects of invoking the business interface. This is also referred to as the Real World Effect in the OASIS RM. A Service Interface supports a business capability that involves multiple business activities, each of which may have real world effects observable after it completes.
· Non Functional Requirements (How) – service characteristics addressing the way the service is delivered (e.g. Availability, Reliability etc).
· Service Interface (operational details)
o Behavior Model (How)
· Action Model – description of message interactions
o Operations - (business activities, Actions)
§ Operation real world effect (Functional Req.)
§ Messages (In, Out, Fault)
§ Message Sequences (MEP + Seq Diag.)
§ Pre/Post-conditions
· Process Model
o Operation Choreography Model – description of the externally observable interactions among the operations of the service.
o Dependent Service Orchestration – the way the subordinate dependent service are orchestrated by this service.
o Information Model (What) - characterization of the information that is exchanged with the business service.
o Interface References (How) – reference to implementation artifacts further describing the service. E.g. WSDL, XSD,
· Service Reachability (Where) – How services are discovered and where the services can be located.
· Service Admin. (Additional info) – Administrative information
8 The role of Service Description within the MDA process
Having a model for a service description is equivalent to defining a bill of materials (BOM) in the manufacturing domain. As the manufacturing supporting systems (e.g. CAD CAM, PLM, etc.) are able to fully automate the creation of the BOM from the product design, mTOP should be able to automate the collection of the information related to a service description. Furthermore, in the hardware world, the BOM is used to procure the parts for the assembly, while in the service world, the model is used to drive service development and assembly.
An example of how a Service Description centric environment may be realized is depicted in Figure 2
In this example, there are three distinct roles involved in MDT for developing Services: SOA Architect, Service Designer, and Integration Engineer. All of these roles interact to provide lifecycle support for the MDT and the Services themselves.
· The SOA Architect sets the framework and ground rules for Services for the whole organization, including: Common Data Model, session Profiles and generation Plugins. Profiles are used to decorate the model for different classes of users. Plugins are used to generate standard Service Descriptions. Plugins use the Common Data Model and Profiles as inputs.
· The Service Designer studies business requirements and uses the MDT to generate Service Descriptions. This design process is constrained to use the framework and ground rules established by the SOA Architect above. The Service Designer may scope and extend the Common Data Model, select behaviors associated with message exchange patterns, and generate Service Descriptions, Service Documentation and Use Case Documentation.
· The Integration Engineer is responsible for deploying the Services in a runtime environment. The MDT can assist by generating test and runtime artifacts that are specialized for the target deployment environment. These environments may include test tools, Service Registries, Enterprise Services Buses (ESB), Application Servers or other environments. The generation Plugins may be extended by the Integration Engineer (or SOA Architect) to create schemas and stubbed versions of the runtime artifacts.
Figure 2 - Example of Service Definition Modeling Environment
This illustration emphasizes the interaction between Tool Adaptation and Service Description processes. These processes are interlinked, because MDT provides the automation, productivity and quality assurance for Service Descriptions.
Once the service description is captured in a machine readable format (e.g. XML) it can be parsed and processed to generate different system artifacts as depicted in Figure 3.
Figure 3 - artifacts generated from the SD
9 Proposed Next Steps
- Validate SD meta-model across the mTOP DDPs
- Relate SD meta-model to TMForum NGOSS System Contract meta-model
- Submit SD meta-model to OASIS
- MDA proof of concept: from SD to Documentation and WSDL/XSDs
- Define mTOP Standard Operating Environment (tool chain and methodology) to support MDA
3
[1] Document Delivery Package, a feature oriented requirement and design document structure embraced by mTOP.
[2] Note, in OASIS SOA RA Service Description model, a contract is a part of the Service Description and closely follows the meaning of contracts in the business world, a legally binding agreement between two or more parties.