Procedure Oriented or Object Oriented approach in session bean?

[S Venkatesh]

Hi All,

I have a stateless session bean. Through a business delegate i look up the session bean and call a method on it to which i pass a model object (value object). Now i use this model object in the method in session bean and do some operations.

Now my doubt is, is it a procedural approach? since the data and the method that operating on that data is no bound in the same class. I am really confused with this .

Thanks
Venkatesh S

[Mark Spritzler]

Huh? Yes, you want that Bean to be a really thin facade. Just a way to provide a public interface to the outside world, and declare you transactions/security that EJBs give you.

You then just pass that Model Object to a Plain Old Java Object to do your work.

Mark

[S Venkatesh]

Thanks Mark Spritzler. Your suggestion seems great!

I got some more suggestions from friends which is "introduce a layer which converts the model objects into XML. This XML is placed in the bean and it is further used for all operations".

Thanks
Venkatesh S

[Mark Spritzler]

Also look at some of the technologies that makes converting XML to Java Objects and the other way easier. It all depends on whether you already have both defined already or not.

But JAXB can take an XML schema and generate Java classes for you, and the other way around.

And there is also the XMLEncoder and XMLDecoder classes introduced into Java 1.4 that are basically the serialization version. So you are serializing your Java Object into XML, and if that XML matches what you will be sending it is even easier than JAXB.

GOod Luck.

Mark

[S Venkatesh]

Thanks Mark Spritzler

I am planning to do the same. Thanks for your valuble suggestions.

Regards
Venkatesh S

[Thomas Taeger]

Dear Venkatesh,

let me come back to your original question:

... a model object (value object) ...

pretends an equity of those terms. But probabely you mean the client side using a "model", and you speak of a "value object" or more modern of a "data transfer object" (DTO) at the boundary between client and server.

A client side "model" should not implement _business_ logic, but it normally has noteworthy MVC logic like despatching a trigger to N presentations - see all the methods on the Swing models like ListModel, TableModel, TreeModel ... All this logic is useless at the server side. What the server needs is just a DTO, maybe with getters, but without any business methods or MVC methods. So you better say you "use that DTO", not that model object, "in the method in session bean ...".

Now we approach your original question. If you say:

Now i use this [...] object in the method in session bean and do some operations.

then it depends heavily on the signature and semantic of that EJB method how object oriented it is:

Case 1: Delegating via RMI
If the model object (not "DTO" nor "VO" please) has the business logic and criteria data to decide which one of the business methods like orderIfAvailable( this) or orderAsSoonAsAvailable( this) to call then it can delegate the appropriate call to the server/EJB via RMI. That would be real oo design.
But: How could the client know about the availability of goods before having called the server? Typically several calls would be necessary, and this must be avoided for keeping the number of server round trips small, because the latter heavily slow down the server (an improtant good practice that in my oppinion corrupts the prominence of RMI a little bit).
Also this would mix server-side business logic and some client-side business logic what is not considered a good practice.

Case 2: Generic Method
If there is a server-side generic receive( DTO) method that takes a command ID from that object to decide what to do with the data then this is no longer what the fathers of OO ment by OO. In my oppinion this is true even if any oo technique like RMI was used to technically pass over the object and trigger the server.

Case 3: Specialized Methods
If there are several specialized server-side business methods like orderIfAvailable( DTO) and orderAsSoonAsAvailable( DTO), and the client calls one of them, then in my opinion this is very poor oo because the caller logic, not the object itself decides.

Case 4: What-to-do Selector
If there is just one order( DTO) method carrying the _selector_ for the decision with it then still the server has to provide the appropriate business logic - poor oo.

Case 5: Command Object
You pass in one of several Command Objects (each extending the DTO) like an OrderIfAvailable or OrderAsSoonAsAvailable object.
If caller and server _would_ be within the same JVM then the command object (without need of RMI) could directly call public methods for fetching the availability, deciding and calling the appropriate business method itself, but this not the fact.
Because caller and EJB reside in different JVMs, you must use a kind of "behaviour injection" (resulting in dependency injection):
- The client has passed its command object having an action method taking a provider parameter (interface!).
- The EJB, when calling the action method of the Coammand Object, passes in a provider object implementing the provider interface parameter.
Thereby you have a good semantical interface and a pretty good decoupling (no implementation dependency).
But again the business implementation is neighter in the client's model nor the DTO's responsibility - "poor" oo again.

(In all these cases XML / JAXB may be applied, but that is just one strategy and can not answer the OO question itself.)


The most important goal of oo design is separation of concerns. But separation of concerns can be found on different levels:
- Object orientation
- - provides separation of concerns within one object (data and its business methods) and
- - tends to be bound to a single JVM.
- Service orientation:
- - spans several [J]VMs
- - is not typically object oriented at the boundary between [J]VMs
- - but its implementation may optionally be object oriented within each JVM.

I would answer your question

"... is it a procedural approach?"

with "yes, it is a procedural approach".

