Re: new editor's draft of WSA available

Jean-Jacques,

I have incorporated the first part of your comments. There was quite a bit
of material to incorporate, so I have placed your full set of unaddressed
comments on the editor's todo list.

New draft at same location:

 http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch.html

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

"Jean-Jacques Moreau" <moreau@crf.canon.fr> wrote on 10/24/2002 06:03:55 
AM:

> Hi Chris,
> 
> On the same line, I think my SOAP comments[1] on Heather's 
> draft[2] were not addressed either...
> 
> Cheers,
> 
> Jean-Jacques.
> 
> [1] http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/0001.html
> [2] http://lists.w3.org/Archives/Public/www-ws-arch/2002Sep/0296.html
> 
> Christopher B Ferris wrote:
> > 
> > Joel,
> > 
> > Not ignored, but missed (by me). Appologies. I will look to 
incorporate 
> > these comments
> > in a subsequent draft.
> > 
> > Cheers,
> > 
> > Christopher Ferris
> > Architect, Emerging e-business Industry Architecture
> > email: chrisfer@us.ibm.com
> > phone: +1 508 234 3624
> > 
> > Joel Munter wrote on 10/23/2002 02:04:33 PM:
> > 
> >  > Several weeks ago, I completed a review of Heather's draft 
"Discovery 
> > Words" before they were
> >  > incorporated into the WSA draft material.  I see in this latest 
> > publication that my suggestions
> >  > and comments were ignored and the issues that I addressed with my 
> > comments are still present.  I
> >  > have re-issue them here for your reference.  Please consider these 
> > comments.
> >  > 
> >  > Original Comments:
> >  > Portal UDDI Registry: The following sentence seems a touch awkward. 
"A
> >  > portal UDDI registry runs in the service provider's outside the 
> > firewall or
> >  > in a DMZ between firewalls." Please consider adding the word 
> > "environment"
> >  > between provider's and outside. There is the beginning of 
discussion of
> >  > "role-based" visibility here also. There is a similar capability 
that is
> >  > now defined within the UDDI specification itself and should be 
expected
> >  > within vendor-based tools and future registries.
> >  > 
> >  > This comment "...complete business context and well thought out 
> > taxonomies
> >  > are essential if the service is to be found be potential service
> >  > requestors..." which you have associated with just the [public] 
UDDI
> >  > Business Registry absolutely applies equally to all forms and 
usages of
> >  > registries.
> >  > 
> >  > Acquiring Service Descriptions: This statement "...Internal 
Enterprise
> >  > Application UDDI registries and Partner Catalog UDDI registries 
will 
> > require
> >  > no pre screening to establish trust of the service..." is not true. 
I 
> > might
> >  > host a web service within my enterprise and still need to establish 
a 
> > level
> >  > of working "trust" with (internal) users of the service.
> >  > 
> >  > I like to describe WSIL as getting a business card from someone 
that 
> > I have
> >  > already met or someone that I have been introduced to. The 
"business 
> > card"
> >  > provides a rich set of very specific information. If you agree with 
this
> >  > analogy, then you might want to add something to that affect.
> >  > 
> >  > Joel
> >  > 
> >  > 
> >  > -----Original Message-----
> >  > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> >  > Sent: Monday, October 21, 2002 9:44 AM
> >  > To: www-ws-arch@w3.org
> >  > Subject: new editor's draft of WSA available
> > 
> >  >
> >  > All,
> >  >
> >  > I've incorporated Eric and Heather's material with some tweaks. I 
> > have also included the harvesting
> >  > material as is (so we don't forget it:) I haven't included the 
> > management material as yet
> >  > because I understand that the MGT TF wants to noodle on that work 
> > some more before
> >  > they are ready to have it integrated (requiring a format change to 
> > XML). I believe that they
> >  > want to defer this until after the f2f.
> >  >
> >  > Anyway, here's the latest WSA:
> >  >
> >  > 
> > http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch.html
> >  >
> >  > As always, comments welcomed. Note that I still need to update some 

> > of the graphics
> >  > to reflect naming changes we have (I think) settled on to a certain 

> > extent. Please let's
> >  > not get sucked into the vortex of endless debating over terms 
simply 
> > because I was
> >  > only able to find older representations of certain graphics. These 
> > will be updated!
> >  >
> >  > Remember, this is ONLY A DRAFT! :)
> >  >
> >  > Cheers,
> >  >
> >  > Christopher Ferris
> >  > Architect, Emerging e-business Industry Architecture
> >  > email: chrisfer@us.ibm.com
> >  > phone: +1 508 234 3624
> >  > ----- Message from "Munter, Joel D" <joel.d.munter@intel.com> on 
Thu, 
> > 26 Sep 2002 13:40:05 -0700 -----
> >  >
> >  > To:
> >  >
> >  > www-ws-arch@w3.org
> >  >
> >  > Subject:
> >  >
> >  > RE: Discovery words
> >  >
> >  > Hi Heather,
> >  > Is this what you are intending for inclusion into the WSAWG spec? 
If 
> > so,
> >  > then please include it and let's just review one document.  I would 

