my dog learned polymorphism*
The moose likes Web Component Certification (SCWCD/OCPJWCD) and the fly likes Business Delegate pattern problem - code example Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Web Component Certification (SCWCD/OCPJWCD)
Bookmark "Business Delegate pattern problem - code example" Watch "Business Delegate pattern problem - code example" New topic
Author

Business Delegate pattern problem - code example

Piotr Nowicki
Ranch Hand

Joined: Jul 13, 2010
Posts: 610

Howdy Ranchers!

I'm trying to gather all the information about design patterns related with the SCWCD - and I have a first problem with the Business Delegate pattern. I would like to understand it on the real-life example, on source code - not only on diagrams and in theory.

Let's begin with plain example of:
- a model interface (IGame),
- a model implementation (Game),
- a controller which executes the model methods (GameController).




Now I don't want to use the JNDI straightly in my controller class and want to be independent from the IGame implementation.
So, that is what I understand the Business Delegate pattern is for...

Thanks to the above business delegate, the controller class got simplified:



And if the whole part to this point is true, than it would be sweet and clear for me. But I'm afraid it isn't. Or I just can't see how it could be.
I mean - I am using an IGame interface, which should be the only thing the web tier should know about the business tier, right? I'm interested in the functionality of the business layer, not about how it is implemented.

Because the IGame interface is purely a business one, it doesn't throw any network-related exceptions. But if it doesn't do that, than the implementation of this interface (Game class) cannot have a signature like that:

That's because the java.rmi.RemoteException is a new checked exception, and therefore the Game class is not implementing the IGame interface properly.

So, there is what I think I can do to fix this problem:

1. I could add a throws RemoteException to the IGame interface.
That just doesn't seem like a good idea to me. What if I would like to use plain SOCKETS for networking, or use some other solution? Then I should prepare the business interface for every possible checked exceptions which might occur in the future (RMI, SOCKETS, CORBA, ...).
Hey, I might not even use the networking, so I most definitely wouldn't like to add try/catch for never-really-thrown-exceptions.

2. I could use this in GameController:

but this breaks the 'programming to interface' rule. I also think that the IGame interface should be used, as this shows exactly what is my business interface.
And the last thing: if I will use the GameDelegate type directly, than this class doesn't have to implement the IGame interface at all.

2.b The similar problem occurs if I would like to throw checked ApplicationExceptions from the GameDelegate class. For example I would like to wrap the low-level RemoteException in the more user-level checked ApplicationException. I can't do that because of the implementation restrictions, so I have to use a runtime exception. Well, I think it isn't a big problem, as the runtime exceptions should be used when user cannot recover from such situation, and I think that network related problem is such a unrecoverable situation, right?

Maybe there should be one business interface (plain, just as the IGame is at the beginning of this post), and some other one (extending the IGame) which will add the networking nature to it? But then again, in my controller class should I change the interface when the implementation will change? There's no point it doing that, isn't it?

How this problem should be solved? Maybe I did overlook some important points or missed the point of the pattern?

Thanks in advance for your time - either spent on reading or answering :-)

Cheers!


OCP Java SE 6 Programmer, OCM Java SE 6 Developer, OCE Java EE 6 JSPSD, OCE Java EE 6 EJBD, OCE Java EE 6 JPAD, Spring 3.0 Core Professional.
Frits Walraven
Creator of Enthuware JWS+ V6
Bartender

Joined: Apr 07, 2010
Posts: 1645
    
  25

Hi Pedro,

It took me a while to digest your question, but let me try to give a few answers.

First of all: you are mixing up the BusinessDelegate and the Business Object(BO). The BusinessDelegate doesn't implement the BusinessObject Interface: it has an interface to the BO, which it has to look up (mostly done by a ServiceLocator). The BusinessDelegate only returns a TransferObject to the Controller. The BO has a getData() method that wraps the data into a TO.
Furthermore, the BusinessDelegate catches the RemoteException(s) and wraps them up in an ApplicationException.

Let me try to adjust your example code:

The controller looks like:

The Delegate like:

and your BO

and your ServiceLocator:

Regards,
Frits
Piotr Nowicki
Ranch Hand

Joined: Jul 13, 2010
Posts: 610

Thanks a lot Frits for your time and answers!

You cleared a lot of things, but still I would like to ask you a few more...
Thank you for pointing out the difference between the real Business Object and DTO - I slightly haven't understood the relationship between those -- until now.

