Hi Stefan,

Yes, but I think it is still a problem, that we think about OO designers 
instead of SO designers...

Services are not objects, and I am only suggesting it would be helpful to 
design the service first, and the object second.  Maybe objects are the best 
way to implement services, but I think objects tend to be more RPC oriented, or 
more typically used for synchronous style interactions.  

I believe some proportion of the world's applications are better served using 
asychronous interactions.  Certainly you can use objects for this - I am not 
trying to minimize the importance of objects in any way.  But I think it helps 
abstract thinking to design a service independently of whether it will be 
implemented using an object or a message queue.  

If you are always designing things in objects I think you might miss one of the 
main benefits of services, which is a higher level of abstraction.

I just think modeling, designing, and thinking about everything in terms of 
objects is overkill, too complex.  But maybe this is because I am kind of an 
old guy, and I remember the world of IT before objects were in it.  

Eric 


----- Original Message ----
From: Stefan Tilkov <[EMAIL PROTECTED]>
To: [email protected]
Sent: Friday, February 9, 2007 5:51:15 PM
Subject: Re: [service-orientated-architecture] Booch on SOA & Architecture

On Feb 8, 2007, at 9:14 PM, Eric Newcomer wrote:

> Yes, an object has a function. But the business more naturally 
> thinks about "getting customer data" than about "the customer is an 
> object on which you perform a get function."

Hi Eric,

I remember we had this discussion before - no OO designer is likely 
to model things this way. It's perfectly fine and custom practice to 
have classes with different roles, some of them more similar to 
"controllers" , others more similar to "entities". Having a 
"CustomerManager" with a "get" operation that returns a "Customer" 
value object is absolutely object-oriented and not at all different 
from a typical SOA approach.

A difference in a typical SOA approach is that the "customer value 
object" would likely be an XML document, but that's a completely 
different aspect than the one you point out.

Stefan
--
Stefan Tilkov, http://www.innoq. com/blog/ st/





 
____________________________________________________________________________________
Never Miss an Email
Stay connected with Yahoo! Mail on your mobile.  Get started!
http://mobile.yahoo.com/services?promote=mail

Reply via email to