Dears,
just want to carry out a couple of thoughts aloud on a topic which has been discussed several times here but hasn't settled (at least in my mind) -- no, I'm not going into segment/flight/leg here
As far as "core
j2ee patterns" (Alur, Crupi, Malks) is concerned, a business delegate is responsible for the following duties:
(1) reduces coupling between different tiers (mostly presentation tier and business tier)
(2) performs lookup services (mostly using the service locator component)
(3) caches results and links of the business tier on the client-side
Now, I've a couple of questions:
(a) How many BD's are necessary? I feel, that the FBN system is simple enough to be handled by only one BD per client-type. Moreover, I think, this is for the better: The different business components (say, for order, search, pay or something else) deal with nearly the very same business objects in FBN. Due to the caching of results, these results therefore may be cached only once for each component and BD. Therefore, the less BDs the less redundant caching. On a side note, if I want BDs to do caching, how would I communicate this decision in my diagrams?
(b) Lookup services may, but not necessarily have to be implemented together with the BD. If I choose to decouple the lookup service from BDs, the component is necessarily to be deployed on the business tier, right?
Well, I'm aware of the fact that we're not expected to provide a deployment diagram. Nevertheless, I'm feeling uncomfortable with having no idea, where each component belongs to
(c) If BDs are able to cache results at client-side, why should the architecture additionally feature value objects?
Oh well, it's Sunday morning
Any thoughts greatly appreciated,
Harbo
