Service Models

Service Models provide the predefined analysis and design-level structures to enable more consistency and reuse in the creation of services.

Service Model components comprise:

  • Business Object Model (BOM) comprises technology-independent class models that enable traceability between:
    • Automated business process requirements
    • Downstream services-oriented architecture (SOA) IT analysis representation
  • Web Service Design Model (WSDM) provides a design for an enterprise-wide and business-services-based architecture though the development of:
    • Participants
    • Service interfaces
    • Messages
  • Interface Design Model (IDM) provides a design for an enterprise-wide and business-services-based architecture through the development of:
    • Components
    • Types
    • Interfaces
    • Data transfer objects
  • Transfer Objects Model (TOM) defines transfer objects, which are simple Unified Modeling Language (UML) data types derived from the IDM class model. Transfer objects are used to explicitly define, at modeling time, the structure of data that will be used in:   
    • Deployed services
    • Data objects in executable Process Models
    This ability to explicitly define data structures at modeling time is a key feature of using transfer objects, rather than attempting to generate data structures directly from the IDM class model. Controlling the size and complexity of artifacts generated from a large and complex class model can be very difficult. Transfer objects can help to ensure the consistency and traceability of data structures deployed in production. The platform-specific design models reference transfer objects to specify the structure of data objects used in services and messages:
    • WSDM
    • Java Service Design Model (JSDM)
    • Message Service Design Model (MSDM)
    Item definitions in the Orchestration Process Models (OPM) in Rational Software Architect (RSA) are linked to transfer objects to define their structure. TOM provides a clean separation between the IDM class model and the transfer objects. This separation enables better management of transfer objects, such as:
    • Governance over multiple versions of transfer objects
    • Governance over multiple transfer object hierarchies intended for different target systems
    • Control over who can modify transfer objects
    Note: it is also possible to have multiple TOMs within a project.
  • Java Service Design Model (JSDM) is a platform-specific model that contains definitions to enable the generation of Java services. Service operations in JSDM are derived from capability operations in BOM. Like the other platform-specific design models, service operations in JSDM do not directly reference IDM classes or interfaces. JSDM service option parameters can only be of type:
    • Transfer object
    • IDM enumeration
    • Design Models Datatypes (DMD) primitive type
    Java is generated from JSDM using UML-to-Java Transformation in RSA. You can control how DMD primitive types are converted to Java types by changing the redirectTo property. This is a property of the <<JavaTypeRedirect>> stereotype, which is applied to DMD primitive types. JSDM is intended only for the definition and generation of Java services. If you want to generate Java for IDM classes, interfaces, for example, you can use UML-to-Java Transformation to generate Java directly from IDM.
  • Message Service Design Model (MSDM) Message Service Design Model (MSDM) is a platform-specific model that contains definitions to enable the generation of XSD messages and commands. Messages in MSDM are derived from capability operations in BOM. Message-based XSDs and command-based XSDs generated from the MSDM can be used in a messaging environment. Request messages can be routed to a messaging engine, which can, in turn, invoke lower-level services created from BPS for Standard Tooling models. When required, a response message can be routed back to the sender. Like the other platform-specific design models, messages in MSDM do not directly reference IDM classes or interfaces. MSDM request/response message attributes can only be of type:
    • Transfer object
    • IDM enumeration
    • DMD primitive type
    XSDs are generated from MSDM using UML-to-XSD Transformation. You can control how DMD primitive types are converted to XSD types by changing <<restriction>> generalizations. DMD primitive types are classes that extend classes in the XSDDataTypes model library using <<restriction>> generalizations. To specify that a DMD primitive type should be converted to a particular XSD type at generation time, ensure that the DMD primitive type has a generalization to that XSD class in the XSDDataTypes model library and that the generalization has the <<restriction>> stereotype applied.
  • RESTful Application Design Model (RADM) The RESTful Application Design Model (RADM) is a UML Service model which contains definitions for REST (Representational State Transfer) Applications, REST Resources and associated REST Data Objects (JSON/XML structures). 
RADM elements are derived from and mapped to IDM Class model elements.