[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 0.6 looks solid
I think we are *now* ready to look at this. tc From: Considine, Toby
(Facilities Technology Office) Very Useful. Well, I've got my homework
set out for me. tc From: Luc
Clement [mailto:luc.clement@systinet.com] Inline as <lc>..</lc> From:
Considine, Toby (Facilities Technology Office)
[mailto:Toby.Considine@fac.unc.edu] 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. 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. 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 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. 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. 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. 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.
BTW, if you track such terms as
"Sustainable Architecture" and " 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. 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 </lc>] thanks tc From: Luc
Clement [mailto:luc.clement@systinet.com] 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]