Subject: RE: [wsdm] Terms being used in WSDM
Generally, +1 to your proposal, John. 4. -> we need to add WS-Resource, not EPRs to the model. EPRs are like URLs they are transient data. 4.a -> 1:1 is not possible as there are EPRs to WS-Resources that are not WSDM manageable resources. For example subscription WS-Resources as per WS-N are not necessarily WSDM manageable resources. I could draft changes that the introduction of WS-Resources will incur in our concept diagrams. -- Igor Sedukhin .. (email@example.com) -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788 -----Original Message----- From: John DeCarlo [mailto:firstname.lastname@example.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: email@example.com 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/leave_workgroup.php.