Application Integration Architecture A Framework For Standard Interface

Application Integration Architecture A Framework For Standard Interface Development Gerald R. Gray, Consumers Energy June 23, 2008 #1

High Level #2

Moderate Level #3

Deep Dive #4

Abstract to Detail • • • Standards Bodies Business Case Conceptual Architecture Use Cases Integration Requirements Sequence Diagram Patterns Services WSDL #5

Leveraging the Overlap: UCAIug Groups – AMI & CIMug Standard Services Utility. AMI Enterprise WG #6

Key Collaboration Concept • Standard building blocks are defined by CIMug (i. e. , IEC working groups) and other relevant industry groups (e. g. , Open Architecture Group (OAG), Multi. Speak, OGC) • Common industry practices are defined by the user community; the AMI Enterprise WG - by specifying how standard building blocks are used for popular scenarios with the resulting artifacts: – Use cases specify required services – Service definitions (WSDLs) contain the building blocks • Artifacts are placed on the Utility AMI Share. Point – Sponsors of work name their directories (could be utility names) – Any utility may reference a common industry practice directory in an RFP. – Popular directories become de facto industry standards #7

Security – Zone Defense Third Parties – Retailers, etc AMI-ENT AMI-SEC Meter. Specific Networks HAN Wide Area Networks Data Collection Systems Data Collection 61968 -9 Open HAN 1. 0 AMI-COMM ? ? ? Meter Data & Comm. C 12. 19 C 12. 22 Control & Configuration 61968 -9 Load Control 61968 -9 AMI-SEC Home PC #8 Utility Systems MDM System MDM Or MDUS 61968 -9 OMS 61968 -3 GIS 61968 -4 Planning & Scheduling 61968 -5 WMS 61968 -6 Load Mgmt. 61968 -9 CIS 61968 -8 Meter Maintenance 61968 -9 MDM 61968 -9 MDUS 61968 -9 Network Operations 61968 -3

Scope #9

Moving To A Common Language # 10

Requirements Traceability Resulting from an activity in a Use Case Scenario Business Benefits Functional Requirements Business Processes Integration Requirements Interface Reference Model Application Portfolio Services Portfolio # 11 Resulting from an flow in a Use Case Scenario Includes application services and common services.

Services Gap Analysis Steps Map system actors to IEC 61968 systems/IRM Create common services per integration requirements Identify integration requirements Gap analysis Documents Review CIM and Multi. Speak services/schema s Model service sequence diagram that includes vendor and legacy services Identify Application services/schema s Create services mapping and gap analysis! # 12

Context – Conceptual Architecture # 13

Use Case – B 1. 3 # 14

Integration Requirements # 15

Operation Naming Patterns utilizing IEC 61968 verb (Reference #9): CREATED CHANGED CANCEL CLOSE DELETE GET CLOSED CANCELED DELETED SHOW REPLY SUBSCRIBE UNSUBSCRIBE <IEC Verb><Information Object>_<Service Pattern Name # 16

Service Naming Patterns: • • • Send – to provide (send) information (message) for public (enterprise) consumption. Receive – to receive information (message) from an external source. Publish – to provide (send) information (message) for public (enterprise) consumption. Subscribe – to receive information (message) from an external source. Request – to request another party to perform a specific service Reply – to confirm the execution of a service on behalf of the provider, and return specific results. Retrieve – to request information Show – to provide information as the result of a request or unsolicited Execute – to run a service provided to the public <Service Pattern Name><Information Object> # 17

Sequence Diagram # 18

Recommended Services # 19

Services • Services provided by MDUS (“Receive” service): – Service: Receive. Meter. System. Event. wsdl • Operation: Created. Meter. System. Event_Receive • Operation: Changed. Meter. System. Event_Receive • Operation: Canceled. Meter. System. Event_Receive • Services provided by ESB (“Show” service): – Service: Show. Meter. System. Event. wsdl • Operation: Created. Meter. System. Event_Show • Operation: Changed. Meter. System. Event_Show • Operation: Canceled. Meter. System. Event_Show • Services provided by CIS (or any interested systems) (“Receive” service): – Service: Receive. Meter. System. Event. wsdl • Operation: Created. Meter. System. Event_Receive • Operation: Changed. Meter. System. Event_Receive • Operation: Canceled. Meter. System. Event_Receive # 20

WSDL (Proof of Concept) <? xml version="1. 0" encoding="UTF-8"? > <wsdl: definitions name="Receive. Meter. System. Event" target. Namespace="http: //ce. corp. com/ei/2008/06/Receive. Meter. System. Event. 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/Receive. Meter. System. Event. wsdl" xmlns: type. Orig="http: //ce. corp. com/ei/2008/06" xmlns: type. In="http: //ce. corp. com/ei/2008/06/Meter. System. Event" xmlns: type. Out="http: //ce. corp. com/ei/2008/06/Output. Data. xsd"> <wsdl: documentation>A web service to receive Meter. System. Event</wsdl: documentation> <!-- type elements define data types used in this wsdl document using xml schema --> <wsdl: types> <xs: schema target. Namespace="http: //ce. corp. com/ei/2008/06/Meter. System. Event"> <xs: import namespace="http: //ce. corp. com/ei/2008/06" schema. Location="Meter. System. Event. xsd"/> # 21

Abstract to Detail • • • Standards Bodies Business Case Conceptual Architecture Use Cases Integration Requirements Patterns Sequence Diagram Services WSDL # 22

Benefits to each Utility • As utilities pull in the same direction, de facto standards are created; economies of scale should yield: – Improved vendor response & support – Reduced product procurement costs – Reduced effort for requirements analysis and design – Reduced risk of overlooking requirements • That are expensive to retrofit later – Reduced life-cycle costs # 23

Next Steps Issues and/or improvements? # 24