You just need to get over to the server because the overall model, i.e. the original data _and_ the business logic, is to be in the server. In words of MVC you can imagine the server being the big model for the client, and the client (maybe having its local MVC ...) being the view and controller for the server-side model.

I think the most important point is that OO is not a relevant criterion at the boundary between subsystems.

Thomas Taeger
[ March 19, 2006: Message edited by: Thomas Taeger ]

[S Venkatesh]

Thomas Taeger,

I do agree with your opinion but i have concerns reguarding it.

"I think the most important point is that OO is not a relevant criterion at the boundary between subsystems."

Do you mean to say that eventhough its not OO at the boundary between subsystems design is fine ?

[Thomas Taeger]

Originally posted by Venkatesh Sai:

Do you mean to say that eventhough its not OO at the boundary between subsystems design is fine?

Yes, surely!

Enjoy it!
Thomas

[S Venkatesh]

Originally posted by Thomas Taeger:


Yes, surely!

Enjoy it!
Thomas

Do you know about any of the designs that avoid this also? May be you have some kind of a mapping layer that can avoid this?

[Thomas Taeger]

Originally posted by Venkatesh Sai:

Do you know about any of the designs that avoid this also?

No idea for OO purism here. And no need.

[S Venkatesh]

Originally posted by Thomas Taeger:


No idea for OO purism here. And no need.

Thats true. Thanks for the reply Thomas Taeger

[Pradeep bhatt]

Originally posted by Venkatesh Sai:
Thanks Mark Spritzler. Your suggestion seems great!

I got some more suggestions from friends which is "introduce a layer which converts the model objects into XML. This XML is placed in the bean and it is further used for all operations".

Thanks
Venkatesh S

Why do you need a XML here?

[S Venkatesh]

Originally posted by Pradip Bhat:


Why do you need a XML here?

The model object is converted to an XML and placed in a private variable inside the session bean. This is done by a mapping layer. Now the methods in the session bean do not take any parameters instead it derives it from the XML. This is to preserve encapsulation.

[Roger Chung-Wee]

I find it hard to think of a good reason why an EJB should do any XML processing. Why are objects not being passed into and returned from the session bean?

[Pradeep bhatt]

Originally posted by Roger Chung-Wee:
I find it hard to think of a good reason why an EJB should do any XML processing. Why are objects not being passed into and returned from the session bean?

I agree with you.

Sai,


Does this layer sit b/w the client and the session bean ? The layer converts the value (DTO)object to XML representation and pass it on to session bean.

[S Venkatesh]

Roger Chung-Wee for your answer please refer my first post.

Yes we have a layer which sits between the delegate and session bean. The client calls the session bean through this delegate. This layer converts the model into XML and places the XML into session bean. In session bean this XML has a private access. We again parse the XML and retrive the info that is contained in the model object.

This is to ensure that we do not isolate the model object data from the methods that are present in the session bean.

[Thomas Taeger]

Originally posted by Roger Chung-Wee:
I find it hard to think of a good reason why an EJB should do any XML processing. Why are objects not being passed into and returned from the session bean?

I totally agree too.

The XMLomania has swapped over all universities worldwide and lets people (or youngsters only?) only think in XML anymore, on the expense of slowing systems down and adding a unnecessary framework and one more errorprawn indirection. What for? If one really needs an additional say WebService he can provide it later as a wrapper and leave the smart EJB methods untouched. The use of XML must be justified by a business reason or a technical lack in say RMI like in OSGi.

Thomas

[S Venkatesh]

Originally posted by Thomas Taeger:

I totally agree too.

The XMLomania has swapped over all universities worldwide and lets people (or youngsters only?) only think in XML anymore, on the expense of slowing systems down and adding a unnecessary framework and one more errorprawn indirection. What for? If one really needs an additional say WebService he can provide it later as a wrapper and leave the smart EJB methods untouched. The use of XML must be justified by a business reason or a technical lack in say RMI like in OSGi.

Thomas

I too agree with you. After some long debates we have knocked off this layer now

[Pradeep bhatt]

Originally posted by Venkatesh Sai:



I too agree with you. After some long debates we have knocked off this layer now

Well done.

[S Venkatesh]

Thanks a lot for your suggestions and replies.

[steve mcdonald]

if adding XML "HOT" technologies to your resume has importance, then add that layer. Other-wise there is no need to make things complicated.

"Good design is always Simple and there are Simple solutions to complex problems"

The world is crazy, we add layers into s/w and every one keeps talking/blog about its benefits, how it might change the world, and no sooner we start removing them to keep it simple.

[Thomas Taeger]

Originally posted by steve mcdonald:
if adding XML "HOT" technologies to your resume has importance, then add that layer.

... very well said!

What an economic harm!

Thomas

[S Venkatesh]

Originally posted by steve mcdonald:
if adding XML "HOT" technologies to your resume has importance, then add that layer. Other-wise there is no need to make things complicated.

"Good design is always Simple and there are Simple solutions to complex problems"

The world is crazy, we add layers into s/w and every one keeps talking/blog about its benefits, how it might change the world, and no sooner we start removing them to keep it simple.