OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsdm] [Disc09/sort of]: Use of UDDI with WSDM.


Thus quoth Sedukhin, Igor S (~ 23-Jun-04 3:10 PM ~)...

> 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 :)...

I think that one of the issues is the ability to include the WSDM 
capabilities in the model.  uddi:bindingTemplates offer little 
flexibility here, while services offer the ability to stuff these into 
keyedRef's in the category bag.  Doing it all through lots of extra 
tModels seems to get more cumbersome.  Doable, but...

>  
> What I'm saying is as follows.
>  
> 1) service
>  
> 
> <businessService>
> 
>    (...)
> 
>    <bindingTemplates>
> 
>       <bindingTemplate>
> 
>          (...)
> 
>        *  <accessPoint urlType="EPR">[serialized EPR]</accessPoint>*
I don't know that I'd really consider an EPR a "urlType".  That might 
require more UDDI changes than otherwise.

Also, I don't know that this is really an "accessPoint" in its 
traditional sense.
> 
>          <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

<Aside>
The "WSDM manageable marker" might be either a concrete ref to the 
associated WSDL Indentity I/F, or might be an "ImAWSDMThingy" tModel.  I 
tend to prefer the latter since it's less obscure, but there's something 
to be said to not have to define things multiple ways.
</Aside>
>  
> CASE II : out-of-bound manageability, same provider
>  
> Business A
>     Service B
>         binding 1 -> WSDL (functional)
>         binding 2 -> WSDL (WSDM) + WSDM manageable marker

Two issues:
    1) If an existing service has multiple [functional] bindings, one 
has to be able to relate their functional & WSDL bindings to one 
another.  Which seems tricky here.   Which might be the case in case III 
below as well, if a functional service has more than one manageability 
provider.

    2) My preference is to try & keep the management stuff somewhat 
separate from the functional.  Over time, these may merge.  Indeed, I 
believe that it's all part of the same thing.  However, in practice, it 
seems that the management portion is often added by "operations" later, 
and if things are mixed, unexpected UDDI purges/mixups might be more 
likely (e.g. a reinstall of "service B" delete's and reinstalls it, 
trashing the manageability part of the world.

    3) In a WSDL 2 world (if we imagine that such a thing exists), we 
might assume that uddi:service & uddi:binding's parallel wsdl:stuff.  In 
that world, it seems like having different binding's here will be 
problematic.  Separating seems cleaner here as well.
>  
>  
> CASE III : out-of-bound manageability, different providers

Why, in your case, are these different businesses?  I don't see why the 
MP here is in a different business entity where in case II it is not?
>  
> 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
>  
> 
> ------------------------------------------------------------------------
> *From:* Fred Carter [mailto:fred.carter@amberpoint.com]
> *Sent:* Wednesday, June 23, 2004 1:24 PM
> *To:* Wsdm (E-mail)
> *Cc:* Fred Carter
> *Subject:* [wsdm] [Disc09/sort of]: Use of UDDI with WSDM.
> 
>     /[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


-- 
Fred Carter / AmberPoint, Inc.

mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]