0.6 looks solid

I think we are *now* ready to look at this.

From: Considine, Toby (Facilities Technology Office)
Sent: Sunday, June 27, 2004 11:52 AM
To: 'Luc Clement'; 'Tom Bellwood'; 'Rogers, Tony'
Cc: 'Aaron Hansen'; EMCS Interest Group
Subject: RE: Congratulations on the formation of the oBIX TC

Very Useful. Well, I've got my homework set out for me.

From: Luc Clement [mailto:luc.clement@systinet.com]
Sent: Sunday, June 27, 2004 11:37 AM
To: Considine, Toby (Facilities Technology Office); 'Tom Bellwood'; 'Rogers, Tony'
Cc: 'Aaron Hansen'
Subject: RE: Congratulations on the formation of the oBIX TC

Inline as <lc>..</lc>

From: Considine, Toby (Facilities Technology Office) [mailto:Toby.Considine@fac.unc.edu]
Sent: Saturday, June 26, 2004 13:09
To: 'Luc Clement'; Tom Bellwood; 'Rogers, Tony'
Cc: Aaron Hansen
Subject: RE: Congratulations on the formation of the oBIX TC

Sorry to be slow to respond. While I have been talking SOAP to control systems for years, nearly 5 now, and telling controls people that controls discovery would be handled by UDDI, I havd always described it as the card catalogue of SOAP and passed on, content that I would not have to think about it.

Now I do.

Aaron Hansen, who chairs the oBIX XML standards SC and I have discussed this, and the answer he came up with was "We are not ready". Having said that, I can still speculate freely on what makes an oBIX registry different.
[<lc>Given from what I read below - you are ready and you must (IMHO) start thinking and designing with registry and management in mind. If you don't, you'll waste too much time retrofitting your specs later on in the process. Read-on.... </lc>]

As a first aproximation, oBIX is different because the first implimentations will feel more like intranet then internet. If I am implimenting a supervisaory control program on top of oBIX, or even an enterprise-wide utility billing system, I will likely be within a company. D&B identifier, for example, will not be a useful identifier.
[<lc>Ah! You have been tainted by the perception that UDDI = "UDDI Business Registry". It is not; I can say that because I've been part of the Microsoft team implementing its public UDDI node along with partners such as IBM, SAP and NTT.

Sure it is true the UBR implements UDDI, but the use cases for UDDI haven't been motivated by B2B/UBR needs in at least two releases of the spec. Products available from many vendors specifically target internal business needs/use cases both in terms of publishing and query support. UDDI is about enterprise use as the registry for Web services.

As for taxonomies: D&B, NAICS, UNSPSC, ISO3166 were just examples of taxonomies that where defined in the v1 spec and incorporated in the v2 spec - they are just that, examples which were used to bootstrap people's thinking about taxonomy and its use with UDDI as a means of supplementing registration with metadata. UDDI provides you with the ability to define any taxonomy. Indeed products available from vendors all have taxonomy support tools to import/export/create/edit taxonomies, their values and associated metadata. Indeed, few customers use D&B et al; they all build their own to meet their internal needs. As such, it's a wide open field.

UDDI is very much part of the Web services stack. Tooling is available from vendors to support publishing, design time and runtime scenarios - all to support enterprise needs.

</lc>]

What I do imagine, however, is three ways I will troll through an oBIX registry:

1) By location. With 400+ buildings on the UNC campus I will be interested in finding the many web services in the Chemistry Building. Thereafter I may be interested in either "All control systems on the 3rd floor" or "all Security Systems in the building" or even "all revenue meeters" in the building
[<lc> Common supported use case </lc>]

2) By Service type. We are thinking 2-3 services in the first release, but it may well be that we have slightly more than one service type per vertical control market; we have listed more of these as a group and more are "discovered" in conversation regularly.

[<lc> Common supported use case. What this calls for is for your TC to define common WSDLs for these vertical control markets with the associated UDDI tModel (interface definitions), supporting taxonomy/metadata definitions, and bindings.

I would recommend that you define 2-3 examples but focus on defining the methodology to use for creating new ones given that folks will have to extend and innovate around your framework.

</lc>]

3) By Tenant. I'm not sure what this means, it just came out when I was typing.
[<lc> UDDI provides for identification and categorization; it is likely that tenants may be identified via "identifier schemes" available in UDDI, though I have a sense that once you start exploring all the possible modeling use cases that you may end up with building "categorization schemes". Too early to tell.</lc>]

