Steve Graham’s Graphics n When we were discussing possible v1.1 and v2.0 features of oBIX, reference was made to some slides that Steve Graham used a few years ago. n Attached are the images referenced. n As a matter of fact, I stole a lot of it and put it in a talk I gave last year. Most of it ties very nicely with Brian’s vision, albeit in a different vocabulary l So I decided to send along most of the slides l Slide 12 is the one I was thinking about most, though l And Steve, Thanks again 1

SOAP n “SOAP Lets computers surf the Web for data like people surf the Web for eye candy.” But how do computers know what they are looking at? n Unstructured content  structured standards n Concrete Content  Abstractions n “Normal” language  Ontology 2

Phase 1: Anything Goes n XML Tagging of Content n Negotiation with Each Trading Partner n Each XML document serves a single purpose n [Expensive] Re-tooling with each change of partner n Everything is possible because you can do what you want n Focus on Process 3

Phase II: Standardization n Adoption of standard data elements l EBXML n Adoption of standard frameworks l WSRF, etc n Still requires re-programming for each new purpose 4

Phase III: Composition n WSDM (WS Distributed Management) l Esp. WSDM-MUWS n BPEL (Business Process Execution Language) n SAML (Security Assertion ML) n UBL (Universal Business Language) 5

Phase IV: Abstraction n WSDM-MOWS (Management of Web Services) n Internationalization n OWL – Ontology Web Language l OWL is designed for use by applications that need to process the content of information instead of just presenting information to humans. OWL facilitates greater machine interpretability of Web content than that supported by XML, RDF, and RDF Schema (RDF-S) by providing additional vocabulary along with a formal semantics. OWL is a W3C specification building the Semantic Web… 6

Better integration 7 "40% of IT spending is on integration” — IDC “ Every $1 for software = $7 to $9 on integration” — Gartner Marketing Partners Web Partners Sales Partners Historical limitations: Monolithic applications can’t be reused Ad hoc integration creates connections that are difficult to change/maintain Lack of standards limits ability to deliver meaningful interoperability

Companies want IT to deliver more business value 8 Source: Accenture I.T. Spending Survey Source: Accenture I.T. Spending Survey Today’s IT Desired IT Increases Value Creation Decreases Maintenance & Delivery 30% New Capability 70% Sustaining & Running Existing Capability 45% New Capability 55% Existing Capability

What is a Web service? n A Web service is: l a software component whose interface is described via WSDL l is capable of being accessed via standard network protocols such as SOAP over HTTP. l a software system designed to support interoperable machine-to-machine interaction over a network. l easy to combine and recombine to meet the needs of customers, suppliers and business partners because it is: n built on open standards and therefore do not require custom-coded connections for integration n self-contained and modular 9 SOAP Router Backend processes WSDL Document + Web service

What is SOA? n A service-oriented architecture (SOA) is an enterprise-scale IT system architecture in which application functions are built as business aligned components (or "services") that are loosely-coupled and well-defined to support interoperability, and to improve flexibility and re-use. l An SOA separates out the concerns of the Service requestors and Service Providers (and Brokers). n A Service is a discoverable software resource which has a service description. The service description is available for searching, binding and invocation by a service requestor. The service description implementation is realized through a service provider who delivers quality of service requirements for the service requestor. Services can be governed by declarative policies. l SOA is not a product – it is about aligning IT and business needs 10

An IT Consultant view of Web Services n Web services can be a part of the answer n Service Oriented Architecture (SOA) is another part n The two are not the same thing: l Most of today's production Web services systems aren't service oriented architectures - they're simple remote procedure calls or point-to-point messaging via SOAP or well structured integration architectures l Most of today's production service oriented architectures don't primarily use Web services - they use ftp, batch files, asynchronous messaging etc. - mature technologies n Achieving the promoted benefits requires both SOA and Web services n Organizations should get interested in the combination of SOA + Web services l business flexibility requires IT flexibility l business flexibility enables a company to support the one constant of change business 11 Thanks to Steve Graham, whose PowerPoints I stole.

Layered SOA 12 QoS, Security, Management & Monitoring (Infrastructure Service ) Data Architecture & Business Intelligence Integration Architecture (Enterprise Service Bus) service modeling Existing Application Resources and Assets Package Custom Application Services Business Process Components Process Choreography Atomic and Composite Services Enterprise Components Custom Application Package Service Requestor Service Provider Presentation Layer 8 5 Industry Models Composite service Atomic service

How do Enterprise Standards Grow? Phase I n Small, tight specifications l Fully functional l Limited Interoperability l Easy to implement 13

How do Standards Grow? Phase II n Component Sockets l Moving from Process to Service n Abstraction n Profile n Domain-Specific Language n Component n Conformance Testing required l Or interoperability will be impossible 14

Characteristics of oBIX Today n REST works the way current control systems work, and so offers an easy transition to existing controls integrators. l REST also allows easy development of AJAX-style interfaces, offering immediate benefits in upgrading deliverable interfaces to the early adopter. l REST provides the best platform for the immediate implementation of monitoring and control functions. n Deeper integration with enterprise systems will require SOAP. l Such integration will also require componentized abstractions, or profiles, which can and now will, be developed on the small tight v1.0 platform. n By supporting both SOAP and REST, oBIX 1.0 allows rapid (and easy) benefits for early adopters while supporting the incremental extension and componentization that long-term enterprise integration will require. 15

Moving oBIX up to the Enterprise n Use Web services and SOA to make IT systems and Building Automation easier to integrate n Define common profiles and services based upon core protocol n Define compliance suites 16

oBIX Mid-Term Goals n Evolve to support composite frameworks n Re-use related Namespaces l UnitsML starting as OASIS TC n Provides an abstraction over base Building Automation data n Get building automation systems “on the [enterprise] bus” 17

oBIX Mid-Term Goals n Full Participant in NBIM l Support of COBIE n Transforms to GBXML and “Continuous Commissioning” n Support of Emergency Response l CAP and EDXL compatibility l OGC Interoperability n Open Geospatial Consortium 18

Layered Building Automation SOA Standards 19 QoS, Security, Management & Monitoring (Infrastructure Service ) Data Architecture & Business Intelligence Integration Architecture (Enterprise Service Bus) service modeling Existing Application Resources and Assets Package Custom Application Services Business Process Components Process Choreography Atomic and Composite Services Enterprise Components Custom Application Package Service Requestor Service Provider Presentation Layer 8 5 Industry Models Composite service Atomic service Existing Building Controls oBIX v1.0, AECXML, GBXML oBIX v2.0, BIM Business Service-oriented automation and better IT Systems integration

Developing Enterprise Abstraction Models...whether called n Abstractions n Profiles n Components n Domain-Specific Languages Its all the same 20

Enterprise Abstractions n Capabilities: One for each control silo l Adaptation of LONMark profiles l Translation of SIA UML Use Cases l Power-Systems Use Cases developed in OASIS n Align with BIM (and N-BIM) l Asset Management l Intelligent Operations n COBIE Project 21