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

# 2 High Level

# 3 Moderate Level

# 4 Deep Dive

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

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

# 7 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), MultiSpeak, 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 SharePoint –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

# 8 AMI-ENT Security – Zone Defense Home PC OMS Planning & Scheduling MDM Or MDUS Data Collection Control & Configuration Meter Maintenance WMS Network Operations Load Mgmt CIS GIS Load Control MDM MDUS Open HAN 1.0 Third Parties – Retailers, etc Meter Data & Comm. C12.19 C12.22 Data Collection Systems Utility Systems MDM SystemWide Area Networks Meter- Specific Networks HAN AMI-SEC AMI-COMM ???

# 9 Scope

# 10 Moving To A Common Language

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

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

# 13 Context – Conceptual Architecture

# 14 Use Case – B1.3

# 15 Integration Requirements

# 16 Operation Naming Patterns Operation Naming Patterns utilizing IEC verb (Reference #9): _ CREATE CREATED CHANGE CHANGED CANCEL CLOSE DELETE GET CLOSED CANCELED DELETED SHOW REPLY SUBSCRIBE UNSUBSCRIBE

# 17 Service Naming Patterns 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

# 18 Sequence Diagram

# 19 Recommended Services

# 20 Services Services provided by MDUS (“Receive” service): –Service: ReceiveMeterSystemEvent.wsdl Operation: CreatedMeterSystemEvent_Receive Operation: ChangedMeterSystemEvent_Receive Operation: CanceledMeterSystemEvent_Receive Services provided by ESB (“Show” service): –Service: ShowMeterSystemEvent.wsdl Operation: CreatedMeterSystemEvent_Show Operation: ChangedMeterSystemEvent_Show Operation: CanceledMeterSystemEvent_Show Services provided by CIS (or any interested systems) (“Receive” service): –Service: ReceiveMeterSystemEvent.wsdl Operation: CreatedMeterSystemEvent_Receive Operation: ChangedMeterSystemEvent_Receive Operation: CanceledMeterSystemEvent_Receive

# 21 WSDL (Proof of Concept) <wsdl:definitions name="ReceiveMeterSystemEvent" targetNamespace=" xmlns:http=" xmlns:soap=" xmlns:wsdl=" xmlns:xs=" xmlns=" xmlns:wsi=" xmlns:soapenc=" xmlns:tm=" xmlns:mime=" xmlns:tns=" xmlns:typeOrig=" xmlns:typeIn=" xmlns:typeOut=" A web service to receive MeterSystemEvent

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

# 23 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

# 24 Next Steps Issues and/or improvements?