RE: [wsdm] Terms being used in WSDM

["Vambenepe, William N" <vbp@hp.com>]

Hi John,

Thanks for your proposal. I have a few concerns with it. The first one
is that it ties us to the name EPR which for all we know might not make
it once the addressing world is standardized. The second is that at this
point the word "endpoint" is useless. Sure we can try to unambiguously
define it one way or the other, but we have the choice between
explaining to people that "what WSDL 2.0 calls an endpoint is not an
endpoint" or that "an endpoint reference does not refer to an endpoint".
Either way, not a very attractive position to be in. So at this point I
say let's stay away form the word endpoint altogether in WSDM
terminology. We didn't create this mess, we don't have to clean it up.
Finally, as long as we keep calling the real, concrete thing we are
managing a "resource" (which I think is the appropriate name) it is
going to be hard to call things that are not real things we are managing
"XXX resource" where XXX is a qualifier like "managed" or "manageable".
What is currently pointed at by an EPR is not a real concrete thing we
are managing, it is an entity through which we are managing real
concrete things. So calling this entity a "XXX resource" is confusing.

Here is what I propose:

- the thing that corresponds to a wsdl11:port and to a wsdl20:endpoint
is now called, when used in the context of WSDM for management, a
"manageability listener". It is not resource-specific (one listener can
be used to manage several listeners). It does not have manageability
capabilities of its own. It is a place where messages are sent that
eventually end up in a resource being managed.

- the thing that corresponds to a fully-qualified wsa:epr is now called,
when used in the context of WSDM for management, a "manageability
representation". It is specific to one "real" resource. One "real"
resource can have more than one such manageability representation.
Manageability representations express and implement manageability
capabilities.

Regards,

William

> -----Original Message-----
> From: John DeCarlo [mailto:jdecarlo@mitre.org] 
> Sent: Thursday, May 27, 2004 11:43 AM
> To: Wsdm (E-mail)
> Subject: [wsdm] Terms being used in WSDM
> 
> 
> Hello,
> 
> As was made painfully clear in today's call, the WSDM TC is using the 
> term "endpoint" in at least two to four different ways.  And this is 
> causing differences in perception of the Logical Model of MUWS.
> 
> IMNSHO, this confusion is a "bad thing".
> 
> While I am not a good diagram creator or modifier, I believe 
> we need to 
> update the MUWS Logical Model to be clearer.
> 
> Here is one proposal that will need to be shredded and reassembled 
> before we can get agreement, but it is a place to start.
> 
> In particular, I think that William and Heather would argue 
> that there 
> is no need any longer for the "manageability endpoint" in the WSDL 
> sense.  They might argue that we only, perhaps, talk about the "thing 
> pointed to by the Manageability EPR that accepts SOAP messages for 
> exactly one Manageable Resource".  I can't say I understand 
> the purpose, 
> and personally find it too confusing.  Though it does simplify in the 
> sense that you are always only talking to Manageable 
> Resources, never to 
> Manageability Providers (or their WSDL endpoints).
> 
> Anyway, here is my proposal.
> 
> PROPOSAL - When we use the term "endpoint", we only use it in 
> the WSDL 
> sense.  In all the WSDM specifications, including MUWS and MOWS.
> 
> 1.  This means that we can leave all our diagrams the same, 
> except that 
> we have to add some things like EPRs or WS-Resources.
> 
> 2.  When we use the term "EPR", we say it is a reference to a 
> Manageable 
> (Fred has a good point here that Managed is more correct once 
> you get to 
> sending SOAP messages) Resource.  And the content of the EPR 
> is defined 
> in WS Addressing, maybe clarified in WS-RF.
> 
> 3.  Logically, to do something like GetResourceId, a Manageability 
> Consumer sends a properly formatted WSDM SOAP message, which 
> contains an 
> EPR so that the Manageability Provider knows which Manageable 
> Resource 
> is being referred to, to the Manageability Endpoint specified 
> in the WSDL.
> 	3.a.  To remind people, this does not constrain the locus of 
> implementation at all.
> 	3.b.  The Manageability Endpoint (being a WSDL 
> Endpoint) may have more 
> than one Manageable Resource behind it.  The EPR helps out 
> here one way 
> or another according to best practices at the time.
> 	3.c.  This begs the question of the singleton pattern.  
> Does it require 
> an EPR or not?  And if we support the *not* case, (which helps 
> implementors that haven't gotten around to WS-RF, WS 
> Addressing, EPRs, 
> etc.) what are the implications?  [Note:  wiser heads than I have 
> started this singleton discussion already.]
> 
> 4.  The MUWS Concept Model should include EPRs.
> 
> 	4.a. One approach is to simply say there is a 1:1 mapping from 
> Manageable Resource to EPR.  Then you have to mention that 
> one "thing" 
> being managed may have multiple Manageable Resources/EPRs.  
> This is what 
> the current MUWS Concept model shows.  So we could add the EPR to the 
> Concept Model as well.  In fact, doesn't the EPR allow the 
> Manageability 
>   Endpoint in the Concept model to provide access to exactly one 
> Manageable Resource?
> 
> 	4.b.  I don't think I like any other approaches, but 
> will leave this in 
> here for a place holder.
> 
> 
> 5.  The MUWS Logical Model should address EPRs.
> 
> 	5.a.  One option is to say that the Manageability 
> Consumer "accesses 
> (and provides an EPR)" the Manageability Endpoint which 
> "provides access 
> to the Manageable Resource indicated by the EPR".
> 
> -- 
> 
> John DeCarlo, The MITRE Corporation, My Views Are My Own
> email:      jdecarlo@mitre.org
> voice:      703-883-7116
> fax:        703-883-3383
> DISA cube:  703-882-0593
> 
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leav
e_workgroup.php.