[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
--> TModel for QoS Information Containing Multiple Categories of QoS Attributes With this solution, we still have the issue of providing metrics' units within the CategoryBag of the QoSInformation tModel even though this information can be easily found in the WSDL file. We know it is too late to open a debate on it and please bear with us for the following comment :) We just have a little concern about the use of WSDL in UDDI and probably you can help us to clarify our thoughts: Usually, a tModel represents a reusable concept. In this solution, if the QoSInformation tModel is categorized with the QoS metrics of a particular service, it is tight to this service and this is not what a tModel is meant to be. We thing that a tModel should be as generic as possible, representing a specific concept/protocole/taxonomy (such as QoS information) but it should not include any information that are bound to one service. What do you think? Are we wrong or did we misunderstand the method? Thank you ! Regards, Maud -----Original Message----- From: blum@systinet.com [mailto:blum@systinet.com] Sent: Thursday, January 22, 2004 2:37 PM To: uddi-spec@lists.oasis-open.org Subject: [uddi-spec] request for item on agenda at next FTF We would like to propose that a technical note be created for how to store web services management information in UDDI. Specifically we think that common quality of service metrics such as average performance, reliability, throughput and availability should be easily available in consistent locations in enterprise registries of web services. We believe that this has great value for customers in providing predictable places to store and search for such information to supplement the information about specific physical implementations of web services, beyond what is natively available on bindingTemplates. We also believe that having such standard ways of accessing this information enhances the value of web services management solutions for customers as there becomes a wider use of the QoS information beyond just the management tool software itself. This includes the ability for developers to use this information in search and browsing for appropriate web service instances to use in a given situation. We would like to involve as many web services management vendors in drafting a recommendation on how and where to store such information. We have posted a rough draft proposal for one possible method of doing such storage (and several other alternatives are presented therein). We are interested in discussing this at the February 10-12 Face to Face in San Francisco. It would be great if we could somehow get on the agenda for this meeting. Thanks in advance for your consideration. Regards, - Adam Blum, CTO, Systinet - Fred Carter, architect, Amberpoint 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/uddi-spec/members/leave_workgro up.php. ------_=_NextPart_001_01C3E205.4FCDFF40 Content-Type: text/html Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2653.12"> <TITLE>RE: [uddi-spec] request for item on agenda at next FTF</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2>Dear all,</FONT> </P> <P><FONT SIZE=3D2>We are extremely interested in this topic and we are = happy to see Adam joining the TC. Here are our comments (for Adam and = the TC) regarding the different methods Adam proposed. To us, the best = approach seems to be the use of UDDI data structure extensions (see our = comments below).</FONT></P> <P><FONT SIZE=3D2>--> TModel for QoS Information Pointing to = External Resource</FONT> <BR><FONT SIZE=3D2>We agree that this solution is very limited since = the QoS document must be processed to retrieve QoS information and no = UDDI query allows us to get this information.</FONT></P> <P><FONT SIZE=3D2>We have two questions for Adam: Are there only = performance and reliability info in this XML document or can we find = further details about the service QoS (such as all the metrics listed = on the document as well as their units, life performance info, ...etc) = ?</FONT></P> <P><FONT SIZE=3D2>Also, how this method affect the compliance with the = WS-I Basic Profile which states that a service specification must be = describe in a WSDL file ?</FONT></P> <P><FONT SIZE=3D2>--> Multiple Categories for QoS Attributes</FONT> <BR><FONT SIZE=3D2>We think that this solution is interesting since = each service implementation is categorized with its own QoS = parameters.</FONT></P> <P><FONT SIZE=3D2>Of course, as long as you want to categorize at the = very maximum a UDDI entity, you will always have large CategoryBags. It = is the same for all types of categorization: for instance, a business, = which is established in 30 different countries, will be categorized = with 30 different geographical taxonomy entries (and that is why = taxonomy browsing mechanisms are really important in UDDI).</FONT></P> <P><FONT SIZE=3D2>For this solution, don't you think it would be better = to create a QoS Taxonomy, which entries represent the different QoS = metrics (taxonomy entries can be hierarchical with sub-level metrics) = and create only one "Categorization" tModel to be used in the = CategoryBag ?</FONT></P> <P><FONT SIZE=3D2>Our concern here is how to provide users with = metrics' unit in the CategoryBag? (does the ResponseTimeAverge is in = second, millisecond, microsecond, ...?)</FONT></P> <P><FONT SIZE=3D2>We guess that, with the progress made on the Semantic = side, we could have another Taxonomy for units, and "semantically" make = a relationship between the two taxonomies to provide Metrics and their = units at the same time. But, at the moment, there is no way to do this = in UDDI.</FONT></P> <P><FONT SIZE=3D2>--> Extend the UDDI Data Structures</FONT> <BR><FONT SIZE=3D2>From our perspective, this method seems to be the = best approach. Also, it would help drive adoption to UDDI V3.0.</FONT> <BR><FONT SIZE=3D2>Don't you think that the data structure extensions = could be standardized so that it would avoid the issue of proprietary = extensions? Moreover, we should determine explicitly which of these = standardized extensions are optional or compulsory.</FONT></P> <P><FONT SIZE=3D2>--> TModel for QoS Information Containing Multiple = Categories of QoS Attributes</FONT> <BR><FONT SIZE=3D2>With this solution, we still have the issue of = providing metrics' units within the CategoryBag of the QoSInformation = tModel even though this information can be easily found in the WSDL = file.</FONT></P> <P><FONT SIZE=3D2>We know it is too late to open a debate on it and = please bear with us for the following comment :) We just have a little = concern about the use of WSDL in UDDI and probably you can help us to = clarify our thoughts: Usually, a tModel represents a reusable concept. = In this solution, if the QoSInformation tModel is categorized with the = QoS metrics of a particular service, it is tight to this service and = this is not what a tModel is meant to be. We thing that a tModel should = be as generic as possible, representing a specific = concept/protocole/taxonomy (such as QoS information) but it should not = include any information that are bound to one service. What do you = think? Are we wrong or did we misunderstand the method?</FONT></P> <P><FONT SIZE=3D2>Thank you !</FONT> <BR><FONT SIZE=3D2>Regards,</FONT> </P> <BR> <P><FONT SIZE=3D2>Maud</FONT> </P> <BR> <BR> <P><FONT SIZE=3D2>-----Original Message-----</FONT> <BR><FONT SIZE=3D2>From: blum@systinet.com [<A = HREF=3D"mailto:blum@systinet.com";>mailto:blum@systinet.com</A>] </FONT> <BR><FONT SIZE=3D2>Sent: Thursday, January 22, 2004 2:37 PM</FONT> <BR><FONT SIZE=3D2>To: uddi-spec@lists.oasis-open.org</FONT> <BR><FONT SIZE=3D2>Subject: [uddi-spec] request for item on agenda at = next FTF</FONT> </P> <P><FONT SIZE=3D2>We would like to propose that a technical note be = created for how to store web services management information in UDDI. = Specifically we think that common quality of service metrics such as = average performance, reliability, throughput and availability should be = easily available in consistent locations in enterprise registries of = web services. We believe that this has great value for customers in = providing predictable places to store and search for such information = to supplement the information about specific physical implementations = of web services, beyond what is natively available on = bindingTemplates. We also believe that having such standard ways = of accessing this information enhances the value of web services = management solutions for customers as there becomes a wider use of the = QoS information beyond just the management tool software itself. This = includes the ability for developers to use this information in search = and browsing for appropriate web service instances to use in a given = situation. </FONT></P> <P><FONT SIZE=3D2>We would like to involve as many web services = management vendors in drafting a recommendation on how and where to = store such information. We have posted a rough draft proposal for one = possible method of doing such storage (and several other alternatives = are presented therein). </FONT></P> <P><FONT SIZE=3D2>We are interested in discussing this at the February = 10-12 Face to Face in San Francisco. It would be great if we could = somehow get on the agenda for this meeting. Thanks in = advance for your consideration.</FONT></P> <P><FONT SIZE=3D2>Regards,</FONT> </P> <P><FONT SIZE=3D2>- Adam Blum, CTO, Systinet </FONT> <BR><FONT SIZE=3D2>- Fred Carter, architect, Amberpoint </FONT> </P> <P><FONT SIZE=3D2>To unsubscribe from this mailing list (and be removed = from the roster of the OASIS TC), go to <A = HREF=3D"http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/l= eave_workgroup.php" = TARGET=3D"_blank">http://www.oasis-open.org/apps/org/workgroup/uddi-spec= /members/leave_workgroup.php</A>.</FONT></P> </BODY> </HTML> ------_=_NextPart_001_01C3E205.4FCDFF40--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]