According to this source (http://www.ibm.com/developerworks/java/library/j-ejb1022.html) - the man uses the Delegate class to implement the Business Interface (listing 3.). But I guess your approach and example is closer to the JEE description (http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html).

Ok, so this approach (with Delegate class not implementing the business interface) allows you to declare throwing new checked exceptions (ApplicationException) and this is great.
So, the DTO should always be created by the BO as a response for the Delegate call and then, forwarded from the Delegate to the client, right?
This makes sense, (BO preparing the DTO), as the Business Delegate <-> Business Object calls are the first ones made through the network.

In your example, in the BO, there are:
- getPlayerNames() method, and
- getData(), which packs the getPlayerNames() result into the DTO.

Does it mean that I have to write such DTO-packaging method like getData() for every business method that returns something different than a void and I would like to send it through the network?

I understand, that this is the typo in the BO listing you posted and it should be "return wrapReturnInTO(getPlayerNames());", right?

And the last thing... In the posted code, the Game Business Object is still throwing a RemoteException (which are checked ones - just like the RMI ones). You cannot throw these if the IGame interface doesn't declare them. So, the question is still valid:
- Should the IGame business interface declare these remote exceptions (and every other possible, as there might be a number of other networked-related exceptions),
- Should there be a different interface (something like a remote interface) which extends the IGame and adds this networking nature (like Exceptions)?
Frits Walraven
Creator of Enthuware JWS+ V6
Bartender

Joined: Apr 07, 2010
Posts: 1645
    
  25

So, the DTO should always be created by the BO as a response for the Delegate call and then, forwarded from the Delegate to the client, right?

Yes, that is correct.
Does it mean that I have to write such DTO-packaging method like getData() for every business method that returns something different than a void and I would like to send it through the network?

Yes, but don't forget that your business method could actually gather data from mutliple data interactions.

Just as an example:

I understand, that this is the typo in the BO listing you posted and it should be "return wrapReturnInTO(getPlayerNames());", right?

Yes, again right
Should the IGame business interface declare these remote exceptions (and every other possible, as there might be a number of other networked-related exceptions)

It is the business layer that has a relation with remoting, and you should wrap the Exceptions up in something more presentation like in the presentation layer (like an ApplicationException). But you are making a good point the methods that are returning a TO should handle the remote exceptions, so:

This way the GameDelegate only deals with ApplicationExceptions.....

This looks better doesn't it?

Regards,
Frits
Piotr Nowicki
Ranch Hand

Joined: Jul 13, 2010
Posts: 610

1.
Frits Walraven wrote:
Does it mean that I have to write such DTO-packaging method like getData() for every business method that returns something different than a void and I would like to send it through the network?

Yes, but don't forget that your business method could actually gather data from mutliple data interactions.


So, this is known as a Composite Entity which uses the Transfer Object Assembler pattern, right? (http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObjectAssembler.html) Didn't know about it before.

------------------------------------------------------
2. The code of the IGame interface definitely looks a way better for me, thanks! :-)

But one question more: does the Business Object always have to return TransferObject if it's public? I mean, what if I would like to call a Business Object method from another Business Object - on the same server, on the same JVM.
In this way, I will also use a TO even for calls within the same JVM. It this the appropriate way?
Is it allowed to make some Business Objects methods public, when they doesn't return a Transfer Object, like getPlayerAddresses() in the below code:



Or is it a bad design to introduce this approach, and every BO public method should return either nothing or a TransferObject?
Piotr Nowicki
Ranch Hand

Joined: Jul 13, 2010
Posts: 610

