On 08.02.2007, at 21:17, Eric Newcomer wrote:
What the service does = what message does it accept for processing
and what message, if any, does it return. A description should
also include some information about how to dispatch the message for
processing, such as an environment variable (or the equivalent)
that maps to a procedure name, object method, input message queue
name, stored procedure name, etc.
Do you say you think that such information should be visible to the
client? Or am I misreading you?
Of course a service does more than this, typical descriptions
include quality of service assertions, service level agreements,
and human readable information. But the machine readable stuff is
pretty much the message and a clue as to how the service needs to
process it,
Hmm, when a client has chosen a particular service to have its
message processed (say an OrderProcessor) isn't the 'how' then
obsolete? Isn't the choice of service type all that is needed? Isn't
the 'How' an implementation detail that should remain hidden (to
achieve looser coupling)?
Jan
whether it needs to return a reply etc.
Eric
----- Original Message ----
From: Jan Algermissen <[EMAIL PROTECTED]>
To: [email protected]
Sent: Thursday, February 8, 2007 2:02:14 PM
Subject: Re: [service-orientated-architecture] Booch on SOA &
Architecture
On 08.02.2007, at 18:58, Eric Newcomer wrote:
I also think there needs to be some kind of description of what
that service does, and if it's machine readable that's helpful to
program-program communications.
What exactly do you mean by "what that service does"?
And how could this ever be machine readable?
Jan
Eric
----- Original Message ----
From: Jan Algermissen <algermissen1971@ mac.com>
To: service-orientated- architecture@ yahoogroups. com
Sent: Thursday, February 8, 2007 10:51:19 AM
Subject: Re: [service-orientated -architecture] Booch on SOA &
Architecture
On 08.02.2007, at 14:44, Eric Newcomer wrote:
I think what Steve said in the previous post is very important.
To gain the benefit of service orientation it's important to
design and model software systems in terms of functions
(services) rather than things (objects) since functions are more
naturally aligned with "what we do" as people and businesses.
Hmm, wouldn't it be more enlightening to emphasize payload
instead of interface design? I think the real difference between
an OO design and a service design is to be found in the kind of
payload the remote system accepts. Services, uuh, endpoints should
IMHO be designed around business documents, not around the idea of
moving from OO- (back) to functional design.
Think 'Order' and 'OrderProcessor' and not service.HandleOrder ()
Jan
Given the service abstraction, implementation is a separate
issue. As we have heard many times on this list a wide variety
of technologies can be used for implementation. The most
important thing is to get the design right - meaning to meet the
business requirements, to align with the services that the
business provides for its customers, or other departments.
Eric
----- Original Message ----
From: Mark Baker <[EMAIL PROTECTED] org>
To: service-orientated- architecture@ yahoogroups. com
Sent: Thursday, February 8, 2007 7:58:18 AM
Subject: Re: [service-orientated -architecture] Booch on SOA &
Architecture
On 2/8/07, Dan Creswell <[EMAIL PROTECTED] org> wrote:
> Hmmm,
>
> "Obviously someone who can't give up objects in favor of services"
>
> Someone thinking in objects has serious wrong-thinking in terms of
> design full stop!
RESTful design is largely object-oriented, and I've had no trouble
designing very large scale systems using it. REST was at one time
called the "HTTP Object Model", in fact.
It's also why I've continued to use "distobj" as my email address.
Mark.
--
Mark Baker. Ottawa, Ontario, CANADA. http://www.markbake r.ca
Coactus; Web-inspired integration strategies http://www.coactus. com
Get your own web address.
Have a HUGE year through Yahoo! Small Business.
8:00? 8:25? 8:40? Find a flick in no time
with theYahoo! Search movie showtime shortcut.
Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A.
