Re: Meeting Notes: 9/7/2001

[Scott Hinkelman <srh@us.ibm.com>]

I have some updates to this below. thanks. <SRH>

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



Farrukh Najmi <Farrukh.Najmi@Sun.COM> on 09/10/2001 08:58:53 AM

To:   "regrep-raws@lists.oasis-open.org" <regrep-raws@lists.oasis-open.org>
cc:
Subject:  Meeting Notes: 9/7/2001




This summarizes the RAWS meeting from last Friday. Please post any
omissions or inaccuracies as my notes were a bit lacking.

Agenda:

-Discuss Registration of Web Services (ROWS) proposal from Sanjay
     -Discuss broader issues like potential UDDI overlap (20 minutes)
     -Discuss use cases and technical details of the proposal (40
minutes)

Attendees: Suresh, Nikola, Scott H. Farrukh, Joel M. and Sanjay

The meeting was devoted entirely to discussing Sanjay's ROWS proposal.

Non-technical Issues
---------------------
We spent the first 30 minutes discussing broader issues that were
non-technical in nature. The focus was exclusively the
concern articulated by Scott H, Dan and Joel M. regarding potential overlap
with like functionality in UDDI.

<editorial>
It should be noted that we had this discussion despite Lisa's direction to
not let UDDI overlap and any future cooperation/convergance
be a factor in our progress.
</editorial>

The meeting started with Scott, Farrukh and Joel echoing their support and
desire for working towards a cooperation/convergence
between UDDI and ebXML registry.

Farrukh said that such cooperation/convergence needs to be bi-lateral and
requires reciprocal and mutual recognition. Currently this is lopsided with
ebXML recognizing the need for cooperation but UDDI not reciprocating.

Scott agreed that the ball is in UDDI's court to reciprocate.

Scott's main concerns was that UDDI's business registration functionality
should not be duplicated by us and that registration of businesses,
services and bindings is not something we should duplicate.

Suresh made an argument that the need for publish/discovery of web
services/bindings is a common and valid use case in non-global
registries such as a public ebXML registry.

Nikola, offered use case of a local soccer league in his hometown offering
a service to sign-up kids for soccer online. This is a purely local service
and it makes no sense to list it in the public UDDI Business Registry (UBR)

Technical Issues
----------------

We spent the next 30 minutes on technical issues though there were
occasional forays into the UDDI overlap issue.

Joel's Technical comments
---------------------------

We started by discussing the technical comments already sent via email by
Joel:

    http://lists.oasis-open.org/archives/regrep-raws/200109/msg00010.html

these are from Joel's comments
< these are from Sanjay's proposal

In section 2.1, Sanjay states "...intrinsic objects by definition would
provide richer functionality with extrinsic objects."  Could someone of
this
list please provide a clear identification of the "benefits" of an
intrinsicObject vs. those of an extrinsicObject.

Sanjay described that the difference between support for web services in
absence of
proposal and with the proposal is that the proposal addresses web services
in a first class
manner, making them more obvious and simpler to use by client.

Farrukh suggested that the model should give first class status to objects
needed in
common use case scenarios and leave a general model for covering all other
scenarios.

In section 4, a SpecificationLink is identified and a preliminary mapping
to
a set of runtime parameters is mentioned.  It is unclear if there is the
possibility of many parameters to each specification link and many
specification links to each binding or some other cardinality.  Please
clarify this.

Farrukh pointed out that the documents clearly states:

<A SpecificationLink instance may have a usageParameters attribute that
provides a collection of Strings
^^^^^^^^

Joel agreed.

Sanjay's Question on Organization-Service Relationship
--------------------------------------------------------

Sanjay asked the question what if there was no compositional relationship
from Organization to Service in model.

Scott felt that this would go a long way to addressing his concerns about
UDDI overlap as this avoid creeping business
semantics into ebXMl Organization object.

<SRH>
However, Scott feels that there should be more discussion around the exact
purpose and semantics of the ebXML
Organization object vrs the exact purpose and semantics of a UDDI Business.
This issue should be a primary topic
of discussion as the ebXML / UDDI relationship emerges. It appears that the
ebXML Organization will now be my final concern in light of UDDI.
</SRH>

Joel felt that the composition relationship was important and should be
retained. He asked how else one would know who
provides the service.

Suresh asked if a Service can be bound to dynamic metadata.

Farrukh said that Service is a RegistryObject under the proposal and all
RegistryObjects relate to their submitting Organization for
audit/security purposes.

Suresh suggested that breaking the Organization-Service Relationship solves
2 problems (addresses Scott's concerns and
improves the model to give Services a first level object status.

Scott said as long as we break Organization-Service Relationship he is
<SRH> musch more </SRH> comfortable. There is nothing new in the proposed
ROWS model; DCE, CDF allowed RPC bindings to be defined in DCE in a similar
manner.

Farrukh and Nikola agreed with Sanjay's idea of breaking the
Organization-Service Relationship and Suresh and Scott's analysis.

Decision: We all agreed to remove the Organization-Service relationship in
next rev of proposal
Action Item: Sanjay to send a revised version of proposal reflecting above
decision

Suresh suggested that <SRH> some </SRH> overlap with UDDI is good, Nikola
agreed that functional <SRH> I believe we meant 'technical' not
'functional'. The difference being that there are technical patterns that
re applicable to support need  use-case functionality, such as
technical-binding-information lookup. The example would be to insure an
ebXML Registry with technical lookup would be applicable for use-cases in
an embedded device. </SRH> overlap is not a bad thing as long as there is
no overlap of business registration functionality. Scott agreed.

Farrukh observed that the functional overlap in ROWS got us talking about
cooperation/convergence so it cant be bad.

Agreement: functional overlap is not a bad thing as long as there is no
overlap of business registration functionality.

Meeting wrapped up with plans to iterate on the proposal and improve it
with team input before submission to TC.

Sanjay ball is in your court. Thanks for the thoughtful proposal and thanks
to team for a fruitful meeting.

--
Regards,
Farrukh