Service Pattern Data Model Goals To create interoperable

Service Pattern & Data Model

Goals • To create interoperable and sustainable message payloads and Web service definitions • To support integration with or without an ESB • To avoid unnecessary major code change

Key Architecture Considerations • • • Decoupling of end-point connections and business semantics Guaranteed delivery Managed integration Process orchestration where necessary End point compliance to common business semantics and syntax for information exchange to the public (enterprise) • End point compliance to service patterns (interaction patterns, naming and structure patterns, and message exchange patterns) • Minimal business logic and transformation within the integration layer • Map to IEC TC 57 WG 14 verbs

Service Naming Patterns • • Used • • • Not Used • Send - to provide (send) information (business object) for public (enterprise) consumption. To be invoked by the system of record for the business object and only when the state of the business object has changed. Receive – to consume (receive) information (business object) from an external source. Request – to request another party to perform a specific service Execute – to run a service provided to the public, which may include a state change request or a query request. Reply – to reply with the result of the execution of a service (by the Execute service) Show - to provide (show) information (business object) for public (enterprise) consumption, when the state of the business object is not changed, by the system of record or other system that has a copy of the same business object. Retrieve– to request specific data of a business object to be provided. Publish - to provide (send) information (business object) for public (enterprise) consumption. To be invoked by the system of record for the business object and only when the state of the business object has changed. Subscribe – to consume (receive) information (business object) from an external source.

IEC 61968 Verb Usage Recommendation Here is a list of IEC 61989 verbs and where and how they are used in the service/operation patterns naming standards: Create ------ operation: used in Request, Execute services Change ------ operation: used in Request, Execute services Cancel ------ operation: used in Request, Execute services Close ------ operation: used in Request, Execute services Delete ------ operation: used in Request, Execute services Created ------ operation: used in Send, Receive, Reply services Changed ------ operation: used in Send, Receive, Reply services Closed ------ operation: used in Send, Receive, Reply services Canceled ------ operation: used in Send, Receive, Reply services Deleted ------ operation: used in Send, Receive, Reply services Get ------ not used, equivalent to Retrieve service Show ------ used as the service level pattern. Reply ------ used as the service level pattern. Subscribe ------ used as the service level pattern. Unsubscribe ------ not used.

Overall Service Design Process

Integration Requirements Created. Meter. Reading (Receive) Created. Meter. Reading (Send)

System Integration 1) Integration without ESB or transparent ESB WS

System Integration 2) Integration with ESB WS WS

Services Involved

Service & Operation Naming Convention • Service name: follows <Information Object> name (such as Meter. Reading). However, if an ESB is involved such service can be deployed in pair such as “Send. Meter. Reading”/”Receive. Meter. Reading” following <Service pattern name>+<Information Object> • Operation name: <Operation pattern name>+<Information Object> (such as Created. Meter. Reading)

Send-Receive Services Interaction Pattern (With ESB) Send. Meter. Reading Service Operations A Native API or Service S/C T Application A S/P Receive. Meter. Reading Created. Meter. Reading Changed. Meter. Reading Canceled. Meter. Reading Orchestration Transparent ESB Guaranteed delivery within ESB, plus internal routing…… S/C S/P T Native API or Service Application B Other interested parties…… B

Send-Receive Services Interaction Pattern (Without ESB) Meter. Reading Created. Meter. Reading Changed. Meter. Reading Canceled. Meter. Reading A Native API or Service T Application A S/C S/P T Native API or Service Application B B

Request-Reply Services Interaction Pattern (With ESB) Request. Meter. Reading A Native API or Service T S/C Execute. Meter. Reading Create. Meter. Reading Change. Meter. Reading Cancel. Meter. Reading S/P S/C T Orchestration S/P S/C Application A Transparent ESB Receive. Meter. Reading Native API or Service Application B Reply. Meter. Reading Created. Meter. Reading Changed. Meter. Reading Canceled. Meter. Reading B

