[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Groups - Draft version of Discovery Section (SOA RM_DiscoveryPresenceandAvailability_05-05.doc) uploaded
Joe,
Wes mistakenly uploaded this to soa-rm instead of
soa-rm-editors. I'd
prefer if you held on for draft 07, and made comments
with line and
section references so that we can track issues properly. I
cannot
process issues that are not made against a proper draft.
And
before you ask...I am only waiting on a couple sections now, and we
should be
seeing an actual draft that you can comment on within
days.
Thanks,
Matt
Chiusano Joseph wrote:
> Here
are my comments on the first few sections:
>
> Section:
“Discovery”:
>
> <Quote>
>
> Discovery, in the
context of Service Oriented Architecture, is the act
> of detecting,
identifying, understanding
>
> </Quote>
>
>
Discovery does not have to do with understanding a service – I believe
>
it has to do with understanding a service description (which is where
>
semantics come in).
>
> <Quote>
>
> and selecting
a service within the constraints and boundary conditions
> of a service
fabric
>
> </Quote>
>
> Please define “service
fabric”.
>
> <Quote>
>
> It must immediately be
pointed out that it is the service description
> that is discovered not
the service itself
>
> </Quote>
>
> If one
discovers a WSDL document that is a service description, and
> that WSDL
document contains a binding that has a SOAP binding with a
> soap:address
element that specifies the location of the service itself
> (a URI),
hasn’t the service itself been discovered? Not sure that
> breaking this
out into 2 levels really helps the reader (too much detail).
>
>
Section: “Structured vs. Unstructured Discovery”
>
>
<Quote>
>
> By and large, unstructured service
descriptions
>
> </Quote>
>
> Recommend striking
this entire paragraph (sorry!:). Rationale: What is
> an “unstructured
service description”? All service descriptions that I
> know of are
structured (WSDL documents, CPP/A, etc.). Do we mean
> “service
specifications”? If so, a service specification is not used
> for
discovery purposes but rather for design, development, and
>
implementation.
>
> Section: “Service Fabric
Constraints”
>
> <Quote>
>
> Should a service
participate in a fabric
>
> </Quote>
>
> Again,
need to define “fabric” otherwise the reader cannot fully
> understand
what is meant by this section. No further comments provided
> on this
section because I am not sure what we mean by “fabric” (I am
> very
familiar with WebMethods “Fabric” and “Glue”, but it is not clear
> that
that is the concept that we mean).
>
> Section: “Discovery
Methods”
>
> <Quote>
>
> The broadcast method for
information (in our case service) discovery
> is used in a number of
technologies and on the Internet today with
> some success
>
>
</Quote>
>
> What are examples of these
technologies?
>
> <Quote>
>
> For example, if an
entity issues an information broadcast,
> specifically a service
description “push”, and the other entity
> (service consumer) is not in a
state capable of receiving it, the
> information is not captured, cannot
be acted upon, and is considered
> lost.
>
>
</Quote>
>
> Why can’t the information be queued in an
asynchronous manner?
>
> <Quote>
>
> Accidental
detection is haphazard at best and reward less at worst
>
>
</Quote>
>
> Why? But primarily, what is “accidental
detection”? Should define it
> here before going further.
>
>
<Quote>
>
> A consumer looking for a suitable service could
search previously
> known locations and if unsuccessful, could then search
other random
> locations ad infinitum.
>
>
</Quote>
>
> That sounds intentional to me – the consumer
intends to find a service
> and is searching intently for
it.
>
> <Quote>
>
> But, how does the consumer
know all replies have been received and
> hence the choice made the
correct one?
>
> </Quote>
>
> If they are unsure
they should allow more time for the replies. This
> seems more like an
implementation issue than an issue for our spec (?).
>
>
<Quote>
>
> Intentional discovery by detection
>
>
</Quote>
>
> Recommend simplifying the term and calling it
“Intentional Discovery”
> or “Discovery by Detection”.
>
>
<Quote>
>
> is typically through a known
medium
>
> </Quote>
>
> Why is this different than
what is being called “accidental
> detection”? The Internet can be used
for accidental detection, and the
> Internet is a known
medium.
>
> <Quote>
>
> This method of discovery
has seen support from the standards bodies
> and significant investment by
the industry
>
> </Quote>
>
> What standards
bodies? What standards? What industry? Why be vague?
>
>
<Quote>
>
> Technologies such as registries and standardized
search engines
> provide for well-defined query semantics
>
>
</Quote>
>
> Is Google a standardized search engine? It is not
clear from the
> description here. If it is, does it have well-defined
query semantics?
> Some would say yes (search rules are made known), and
some may say no
> (it is not possible, for instance, to say “find me all
references to
> the term title, but meaning the title of a house rather
than a book”
>
> <Quote>
>
> simplifying and
removing the burden from the service consumer and
> placing it onto a
well-known entity or agent
>
> </Quote>
>
> What
does “well-known” mean here? Well-known to who?
>
>
<Quote>
>
> There are several competing standards that satisfy
the requirements
> for intentional discovery by detection each with known
issues and
> limitations
>
> </Quote>
>
>
What are these standards? Do you mean UDDI and ebXML Registry? If so,
>
these are not completely competing standards.
>
> Next up: Section
“Identification, Understanding and Matching”
> Thanks for considering
these,
> Joe
>
> Joseph Chiusano
>
> Booz Allen
Hamilton
>
> Visit us online@ http://www.boozallen.com
> <https://webmail.bah.com/exchweb/bin/redir.asp?URL=http://www.boozallen.com/>
>
>
>
------------------------------------------------------------------------
>
*From:* mcgregor.wesley@tbs-sct.gc.ca
> [mailto:mcgregor.wesley@tbs-sct.gc.ca]
>
*Sent:* Tue 5/10/2005 9:34 PM
> *To:* soa-rm@lists.oasis-open.org
>
*Subject:* [soa-rm] Groups - Draft version of Discovery Section (SOA
>
RM_DiscoveryPresenceandAvailability_05-05.doc) uploaded
>
> This
document needs to align with service description.
>
> -- Mr Wesley
McGregor
>
> The document named Draft version of Discovery Section
(SOA
> RM_DiscoveryPresenceandAvailability_05-05.doc) has been submitted
by Mr
> Wesley McGregor to the OASIS SOA Reference Model TC document
repository.
>
> Document Description:
> Preliminary thoughts
on Service Discovery.
>
> View Document Details:
> http://www.oasis-open.org/apps/org/workgroup/soa-rm/document.php?document_id=12564
>
>
Download Document:
> http://www.oasis-open.org/apps/org/workgroup/soa-rm/download.php/12564/SOA%20RM_DiscoveryPresenceandAvailability_05-05.doc
>
>
>
PLEASE NOTE: If the above links do not work for you, your email
>
application
> may be breaking the link into two pieces. You may be able to
copy and
> paste
> the entire link address into the address field of
your web browser.
>
> -OASIS Open
Administration
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]