RE: latest ws-naming draft (Re: [ogsa-naming-wg] One more thing)

<trm>Comments inline</trm> -----Original Message----- From: owner-ogsa-naming-wg@ggf.org [mailto:owner-ogsa-naming-wg@ggf.org] On Behalf Of Mark McKeown Sent: Tuesday, November 22, 2005 9:58 AM To: Frank Siebenlist Cc: ogsa-naming-wg@ggf.org; ogsa-wg@ggf.org Subject: Re: latest ws-naming draft (Re: [ogsa-naming-wg] One more thing) Hi Frank, I have made some comments inline... First to remove some confusion about IRIs that have appeared in previous mails in this thread. URNs and URLs are URIs[1], IRIs[2] are an extension of URIs to support extra charactors. A URI may or may not map to a real physical address. The WS-Addressing specification[3] defines a number of URIs that do not map to real network locations (eg http://www.w3.org/2005/08/addressing/anonymous). WS-Addressing mandates that the wsa:Address element is an absolute IRI.
* include a profile for the use of the Address and ReferenceParameters that ensure the proper uniqueness property in time and space of the reference. Tom Maguire suggested to use the wsdl binding of the address which sounded very promising.
I am not sure I have understood Tom's argument correctly so I will try and repeat it here in order to be corrected... TomM suggested using the wsa::Address as the name, I understand his argument as being that with the WSDL binding for WS-Addressing you can include the service part of the WSDL into the wsa:Metadata of the EPR, the service part may contain a number of network endpoints indicating that the WS-Resource is available at a number of locations.
From 'Web Services Addressing 1.0 - WSDL Binding' [4]:
"In particular, embedding a WSDL service component description MAY be used by EPR issuers to indicate the presence of alternative addresses and protocol bindings to access the referenced endpoint." In this case the wsa:Address could be a URN (or URI that is not an actual network location) and the client could look to the wsa:Metadata to find the actual network location of the WS-Resource. Quoting Tom[5]: "Let me be very clear about this an EPR does not have a 1 to 1 correspondence with a protocol and binding address. It MUST be true that an EPR can support multiple protocols and their associated addresses." I am not sure I agree, the WS-Addressing WSDL binding uses "MAY" when discussing including WSDL components in the EPR, there is no obligation. <trm>probably should not have capitalized MUST. The important aspect of that statement is 'can support'</trm> I think most services will only use one transport protocol so I think this feature will not be used often - even if a service does use more than one transport/port there is no requirement to advertise this in the EPR. <trm>yes, that is what the 'MAY' means wrt requirement to advertise. I am puzzled why you think that most services will use only one transport protocol. Certainly there are a few to choose from, SOAP/HTTP, SOAP/JMS, SOAP/BEEP and clearly the separation of protocol handlers from service implementation is a good thing.</trm> Also there is no transport bindings available for WS-Addressing - for example the SOAP bindings tells us to take the wsa:Address element and put it into the wsa:To element in the SOAP header but does not tell us what to do with it with regards to the transport protocol (eg most people use the wsa:Address element to create a RequestURI which they set as the POST HTTP Header when using HTTP - this issue has been raised with the W3C TAG[6]). <trm>I wonder what their solution will be.....</trm> Quoting WS-Addressing: "A Web service endpoint is a (referenceable) entity, processor, or resource to which Web service messages can be addressed. Endpoint references convey the information needed to address a Web service endpoint." To me there is a strong emphasis on singlar. <trm>Do me a favor; Define endpoint. That argument has been raging forever.... </trm>
* include a recipe for generation of a single IRI from the Address and ReferenceParameters that can function as an identifier of the resource. Mark Mc Keown pointed at the W3C Web Architecture description of the use of URIs which we could borrow from.
I am not sure about creating an IRI from the wsa:Address and the wsa:ReferenceParameters. Consider the following EPRs <wsa:EndPointReference> <wsa:Address>http://grid.org/jobs/4654</wsa:Address> <wsa:ReferenceParameters> <DateCreated>Thu Nov 17 16:05:43 UTC 2005</DateCreated> </wsa:ReferenceParameters> </wsa:EndPointReference> and <wsa:EndPointReference> <wsa:Address>http://grid.org/jobs/4654</wsa:Address> <wsa:ReferenceParameters> <DateCreated>Thu Nov 17 13:07:53 UTC 2005</DateCreated> </wsa:ReferenceParameters> </wsa:EndPointReference> If DateCreated is just to inform the service when the EPR was created and is not used by the service for anything else then the two EPRs are for the same WS-Resource. However if I create a name based on a combination of the wsa:Address and wsa:ReferenceParameters I will get two different names, ie I have created URI aliases and divided the network losing some of the goodness of Metcalfes law [7]. cheers Mark [1] http://www.ietf.org/rfc/rfc2396.txt [2] http://www.ietf.org/rfc/rfc3987.txt [3] http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/ [4] http://www.w3.org/TR/2005/WD-ws-addr-wsdl-20050413/ [5] http://www-unix.gridforum.org/mail_archive/ogsa-naming-wg/2005/11/msg00021.h tml [6] http://www.w3.org/2001/tag/issues.html#endPointRefs-47 [7] http://www.w3.org/TR/webarch/

Hi Tom,
TomM suggested using the wsa::Address as the name, I understand his argument as being that with the WSDL binding for WS-Addressing you can include the service part of the WSDL into the wsa:Metadata of the EPR, the service part may contain a number of network endpoints indicating that the WS-Resource is available at a number of locations. From 'Web Services Addressing 1.0 - WSDL Binding' [4]:
"In particular, embedding a WSDL service component description MAY be used by EPR issuers to indicate the presence of alternative addresses and protocol bindings to access the referenced endpoint."
In this case the wsa:Address could be a URN (or URI that is not an actual network location) and the client could look to the wsa:Metadata to find the actual network location of the WS-Resource. Quoting Tom[5]:
"Let me be very clear about this an EPR does not have a 1 to 1 correspondence with a protocol and binding address. It MUST be true that an EPR can support multiple protocols and their associated addresses."
I am not sure I agree, the WS-Addressing WSDL binding uses "MAY" when discussing including WSDL components in the EPR, there is no obligation. <trm>probably should not have capitalized MUST. The important aspect of that statement is 'can support'</trm>
I think most services will only use one transport protocol so I think this feature will not be used often - even if a service does use more than one transport/port there is no requirement to advertise this in the EPR. <trm>yes, that is what the 'MAY' means wrt requirement to advertise. I am puzzled why you think that most services will use only one transport protocol. Certainly there are a few to choose from, SOAP/HTTP, SOAP/JMS, SOAP/BEEP and clearly the separation of protocol handlers from service implementation is a good thing.</trm>
The reasons why I think that most people will only use one transport protocol when they come to implement a service are as follows: 1) Most people only use one transport at the minute - HTTP. 2) The extra effort to support more than one tranpsort protocol - debugging etc 3) The interoperability issues - only now with WS-I Basic Profile do we understand how to use HTTP + SOAP. 4) I think when people design systems they will choose protocols that best match the requirements of their application. Each of the different transport protocols have different properties, for example if I use SMTP I can do multicast eg. <wsa:EndpointReference> <wsa:Address>mailto:ogsa-wg@ggf.org</wsa:Address> </wsa:EndpointReference> Replacing SMTP with HTTP for this application would probably break it. 5) The "transport" protocols are leaking into the WS-* layer - you can now have Web Services that support the HTTP GET operation. (If your WSRF implementation doesn't use ReferenceParameters you might be able to use a HTTP GET to retrieve the ResourceProperties document using the HTTP caching support for optimization) I think it is basically an "end-to-end" issue[1], when building a distributed application the developer needs to have an understanding of properties of all layers of his system. For example when signing a SOAP message you should put a ttl value into the message - this value depends on how long you think it will take the message to arrive, a function of the underlying transport protocol. I think SOAP and WS-* has all the ingredients to build "end-to-end" systems (eg if your transport layer doesn't encrypt messages turn on WS-Security, if your tranpsort layer does do reliable message delivery turn on WS-ReliableMessaging etc) but I still think that a developer needs to understand his transport protocol and choose the best one for the job.
Also there is no transport bindings available for WS-Addressing - for example the SOAP bindings tells us to take the wsa:Address element and put it into the wsa:To element in the SOAP header but does not tell us what to do with it with regards to the transport protocol (eg most people use the wsa:Address element to create a RequestURI which they set as the POST HTTP Header when using HTTP - this issue has been raised with the W3C TAG[6]). <trm>I wonder what their solution will be.....</trm>
Quoting WS-Addressing:
"A Web service endpoint is a (referenceable) entity, processor, or resource to which Web service messages can be addressed. Endpoint references convey the information needed to address a Web service endpoint."
To me there is a strong emphasis on singlar.
<trm>Do me a favor; Define endpoint. That argument has been raging forever.... </trm>
I guess should be a question for the WS-Addressing working group... cheers Mark [1] http://mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf

