RE: [soa-rm] Groups - SOA Service Description Proposal (#295437 v1 - SOA Model for OASIS_05-04.doc) uploaded

[<McGregor.Wesley@tbs-sct.gc.ca>]

Hi Joe,

Thanks for your comments!

One of the most problematic issues with respect to models is the level of abstraction.

If we agree that an implementation is based on an architecture which is derived from a model which has its principles founded in a meta-model whose context is set by a meta-meta-model then yes I think my stuff might be a bit too abstract. To restate:

Meta-meta-models
	generalize 
Meta-Models
generalize 
Models
generalize
Architectures
	generalize
Implementations

So where do I put my comments? Perhaps the Meta-Model layer? You might be right.

But I do think we should allow domains to express themselves somehow in some generalized way. For example, a security policy is inadequate as it is not able to express completely the entire required security continuum and usually defers to governance anyways.  We need a broader brush and a pseudo-mathematical approach may satisfy some of the expressive issues. For example, defining a service in technical and non-technical terms using words is very, very hard to do. Sometimes words do not get the point across well, as we all know. Words can add value but in this instance may cause dissention.

Also, by giving a placeholder to known and not known domains allows for expansion and representation for the architecture to define as they wish.

Perhaps I should add more content first before I turn too many people off.

Have a good day,

Wes

 -----Original Message-----
From: 	Chiusano Joseph [mailto:chiusano_joseph@bah.com] 
Sent:	April 17, 2005 12:18 PM
To:	McGregor, Wesley; soa-rm@lists.oasis-open.org
Subject:	RE: [soa-rm] Groups - SOA Service Description Proposal (#295437 v1 - SOA Model for   OASIS_05-04.doc) uploaded

[Make sure you don't miss the part below regarding the hotel Web Service
and dynamic interfaces!]

Thanks for this - in general, I believe that while this is really good
information, much of it - as represented - is too abstract for our
purposes (as I see them).

Here are my quick thoughts:

We say:

"Therefore a service, at the point of consumption, can be described as
the intersection set of the constraints bounding the producer and those
bounding the consumer"

Yes, but what are we *really* trying to say here, in more concrete
terms? 

I would propose that it is this: In order for a service consumer to
consume a service offered by a service producer, that service has to
satisfy the needs of the service consumer. For example, if the service
consumer has a minimum requirement for QoS (perhaps a minimum response
time), and the service provider - assuming that QoS for the service is
made known - offers a minimum response that is not satisfactory to the
service consumer, then the service consumer will not consume the
service.

We also say:

"With this model we acknowledge that all domains and their constraints
when described by the provider as part of his offering, must be
satisfied by the consumer."

I would amend the end to say "must be found to be *satisfactory* by the
consumer".

We also say:

"A common misconception is that stable interfaces are a key component to
an SOA."

But we don't define what "stable interface" means here. I suspect we
mean - for example - a WSDL document whose operation/message/message
part declarations for a given interface will not change dynamically.

Continuing on this thought, I like the following:

"In the future, dynamically downloadable and configurable service
consumption engines will be developed which will allow dynamic interface
changes and we must be abstract enough to accommodate them."

I just had a good conversation last week with some of the main OWL-S
folks on this concept. I have been thinking of a use case such as the
following: 

- A hotel Web Service is involved by a travel agent (referred to as the
"travel agent hotel Web Service); that hotel Web Service searches hotel
Web sites that each offers its own Web Services accessible from its site
(or from a registry/set of registries) that provides information on
prices for that hotel given various parameters (date of stay, etc.)

- The travel agent hotel Web Service then ranks all hotels according to
the best price

Sounds straightforward so far, but here's the catch:

- When invoked, one of the hotel Web Services says "hey, can give you a
discount if you have 2 or more children" - but that information was not
sent on the wire (i.e. the WSDL message does not contain a message part
for "number of children")

Here's what cannot yet be done, but - IMO - needs to be able to happen
in the future:

- The individual hotel Web Service described above sends a message back
to the travel agent hotel Web Service stating that it needs this
information. Perhaps it sends the request in the form of a message with
parts traveler ID (from original message) and number of children.

- The aggregation process by the travel agent hotel Web Service is
paused, while it serves the request for this additional information

- The message is understood by the travel agent hotel Web Service to the
point where it can query for that exact information regarding the
traveler (NOTE: If such information were described in RDF, simple
reasoning could yield the answer given relationships such as "hasSon",
"hasFather", etc.)

- The message is sent back to the individual hotel Web Service, by the
travel agent hotel Web Service, that contains the additional information
(number of children).

- The individual hotel Web Service now responds with its information,
and the travel agent hotel Web Service now continues the process. It
aggregates all price information, ranks it, and sends the information
back to the screen of the travel agent.  

Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
 

> -----Original Message-----
> From: mcgregor.wesley@tbs-sct.gc.ca 
> [mailto:mcgregor.wesley@tbs-sct.gc.ca] 
> Sent: Friday, April 15, 2005 10:00 AM
> To: soa-rm@lists.oasis-open.org
> Subject: [soa-rm] Groups - SOA Service Description Proposal 
> (#295437 v1 - SOA Model for OASIS_05-04.doc) uploaded
> 
> The document named SOA Service Description Proposal (#295437 
> v1 - SOA Model for OASIS_05-04.doc) has been submitted by Mr 
> Wesley McGregor to the OASIS SOA Reference Model TC document 
> repository.
> 
> Document Description:
> Just some thoughts on what a service is and how one can describe it.
> 
> View Document Details:
> http://www.oasis-open.org/apps/org/workgroup/soa-rm/document.p
> hp?document_id=12271
> 
> Download Document:  
> http://www.oasis-open.org/apps/org/workgroup/soa-rm/download.p
> hp/12271/%23295437%20v1%20-%20SOA%20Model%20for%20OASIS_05-04.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
>