Re: [service-orientated-architecture] Re: Keith on BPM, SOA, OO & Brown Paper

[Eric Newcomer]

One reason this topic comes up is that objects are not the best way to model the world in software.  Services are better, and simpler.  It is too difficult to try to think of all functions the world needs automating in terms of things with operations.  GetCustomerInfo is a valid function but to implement it you shouldn't have to model a Customer object.

 

I completely agree that objects have many benefits in terms of how you instantiate and lifecycle programs but these benefits are often carried too far when they become constraints on thinking, designing, and modeling systems.

 

It may seem like we are going backwards in the software industry but actually I see a lot of progress.  In the distinction between a service and an object I also see the potential for introducing domain specific languages and for a helpful division of labor between those who develop services (and should know about and take advantage of the benefits of OO) and those who consume the services (who should not have to deal with that level of complexity).

 

Eric

----- Original Message ----
From: Gregg Wonderly <[EMAIL PROTECTED]>
To: service-orientated-architecture@yahoogroups.com
Sent: Thursday, October 5, 2006 2:00:45 PM
Subject: Re: [service-orientated-architecture] Re: Keith on BPM, SOA, OO & Brown Paper

William Henry wrote:
> First of all apologies to Keith for calling him Kevin. Don't know why
> that happened. Sincerest apologies Keith.
>
> I think that Keith's comment about modeling real life is fairly
> accurate. But real life also has constraints like bandwidth. So my
> illustration regarding talking to you I(n person or on the phone etc.)
> introduces different abstractions - some looking very procedural.
>
> Remember too that many technologies like services are implemented in OO.
> So the stacks might be implemented in OO even though the layer that we
> use looks very procedural.

I think this is the key issue. It points out that people want simplicity, and
if they don't get any value out of caring about what happens, why should they care?

OO helps with the creation of multiple instances of a service, or stateful
service operations. Each instance, tied to a client/user, can maintain a simple
view of the state involved, and manage it separately from the rest of the
instances. There are, of course, techniques which provide an OO view in a
procedural environment by passing state values around. But in the end, these
are OO systems, because they have state that is not globally viewed.

These discussion about OO, and problems, strongly smack of OO == CORBA/COM/DCOM
where everything becomes a remote call and the granularity of operations
involves many remote exchanges. That's just bad design, not OO. Granularity
has to meet up with needs of the system. Technologies such as Java and mobile
code allow you to use whatever granularity you need, and to adjust it over time,
and customize it even, per client.

Gregg Wonderly

__._,_.___

SPONSORED LINKS

Computer software program	Computer software spy	Computer job
Database software	Discount computer software

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___