[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>
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_workgr
oup.php>
http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgro
up.php.
------=_NextPart_000_005C_01C3EBE0.935D6900
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1264" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D733482019-05022004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>We absolutely agree that the specific =
information available=20
should be defined by WSDM. The proposal is just intended to =
identify the=20
specific mechanism that such information will be reflected in UDDI,=20
which presumably there is value in the UDDI TC =
identifying.=20
But your point is well taken. I will be posting another revision =
of=20
the document today that makes that division of goals more=20
clear.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D733482019-05022004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN> </DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D733482019-05022004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Wrt your questions:</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D733482019-05022004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>- We think that having management information =
including QoS=20
metrics is valuable to potential developers that may consider using =
those=20
services and to administrators of those services. So yes, it =
is=20
intended for quality of service discovery. We also think there is =
value to=20
management software in having standard places to store that information, =
but on=20
an aggregated and not necessarily realtime basis. So yes, its to =
"assist=20
management software" but not at runtime (it will probably not be their =
primary=20
store for realtime and detailed information). </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D733482019-05022004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>- I see this fitting in well with =
registries with=20
access control policies, which would identify the management software as =
a =20
(or possibly the only) valid updator of this WSM information. =20
</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D733482019-05022004></SPAN><SPAN=20
class=3D733482019-05022004></SPAN><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
size=3D2>-<SPAN class=3D733482019-05022004> The proposal is a method of =
attaching=20
WSM information to existing published services and binding templates for =
those=20
services. Those services and their physical implementation have =
presumably=20
gone through whatever validation and approval process is appropriate. As =
you=20
probably know we think an approval mechanism for service publishing =
is a=20
very good thing.</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D733482019-05022004>- We have assumed that the administrator of =
the=20
registry has determined who can publish WSM information attached to =
services=20
(via the mechanisms outlined in the paper). The=20
scenario you mention seems to be of a service publisher that=20
"self-assesses" their service or its implementation as having a certain =
quality=20
of service. We would consider this selfassessment to be a service =
level=20
agreement not QoS. And I agree it would be a bad thing if =
every=20
publisher of a service filled in their QoS information in lieu of =
allowing=20
the management software to do so. Perhaps, as a best=20
practice, ACLs should be used to restrict only certain parties =
(such as the=20
external management software) being able to update the QoS=20
information. Some of the approaches mentioned for storage of =
this=20
should make that easy enough to do. =20
</SPAN></FONT></FONT></FONT></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Andrew Hately =
[mailto:hately@us.ibm.com]=20
<BR><B>Sent:</B> Tuesday, January 27, 2004 11:10 AM<BR><B>To:</B>=20
uddi-spec@lists.oasis-open.org<BR><B>Subject:</B> RE: [uddi-spec] =
request for=20
item on agenda at next FTF<BR></FONT><BR></DIV>
<DIV></DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
face=3DArial color=3D#0000ff size=3D2></FONT><BR><FONT face=3Dsans-serif =
size=3D2>My=20
interpretation of the posting is that this is not detailed enough on =
what should=20
be discoverable in UDDI from the Web services management information. =
A=20
better approach to solve the technical mapping between Web service =
management=20
and UDDI should include a detailed review of the specification in =
development in=20
the OASIS TC for Web services distributed management=20
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=3Dwsdm</FONT> =
<BR><BR><BR><FONT face=3Dsans-serif size=3D2>As an alternative, is it =
better to=20
recast this paper as end user quality of service discovery? From =
what I=20
read, the recommended metrics are being used by end users to select web=20
services, as opposed to management software. If that is the intent, I =
think much=20
more discussion of the context of the registry and who is asserting each =
of the=20
properties for the Web service is needed.</FONT> <BR><BR><FONT =
face=3Dsans-serif=20
size=3D2>Answers to the following would help me understand the =
proposal:</FONT>=20
<BR><BR><FONT face=3Dsans-serif size=3D2>Is this proposal intended to =
assist initial=20
selection of a service from a user's perspective or assist management =
software=20
at runtime?</FONT> <BR><FONT face=3Dsans-serif size=3D2>Is this proposal =
intended to=20
apply to registries with particular access control policies? =
</FONT><BR><FONT=20
face=3Dsans-serif size=3D2>Is there any barrier to publishing services =
in the=20
registry such as validation of the service or approval of the =
administrator of=20
the registry?</FONT> <BR><FONT face=3Dsans-serif size=3D2>Are there =
related services=20
that can/should verify the assertions made by the publisher who has =
labelled a=20
service with a certain metric?</FONT> <BR><BR><FONT =
face=3Dsans-serif=20
size=3D2>Regards,</FONT> <BR><FONT face=3Dsans-serif size=3D2><BR>Andrew =
Hately<BR>IBM=20
Austin<BR>UDDI Development, Emerging Technologies <BR>Lotus Notes: =
Andrew=20
Hately/Austin/IBM@IBMUS<BR>Internet: hately@us.ibm.com<BR>(512) =
838-2866,=20
t/l 678-2866<BR></FONT><BR><BR><BR>
<TABLE width=3D"100%">
<TBODY>
<TR vAlign=3Dtop>
<TD width=3D"40%"><FONT face=3Dsans-serif size=3D1><B>"Zdenek =
Svoboda"=20
<zdenek@systinet.com></B> </FONT>
<P><FONT face=3Dsans-serif size=3D1>01/27/2004 08:48 AM</FONT>=20
<TABLE border=3D1>
<TBODY>
<TR vAlign=3Dtop>
<TD bgColor=3Dwhite>
<DIV align=3Dcenter><FONT face=3Dsans-serif size=3D1>Please =
respond=20
=
to<BR>zdenek.svoboda</FONT></DIV></TR></TBODY></TABLE><BR></P>
<TD width=3D"59%">
<TABLE width=3D"100%">
<TBODY>
<TR>
<TD>
<DIV align=3Dright><FONT face=3Dsans-serif =
size=3D1>To</FONT></DIV>
<TD vAlign=3Dtop><FONT face=3Dsans-serif=20
size=3D1><uddi-spec@lists.oasis-open.org></FONT>=20
<TR>
<TD>
<DIV align=3Dright><FONT face=3Dsans-serif =
size=3D1>cc</FONT></DIV>
<TD vAlign=3Dtop>
<TR>
<TD>
<DIV align=3Dright><FONT face=3Dsans-serif =
size=3D1>Subject</FONT></DIV>
<TD vAlign=3Dtop><FONT face=3Dsans-serif size=3D1>RE: =
[uddi-spec] request=20
for item on agenda at next =
FTF</FONT></TR></TBODY></TABLE><BR>
<TABLE>
<TBODY>
<TR vAlign=3Dtop>
<TD>
=
<TD></TR></TBODY></TABLE><BR></TR></TBODY></TABLE><BR><BR><BR><FONT =
face=3DArial=20
color=3Dblue size=3D2>To me there are following two use cases regarding =
QoS=20
metadata:</FONT> <BR><FONT size=3D3> </FONT> <BR><FONT face=3DArial =
color=3Dblue=20
size=3D2>A) Searching for service by QoS metrics. Service QoS metadata =
might be=20
helpful in this scenario. As UDDI registry does not allow for interval =
searches=20
in keyedReference values, storing actual values (average response time =
=3D 5.82=20
ms) does not add much value for searches. I would like to see some =
well-defined=20
categorization of major QoS metrics being defined in this proposal (I'm =
not=20
expert in WS management so I don't have any good suggestion) so I know =
if the=20
business service runs on somebody's laptop or on corporate Sun E 10 000=20
machine.</FONT> <BR><FONT size=3D3> </FONT> <BR><FONT face=3DArial =
color=3Dblue=20
size=3D2>B) Reading service QoS info. I think that ideal way for =
accessing actual=20
QoS data about business service is to define some well-known service=20
(QoSService) that provides complex QoS information about the business =
service=20
and reference the QoSService binding template (deployment) from the =
business=20
service binding template (either via V3 compliant reference in =
categoryBag or=20
tModelInstanceInfos). This approach is very easy for management vendors =
who=20
would simply implement the standard the QoSService interface as layer on =
top of=20
their QoS data stores. I can also imagine some automated process that =
performs=20
some aggregation on top of the QoSService and regularly updates QoS =
categories=20
described in ad A).</FONT> <BR><FONT size=3D3> </FONT> <BR><FONT =
face=3DArial=20
color=3Dblue size=3D2>Regards</FONT> <BR><FONT face=3DArial color=3Dblue =
size=3D2><BR>ZD</FONT> <BR><FONT size=3D2>--<BR>Zdenek =
Svoboda<BR>Systinet=20
Corp.<BR>5 Cambridge Center, Cambridge, MA 02142<BR>Tel: (617) =
768-4240<BR>Fax:=20
(617) 621-1168 </FONT><BR><FONT size=3D3> </FONT> <BR><BR>
<HR>
<FONT face=3DTahoma size=3D2><B>From:</B> John Colgrave=20
[mailto:colgrave@hursley.ibm.com] <B><BR>Sent:</B> Tuesday, January 27, =
2004=20
5:02 AM<B><BR>To:</B> uddi-spec@lists.oasis-open.org<B><BR>Subject:</B> =
RE:=20
[uddi-spec] request for item on agenda at next FTF</FONT><FONT=20
size=3D3><BR></FONT><BR><FONT face=3DArial color=3D#000080 size=3D2>I =
have always been=20
very wary of adding such “live” metadata to UDDI. =
Trying to describe=20
things like availability in UDDI can overlap with the support for =
availability,=20
workload management etc. in the servers hosting the =
applications/services.=20
Similarly, trying to represent service compositions in UDDI =
overlaps with=20
flow/process execution systems. Such systems can allow for =
alternative=20
services and compensating services so I doubt it would be sufficient to =
deem=20
every service inoperable that had a (transitive) dependency on a =
particular=20
service that was deemed inoperable.</FONT> <BR><FONT face=3D"Times New =
Roman"=20
size=3D3> </FONT> <BR><FONT face=3D"Times New Roman" =
color=3D#000080 size=3D3>John=20
Colgrave</FONT> <BR><FONT face=3D"Times New Roman" color=3D#000080 =
size=3D3>IBM</FONT>=20
<BR><FONT face=3D"Times New Roman" size=3D3> </FONT> <BR><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<B><BR>From:</B> Morgenthal, JP=20
[mailto:JP.Morgenthal@softwareagusa.com] <B><BR>Sent:</B> 26 January =
2004=20
22:10<B><BR>To:</B> uddi-spec@lists.oasis-open.org<B><BR>Subject:</B> =
FW:=20
[uddi-spec] request for item on agenda at next FTF</FONT> <BR><FONT=20
face=3D"Times New Roman" size=3D3> </FONT> <BR><FONT face=3DArial =
color=3Dblue=20
size=3D2>All,</FONT> <BR><FONT face=3D"Times New Roman" =
size=3D3> </FONT>=20
<BR><FONT face=3D"Times New Roman" size=3D3> </FONT><FONT =
face=3DArial=20
color=3Dblue size=3D2>I would like to add some additional thought to the =
work of=20
Adam and Fred. I believe there is a more generic category of =
"live"=20
metadata that pertains to the registration, status, and availability of =
Web=20
Services. QoS is one such area, but so is application =
configuration and=20
dependency. For example, a composite application that binds =
multiple Web=20
Services into one should be able to be described in the UDDI in such a =
way that=20
if one Service is inoperable, the status of the entire Composite=20
application--through dependency chains--could be deemed inoperable. =
By=20
capturing a) a category of data that is marked as volatile and b) a =
model for=20
capturing the dependency of one tModel on another. I believe we =
can=20
accomplish the goals set forth by Adam and Fred as well as enable a much =
greater=20
capability for complete management of composite software.</FONT> =
<BR><FONT=20
face=3D"Times New Roman" size=3D3> </FONT> <BR><FONT face=3DArial =
color=3Dblue=20
size=3D2>Regards,</FONT> <BR><FONT face=3DArial color=3Dblue =
size=3D2>JP</FONT>=20
<BR><FONT face=3D"Times New Roman" size=3D3> </FONT>=20
<DIV align=3Dcenter><BR>
<HR>
</DIV><BR><FONT face=3DTahoma size=3D2><B>From:</B> CAHUZAC Maud / =
FTR&D / US=20
[mailto:maud.cahuzac@rd.francetelecom.com] <B><BR>Sent:</B> Friday, =
January 23,=20
2004 6:05 PM<B><BR>To:</B> blum@systinet.com;=20
uddi-spec@lists.oasis-open.org<B><BR>Cc:</B> GARG Shishir / FTR&D /=20
US<B><BR>Subject:</B> RE: [uddi-spec] request for item on agenda at next =
FTF</FONT>=20
<P><FONT face=3D"Times New Roman" size=3D2>Dear all,</FONT><FONT=20
face=3D"Times New Roman" size=3D3> </FONT>
<P><FONT face=3D"Times New Roman" size=3D2>We are extremely interested =
in this topic=20
and we are happy to see Adam joining the TC. Here are our comments (for =
Adam and=20
the TC) regarding the different methods Adam proposed. To us, the best =
approach=20
seems to be the use of UDDI data structure extensions (see our comments=20
below).</FONT>=20
<P><FONT face=3D"Times New Roman" size=3D2>--> TModel for QoS =
Information=20
Pointing to External Resource</FONT><FONT face=3D"Times New Roman" =
size=3D3>=20
</FONT><FONT face=3D"Times New Roman" size=3D2><BR>We agree that this =
solution is=20
very limited since the QoS document must be processed to retrieve QoS=20
information and no UDDI query allows us to get this information.</FONT>=20
<P><FONT face=3D"Times New Roman" size=3D2>We have two questions for =
Adam: Are there=20
only performance and reliability info in this XML document or can we =
find=20
further details about the service QoS (such as all the metrics listed on =
the=20
document as well as their units, life performance info, ...etc) ?</FONT> =
<P><FONT face=3D"Times New Roman" size=3D2>Also, how this method affect =
the=20
compliance with the WS-I Basic Profile which states that a service =
specification=20
must be describe in a WSDL file ?</FONT>=20
<P><FONT face=3D"Times New Roman" size=3D2>--> Multiple Categories =
for QoS=20
Attributes</FONT><FONT face=3D"Times New Roman" size=3D3> </FONT><FONT=20
face=3D"Times New Roman" size=3D2><BR>We think that this solution is =
interesting=20
since each service implementation is categorized with its own QoS=20
parameters.</FONT>=20
<P><FONT face=3D"Times New Roman" size=3D2>Of course, as long as you =
want to=20
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=20
business, which is established in 30 different countries, will be =
categorized=20
with 30 different geographical taxonomy entries (and that is why =
taxonomy=20
browsing mechanisms are really important in UDDI).</FONT>=20
<P><FONT face=3D"Times New Roman" size=3D2>For this solution, don't you =
think it=20
would be better to create a QoS Taxonomy, which entries represent the =
different=20
QoS metrics (taxonomy entries can be hierarchical with sub-level =
metrics) and=20
create only one "Categorization" tModel to be used in the CategoryBag =
?</FONT>=20
<P><FONT face=3D"Times New Roman" size=3D2>Our concern here is how to =
provide users=20
with metrics' unit in the CategoryBag? (does the ResponseTimeAverge is =
in=20
second, millisecond, microsecond, ...?)</FONT>=20
<P><FONT face=3D"Times New Roman" size=3D2>We guess that, with the =
progress made on=20
the Semantic side, we could have another Taxonomy for units, and =
"semantically"=20
make a relationship between the two taxonomies to provide Metrics and =
their=20
units at the same time. But, at the moment, there is no way to do this =
in=20
UDDI.</FONT>=20
<P><FONT face=3D"Times New Roman" size=3D2>--> Extend the UDDI Data=20
Structures</FONT><FONT face=3D"Times New Roman" size=3D3> </FONT><FONT=20
face=3D"Times New Roman" size=3D2><BR>From our perspective, this method =
seems to be=20
the best approach. Also, it would help drive adoption to UDDI =
V3.0.</FONT><FONT=20
face=3D"Times New Roman" size=3D3> </FONT><FONT face=3D"Times New Roman" =
size=3D2><BR>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=20
are optional or compulsory.</FONT>=20
<P><FONT face=3D"Times New Roman" size=3D2>--> TModel for QoS =
Information=20
Containing Multiple Categories of QoS Attributes</FONT><FONT=20
face=3D"Times New Roman" size=3D3> </FONT><FONT face=3D"Times New Roman" =
size=3D2><BR>With this solution, we still have the issue of providing =
metrics'=20
units within the CategoryBag of the QoSInformation tModel even though =
this=20
information can be easily found in the WSDL file.</FONT>=20
<P><FONT face=3D"Times New Roman" size=3D2>We know it is too late to =
open a debate=20
on it and please bear with us for the following comment :) We just have =
a little=20
concern about the use of WSDL in UDDI and probably you can help us to =
clarify=20
our thoughts: Usually, a tModel represents a reusable concept. In this =
solution,=20
if the QoSInformation tModel is categorized with the QoS metrics of a =
particular=20
service, it is tight to this service and this is not what a tModel is =
meant to=20
be. We thing that a tModel should be as generic as possible, =
representing a=20
specific concept/protocole/taxonomy (such as QoS information) but it =
should not=20
include any information that are bound to one service. What do you =
think? Are we=20
wrong or did we misunderstand the method?</FONT>=20
<P><FONT face=3D"Times New Roman" size=3D2>Thank you !</FONT><FONT=20
face=3D"Times New Roman" size=3D3> </FONT><FONT face=3D"Times New Roman" =
size=3D2><BR>Regards,</FONT><FONT face=3D"Times New Roman" size=3D3> =
</FONT><BR><FONT=20
face=3D"Times New Roman" size=3D3> </FONT>=20
<P><FONT face=3D"Times New Roman" size=3D2>Maud</FONT><FONT =
face=3D"Times New Roman"=20
size=3D3> </FONT><BR><FONT face=3D"Times New Roman" =
size=3D3> </FONT>=20
<P><FONT face=3D"Times New Roman" size=3D2>-----Original =
Message-----</FONT><FONT=20
face=3D"Times New Roman" size=3D3> </FONT><FONT face=3D"Times New Roman" =
size=3D2><BR>From: blum@systinet.com [</FONT><A=20
href=3D"mailto:blum@systinet.com";><FONT face=3D"Times New Roman" =
color=3Dblue=20
size=3D2><U>mailto:blum@systinet.com</U></FONT></A><FONT face=3D"Times =
New Roman"=20
size=3D2>] <BR>Sent: Thursday, January 22, 2004 2:37 PM</FONT><FONT=20
face=3D"Times New Roman" size=3D3> </FONT><FONT face=3D"Times New Roman" =
size=3D2><BR>To: uddi-spec@lists.oasis-open.org</FONT><FONT =
face=3D"Times New Roman"=20
size=3D3> </FONT><FONT face=3D"Times New Roman" size=3D2><BR>Subject: =
[uddi-spec]=20
request for item on agenda at next FTF</FONT><FONT face=3D"Times New =
Roman"=20
size=3D3> </FONT>
<P><FONT face=3D"Times New Roman" size=3D2>We would like to propose that =
a technical=20
note be created for how to store web services management information in =
UDDI.=20
Specifically we think that common quality of service metrics such as =
average=20
performance, reliability, throughput and availability should be easily =
available=20
in consistent locations in enterprise registries of web services. We =
believe=20
that this has great value for customers in providing predictable places =
to store=20
and search for such information to supplement the information about =
specific=20
physical implementations of web services, beyond what is natively =
available on=20
bindingTemplates. We also believe that having such standard ways =
of=20
accessing this information enhances the value of web services management =
solutions for customers as there becomes a wider use of the QoS =
information=20
beyond just the management tool software itself. This includes the =
ability for=20
developers to use this information in search and browsing for =
appropriate web=20
service instances to use in a given situation. </FONT>
<P><FONT face=3D"Times New Roman" size=3D2>We would like to involve as =
many web=20
services management vendors in drafting a recommendation on how and =
where to=20
store such information. We have posted a rough draft proposal for one =
possible=20
method of doing such storage (and several other alternatives are =
presented=20
therein). </FONT>
<P><FONT face=3D"Times New Roman" size=3D2>We are interested in =
discussing this at=20
the February 10-12 Face to Face in San Francisco. It would be great if =
we could=20
somehow get on the agenda for this meeting. Thanks in =
advance for=20
your consideration.</FONT>=20
<P><FONT face=3D"Times New Roman" size=3D2>Regards,</FONT><FONT=20
face=3D"Times New Roman" size=3D3> </FONT>
<P><FONT face=3D"Times New Roman" size=3D2>- Adam Blum, CTO, Systinet =
<BR>- Fred=20
Carter, architect, Amberpoint </FONT>
<P><FONT face=3D"Times New Roman" size=3D2>To unsubscribe from this =
mailing list=20
(and be removed from the roster of the OASIS TC), go to </FONT><A=20
href=3D"http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/le=
ave_workgroup.php"=20
target=3D_blank><FONT face=3D"Times New Roman" color=3Dblue=20
size=3D2><U>http://www.oasis-open.org/apps/org/workgroup/uddi-spec/member=
s/leave_workgroup.php</U></FONT></A><FONT=20
face=3D"Times New Roman" size=3D2>.</FONT>=20
<P></P></BODY></HTML>
------=_NextPart_000_005C_01C3EBE0.935D6900--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]