> > like to
> >  > see the graphics.
> >  > Line numbers would help when providing comments.
> >  > While WSDL is absolutely preferred, there are other mechanisms for 
> > discovery
> >  > of a web service's methods and input and output parameters.  For 
> > instance,
> >  > Microsoft tools offer "reflection."  Maybe we should just state 
that 
> > WSDL is
> >  > preferred.
> >  > Portal UDDI Registry: The following sentence seems a touch awkward. 
 "A
> >  > portal UDDI registry runs in the service provider's outside the 
> > firewall or
> >  > in a DMZ between firewalls."  Please consider adding the word 
> > "environment"
> >  > between provider's and outside.  There is the beginning of 
discussion of
> >  > "role-based" visibility here also.  There is a similar capability 
> > that is
> >  > now defined within the UDDI specification itself and should be 
expected
> >  > within vendor-based tools and future registries.
> >  > 
> >  > This comment "...complete business context and well thought out 
> > taxonomies
> >  > are essential if the service is to be found be potential service
> >  > requestors..." which you have associated with just the [public] 
UDDI
> >  > Business Registry absolutely applies equally to all forms and 
usages of
> >  > registries.
> >  > Acquiring Service Descriptions: This statement "...Internal 
Enterprise
> >  > Application UDDI registries and Partner Catalog UDDI registries 
will 
> > require
> >  > no pre screening to establish trust of the service..." is not true. 

> >  I might
> >  > host a web service within my enterprise and still need to establish 
a 
> > level
> >  > of working "trust" with (internal) users of the service.
> >  > I like to describe WSIL as getting a business card from someone 
that 
> > I have
> >  > already met or someone that I have been introduced to.  The 
"business 
> > card"
> >  > provides a rich set of very specific information.  If you agree 
with 
> > this
> >  > analogy, then you might want to add something to that affect.
> >  > Joel
> >  >
> >  > -----Original Message-----
> >  > From: Heather Kreger [mailto:kreger@us.ibm.com]
> >  > Sent: Wednesday, September 25, 2002 2:06 AM
> >  > To: www-ws-arch@w3.org
> >  > Subject: Discovery words
> >  >
> >  >
> >  >
> >  >
> > 
> >  > Folks,
> >  > Here are the words I had for what I called the Registry Stack. I 
> > tried to
> >  > rename it to the Discovery Agency (I'm still uncomfortable with 
this
> >  > name... any other ideas?).  Again, these words are plaguerized from 

> > our Web
> >  > Services Conceptual Architecture paper 
(http://www.ibm.com/webservices,
> >  > click on resources and scroll down).  Of course this is just a 
starter
> >  > set...
> >  > (See attached file: HKsContribution.discoveryagency.htm)
> >  > Heather Kreger
> >  > Web Services Lead Architect
> >  > STSM, SWG Emerging Technology
> >  > kreger@us.ibm.com
> >  > 919-543-3211 (t/l 441)  cell:919-496-9572
>