Hi all,
I've started to read the paper about entity aggregation (http://msdn.microsoft.com/library/default.asp url=/library/en-us/dnbda/html/dngrfSOAChallenges-EntityAggregation.asp) and I've started to wonder - In layered service programming, where you have the service interface, the business process, business components and data components, we sometimes want to do an aggregation of entities (for example - an order might contains the order and order line details, but might also contain customer information, history of shippment etc.), each of them handled by it's own business component and data component.
So if I want to create a service method called "GetOrderInfoAndAllOtherStuff", where does the aggregation takes place In the business process because it's not quite a "process". In the business component I've always though that business components should not interact with other business componenets (only with their own data components).
I know that might one say - why not just let the client call each of the components service (I.E. GetOrder(), GetCustomer(), GetShippmentHistory() ...) I've thought of that of course, but it just looks like a waste of time (a lot of time) because some ot the times the requirement is to supply "all" the details, and especially in cases where the requirement is to return a bunch of entities (all with the same form of aggregation).
What's your opinion of the matter
Ido.
Entity Aggregation in the BLL/DAL world
noname00
Matthew
Pepp
because these are not method calls - these are service invocations and the "fine grained" calls are request from services which have real business value - the aggregate in this case as Tom (Mr. SOAPitStop) said is not "some new useful business entity"
Arnon
Brett H.
This is exactly the type of generalization that will kill you if you are aspiring to build reusable assets through service orientation. Please don't take this the wrong way but I seriously doubt that your performance problem has anything to do with calling web services. If you have 4 service calls and they take ~10 seconds to complete you need to put some time into looking at what is causing that delay. I seriously doubt that object serialization/deserialization is your biggest problem. This is the same reason why I almost never see a reason for .NET remoting or binary transports. The degrees of performance benefit you get when stacked up against the network (in a WAN) or your database query is marginal at best.
Also you have the option to make those service calls in parallel if there are not any dependencies between the calls, this would allow you to take that 10 second estimate and bring it right back down to where you were before. I know as a good developer it is always unsettling to see less than optimal request/response strategies like this but in order to move toward reusability you need to find the right level to "componentize" your services. I will bet no one wants to reuse your GetOrderWithExtraStuff service.
Some of the other ideas were good too but I don't know if I'd waste my time building both. I believe it is the responsibility of the Client service agent to aggregate and return to the controller (if you're using MVC) exactly the information the controller needs to build the view. I think the service interface is where you start to expose the meaningful component behavior of your encapsulated business entities.
roadsign71
Regarding the "waste of time" - since the client's agent is responsible to "consume" all the needed services to complete it's "view" of the entity, it sometimes requires the agent to contact 4 service methods :
Each of these calls is sent from the web server to the application server, and each of these calls gets sent from the application server to the db and back (web->app->db->app->web * 4, instead of wep->app->db->app->web * 1).
Calls like these might sometimes take up to a couple of seconds (let's say 10 seoncds) instead of mere seconds - which is quite meaningfull for the end-user.
So some might consider this as a "user interface" requirement, and some might consider this as a "performance" requirement of a system - the first one usually doesn't affect (and shoulnd't affect) how we design the service, but the second one does !
I myself tend to leave user inferface considerations aside when I design services, but performance is something I cannot ignore (if I ignore it in the service, I'll get back to it when designing the client with, for example - caching data)
Ido.
axp
My opinion on the matter is that this is one of the keys to defining services/components that have a broad potential for reuse. Most likely if you are aggregating the order, customer, and shipping history you are doing that to satisfy some requirement of some specific view in some application. This is not in fact some new useful business entity. I would say you should not do the aggregation within that domain.
In my opinion it would be the responsiblity of the Client Service Agent to manage those requests to the autonomous loosely coupled components in an efficient enough way to guarantee we can perform within acceptable limits to the consuming application. The whole thought around building composite applicaitons is that the business services and entities are encapsulated within some type of component structure. Those structures can then be used by any number of clients in any way they see fit (because of the loose coupling).
You mention in your last paragraph that it seems like a "waste of time". Is that some deep rooted concern about perfromance Do you worry about additional complexity What is contributing to this "waste of time".
Carlos Pérez