And few following questions if I may (don't hit me Frits! :-)...

1. So, the business delegate doesn't work as a proxy for the Business Object, doesn't it? The Proxy imitates the real object, therefore it implements the common business interface (IGame in my example). If it doesn't implement it, so I guess you can introduce new methods to the GameDelgate class? For example, for simplifying the usage for servlet controller. Let's say:



So, is the GameDelegate allowed to do such things, or it should be mapping 1:1 the Business Object public functions?
So if I have a "addPlayer(PlayerDTO)" method in Game BO, than in my BusinessDelegate it should be also "addPlayer(PlayerDTO)"?
Are such changes allowed, or should be rather done in some different class (i.e. the SessionFacade - http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html) which, as I understand, goes between the Business Object and Business Object Delegate, like:

ServletController->BusinessDelegate->SessionFacade->BusinessObject
or
ServletController->BusinessDelegate->SessionFacade->ServiceLocator->BusinessObject (if you want to use the ServiceLocator).

Am I right with this, or messed up something once again?

-----------------------

2. So the BO is sending the DTO, so I understand that:
IGame - business interface
Game - Business Object
PlayerDTO, GameDetailsDTO, WeaponDTO, etc. - are my DTO's related with the Game BO?

So, the Business Object can serve multiple different DTO's for the client, like:



Is this correct? So, the Business Object doesn't come with only one DTO, a BO can encompass many DTO's.

If so, than does the BO have any properties / fields within? I mean should it looks like:



So, a Business Object can have a different Business Object as its field? But should it have a fields like "gameTitle", "playersNum", etc (which are already a part of the GameDTO)? Or should it rather looks like this:



Or maybe the BO shouldn't have any DTO's or any other fields related with the data, and instead it should only update / fetch the data when the Game BO client (i.e. the BusinessDelegate) requests so?

Thanks once again for your time and kind answers!
Frits Walraven
Creator of Enthuware JWS+ V6
Bartender

Joined: Apr 07, 2010
Posts: 1645
    
  25

whow, where should I start

So, this is known as a Composite Entity which uses the Transfer Object Assembler pattern, right?

Yes
Is it allowed to make some Business Objects methods public, when they doesn't return a Transfer Object, like getPlayerAddresses() in the below code:
..... left out code ....
Or is it a bad design to introduce this approach, and every BO public method should return either nothing or a TransferObject?

Everything is allowed of course ( ), but the thing here is to separate the presentation layer (DTO, or ValueObject) from the business layer (BO). If your Business Layer implementation changes it doesn't have to affect your presentation layer.
So, the business delegate doesn't work as a proxy for the Business Object, doesn't it?

No it can actually work with different Business Objects, therefore delegating the business request to the object that know about the business. The Delegate knows about who does what and where the specific object is, like:

So, is the GameDelegate allowed to do such things, or it should be mapping 1:1 the Business Object public functions?
So if I have a "addPlayer(PlayerDTO)" method in Game BO, than in my BusinessDelegate it should be also "addPlayer(PlayerDTO)"?

There is no need for a 1:1 mapping, your addPlayer() method in the Delegate doesn't have to create a playerDTO: the String is in this case sufficient.

A SessionFacade is needed when for instance your service (playing a game) is more or less a business process. For instance: you would only allow customers to play the game (IGame) if they have paid for it (IPayTheGame). The SessionFacade will then coordinate calling the different BO's in the right order.

So the BO is sending the DTO, so I understand that:
IGame - business interface
Game - Business Object
PlayerDTO, GameDetailsDTO, WeaponDTO, etc. - are my DTO's related with the Game BO?

Yes, correct.
Is this correct? So, the Business Object doesn't come with only one DTO, a BO can encompass many DTO's.

Yes again!
If so, than does the BO have any properties / fields within? I mean should it looks like:
public class Game implements IGame {
private Integer playersNum;
private String gameTitle;
private DifficultyLevelEnum difficultyLevel;
private List<Player> players; // Assume that Player is a different BO
...
// Public and / or private methods here
}

Yes, that is very well possible
So, a Business Object can have a different Business Object as its field?

Yes it could, it depends on your model. A Player and an Address are different objects and probably also in different tables in the database, but they have a relation (i.e. the foreign key of Address is in the Player tabel)
So, a Business Object can have a different Business Object as its field? But should it have a fields like "gameTitle", "playersNum", etc (which are already a part of the GameDTO)?

Yes, the DTO is only for the outside world, the properties describe the BO.

I hope I have given enough answers
Regards,
Frits
Piotr Nowicki
Ranch Hand

Joined: Jul 13, 2010
Posts: 610

Thanks a lot once again Frits :-)

One last thing (really!):

Frits Walraven wrote:Yes, the DTO is only for the outside world, the properties describe the BO.


So, the properties are in the BO. The DTO is sent to the controller (web/presentation layer), and what about the other side - the database layer? I mean, you can use i.e. Hibernate, or any other O/R Mapper which allows you to define entities which will be stored into the physical database.
So, I need to have a BO with properties:



then I have a DTOs which I send to the presentation layer, like this:




And I've got separate classes for DB entities like:



and so on for every Entity in the application?
Or maybe the DTO could act as an database entity (which will combine the *Entity classes and *DTO classes)?
Or perhaps they shouldn't be the same, as this introduces the low cohesion of these classes?

But then again, if they are separate, there is a feeling of duplicated code creation (one property added to the Player object needs to be added in several other places like DB entity property, DTO object property, ...).
So, the properties describing an object are held in:
- business object, for whole application processing purposes,
- DTO objects, for presentation layer,
- entities, for database storage.