In any case, I think this means thaty there will be an oBIX taxonomy to support this. At some level, parts of the top level identifier may well look like the top hierarchy in the GBXML spec (www.gbxml,org); please refer to the GBXML object halfway through the schema, immediately below the enumerations.
[<lc> I've had a *brief* look at the schema file and can say that it can be accommodated directly via UDDI categorization; you should note that the enums defined would likely be represented as "checked" taxonomies implying node enforcement of the values used at time of publishing. There are few other things that I can think of at the moment to establish relationships between these enums but I'll refrain to venture into that discussion until I've taken the time to look at the categorization schemes proposed by the schema.</lc>]

Many obix things are sensors, effectively read only. I might have an oBIX weather station; of great interest, but read only until we develop a method to turn off the rain. In the same way, many interactive oBIX services will be filled with read-only data points; revenue meters, room temperatures, humidity sensors, etc. We anticipate tenants, for example will have great interest in these. Somehow I imagine that a UDDI-oBIX appllication will be able to post the sensor versionj and the control system version.
[<lc> I love to hear this as we are in the process of partnering with the Web services Distributed Management (WSDM) TC to identify the WSDM-UDDI "binding" (if you like). Fred Carter of the WSDM TC and I are co-authoring a UDDI Technical Note (does not have to be a spec given that it is simply an application of UDDI - much as I think oBIX would do). Here is the abstract:

This Technical Note provides the framework for describing how Web services management properties and manageability provider information are represented in UDDI. This document defines 1) how to map manageability capabilities defined by the Management using Web Services (MUWS) and Management of Web Services (MOWS) specifications of the OASIS Web Services Distributed Management TC onto UDDI structures; 2) how to publish and discover the manageability provider endpoints using UDDI; and 3) how to represent in UDDI purpose-specific management properties such as quality of service metrics.

The document should be available within 2 weeks in (solid) draft form. </lc>]

BTW, if you track such terms as "Sustainable Architecture" and "Green Buildings" and "LEEDs", these standards all rely on a very large number of sensors, to allow auditing of building peroformance. I would not be surpised to find many oBIX end-points that are nothing but sensors, with no control functionality. (I do not anticipate a single oBIX point will often be found; I want the oBIX data logger to classifiy, and categorize the callibration of data - and perhaps correlate several of them temperature + humidity to compute dewpoint)
[<lc> I think you should look at WSDM's MUWS/MOWS specifications as they provide the framework for thinking and articulating how to represent these "managed" devices; it is that framework from which the aforementioned UDDI Technical note leverages.</lc>]

Do we need to have a way to classify action points? "I am a temperature, and if you want to change me, go talk to that HVAC service over there. . ." Another one might be the URL of who to call about this service - or what department maintains it, or. .

What questions would you have us be thinking of? I know just enough about UDDI to spel it.
[<lc> IMO you need to start thinking about management and registry as early on as possible. I've been tracking WSDM and they are now just really starting to think about registry and I think that they are having problems articulating/thinking about their needs at the moment precisely because they delayed the discussion too long. It's a fine balance; I can't say I blame them. The good news is that they are now in the midst of the discussion - which is what motivated the Technical Note I described above.

I would suggest that your TC track WSDM and the UDDI TechNote ASAP; doing so will help provide clarity of thinking about your management and registry needs. A liaison between our TCs is probably warranted.

So to recap, "UDDI != UDDI Business Registry"; UDDI is the Web services registry and if you intend to expose Web services, UDDI needs to be your registry; and let's not forget wide vendor support for registry products and tooling (design-time and runtime).

Hope this helps clarify things a tad.

Luc Cl�ment

Secretary, OASIS UDDI Spec TC

Systinet Corporation
Tel: +1.617.395.6798

</lc>]

thanks

From: Luc Clement [mailto:luc.clement@systinet.com]
Sent: Monday, June 21, 2004 1:04 PM
To: Considine, Toby (Facilities Technology Office)
Cc: Tom Bellwood; 'Rogers, Tony'
Subject: Congratulations on the formation of the oBIX TC

Toby,

Congratulations on establishing your TC. I'd (and I'd expect the UDDI Spec TC co-chairs cc'ed) be interested in understanding your TC's registry needs.

Regards,

Luc

Luc Cl�ment

Secretary, OASIS UDDI Spec TC

Systinet Corporation
Tel: +1.617.395.6798

obix-xml message