1

ECCF Training 2.0

Platform Specific Model (PSM)

ECCF Training Working Group

January 2011

2

Remember our Case Study:

Molecular Annotations Service:

• We have defined the CIM.

• “Conceptually what purpose does this service serve?”• We have defined the PIM.

• “What are the specific capabilities and data model look like at a high level?”

• Now we want to define a PSM.

• “What would a platform specific instance of this service look like?”

3

Considerations:

• What is the PSM?

• Platform Specific Model.

• “implementable view”…..not necessarily “implemented view”

• What is the “Platform”?

• Most specifications in the NCI CBIIT SOA Enterprise the “Platform” will be web or REST services. So we need to think at the level of WSDL/WADL and/or Schema artifacts for defining operations, messages, data types, and attributes.

4

NCI CBIIT PSM Required Artifacts

5

Outline

• Platform-specific Model (PSM) Specification

• PSM Enterprise Viewpoint

• PSM Information Viewpoint

• PSM Computational or Behavioral Viewpoint

• PSM Engineering or Implementation Viewpoint

• PSM Technology Viewpoint

• PSM Specification Overview

6

Enterprise Viewpoint PSM Artifacts

• The primary artifacts generated from the Enterprise Viewpoint at the PSM specification include:

• Technology Stack: Defines the list of the approved technology platforms through which the service can be realized

• Traceability Matrix: Traces back the functional interface and information model that are tied to a particular platform at the PSM specification level to the PIM specification level. This ensures that there is no loss of functionality or information from the CIM to PIM to PSM specification levels.

7

Technology Stack

• Enables setting guidance and requirements to implementation teams for technology choices.

• May refer to an existing technology stack such as the NCI CBIIT Technology Stack.

• Ensures technology compatibility across other PSM implementations.• Enables top level technology changes to be reflected across a wide range of

service specifications.

• May also put in service specific technology requirements or choices above and beyond a referenced technology stack.

8

Technology Stack Example

• https://wiki.nci.nih.gov/display/TechStack/Technology+Stack+2010

9

Technology Stack Exercise

• In a PSM for a service that utilizes XML data storage what additions might I make to a technology stack to ensure technology compatibility across other service with similar data storage requirements?

10

Technology Stack Exercise

• In a PSM for a service that utilizes XML data storage what additions might I make to a technology stack to ensure technology compatibility across other service with similar data storage requirements?

• Exist or BerkleyDB for example

11

Traceability Matrix

• The traceability matrix enables the mapping of the profiles at the PIM level to that of actual functionality described at the PSM level to ensure that at the PSM level no functionality or conformance capabilities described in the PIM is lost.

• Example:• In the PIM we define a functional profile describing a set of required capabilities,

realized by some operations, that are required. In the PSM we must be sure that each of these operations is actually specified in the PSM service specification. We can explicitly state which functionally profiles the service is going to adhere do by mapping from one in the PIM directly to an interface in the PSM. A traceability matrix artifact will define this.

12

Traceability Matrix Example

The Molecular Annotation Service explicitly defines that it will implement the MA-FP1 function profile.

13

Traceability Matrix Example

Then it maps each capability from the PIM to the actual operation in an interface which provides the implementation of that capability.

14

Information Viewpoint PSM Artifacts

• The primary artifacts generated from the Information Viewpoint at the PSM specification include:

• Domain Information Model: Further expansion and/or localization of the Domain Information Model in the PIM

• Enables expansion of model for classes needed for behind the scenes or for this particular platform specific instance.

• Enables specification of a transport or persistence model use in the platform specific instance.

• Enables localization of a model for restricting values for use in the platform specific instance.

15

Information Model Example (Schema/Message Types)

16

Information Model Example (Localization)

• Example restriction/localization of values to a particular vocabulary. The Person objects attributes are being defined to be of value types defined in another vocabulary.

17

Information Model Example (Class Diagram)

18

Behavioral Viewpoint PSM Artifacts

• The primary artifacts generated from the Behavioral Viewpoint at the PSM specification include:

• Service Interface: Platform specific specification of service interface.

• Should be the WSDL/URL representation of the PIM functional profiles.

• Could also contain the Java API representation of the PIM functional profiles.

• Could also contain the .NET API representation of the PIM functional profiles.

• May add extra operations to facilitate required platform specific functionality.

19

Service Interface Example (DOC)

Each interface and its operations should be specified in the PSM document so that it can easily be traced back to the PIM

20

Operation Behavior

• getGenesBySymbol

21

Service Interface Example (WSDL) for soap bast services

• Basic Structure • Simple Example

22

Service Interface Example (WADL) for REST based services

• platform specific functionality.

23

Implementation Viewpoint PSM Artifacts

• The primary artifacts generated from the Implementation Viewpoint at the PSM specification include:

• Standards: A list of standards that are applicable for the chosen platform to which the service implementation needs to adhere.

• Deployment Diagrams: Deployment diagrams define the deployment model for the given service, identify various nodes on which service will be deployed, and identify the connections between them. If there are additional deployment-specific details, they need to be highlighted as well.

• Sequence Diagram: Sequence diagrams define the sequence of events and operation calls that the client will perform, such as to discover or invoke the service, to authenticate the service, to initiate a transaction, or to obtain a connection. The sequence diagrams should showcase the non-functional platform-level interactions only.

• Deployment and Implementation Considerations: Based on the deployment model, as well as on various non-functional capabilities, the Engineering Viewpoint can inform the service developers about various deployment and implementation considerations that need to be addressed during development.

24

Standards

25

Standards

Technology standards are defining the “platform” at the PSM level. Standards such as WSDL, WSRF, and XML (technology standards from caGrid 1.X) are used to define the platform by which this service is indented to operate in.

26

Deployment Diagrams

27

Sequence Diagrams

28

Deployment and Implementation Considerations

• Security

29

Deployment and Implementation Considerations

• Details about errors.

30

Deployment and Implementation Considerations

• Deployment details.

31

Deployment and Implementation Considerations

• Security details.

32

PSM Specification Artifacts

• The primary artifacts-generated Technology Viewpoint at PSM specification include:

• Implementation Considerations

33

Case Study: Molecular Annotation PSM

• One final Look at a complete PSM and all its artifacts in the submit-able template.

• https://wiki.nci.nih.gov/display/EAWiki/NCI+Enterprise+Services+Inventory+Blueprint