Aren't this approach also possible to bring a desynchronization of object state problem, like this:

- [Developer] I've added the playerHeight property.
- [Chief] Maybe, but after your app is destroyed, there is no sign of this property!
- [Developer] Oh, I did forget to add it to the DB entity so it's not stored properly.... Ok it should be fine now.
- [Chief] Well... It is stored, but the end-user can't see this property.
- [Developer] What? Why you can't see it? Oh, wait, I forgot to add it to the DTO object... wait a sec...
(...)
- [Chief] Ok, It's fine now.

Or perhaps, this work is needed and it's a natural trade-off the loose coupling of such design?

Cheers, and I promise there will be no more questions :-)
I think this thread has a great impact on my Web layer <-> Business layer perceiveness.

Thank you Frits!
Frits Walraven
Creator of Enthuware JWS+ V6
Bartender

Joined: Apr 07, 2010
Posts: 1645
    
  25

Hi Pedro!

and so on for every Entity in the application? there is a feeling of duplicated code creation (one property added to the Player object needs to be added in several other places like DB entity property, DTO object property, ...).

I agree and even Sun says the following:
Data Access Object:
Consequences
Adds Extra Layer
The DAOs create an additional layer of objects between the data client and the data source that need to be designed and implemented to leverage the benefits of this pattern. But the benefit realized by choosing this approach pays off for the additional effort.

and also David Bridgewater in his book:
A Transfer Object is likely to duplicate code (getters and setters will shadow those of the EJB)

When designing a web-application you always have to think ahead.
Yes, it is possible to refer from my jsp directly to an EJB property or even a DAO property. You will even create a web-application sooner (happy project manager) but what if my business layer or data layer implementation is going to change (for instance: change of company contracts). I will create a lot of work, probably far more (bye bye project manager....) then that bit of extra work of copying properties to create different objects in subsequent layers in your application from the start!

(As a last note: by the way the layers have their own responsibility, so the properties and methods for the presentation layer won't be copied onto objects in the business layer....)

Thanks Pedro,
I enjoyed the discussion!!!
hope other people too

Regards,
Frits
Piotr Nowicki
Ranch Hand

Joined: Jul 13, 2010
Posts: 610

Thank you Frits!

Thank to people like you I really, really like being here. It is a normal discussion which definitely expand your skills.

There are (in the Internet) plenty of people with knowledge but acting like: "look how smart I am!".
Here, on Javaranch, you can meet people with great knowledge but acting more like "look how easy it is!".

Much obliged, and I also hope that this discussion will help someone just as it helped me :-)

Cheers!
Simran Dass
Ranch Hand

Joined: Jan 09, 2010
Posts: 183


Great discussion

Here are we assuming that there is a class called TransferObject.
Frits Walraven
Creator of Enthuware JWS+ V6
Bartender

Joined: Apr 07, 2010
Posts: 1645
    
  25

Hi Simran!

Here are we assuming that there is a class called TransferObject.

Yes, we were refering to the 6 J2EE patterns that you have to know for the certification. The TransferObject pattern is one of them. In our sort of Game implementation we were calling them DTO (data transfer objects). The business layer is handing over the TransferObject to the presentation layer to hide the (difficult) details of the implementation of the BusinessObjects.

The other advantage of the TO is the possiblity to combine the potential expensive netwerk calls. For instance: in your client code (presentation layer) you would combine getting the Player details and the Address details in one go (i.e. one TransferObject) whereas the business layer has to do two roundtrips to the data layer.

Regards,
Frits
Harikrishna Gorrepati
Ranch Hand

Joined: Sep 23, 2010
Posts: 422
Hi Pedro, Can you please post complete working code..Thanks


OCPJP 6.0-81% | Preparing for OCWCD
http://www.certpal.com/blogs/cert-articles | http://sites.google.com/site/mostlyjava/scwcd |
Piotr Nowicki
Ranch Hand

Joined: Jul 13, 2010
Posts: 610

Howdy Harikrischna!

Well, I've thought about this - to gather all the advice given in this topic - and I'll do this and post the results here.

The code is purely exemplary, so that's why I can't just paste the result here, as I don't have it yet :-) I hope I will be able to post it soon :-)

Cheers!
Filipe Pinheiro
Greenhorn

Joined: Oct 08, 2009
Posts: 9
Thank you all guys for a design patterns' online class room.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Business Delegate pattern problem - code example
 
Similar Threads
struts2 MVC pattern - business logic question
Non-Networked Mode
Design questions (with RMI)
RMI server interfaces
MVC