It is cool <rant>; I do not have such however I believe that neither SOAP, no
REST, no OO (itself) is, first of all, a platform, and, second, - is SOA. I see
a service programmatic interface, which is not an API (the term's taken for an
object interface) because SOA Service is not an object according to the SOA
standard (likes it Jini or not).
I would like to discuss SOA in this forum, not Java or C#. To Gregg
information, I am afraid, I have to refer to the SOA standard once again and
outline that SOA service user is NOT a programmer in any case and opposite
assumption defeats the purpose and definition of SOA (that were many times
discussed in this forum). Does it make sense to discuss what is a user of a SOA
service once again?
...Back to discussion...
Service execution context (Gregg's "different circumstances") is not a
privilege of of a service provider; it is the circumstances where the
communication between the user/consumer and the service happens (among others).
That is, in SOA, it is expected that the user is aware about the context; if it
is not - the Service Description and Service Contract can help the user
awareness (for the execution context, Description and Contract see SOA RM
standard).
Thus, instead of trying to squeeze two different responses into the single
format, it is better (more comprehensive from the business perspectives) having
two separate response formats that depend on the execution context. Both of
the responses are correct in particular context and none of them is exception.
If one is shooting toward Moon with a pistol and cannot reach it, does it make
sense to discuss the bullet?
I think, the major question is what conditions define service failure and
require throwing an exception and what conditions require return a response.
Plus, in several cases, previous practice demonstrated a return of status
instead of exception and instead of response (status value indicated success or
failure).
My considerations with this regard are:
1) return of status is not sufficient for high level return such as the SOA
service return;
2) properly defined SOA service always defines necessary set of returns
adequate to the execution contexts the service provider offers the service for
(anybody can use the service for whatever is desired but do not blame service
provider if you do not accept Service Description - you are acting on your own
risk). Some of the returns may be negative as defined by the business scenarios
and execution contexts
3) SOA service exception is always caused by a malfunctioning that the service
cannot overdo/recover/compensate.
Simple distinguisher between negative business return and exception is in the
definition of the execution context; the latter has to observe and define all
meaningful negative business returns. However, a SOA request w/o an execution
context is a mistake (this is where SOA != OO and SOA interface != Object API).
- Michael
Gregg Wonderly <[EMAIL PROTECTED]> wrote:
Michael Poulin wrote:
> Unfortunately, I have not received this message from Gregg and got it
> from the Todd's response.
>
> I am curious, what API we are talking about in here? Is this a SOA forum
> or OO forum?
<my rant>
I believe you are being overly narrow in your thinking and response. If all
you
want to do is discuss SOAP, then go to SOAP forum. If you find value in
hearing
others perspectives on how they view SOA and how they design and build
services
than this is a good list for exactly that.
If you tire of my relentless Jini and Java make a great SOA platform, and my
responses focused around that technology, realize that I probably have the
same
experience each time I read the same repeatative mantra from those who think
that SOAP or REST or ... are THE SOA platform. There is no X is SOA...
</my rant>
...Back to discussion...
As service has a set of operations that it can provide the user access too.
If
the service is software and the user is a programmer, than there is an API for
some definition of that (beyond the requisit acronym).
If the set of operations don't allow the service to be useful, than it needs
to
have a different set of operations. I'd contend that a service which provides
a
score for a baseball team, given a date, or another teams name, should have a
corresponding operation that allows you to know if such a game exists.
Otherwise you are complicating the use of the score operation by burdening the
user with having to know how to treat the values returned in two different
circumstances.
Gregg Wonderly
---------------------------------
Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
