[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-spec] request for item on agenda at next FTF
I've not had a chance to read the QoS requirements fully but I suspect that there are a number of similarities with the QoS requirements and the GRID requirements (REQ#17). In GRID Services we have a concept of Service Data Elements (SDEs). Without going into the details, roughly this equates to a GRIDService always supporting two operations of the form Get(dataElementName) Set(dataElementName, dataElementValue) Then the WSDL has some extensions which specify what are valid dataElementNames and whether these are read/write or read only [This is a simplification, but good enough to understand the concept] Within GRID SDE's are used for a number of purposes to get additional information about the resource represented by the GRIDService. So a GRIDService representing a computation cluster might have SDE's such as No of CPUs Type of CPU Total amount of memory Amount of memory available to any individual Operating System Current available memory Current load Current number of users Etc. The current model proposed in REQ#17 is that only static (relatively) SDE's which are useful in service discovery are represented in the UDDI registry (via keyedReferencedData probably using general_keyword category). So from the above list the following would be represented in UDDI: No of CPUs Type of CPU Total amount of memory Amount of memory per individual Operating system Etc. The idea is that UDDI is used to bootstrap the process rather than do everything. So a typical scenario might be locate all compute resources which have intel Pentium 4 processors running Linux which have 4GB of currently available RAM. In this case a UDDI search on CPU Type and Operating System would be done to locate potential resources, and then these are queried directly as to current available memory. This fits *my* understanding of the UDDI model better than UDDI containing dynamic data. It is also more efficient on network bandwidth (we don't get thousands of compute resources sending their free memory details etc. every few minutes to a UDDI registry on the off chance someone might try to find them). [Range searching becomes important however to searching SDE's published in UDDI though - a query might have been locate all compute resources with >4 processors] My impression is that QoS data may fall into the same camp as GRID SDE's (i.e. fairly static data in the UDDI registry, more dynamic data exposed by the service itself). Matthew > -----Original Message----- > From: Tom Bellwood [mailto:bellwood@us.ibm.com] > Sent: 27 January 2004 16:01 > To: uddi-spec@lists.oasis-open.org > Subject: RE: [uddi-spec] request for item on agenda at next FTF > > Regarding range based query, please note that REQ#23 for > "keyedReferenceGroup behavioral override" includes a > requirement for range based query of keyedReferences. It's > also in REQ#17 for "Grid Service Items". This capability > should simplify the use of QoS, and our modeling should take > into account these requirements. > > Thanks, > Tom Bellwood Phone: (512) 838-9957 (external); TL: 678/9957 > (internal) Co-Chair, OASIS UDDI Specification TC STSM - > Emerging Technologies IBM Corporation > > > Please respond to <zdenek.svoboda@systinet.com> > > To: <uddi-spec@lists.oasis-open.org> > cc: > Subject: RE: [uddi-spec] request for item on agenda at next FTF > > > > > To me there are following two use cases regarding QoS metadata: > > A) Searching for service by QoS metrics. Service QoS metadata > might be helpful in this scenario. As UDDI registry does not > allow for interval searches in keyedReference values, storing > actual values (average response time = 5.82 ms) does not add > much value for searches. I would like to see some > well-defined categorization of major QoS metrics being > defined in this proposal (I'm not expert in WS management so > I don't have any good suggestion) so I know if the business > service runs on somebody's laptop or on corporate Sun E 10 > 000 machine. > > B) Reading service QoS info. I think that ideal way for > accessing actual QoS data about business service is to define > some well-known service (QoSService) that provides complex > QoS information about the business service and reference the > QoSService binding template (deployment) from the business > service binding template (either via V3 compliant reference > in categoryBag or tModelInstanceInfos). This approach is very > easy for management vendors who would simply implement the > standard the QoSService interface as layer on top of their > QoS data stores. I can also imagine some automated process > that performs some aggregation on top of the QoSService and > regularly updates QoS categories described in ad A). > > Regards > > > ZD > -- > Zdenek Svoboda > Systinet Corp. > 5 Cambridge Center, Cambridge, MA 02142 > Tel: (617) 768-4240 > Fax: (617) 621-1168 > > > > ________________________________ > > From: John Colgrave [mailto:colgrave@hursley.ibm.com] > Sent: Tuesday, January 27, 2004 5:02 AM > To: uddi-spec@lists.oasis-open.org > Subject: RE: [uddi-spec] request for item on agenda at next FTF > > > I have always been very wary of adding such "live" metadata > to UDDI. Trying to describe things like availability in UDDI > can overlap with the support for availability, workload > management etc. in the servers hosting the > applications/services. Similarly, trying to represent > service compositions in UDDI overlaps with flow/process > execution systems. Such systems can allow for alternative > services and compensating services so I doubt it would be > sufficient to deem every service inoperable that had a > (transitive) dependency on a particular service that was > deemed inoperable. > > > > John Colgrave > > IBM > > > > -----Original Message----- > From: Morgenthal, JP [mailto:JP.Morgenthal@softwareagusa.com] > Sent: 26 January 2004 22:10 > To: uddi-spec@lists.oasis-open.org > Subject: FW: [uddi-spec] request for item on agenda at next FTF > > > > All, > > > > I would like to add some additional thought to the work > of Adam and Fred. I believe there is a more generic category > of "live" metadata that pertains to the registration, status, > and availability of Web Services. QoS is one such area, but > so is application configuration and dependency. For example, > a composite application that binds multiple Web Services into > one should be able to be described in the UDDI in such a way > that if one Service is inoperable, the status of the entire > Composite application--through dependency chains--could be > deemed inoperable. By capturing a) a category of data that > is marked as volatile and b) a model for capturing the > dependency of one tModel on another. I believe we can > accomplish the goals set forth by Adam and Fred as well as > enable a much greater capability for complete management of > composite software. > > > > Regards, > > JP > > > > ________________________________ > > > From:CAHUZAC Maud / FTR&D / US > [mailto:maud.cahuzac@rd.francetelecom.com] > Sent: Friday, January 23, 2004 6:05 PM > To: blum@systinet.com; uddi-spec@lists.oasis-open.org > Cc: GARG Shishir / FTR&D / US > Subject: RE: [uddi-spec] request for item on agenda at next FTF > > Dear all, > > 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). > > --> TModel for QoS Information Pointing to External Resource > 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. > > 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) ? > > 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 ? > > --> Multiple Categories for QoS Attributes > We think that this solution is interesting since each service > implementation is categorized with its own QoS parameters. > > 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). > > 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 ? > > Our concern here is how to provide users with metrics' unit > in the CategoryBag? (does the ResponseTimeAverge is in > second, millisecond, microsecond, ...?) > > 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. > > --> Extend the UDDI Data Structures > From our perspective, this method seems to be the best > approach. Also, it would help drive adoption to UDDI V3.0. > 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. > > --> 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 > <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_workgroup.php > <http://www.oasis-open.org/apps/org/workgroup/uddi-spec/member > s/leave_workgroup.php> . > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]