Yes, I think this is very important - both are needed, and it is a good idea to validate any top-down design using bottom up approaches, and vice versa.
Ereic ----- Original Message ---- From: ash galal <[EMAIL PROTECTED]> To: [email protected] Sent: Monday, February 12, 2007 2:40:28 PM Subject: Re: [service-orientated-architecture] Booch on SOA & Architecture There are no green field projects in the real-world as legacy applications always have to be taken into account. Therefore, a meet-in-the- middle approach is required, rather than pure, top-down or bottom-up process. The bottom-up approach tends to lead to poor business-service abstractions in case the design is dictated by the existing IT environment, rather than existing and future business needs. On the other hand, top-down processing might cause insufficient, non-functional requirement characteristics, and compromise other architecture quality factors (for example, performance problems due to lack of normalization in the domain model) as well as provide impedance mismatches on the service and component layer. Eric Newcomer <[EMAIL PROTECTED] com> 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 <stefan.tilkov@ innoq.com> To: service-orientated- architecture@ yahoogroups. com 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/ Have a burning question? Go to Yahoo! Answers and get answers from real people who know. ____________________________________________________________________________________ Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. http://videogames.yahoo.com/platform?platform=120121
