Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Obstakles of Business Delegates

 
H. Hafer
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Eduardo Rodrigues
Ranch Hand
Posts: 199
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
Ricardo Polero Baraldi
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Eduardo:
Vi que vc e do Brasil, eu estou em SP.
Estou fazendo o assigment. Podemos ajudarnos mutuamente ?
Estoy fazendo os User case agora e terminei o prepare.
 
H. Hafer
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic