[Argh, this was stuck in my "draft"
folder...]
Thanks Fred and Igor. Looks like I am going to have to dust
of my UDDI...
Pending this (at which point I'll be better equipped to comment on the
specifics of Igor's proposal and not embarrass myself which I might very well be
doing in this email) I think I will Igor's proposal the best. The way I see it,
here is what I would like to get from UDDI (in order of
importance):
-1- When I find the "operational" endpoint for a service in UDDI, also be
able to find (if they are made available) its "management" endpoint(s). I think
this is what Igor's tModel extension gives us. And BTW, this is in the domain of
MOWS since it only makes sense when the resource is a Web
service.
-2- Register and discover management endpoints (after all, they are
Web services like any other) in UDDI. Ideally I would be able to query a
registry specifically for these endpoints, if only because of the marker
portType (identity).
-3- Register for notification when a new management endpoint is adding to
a registry (or removed from the registry).
-4- Register collections of management endpoints (once we have support
for collections in MUWS)
The way I see it, Igor's proposal gives us -1- and unless I am missing
something we get -2- without having to do anything special. I am not sure that
-3- and -4- are critical to WSDM 1.0. In any case, for -3- I think we should
leverage a generic notification mechanism for UDDI if possible. Is there such a
thing? Also, -3- should cover notifications when manageable resources are
added/removed from a collection, but that's a different topic. And I am not sure
at this point that we would need anything special to accommodate -4- but we
won't know for sure until we have Collections done.
That's the beauty of using Web services for management, we get to reuse
the Web services architecture without as it is. I don't see us needed to modify
the security, reliable messaging, etc specs to use them and hopefully we
can reuse UDDI with limited (or no) changes to UDDI, only with best practice
recommendations that leverage existing mechanisms.
Regards,
William
Fred, this is interesting. Why not, though, simply extend
the WSDL tModel to accomodate extra information needed for manageability. May
be we are saying the same thing, but I can't be sure :)...
What I'm saying is as follows.
1) service
<businessService>
(...)
<bindingTemplates>
<bindingTemplate>
(...)
<accessPoint urlType="EPR">[serialized
EPR]</accessPoint>
<tModelnstanceDetails>
<tModelnstanceInfo tModelKey="A"/>
(...)
</tModelnstanceDetails>
</bindingTemplate>
(...)
</bindingTemplates>
</businessService>
2) tModel
<tModel authorizedName="..." operator="..."
tModelKey="A">
<name>StockQuote
Service</name>
<description xml:lang="en">
WSDL description of a
standard stock quote service interface
</description>
<overviewDoc>
<description
xml:lang="en">WSDL source document.</description>
<overviewURL>
http://stockquote-definitions/stq.wsdl
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"
keyName="uddi-org:types"
keyValue="wsdlSpec"/>
<keyedReference tModelKey="uuid:??"
keyName="wsdl-org:markers"
keyValue="manageable"/>
</categoryBag>
</tModel>
Then it would cover as follows.
CASE I : in-bound manageability
Business A
Service B
binding 1 -> WSDL (functional + WSDM)
+ WSDM manageable marker
CASE II : out-of-bound manageability, same
provider
Business A
Service B
binding 1 -> WSDL
(functional)
binding 2 -> WSDL (WSDM)
+ WSDM manageable marker
CASE III : out-of-bound manageability, different
providers
Business A
Service B
binding 1 -> WSDL
(functional)
Business C
Service B
binding 1 -> WSDL (WSDM) + WSDM
manageable marker
--
Igor
Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza,
Islandia, NY 11788
[Disc09]
From management repository to EPR. This is the
topic of the thesis that Fred is currently writing as part of his action
item to the group... ;-) Basically, how much do we want to specify
about the involvement of registries in MUWS.
Well,
what I had signed up for was really use of UDDI for [some of] this
information. At a high level, I think that UDDI as a registry for web
services is quite appropriate for use in relating management providers to the
web services they manage. I suspect it is less appropriate for "other"
managed objects. Nonetheless...
The final result for this AI will
likely be a tech note shared between the WSDM & UDDI groups. It is
still in a rough form; this note outlines the basic ideas for purposes
of discussion.
As background, [a simplistic overview of UDDI states
that] UDDI divides the world into three constituent entity types:
Business entities, business services, and binding templates. These are
arranged in a hierarchy whereby business entities form an organizational unit
in which one places business services; business services, in turn,
represent business functions which are available via binding templates.
Binding templates generally refer to real endpoints.
The world, as
defined above, is described by technical models (or tModels). There are
a number of predefined tModels (for WSDL and its constituent parts, various
business categorization forms, etc.), and users can define their own tModels
to represent various things. tModels can be used to describe identity
& categorization as well as more detailed things like current state,
etc.
For a better description, see the uddi section @ oasis (also
available via uddi.org). Anyway, on to the show...
Proposal Overview
At a high level, we propose to set up a different
business entity (or entities) for managability providers. Where some
organization may have a single (or multiple) business entities which contain
its collection of services and bindings, another one (or few/many) would be
added to contain the management providers.
Within such an entity, each
MP would be represented by a business service entry. Amongst the
information available about the MP would be the following:
- A list of the binding templates (i.e. endpoints) for which it provides
services,
- The management capabilities it would offer on behalf of said binding
- The resource ID (EPR, whatever) by which to reference the managed
service/object
The separation of the managability providers into
a separate business entity allows the current usage within the organization of
UDDI to continue without significant change; only those interested in
management stuff (to use a technical term) need be concerned with the
other entities.
The result of this is that if you want to find the MP
for a service, you can query UDDI for services whose category bag contains a
reference to a your bindingTemplate. Having found such a service, it
will contain the resource identification for your service w.r.t. the MP in
question. Furthermore, you have the list of capabilities that it can
provide (this looks similar to UDDI's WSDL decomposition).
--
Fred Carter / AmberPoint, Inc.
mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525
fax:+1.510.663.6301
1.510.433.6525 fax:+1.510.663.6301