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]>
To: [email protected]
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.