Mark McKeown wrote:
I think most services will only use one transport protocol so I think this feature will not be used often - even if a service does use more than one transport/port there is no requirement to advertise this in the EPR. <trm>yes, that is what the 'MAY' means wrt requirement to advertise. I am puzzled why you think that most services will use only one transport protocol. Certainly there are a few to choose from, SOAP/HTTP, SOAP/JMS, SOAP/BEEP and clearly the separation of protocol handlers from service implementation is a good thing.</trm>
The reasons why I think that most people will only use one transport protocol when they come to implement a service are as follows:
1) Most people only use one transport at the minute - HTTP.
2) The extra effort to support more than one tranpsort protocol - debugging etc
3) The interoperability issues - only now with WS-I Basic Profile do we understand how to use HTTP + SOAP.
WS-I BP doesnt actually fix interop at the SOAP level, because they completely dodged the whole question of which subset of XSD to recommend, so java can still happily reject xsd:unsignedLong, .NET can handle nillables differently, and end users suffer. Maybe, just maybe, the new XSD best practises WG will fix this.
4) I think when people design systems they will choose protocols that best match the requirements of their application. Each of the different transport protocols have different properties, for example if I use SMTP I can do multicast eg.
<wsa:EndpointReference> <wsa:Address>mailto:ogsa-wg@ggf.org</wsa:Address> </wsa:EndpointReference>
Replacing SMTP with HTTP for this application would probably break it.
5) The "transport" protocols are leaking into the WS-* layer - you can now have Web Services that support the HTTP GET operation. (If your WSRF implementation doesn't use ReferenceParameters you might be able to use a HTTP GET to retrieve the ResourceProperties document using the HTTP caching support for optimization)
My WSRF impl rejects any incoming message without a WS-Address, which I believe is a requirement, so implicitly all GET soap reqs fail.
I think it is basically an "end-to-end" issue[1], when building a distributed application the developer needs to have an understanding of properties of all layers of his system. For example when signing a SOAP message you should put a ttl value into the message - this value depends on how long you think it will take the message to arrive, a function of the underlying transport protocol. I think SOAP and WS-* has all the ingredients to build "end-to-end" systems (eg if your transport layer doesn't encrypt messages turn on WS-Security, if your tranpsort layer does do reliable message delivery turn on WS-ReliableMessaging etc) but I still think that a developer needs to understand his transport protocol and choose the best one for the job.
I'd actually consider the option of sending notifications back over alternate transports than HTTP. That is, you may send a message over HTTP(S), but you subscribe with an address that uses XMPP. That way your messages will route through firewalls using the existing jabber relay infrastructure, and make it to you, wherever your laptop happens to be at the time. That is the special case of notificiations, which have two extra needs -sent from a server to a recipient that may be behind a firewall -the delay between subscription and message means that a mobile recipient cannot know what its network address will be in the future, even if the firewall is not an issue (ignoring dynamic dns registries)
Also there is no transport bindings available for WS-Addressing - for example the SOAP bindings tells us to take the wsa:Address element and put it into the wsa:To element in the SOAP header but does not tell us what to do with it with regards to the transport protocol (eg most people use the wsa:Address element to create a RequestURI which they set as the POST HTTP Header when using HTTP - this issue has been raised with the W3C TAG[6]). <trm>I wonder what their solution will be.....</trm>
Quoting WS-Addressing:
"A Web service endpoint is a (referenceable) entity, processor, or resource to which Web service messages can be addressed. Endpoint references convey the information needed to address a Web service endpoint."
To me there is a strong emphasis on singlar.
<trm>Do me a favor; Define endpoint. That argument has been raging forever.... </trm>
I guess should be a question for the WS-Addressing working group...
Its the thing at the far end that doesnt recognise your XSD, as opposed to the things in the middle :)

Hi Steve,
5) The "transport" protocols are leaking into the WS-* layer - you can now have Web Services that support the HTTP GET operation. (If your WSRF implementation doesn't use ReferenceParameters you might be able to use a HTTP GET to retrieve the ResourceProperties document using the HTTP caching support for optimization)
My WSRF impl rejects any incoming message without a WS-Address, which I believe is a requirement, so implicitly all GET soap reqs fail.
WSRF ISSUE 36 - "Consider optional binding to HTTP state transfer protocol" Proposed Recommendation: "The TC must not publish specifications which prevent such a binding being defined. That said, a WSDL 2.0 Web method binding must be possible"
I think it is basically an "end-to-end" issue[1], when building a distributed application the developer needs to have an understanding of properties of all layers of his system. For example when signing a SOAP message you should put a ttl value into the message - this value depends on how long you think it will take the message to arrive, a function of the underlying transport protocol. I think SOAP and WS-* has all the ingredients to build "end-to-end" systems (eg if your transport layer doesn't encrypt messages turn on WS-Security, if your tranpsort layer does do reliable message delivery turn on WS-ReliableMessaging etc) but I still think that a developer needs to understand his transport protocol and choose the best one for the job.
I'd actually consider the option of sending notifications back over alternate transports than HTTP. That is, you may send a message over HTTP(S), but you subscribe with an address that uses XMPP. That way your messages will route through firewalls using the existing jabber relay infrastructure, and make it to you, wherever your laptop happens to be at the time.
That is the special case of notificiations, which have two extra needs -sent from a server to a recipient that may be behind a firewall -the delay between subscription and message means that a mobile recipient cannot know what its network address will be in the future, even if the firewall is not an issue (ignoring dynamic dns registries)
IMHO ATOM might be another good protocol for notification, again it has different properties to JABBER. cheers Mark

(Apologies for multiple copies due to cross postings. Please send to interested colleagues and students) ------------------------------------------------------------------- The First International Conference on Availability, Reliability and Security (AReS) ARES 2006 - "The International Dependability Conference- Bridging Theory and Practice" April, 20th April, 22nd 2006 Vienna University of Technology http://www.ares-conf.org ------------------------------------------------------------------- In conjunction with AINA 2006 (The IEEE 20th International Conference on Advanced Information Networking and Applications ( http://www.aina-conference.org/2006/) Objectives ---------- The First International Conference on Availability, Reliability and Security ("ARES 2006 The International Dependability Conference") will bring together researchers and practitioners in the area of dependability. ARES 2006 will highlight the various aspects of dependability - especially on the crucial linkage between availability, reliability, and security. ARES 2006 aims at a full and detailed discussion of the research issues of dependability as an integrative concept that covers amongst others availability, safety, confidentiality, integrity, maintainability and security in the different fields of applications. ARES 2006 will emphasize on the interplay between foundations and practical issues of dependability in emerging areas such as e- government, m-government, location-based applications, ubiquitous computing, autonomous computing, chances of grid computing etc. ARES 2006 is devoted to the critical examination and research challenges of the various aspects of Dependable Computing and the definition of a future road map. Topics of interest include, but are not limited to: * Secure Enterprise Architectures * (Process based) Security Models / Methods * Risk planning, analysis & awareness * Availability and Reliability * Reliability Models * Failure Prevention * Dependability Assessment * Standards, Guidelines and Certification * Common Criteria Protocol * Security in Distributed Systems / Distributed Databases * Dependability in Open Source Software * Authorization and Authentication * Dependability Requirement Engineering * Network Security * Software Security * Dependability Modelling and Prediction * Cryptographic protocols * Intrusion Detection and Fraud Detection * Privacy-enhancing technologies * Security and privacy issues for sensor networks, wireless/mobile devices and applications * Security and Trust Management in P2P and Grid applications * Survivability of Computing Systems * Interoperability aspects * Security as Quality of Service. * Information Flow Control * Dependability Modelling and Prediction * Tools for Dependable System Design and Evaluation * Temporal Aspects of Dependability * Dependability administration * Dependability Measurement and Analysis * Dependability Benchmarking * Trust Models and Trust Management * Fault/Bug Tolerant Aspects * Internet Dependability * E-Commerce Dependability * Safety Critical Systems * Software Engineering of Dependable Systems * Dependability Aspects of Mobile Government (m-Government) * Dependability Aspects of Electronic Government (e-Government) * Effectivity of Biometrics * Security in Electronic Voting * Security Issues for Ubiquitous Systems * Availability of Pervasive Computing Systems * Dependability Aspects for Special Applications (e.g ERP-Systems, Logistics) * Designing Business Models with security requirements * Security for Biometrics Applications * Security in Electronic Payments * Incident Response and Prevention * Mobile Resources/Services * Mobile Security * VOIP/Wireless Security * Web Security * RFID Security and Privacy * User Interfaces and Dependability * Legal issues * IPR of Security Technology Submission Guidelines --------------------- Authors are invited to submit research and application papers following the IEEE Computer Society Proceedings Manuscripts style: two columns, single-spaced, including figures and references, using 10 fonts, and number each page. You can confirm the IEEE Computer Society Proceedings Author Guidelines at the following web page: URL: http://computer.org/cspress/instruct.htm or http://www.tinmith.net/tabletop2006/IEEE/Format/instruct.htm Submission papers are classified into 3 categorizes (1) full paper (8 pages), (2) short paper (5 pages), and (3) poster (2 pages) representing original, previously unpublished work. Submitted papers will be carefully evaluated based on originality, significance, technical soundness, and clarity of exposition. Contact author must provide the following information at the AReS2006 web site: paper title, authors' names, affiliations, postal address, phone, fax, and e-mail address of the author(s), about 200-250 word abstract, and about five keywords. Prepare your paper in PDF file and submit it at our web site: URL: http://www.ares-conf.org/ Submission of a paper implies that should the paper be accepted, at least one of the authors will register and present the paper in the conference. Accepted papers will be given guidelines in preparing and submitting the final manuscript(s) together with the notification of acceptance. Proceedings of the ARES 2006 conference will be published by IEEE Computer Society Press. Based on quality and referee reviews, some papers not suitable for acceptance as full paper will be accepted for presentation at ARES 2006 in Poster category and will be also included in the IEEE Proceedings. The best papers selected by ARES 2006 program committee out of papers accepted for presentation at ARES 2006 will be further published in some International journals. Important Dates ---------------
Workshop Proposal: September, 30th 2005 Submission Deadline: December, 4th 2005 ==> extended to December, 15th Author Notification: January, 15th 2006 Author Registration: February, 1st 2006 Proceedings Version: February, 1st 2006
ARES 2006 Workshops ===================== In conjunction with the AReS2006 conference, the following workshops will be organised. Workshop 1: The First International Workshop on Dependable and Sustainable Peer-to-Peer Systems (DAS-P2P 2006), Yusuke Doi, TOSHIBA Corporation, Japan + Youki Kadobayashi, Nara Institute of Science and Technology, Japan + Kenji Saito, Keio University, Japan. DAS-P2P 2006 (http://das-p2p.wide.ad.jp/ Workshop 2: "Bayesian Networks in Dependability", BND 2006, Hichem Boudali, University of Virginia, USA + Stefania Montani, University of Piemonte Orientale, Italy. BND 2006 (http://www.mfn.unipmn.it/~stefania/BND2006cfp.html) Workshop 3: "Dependability in large-scale service-oriented systems" (DILSOS), Karl M. Göschka + Schahram Dustdar + Mehdi Jazayeri, Vienna University of Technology, Austria. DILSOS (http://www.ares-conf.org/?q=dilsos) Workshop 4: "Value-based Software Engineering for Dependable Software-Based Systems" (VBSE DSS), Stefan Biffl, Vienna University of Technology + Paul Grünbacher, Johannes Kepler University Linz, Austria. VBSE DSS (http://www.ares-conf.org/?q=vbsedss) Workshop 5: "Security in E-Learning", SEL, Edgar R. Weippl, Vienna University of Technology, Ismail K. Ibrahim, Johannes Kepler University Linz, Austria. SEL (http://www.ares-conf.org/?q=sel) Workshop 6: International Workshop "Dependability Aspects on Data WArehousing and Mining applications" (DAWAM 2006), Jimmy Huang, York University, Canada + Josef Schiefer, Senactive IT-Dienstleistungs GmbH, Austria + Nguyen Manh Tho, Vienna University of Technology, Austria. DAWAM 2006 (http://www.ares-conf.org/?q=dawam) Workshop 7: 1st International Workshop on Bioinformatics and Security (BIOS 06), Küng Josef, University of Linz, FAW Austria + Mazuran Petra, FAW, Austria + Wagner Roland, University of Linz, FAW Austria . BIOS 06 (http://www.ares-conf.org/?q=bios) ARES2006 Organizing Committee ============================= Honorary Co-Chairs ------------------- Norman Revell, Middlesex University, United Kingdom Roland Wagner, University of Linz, Austria General Co-Chairs ------------------ Guenther Pernul, University of Regensburg, Germany Makoto Takizawa, Tokyo Denki University, Japan Program Co-Chairs ------------------ Gerald Quirchmayr, University of Southern Australia, Australia A Min Tjoa, Vienna University of Technology, Austria Workshops Co-Chairs -------------------- Nguyen Manh Tho, Vienna University of Technology, Austria Abdelkader Hameurlain, University of Toulouse, France Leonard Barolli, Fukuoka Institute of Technology (FIT), Japan International Liaison Chair ---------------------------- Maria Wimmer, University of Koblenz-Landau, Germany Charles Shoniregun, University of East London, United Kingdom Publicity Chair --------------------- Vladimir Marik, Czech Technical University, Czech Republic Publication Chair ------------------ Monika Lanzenberger, Norwegian University of Science and Technology, Trondheim, Norway Local Organizing Co-Chairs --------------------------- Maria Schweikert, Vienna University of Technology, Austria Markus Klemen, Vienna University of Technology, Austria Program Committee ----------------------------- See the ARES 2006 Website (http://www.ares-conf.org/?q=pc) For further information, please contact Workshop co-chair: Dr. Nguyen Manh Tho, Institute of Software Technology and Interactive Systems, Vienna University of Technology, Favoritenstraße 9-11/188 A-1040 Vienna, Austria, Tel.: +43-1-58801-18862, Fax: +43-1-58801-18899, email: tho@ifs.tuwien.ac.at
participants (4)
-
Maguire_Tom@emc.com
-
Mark McKeown
-
Nguyen Manh Tho
-
Steve Loughran