All things are created twice. We first create a complete blueprint (1st creation as abstraction) of a house before digging the ground(2nd creation). When we layed out the schemata of a car we then build smallest parts and assemble them to immediate parts to be assembled into larger parts until the final car.
So the first creation is specification in levels to be effective with lowest level being most general and the highest level being the most specific. So specify top down and build bottom up. It is just common sense and theory of hierarchy(Simon, Pattee, Polanyi, Salthe, and Tarski). What is the hierarchy of enterprise software specification? We agree that service is a higher abstraction than object. I'd say that process (related modeling and technology is BPM) is higher abstraction than service. Eric's book says that SOA resides between BPM and applications. That is why we model process priori to service priori to objects and then implement them from objects to services to processes. Processes depend on services that depend on objects. We can add new objects to derive new services while do not impact existing services. New processes could be derived from the orchestration of both existing and new services. So better process agility. Jerry --- Steve Jones <[EMAIL PROTECTED]> wrote: > 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/ > > > > > > > > > > > > > > > > > > > === message truncated === ____________________________________________________________________________________ Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html