Request-Reply Services Interaction Pattern (Without ESB) Meter. Reading. Request Create. Meter. Reading Change. Meter. Reading Cancel. Meter. Reading A Native API or Service T S/C S/P S/C Application A T Native API or Service Application B Meter. Reading Created. Meter. Reading Changed. Meter. Reading Canceled. Meter. Reading B

XML Schema Definition • Model driven process <? xml version="1. 0" encoding="utf-8"? > <xs: schema xmlns: m=http: //ce. corp. com/ei/2008/06/Meter. Reading. Request xmlns: prism="http: //ce. corp. com/ei/2008/06" xmlns: xs="http: //www. w 3. org/2001/XMLSchema" target. Namespace="http: //ce. corp. com/ei/2008/06/Meter. Reading. Request" version="1. 0"> <xs: import namespace="http: //ce. corp. com/ei/2008/06" schema. Location="_prism. Entities. xsd"/> <xs: complex. Type name="Meter. Reading. Request_Type"> <xs: sequence> <xs: element ref="prism: Meter. Reading"/> </xs: sequence> </xs: complex. Type> <xs: element name="Meter. Reading. Request" type="m: Meter. Reading. Request_Type"/> </xs: schema>

Model Driven Process Based on a Enterprise Semantic Model (ESM) Existing Terminology and Metadata Controlled Vocabulary (i. e. wiki, data dictionary, etc. ) UML XML Schema

Modeling the ESM – Reference Base • The Reference Base provides a common representation of multiple information sources at the semantic granularity required for an ESM. Database Metadata CIM Application Interfaces Multi. Speak Enterprise Semantic Model (ESM) Existing Models GML XBRL Business Terminology Reference Base

Modeling the ESM – Semantic Base • The Semantic Base refines the Reference Base to create enterprise-wide semantic elements while adding enterprise standard data types. Semantic Base Entity Database Metadata CIM Semantic Base Application Interfaces Multi. Speak Existing Models SAP CIS Business Terminology Reference Base

Modeling the ESM – Semantic Base Entities in Context • Semantic Base Entities are refined for use within specific contexts. Context Specific Refinement Context Database Metadata XBRL Application Interfaces GML Semantic Base Existing Models CCL OAGi Business Terminology Reference Base

Modeling the ESM – Semantic Traceability • A semantic network applied to the ESM provides explicit semantic correlation at the attribute level and facilitates semantically based traversal of the model.

Modeling the ESM – Implementation Models Example Implementation Model Requirement: Model information exchange as a message for application integration where XML Schema is the target implementation technology. Implementation Model

Web Service Definition • Web services defined using Web Service Description Language as part of integration governance. • Web services can be defined following model driven technology such as the one provided by EA. • Or Web services can be defined following a standard template

