Herbjörn, what I would like to avoid in SOA services is repeating the same mistake we (industry) made with EJB. It was taken as new style of old Java objects and all concentrated on details totally forgetting what EJB was for. Since I worked with EJB from day One, I can witness that EJB were meant as enterprise distributed COMPONENTS, not objects, and it was silly to demand OO principles to be preserved in EJB.
I think that Architects (there were very few of them that time) actually lost to developers and could not shield the boundaries of components squeesing objects into them. Details are very important. This is why I write about DOSOM where proper domain functional/service design goes ahead of domain object design, i.e. service set the scope and boundaries for details implemented by objects. - Michael ________________________________ From: Herbjörn Wilhelmsen <[email protected]> To: [email protected] Sent: Thursday, April 16, 2009 7:18:39 AM Subject: Re: [service-orientated-architecture] Re: Erl & Herbjörn offer the 5th SOA Pattern of the Week Colin, I agree that creating business meaningful services is of utmost importance, and that the big picture is the most important one. But, you can have several layers of business meaningful services - all coarse grained in one way or another (e.g. focused on a process or some kind of information) . And, if you only care about the biggest picture you are bound to run into a lot of trouble. That sounds more like powerpoint, ivory tower architecture to me. Caring about architecture at a somewhat more detailed level does not mean that you do not care about the big picture - at least not in my world. /Herbjörn 2009/4/15 Colin Jack <colin.j...@gmail. com> > I do not understand, why bother with services? Make them RPC, and > end the story. > > I think that both Erl & Herbjör miss the point - why services, > especially business services are coarse-grained. They are such > because they implement business functionality. Retrieving a data > field content from a database that somebody calls 'business data' - > fine-grained activity - has nothing to do with any business > functionality, this is why I do not consider it as a business > service (in spite of calculation capabilities of modern hardware). I agree, discussions with people from the business are not at this low level nor should they be. This is one of the many reasons I dislike the style of SOA Erl focusses on so much in his books (others include the unnecessary complexity and, as I see it, inelegance of the resulting solutions). The linked pattern decompose capability (http://www.soapatte rns.org/decompos ed_capability. asp) is a good example of focussing on the details. In the example Invoice service has ReportProcessed which is moved to the InvoiceHistory service. Maybe there is an argument for that change, for example even if we went for a RESTful approach we might decide to create more fine-grained resources so instead of a PUT to Invoice to change the Process value we instead POST an InvoiceHistoryEvent . Whilst these sorts of choices are important I think if we only focus on decisions at this detailed level we do miss the bigger picture (business services, capabilities or bounded contexts depending on your viewpoint). Colin -- Med vänliga hälsningar Herbjörn Wilhelmsen
