SG Systems - Service Definition Team Chair: Gerald Gray, Guiding Principle Consulting [email protected] Co-Chair: Shawn Hu, Xtensible Solutions [email protected].
Download ReportTranscript SG Systems - Service Definition Team Chair: Gerald Gray, Guiding Principle Consulting [email protected] Co-Chair: Shawn Hu, Xtensible Solutions [email protected].
SG Systems - Service Definition Team Chair: Gerald Gray, Guiding Principle Consulting [email protected] Co-Chair: Shawn Hu, Xtensible Solutions [email protected] You Are Here You are here Introduction • Why Service Definitions? – Best Practice CIM implementation – “The CIM is neat but…” • IEC CIM alignment • The service definition process (high level view) • Future Plans SDO – User Group Relationship • Iterative process • Analogy – early browser development SDO Yes and... Thou shalt... Feedback OpenSG OpenAMIENT example • First pass – IEC CIM draft XSD as informative • Now – XSD as normative User Community IEC CIM Alignment • Consistent –some features of the spec, and in accordance, but also some additional features • Compliant – some of spec not implemented, but what is implemented is in accordance • Conformant – All features of spec implemented, but some additional features that are not conformant • Fully Conformant – full correspondence between the spec and implementation. . Irrelevant . Consistent . Compliant . Conformant . - Implementation - Specification Fully Conformant Adapted from TOGAF 9 OpenSG - Where We Fit Open AMIENT Use Case Team SRS Team Service Definition Team Interoperability Team Security Team OpenADE OpenADR OpenHAN The Process Use Cases Business Processes System Requirements Specification Integration Requirements Services •WSDLs •XSDs For more info: http://osgug.ucaiug.org/sgsystems/SDTeam/Implementation%20Projects/Home.aspx The Process • • • • • • • Logical model input & development Identification of integration requirements Pattern naming Information objects Artifact generation (XSD, WSDL) Posting Issue generation and resolution Logical Model Development • Standardized actors from AMI-ENT SRS • Document business process in use cases and activity diagrams Identify Integration Requirements • Where an object crosses a system boundary Harmonize Integration Requirements • Compare integration requirements and look for commonality: – – – – Common actors Common consumers Common providers Common information objects • Eliminate duplicates, refine integration requirements Patterns – Using CIM Verbs • Pattern naming allows for both ESB and nonESB (point-to-point) architectural assumptions • Verbs and Information objects are based IEC 61968 • Verb examples: – Create, Created – Send, Reply • Information Object examples: – EndDeviceAsset – MeterSystemEvent – MeterReading <IEC Verb><Information Object> e.g. CreatedMeterReading Sequence Diagrams • Show the services and integration with actors Crafting Message Payloads • Based on requirements identified in the Systems Requirements Specification Notification • Subscribe to the Listserv – http://listserv.enernex.com/cgi/wa.exe • Send listserv e-mail – [email protected] • Issues with artifacts should be noted on the OpenSG Help Desk site – http://osgug.ucaiug.org/HelpDesk/default.aspx • Implementation Projects: Service Definition Team Wiki – http://osgug.ucaiug.org/sgsystems/SDTeam/Implementation%20Proje cts/Home.aspx Plans - Feedback • OpenAMI-ENT work was shared with IEC WG14 (Use Cases, Requirements, Artifacts) • Continuing service definition work… OpenAMIENT ballot Oct ‘09 IEC WG14 Jan ‘10 Re-factor artifacts OpenADE 1.0 artifacts REST/SOAP ballot May ‘10 Jul ‘10 Nov ‘10 OpenADR 1.0 Artifacts ballot Thank you!