Web Service Definition Language <? xml version="1. 0" encoding="UTF-8"? > <wsdl: definitions name="Request. Meter. Reading" target. Namespace="http: //ce. corp. com/ei/2008/06/Request. Meter. Reading. wsdl" xmlns: http="http: //schemas. xmlsoap. org/wsdl/http/" xmlns: soap="http: //schemas. xmlsoap. org/wsdl/soap/" xmlns: wsdl="http: //schemas. xmlsoap. org/wsdl/" xmlns: xs="http: //www. w 3. org/2001/XMLSchema" xmlns="http: //schemas. xmlsoap. org/wsdl/" xmlns: wsi="http: //ws-i. org/schemas/conformance. Claim/" xmlns: soapenc="http: //schemas. xmlsoap. org/soap/encoding/" xmlns: tm="http: //microsoft. com/wsdl/mime/text. Matching/" xmlns: mime="http: //schemas. xmlsoap. org/wsdl/mime/" xmlns: tns="http: //ce. corp. com/ei/2008/06/Request. Meter. Reading. wsdl" xmlns: type. Orig="http: //ce. corp. com/ei/2008/06/Meter. Reading. Request" xmlns: type. In="http: //ce. corp. com/ei/2008/06/Meter. Reading. Request. xsd" xmlns: type. Out="http: //ce. corp. com/ei/2008/06/Output. Data. xsd"> <wsdl: documentation>A web service to send Meter. Reading. Request</wsdl: documentation>  <wsdl: types> <xs: schema target. Namespace="http: //ce. corp. com/ei/2008/06/Meter. Reading. Request. xsd"> <xs: import namespace="http: //ce. corp. com/ei/2008/06/Meter. Reading. Request"schema. Location="Meter. Reading. Request. xsd"/> <xs: element name="Create. Meter. Reading" type="type. Orig: Meter. Reading. Request_Type"/> </xs: schema> <xs: import namespace="http: //ce. corp. com/ei/2008/06/Output. Data. xsd" schema. Location="Output. Data. xsd"/> </xs: schema> </wsdl: types> <wsdl: message name="create. Meter. Reading. Input"> <wsdl: part name="create. Meter. Reading" element="type. In: Create. Meter. Reading"/> </wsdl: message> <wsdl: message name="acknowledgement"> <wsdl: part name="output. Data" element="type. Out: Output. Data"/> </wsdl: message> <wsdl: message name="fault. Return"> <wsdl: part name="fault. Infor" element="type. Out: Output. Data"> <wsdl: documentation>fault information</wsdl: documentation> </wsdl: part> </wsdl: message> <wsdl: port. Type name="Meter. Reading. Request"> <wsdl: operation name="Create. Meter. Reading_Request"> <wsdl: documentation>Send create Meter. Reading. Request</wsdl: documentation> <wsdl: input name="create. Meter. Reading. Input" message="tns: create. Meter. Reading. Input"/> <wsdl: output name="create. Meter. Reading. Output" message="tns: acknowledgement"/> <wsdl: fault name="fault. Infor" message="tns: fault. Return"/> </wsdl: operation> </wsdl: port. Type> <wsdl: binding name="Meter. Reading. Request_Binding" type="tns: Meter. Reading. Request"> <soap: binding style="document" transport="http: //schemas. xmlsoap. org/soap/http"/> <wsdl: operation name="Create. Meter. Reading_Request"> <wsdl: documentation>Send create Meter. Reading. Request</wsdl: documentation> <soap: operation soap. Action="http: //ce. corp. com/ei/2008/06/Request. Meter. Reading. wsdl" style="document"/> <wsdl: input name="create. Meter. Reading. Input"> <soap: body use="literal"/> </wsdl: input> <wsdl: output name="create. Meter. Reading. Output"> <soap: body use="literal"/> </wsdl: output> <wsdl: fault name="fault. Infor"> <soap: fault name="fault. Infor" use="literal"/> </wsdl: fault> </wsdl: operation> </wsdl: binding> <wsdl: service name="Request. Meter. Reading"> <wsdl: port name="Meter. Reading. Request. Port" binding="tns: Meter. Reading. Request_Binding"> <soap: address location="http: //ce. corp. com/ei/2008/06/Request. Meter. Reading. wsdl"/> </wsdl: port> </wsdl: service> </wsdl: definitions> <wsdl: types> <wsdl: message> <wsdl: operation> <wsdl: binding> <wsdl: service> Meter. Reading. Request. xsd

Web Service Modeling in EA

Web Service Defined following a CMS Standard Template A standard WSDL template is provided with the following strings to be replaced according to the Service Inventory Sheet • _Service_Name_ • Replaced with Service Name in CMS AMI Service Inventory Sheet such as Send. Activity. Record • _Information_Object_Name_ • Replaced with Information Object Name in CMS AMI Service Inventory Sheet such as Activity. Record • _Operation 1_Name_ (or 2) • Replaced with one Operation Name in CMS AMI Service Inventory Sheet such as Created. Activity. Record_Send • _WSDL_Version_ • Replaced with a WSDL version string such as 2008/11 • _Input_XSD_Version_ • Replaced with a WSDL version string such as 2008/10

High Level View of SOA Services Request. Meter. Reading Note if a Web service is defined based on a template its WSDL should be reverse engineered into EA for deployment and governance.

Questions and Comments