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

[Eric Newcomer]

I think that might have been funny except that it is exactly the opposite of what I said.

 

So let me try something it another way.  Services are more abstract than objects.  Services can be implemented using objects, and many times this is a good choice.  However a service can also be implemented using a procedure (stored or otherwise), script, asynchronous messaging system, or ERPcomponent, among others.

 

The purpose of software is to allow humans to tell computers what to do, since computers are basically stupid collections of ones and zeroes that need to be explicitly manipulated and interpreted.  The history of the software industry can be characterized, at least in part if not mainly, as an continued effort to improve the level of abstraction at which a human can tell a computer what to do. 

 

Objects are not as simple or abstract as services, which is another way of putting it as to why it's easier to design systems using the service abstraction.  It is not (at least if it is to fullfill its promise) influenced or constrained by restrictions of the implementation technology.  I believe based on many of your posts that you view this as a bad thing because you are losing control, losing flexibility.  This is the constant argument and constant tension resulting from the evolutionary process. 

 

However in other parts of your posts you also note the difficulty in finding qualified developers, or developers expert enough to understand and capitalize on the rich functionality available.  This suggests that the software is at fault rather than the humans, since it is still too hard for people to tell computers what to do.  Part of the problem is that object orientation requires a somewhat unnatural or non-intuitive way of mapping human and business functions into executable software artifacts. 

 

I am not saying objects are bad - I am saying that OO analysis and design is more complex than SO analysis and design because SO maps more naturally to the real world.  (I imagine Keith would argue with this since one can say that the world consists of a bunch of things but while that is true it is the actions that are important to people and business, not the things in and of themselves - if things don't do anything they are not helpful, but to model a function it should not be required to figure out what the thing is first just because you might want to later make an implementation choice for the service to use OO technology).

 

A corollary is that service development should not be easy for the developer since there is extra work involved in abstracting the object from the service consumer, who should not have to be aware of the implementation technology when requesting a service. 

 

If we (as an industry) can pull this off we can radically change the dynamics of software development and reuse, and take an important step toward the introduction of scientific and industrial methods.

 

Eric

----- Original Message ----
From: Gregg Wonderly <[EMAIL PROTECTED]>
To: service-orientated-architecture@yahoogroups.com
Sent: Friday, October 6, 2006 10:40:44 AM
Subject: Re: [service-orientated-architecture] Re: Keith on BPM, SOA, OO & Brown Paper

Eric Newcomer wrote:
>
>
> Keith,
>
> I wouldn't necessarily characterize it as harder, just unnecessary ;-)

Yes, we should, in fact, all code our software in assembly language. That would
eliminate a lot of tool dependencies, and allow us to take ultimate advantage of
all the features of the hardware that we've spent so much money on.

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

__,_._,___