business delegate and service locator

[Peter Bergoff]

Hi everyone,

Do you think it's okay to collapse the service locator and the business delegate into one class?

Also - although both of these classes are created in the business tier they physically reside with the client - correct?? So each client would need their own business delegate and service locator from the common business tier?

Many thanks for your help!!

Peter

[Parag Doshi]

Originally posted by PETER BERGOFF:
Hi everyone,

Do you think it's okay to collapse the service locator and the business delegate into one class?

Also - although both of these classes are created in the business tier they physically reside with the client - correct?? So each client would need their own business delegate and service locator from the common business tier?

Many thanks for your help!!

Peter

Hi Peter,
This is an excerpt from the SUN blueprints site (http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html)

'A Business Delegate uses a component called the Lookup Service. The Lookup Service is responsible for hiding the underlying implementation details of the business service lookup code. The Lookup Service may be written as part of the Delegate, but we recommend that it be implemented as a separate component, as outlined in the Service Locator pattern (See "Service Locator" on page 368.)'


From what I understand, a business delegate uses the services of ServiceLocator. Business delegate is far more broader than a service lookup and its interface would have lot more business calls than a service locator. I feel that they both should be kept separate as its always better to provide the client a narrow interface (only giving what they need) than a broad one. As far as where they are located, I think the ServiceLocator is basically a singleton and the business delegate would be common for every client, as you would normally have only one business tier for all types of client. So, you could bundle the business delegate and the servicelocator in a common jar file and place it with every client or it can be located in the .war file, I am not sure where they would reside.
Hope this helps..

Parag
[ July 24, 2004: Message edited by: Parag Doshi ]

[Peter Bergoff]

Thanks Parag! Good info.

So I guess if each client needs it's own business delegate and service locator then it should be repeated for each client in a component diagram - assuming they don't share a common location. However, the code for the business delegate and service locator would be identical.

What are people's thoughts about my assumptions???

Thanks.

[Tomi Tuomainen]

I'm not quite sure that implementation of the Business Delegate would be same for all the clients. For example web app Business Delegate component would have to serve many clients (synchronized methods must be considered?) but swing app Business Delegate will always take care of one client. Maybe caching requirements could also be different for each client type.

Could we create different Business Delegate components (for example WebAppBusinessDelegate, SwingBusinessDelegate) and let the designers decide if these components can use (partly) same classes?

Tomi

[Parag Doshi]

Originally posted by Tomi Tuomainen:
I'm not quite sure that implementation of the Business Delegate would be same for all the clients. For example web app Business Delegate component would have to serve many clients (synchronized methods must be considered?) but swing app Business Delegate will always take care of one client. Maybe caching requirements could also be different for each client type.

Could we create different Business Delegate components (for example WebAppBusinessDelegate, SwingBusinessDelegate) and let the designers decide if these components can use (partly) same classes?


Tomi

Hmmm.. I didnt think that far off..If such a scenario does exist, then its time to introduce the abstract factory. And definetely at this level of the game, we just define the interfaces and leave the implementation to the designers/coders.

any thoughts?

Parag
[ July 25, 2004: Message edited by: Parag Doshi ]

[Peter Bergoff]

Okay - I'm pretty sure the business tier creates the service locator and business delegate but then it is used by their clients to gain access to the business tier. So it's placed with the client's code. If this is true each client will need to show their own business delegate and service locator in the component diagram.

Would everyone agree with this??

[Tomi Tuomainen]

Peter,

If I'm not totally lost here, each client will create their own Business Delegate and Service Locator and uses those to access business services. So each client (web and swing) could show their own access components in a component diagram. If the access is similar, this would mean copying the same component for both clients. If the access is different, we still could build a common component (with Abstract Factory) to serve all clients.

Please, correct me if I'm wrong!

Tomi

[Peter Bergoff]

Tomi - I think you and I are on the same page.

Can anyone else confirm or/and comment?

Thanks.

[Parag Doshi]

Originally posted by Tomi Tuomainen:
Peter,

If I'm not totally lost here, each client will create their own Business Delegate and Service Locator and uses those to access business services. So each client (web and swing) could show their own access components in a component diagram. If the access is similar, this would mean copying the same component for both clients. If the access is different, we still could build a common component (with Abstract Factory) to serve all clients.

Please, correct me if I'm wrong!

Tomi

Tomi,
I did not understand the access component part. What did you mean by access component?

guys..These are my 2 cents on this topic. The way I see it, the swing app can be architected in atleast 2 different ways. First one is where the client tier (EventController, for instance) communicates directly with the business tier via the business delegate (which I assume is what Tomi and Peter are driving towards) and the second way is that the client controller (EventController) which resides on the client side, communicates with the web tier and the web tier depending on the request (url based, perhaps) would instantiate the right implementations of Business Delegate, Service locator etc (Abstract Factory pattern --creating family of related objects).
Given these 2 scenario, I would personally go for the second approach (if its doable). That will bring consistency in the web tier and everything can be streamlined from that tier onwards. That way, if we introduce a totally different type of client in the future, all we need to do is have another family of implementation objects to be instantiated at the web tier and we are all set.
The reason for opting for the second approach is also due to the fact that if everything is streamlined via the web tier, the system can be vertically scaled and load balancing/fail over can be achieved as we have 2 web servers against 1 application server. The system can be scaled better at the web tier.Given that, I wouldnt want to burden the application server by direct requests from the client app.
Does this make sense?

Parag

[Tomi Tuomainen]

Originally posted by Parag Doshi:

I did not understand the access component part. What did you mean by access component?

I meant Business Delegate and Service Locator (my own "access component" definition :roll: ) . Client uses these components to access business services so these must physically reside in client distribution package.

