I'll just get on my soap box.....
On 12/02/07, Jerry Zhu <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
>
> Eric,
>
> Regarding whether service or object first, my view on
> this is that we model top down from processes to
> services to components/objects and implement bottom
> up.
>
> I agree with you that service is at higher level of
> abstraction and objects are at lower level. So at
> service level we have asynchronous interaction and
> synchronous communication at object level. So the
> higher level include the lower level instead of beign
> exclusive.
>
> I see three levels of modeling and implementation:
> model activities as objects, service as business
> sub-processes and service orchestration as business
> processes. Each level requires different technologies.
I see slightly less
1) Business Services
2) Implementation of business services
a) process
b) object
Sure different technologies, but if you start with Process then by
definition you are not doing SOA you are doing POA.
>
>
> We must model business process first to be able to
> model subprocesses/services and then to model objects.
No, no and thrice no :) Business Process is not where to start, it is
not how businesses are organised and BP does not give flexibility. If
services are just "subprocesses" then SOA isn't worth anything as its
just a subset of POA. BP is one possible implementation approach for
a business service, and it is a long way away from being the only or
most important one.
> Once the modeling is complete we are able to
> implement bottom up: objects to services to service
> orchestration.
Why can't we implement top down?
>
> Implement activities as objects before services give
> us the benefits of reusing objects (activities)
> because activities can be shared by multiple
> subprocesses so that we do not reinvent the wheel.
I'm a bit confused as to how an object can be an activity, surely an
activity is just a method?
>
> Jerry
>
>
> --- Eric Newcomer <[EMAIL PROTECTED]> wrote:
>
> > 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
>
> __________________________________________________________
> Looking for earth-friendly autos?
> Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
> http://autos.yahoo.com/green_center/
>
>
>
