OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[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


Title: [soa-rm] Groups - Draft version of Discovery Section (SOA RM_DiscoveryPresenceandAvailability_05-05.doc) uploaded

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



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]