Obstakles of Business Delegates
H. Hafer
Ranch Hand
Posts: 108
posted 12 years ago
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
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
Eduardo Rodrigues
Ranch Hand
Posts: 199
posted 12 years ago
Hi Hafer
Why did you planning to provide two different business delegate???
I am providing only one business delegate and one service locator. Just posting a note saying that the InitialContext must be configured according to the client...
Please, post your reasons to provide two different BD's...
Thank you so much!
Why did you planning to provide two different business delegate???
I am providing only one business delegate and one service locator. Just posting a note saying that the InitialContext must be configured according to the client...
Please, post your reasons to provide two different BD's...
Thank you so much!
Eduardo Rodrigues<br />SCJP 1.4/5.0 SCWCD 1.3/1.4, SCBCD 1.3, SCMAD, SCEA<br />IBM 484 & 486<br />Belo Horizonte<br />Minas Gerais<br />Brasil
Ricardo Polero Baraldi
Greenhorn
Posts: 26
H. Hafer
Ranch Hand
Posts: 108
posted 12 years ago
In order to facilitate local(!) caching my understanding is that each client-type has to implement its own BD: one for the swing app deployed on the client tier and one for the thin client deployed on the web tier.
If that's nonsense, please speak up.
Ah, well, if you connect your swing app to the business tier through the web app (as suggested sometimes in the forum) then there's no need for two BDs.
Cheers,
Harbo
Originally posted by Eduardo Rodrigues:
Why did you planning to provide two different business delegate???
In order to facilitate local(!) caching my understanding is that each client-type has to implement its own BD: one for the swing app deployed on the client tier and one for the thin client deployed on the web tier.
If that's nonsense, please speak up.
Ah, well, if you connect your swing app to the business tier through the web app (as suggested sometimes in the forum) then there's no need for two BDs.
Cheers,
Harbo