The way I see it, the swing app can be architected in atleast 2 different ways. First one is where the client tier (EventController, for instance) communicates directly with the business tier via the business delegate (which I assume is what Tomi and Peter are driving towards)

Yes, but basically I was talking about any client that needs to access EJB tier.

and the second way is that the client controller (EventController) which resides on the client side, communicates with the web tier and the web tier depending on the request (url based, perhaps) would instantiate the right implementations of Business Delegate, Service locator etc (Abstract Factory pattern --creating family of related objects).

I'm still considering these both possibilities. The latter sounds very reasonable, but I still have doubts if this architecture gets too complicated because we need to create communication mechanism between web server and swing client. And can we truly have common presentation logic in web tier? But going with the first one may end in duplicating code and less maintenability. For example view helpers could be common for both, but is it best to reuse the same component within another client, or to centralize the logic by installing the component into just one client (web server)?

I'm not sure if this decision will affect scalability. If the logic resides directly in swing client workstation (and not in web server) that can't make the system less scalable. The amount of communication to EJB tier would probably be the same in both cases?

Tomi

[ July 25, 2004: Message edited by: Tomi Tuomainen ]
[ July 25, 2004: Message edited by: Tomi Tuomainen ]

[Parag Doshi]

Originally posted by Tomi Tuomainen:

I'm still considering these both possibilities. The latter sounds very reasonable, but I still have doubts if this architecture gets too complicated because we need to create communication mechanism between web server and swing client. And can we truly have common presentation logic in web tier? But going with the first one may end in duplicating code and less maintenability. For example view helpers could be common for both, but is it best to reuse the same component within another client, or to centralize the logic by installing the component into just one client (web server)?

I'm not sure if this decision will affect scalability. If the logic resides directly in swing client workstation (and not in web server) that can't make the system less scalable. The amount of communication to EJB tier would probably be the same in both cases?

Tomi

[ July 25, 2004: Message edited by: Tomi Tuomainen ]

[ July 25, 2004: Message edited by: Tomi Tuomainen ]

okay, one thing is certain that the client tier can communicate either directly with the ejb tier or through the web tier. which is the better of the two? well..its quite debatable..lets look at the non-functional aspects of it..

Performance - The agents are supposed to get a response time of not more than 5 seconds on every request. If we introduce the web tier in between, then I think the response time would be longer than directly accessing the business tier. As the java client would communicate directly with the ejb tier, the response time should be better than the web tier (any thoughts?).

Manageability - Its easier to manage the code if its localized on only one tier (business) . So, any further updates to the business tier code wouldnt require to be handled out to each client desktop, but would be localized only on the app server (even though, java web start makes code refresh pretty trivial nowadays). again, it can go either way...

Maintenance - There is definitely more code to maintain on the java app side if it accesses the business tier directly. In this scenario the java app now needs to know which technology the business objects are implemented in (ejb) as the business delegate would be using the service locator to locate and invoke remote methods on ejbs. On the other hand, if this is moved to the web tier, then the java app would only need to know abt Value Objects, which would be returned from requests made to the web tier. Tomorrow, if the technology in which the business tier is implemented changes, then the java swing client wouldnt be affected at all (i think !). This makes the system more flexible too, i guess.

Security - It is declarative and managed by the container in both the scenarios, so not sure how would one outweigh the other.

Scalability - I am not sure if any of these choices affect the scalability of the app. We have only 1 app server, so the most we can do is vertically scale it and that would need to be done in either scenarios. The web servers would be horizontally scaled, i guess..though not sure if that helps the java client tier in this case or not.

Given some of the non -functional specs, I think the 2 biggest factors which can affect the decision is going to be performance and security.

I am still not convinced which of them is a better architectural decision either way.

Any thoughts ?

Parag
[ July 26, 2004: Message edited by: Parag Doshi ]

[D. Rose]

Hi Parag,

Is security an issue for travel agents? Aren't they inside the boundry?(using shared computer etc...)

[Parag Doshi]

Originally posted by D. Rose:
Hi Parag,

Is security an issue for travel agents? Aren't they inside the boundry?(using shared computer etc...)

I dont think its indicated that they are inside the same intranet etc..and it would be good to keep security into consideration for travel agents from the beginning itself as it makes the movement of the agents to other networks easier..again, when it comes to agents, I think performance would be the main driving issue in determining most of the things.
We can put in assumptions that agents *seem* to be part of the same intranet so we wouldnt use SSL or any other security mechanism for communication and that would improve our performance (no SSL overheads).
We can justify that. Because, in all the use cases, they have mentioned that all communication with customer has to be secure, they didnt mention anything about security when it comes to agents.
Its all about assumptions

Parag

[Tomi Tuomainen]

Parag,

I agree with your non-functional aspects. If you just copy that to your assumptions and emphasize some of them, you should pass I think common presentation tier for all clients sounds better architecture in general. But this doesn't fit in my WAF that well (meaning that I'm not sure how to model that). And I'm sure that Swing -> EJB tier will work in practise so I'll probably go that way. Unless there are good arguments why I definitely shouldn't?

Tomi

[Parag Doshi]

Originally posted by Tomi Tuomainen:
Parag,

I agree with your non-functional aspects. If you just copy that to your assumptions and emphasize some of them, you should pass I think common presentation tier for all clients sounds better architecture in general. But this doesn't fit in my WAF that well (meaning that I'm not sure how to model that). And I'm sure that Swing -> EJB tier will work in practise so I'll probably go that way. Unless there are good arguments why I definitely shouldn't?

Tomi

Tomi,
I think we can leverage the better performance aspect for the swing-ejb tier communication..i have to read up more on client container security to make sure that there isnt any complication involved in that process..other than that, i would choose direct comm over web tier comm (even though its the ideal solution).

parag
[ July 28, 2004: Message edited by: Parag Doshi ]