0.6 looks solid

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

 

tc

 

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.

 

tc

From: Luc
Clement [mailto:] 

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:] 

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幦ent                       

Secretary,
OASIS UDDI Spec TC

Systinet
Corporation

Tel: +1.617.395.6798

 

</lc>]  

 

thanks

 

tc

 

 

 

From: Luc
Clement [mailto:] 

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幦ent                       

Secretary, OASIS UDDI
Spec TC

Systinet Corporation

Tel: +1.617.395.6798