How many business delegate components??

[Eduardo Rodrigues]

Hi guys!

I just want to know how many classes that implement Business Delegate in a project???
Is just one??? Like the Service Locator???
Or I can create PaymentDelegate, CustomerDelegate and so on...???

Thank you so much.

[Darryl A. J. Staflund]

Hi there,

I have heard two different answers to this that I like:

1. If the application is small enough, use a single delegate class and a single service locator class.

2. Or, for bigger apps, create one delegate class and one service locator for each EAR file in your application. In this scenario, if you have three EAR files (i.e. consumer.ear, producer.ear, and license.ear -- each with their own collection of EJB files), then you would create 1 delegate class and 1 service class for each.

Darryl
[ June 24, 2004: Message edited by: Darryl A. J. Staflund ]

[Pradeep bhatt]

Or I can create PaymentDelegate, CustomerDelegate and so on...???

Yes, I would go for this approach.

[Eduardo Rodrigues]

Ok but I think one Service Locator is enough for the entire application.
I am thinking in put my ServiceLocator in a CommonServices module...

Thank you guys!

[Ramon Gill]

I agree with one service locator.
Ray

[Peter Bergoff]

1 service locator and 2 business delegates(1 for web and 1 for java client) at a minimun I would think.

[Darryl A. J. Staflund]

> 1 service locator and 2 business delegates(1 for web and 1 for java
> client) at a minimun I would think.

Since business delegates are classes that logically belong to the business tier but are deployed on the presentation tier (so that presentation tier classes can communicate with business tier components using the delegates), this statement is true if we are talking about the number of delegate class files (i.e. components) that need to be created and during deployment, but false if we are talking about the number of different delegate classes (i.e. types) that need to be created in the design model.

That is, if the application you are developing has one or more business components (i.e. EAR files in the deployment model), then you will probably want to do the following:

a. Create one business delegate class in the design model whose component realization in the deployment model will be bundled with each HTML web and Java GUI applicagion. The applications can then use these delegate instances to communication with any of the business components in the business tier.

b. Create one business delegate class for each business component (i.e. EAR file) in the business tier, and then bundle instances of these classes in each of the deployed HTML Web and Java GUI applications. These applications can then use the appropirate delegate instances to talk to a given business component in the business tier.

There are other ways of doing it of course that might be driven by other factors.

Darryl

[Peter Bergoff]

That sounds good to me. One question on how this is represented in the componenet diagram - In Cade's examples of component diagrams he shows a business delegate class. I'm wondering would you separate out the business delegate class like this in a java client component connecting to the business tier also? It's a little hard for me to conceptualize because the java client code is all bundled together and pushed out to the user.

My scenario assumes that it's the same code in each business delegate - just two different client types (web and java client) communicating with the business tier.

[Darryl A. J. Staflund]

> That sounds good to me. One question on how this is represented in the
> componenet diagram - In Cade's examples of component diagrams he shows a
> business delegate class. I'm wondering would you separate out the
> business delegate class like this in a java client component connecting
> to the business tier also?

I am not sure how to answer your question Peter because I don't know what you mean by "separate out". A UML component, as I understand the term, is a "...physical, replaceable part of a system that packages implementation and conforms to and provides the realization of a set of interfaces." A UML component diagram, on the other hand, "...shows the organization and dependencies among component types." In Java-speak, a component is a physical file like JSP pages, Java class files, EAR files, XML descriptors, etc, and a component diagram shows how these components interact with each other when physically deployed in an environment. Although business delegate classes are logically part of the business tier (and should be pictured as such in a class or domain diagram), they are physically deployed with the presentation-tier class-files since they are used by these files to communicate with the business tier. This means that component diagrams will depict delegate class files as being physically deployed on the presentation tier.


> It's a little hard for me to conceptualize
> because the java client code is all bundled together and pushed out to
> the user.

Business delegates conceptually belong to the business tier, but are physically deployed with the presentation tier. Why? Unless they were physically deployed on the business tier, presentation class files couldn't use it to communicate with the business tier.


> My scenario assumes that it's the same code in each business delegate -
> just two different client types (web and java client) communicating with
> the business tier.

That is exactly how it should be because you are deploying the same business delegate with two different presentation-tier impelementations.

Darryl

[Peter Bergoff]

Many thanks! I think I know what I'll do here.