Hi,My view on this is that object is both on a higher and a lower level of abstraction compared to services. It depends on what kind of objects and what kind of services we are talking about. I regard information information as the most stable asset in a organisation, and as such is should be a first class member of the organisation and used as the basis for finding the most stable services.
I've been using object models for over 10 years to model information in the business and I find object models (that has been modeled by business experts) invaluable for aligning IT with business. The kind of object models I'm refering to have many names like business entity models, conceptual object models, business information models and so on. It is about things, events and catogories that are important to the business and their relations to each other.
You need to model processes as well, but the processes should be mapped to the object model to find out which process creates or uses which object. In the same way all systems needs to be mapped to the object model. In this way you should be able to maka a long term plan for which systems that should be retired and which services that should be built to support the business processes in the most efficient way.
I would say that object models on this level (enterprise wide models) has a higher abstraction than the services that implements the object model, but fine grained object models used for implementing a specifik services has a lower abstraction than the service it implements (quite clearly).
regards, // Dennis Jerry Zhu 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.We must model business process first to be able to model subprocesses/services and then to model objects. Once the modeling is complete we are able to implement bottom up: objects to services to service orchestration. 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. 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 forsynchronous 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 amessage 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 beforeobjects 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:more naturallyYes, an object has a function. But the business"the customer is anthinks about "getting customer data" than aboutobject on which you perform a get function."Hi Eric, I remember we had this discussion before - no OOdesigner 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/Yahoo! Groups Links
