Issue 6597: replace the update operation (deployment-ftf) Source: Raytheon (Mr. Gerald Lee Bickle, Gerald.L.Bickle(at)raytheon.com) Nature: Uncategorized Issue Severity: Summary: 6.7.1. Target Manager The Target manager serves 3 purposes, deployment behavior, domain information, and registration information. Three different actors use this component. Issue 1: To be consistent with other interfaces for registering and unregistering information with the domain. I would replace the update operation with two operations, register node and unregister node. The register node takes in an abstract nodeManager (needs to be added to spec) and node's xml profile descriptor. This provides a more open interface and can easily accommodate extensions by the type of node manager registering and type of profile information. This allows domains to extend the behavior as necessary without changing the specification. This needs to be a separate interface. The separate interface again provides the capability of extending the registration interface with system/domain specific registration needs. This also may affect the domain profile definition since a node can a profile associated with it. For systems or domains implementations that need this behavior a component could exist that provides this behavior. Not all systems need to formally register their information. Resolution: Revised Text: Actions taken: November 11, 2003: received issue Discussion: During the RTF meetings and telephone conferences the RTF agreed on a general solution outline. A concrete text proposal is needed for resolving this issue. Since such proposal is not yet available this issue is deferred to the next Deployment RTF. End of Annotations:===== ubject: D & C Issues To: issues@omg.org Cc: swradio@omg.org, deployment-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Gerald_L_Bickle@raytheon.com Date: Tue, 11 Nov 2003 07:20:40 -0500 X-MIMETrack: Serialize by Router on NotesServer3/HDC(Release 5.0.12 |February 13, 2003) at 11/11/2003 07:18:57 AM Deployment & Configuration technical Issues 6.7.1. Target Manager The Target manager serves 3 purposes, deployment behavior, domain information, and registration information. Three different actors use this component. Issue 1: To be consistent with other interfaces for registering and unregistering information with the domain. I would replace the update operation with two operations, register node and unregister node. The register node takes in an abstract nodeManager (needs to be added to spec) and node's xml profile descriptor. This provides a more open interface and can easily accommodate extensions by the type of node manager registering and type of profile information. This allows domains to extend the behavior as necessary without changing the specification. This needs to be a separate interface. The separate interface again provides the capability of extending the registration interface with system/domain specific registration needs. This also may affect the domain profile definition since a node can a profile associated with it. For systems or domains implementations that need this behavior a component could exist that provides this behavior. Not all systems need to formally register their To: lsr-identifiers-ftf@omg.org Cc: Michael Niemi , senger@ebi.ac.uk Subject: lsr-identifiers-ftf - proposals for issue resolution (please discuss!) Sensitivity: X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Sean Martin Date: Tue, 13 Jul 2004 11:53:05 -0400 X-MIMETrack: Serialize by Router on D01ML259/01/M/IBM(Release 6.51HF339 | June 21, 2004) at 07/13/2004 11:53:06, Serialize complete at 07/13/2004 11:53:06 Summary of issues from lsr-identifiers-ftf copied from http://www.omg.org/issues/lsr-identifiers-ftf.open.html and proposed resolution for each. Please respond with comments to the list. Kindest regards, Sean ------------------------------------------------------------------------------ Issue 6957: Regarding Life Sciences ID service lifesci 3-5-12, and3-12-02 (lsr-identifiers-ftf) Summary: This OMG spec specifies a mapping to Web services in section 8.2. The second para of 8.2 needs to be clarified to state that only the soap/http binding is conformant to the WS-I Basic ­Profile 1.0a. The basic profile has placed HTTP get/ mappings outside the scope (i.e., BP 1.0 conformant systems may ignore these bindings). This Lifesciencs mapping specifies and uses a new WSDL binding extension, FTP binding. It needs to be clarified that this is an extension to wsdl defined in this OMG spec, and needs to use an OMG lifesciences url (instead of an IBM url) for the namespace of the FTP finding extensions. The actual extension elements need to be defined in a schema which is part of this specification. The semantics of this new FTP binding do not seem toe be completely specified. The explanation of the FTP binding (8.2.4.3 Bindings for FTP) should be enhanced. In particular, it is unclear how the get data with range operation is mapped to FTP, since it states that the binding ignores the input message parts Suggested Resolution: Add the following sentence to end of the second paragragh of Section 8.2: "Note, however, that the only the SOAP over HTTP bindings are compliant with current WS-I profiles. The HTTP and FTP bindings are not WS-I compliant and can be ignored by WS-I compliant systems. The FTP binding is not endorsed by the W3C in the Web Service protocols at this time. It provided for convenience and backwards compatability with existing Life Science data resources that are available as files using the File Transfer Protocol. The WSDL FTP extension specified is not intended to serve as a more general purpose mechanism for describing FTP services beyond this specification. For the purposes of this specification, the LSID resolution client utilizing the FTP binding, is expect to extract the server name and file path from a WSDL port that references the standard FTP binding described in this specification and access that file using the standard FTP protocol. In the absence of any other out band information, that file transfer will default to an anonymous login with a binary transfer mode." As for the FTP binding. The issue asks how the GetDataByRange function is implemented in the FTP binding. The specification, however, already specifies that the GetDataByRange is not implemented in the FTP binding. - So leave document as is. The letters "ibm" should be changed to "omg" and the paths should be made consistant. information.