This week's giveaway is in the EJB and other Java EE Technologies forum.
We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes design approach - application specific business objects Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "design approach - application specific business objects" Watch "design approach - application specific business objects" New topic
Author

design approach - application specific business objects

manish ahuja
Ranch Hand

Joined: Oct 23, 2003
Posts: 312
Hi there,

Currently I am working on a straight forward j2ee application which has use cases like search customer, add/edit/delete customer & show customer details. There are lot of ancillary objects to the customer.

Now the only difference here than typical 3 tier approach is we have to communicate to a web service (developed by a different vendor)and we do not directly interact with the database.
So what we have done is used xml beans/client gen combination to generate java classes out of the wsdl.
We have the CRUD screens in jsp which communicates to the struts controller. So our forms will represent all the CRUD screen attributes.
From the struts controller layer we have another intermediary service layer. This service layer talks to web services.
Now my question here, is it a good idea to create wrapper classes representing each of the clientgen/xml beans generated java classes representing web services or shall we directly instantiate the web services related java classes at the controller layer(via some helper) & pass it on to the service layer which communicates to the web service.

Say if we go ahead with the idea of creating application specific business objects & then transform them to their web services counterparts we will have to build a mapper utility whose sole responsibility is to convert our application specific objects to their web service counterparts & vice versa.


Do post your comments on the same.


Regards
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I'd probably introduce one more conceptual layer for Data Access. I've worked on large integration projects where the data comes and goes from many places but always through a common data access interface. So try to keep your services from knowing about web calls to remote partners or databases or the like.

To your real question, I've wound up passing the very same objects from controller to service, from service to data access and the very same return objects from data access to service and from service to controller. For the first data source. Then for the second data source we had to transform the request and response for the second remote partner look like those from the first one. Some times a painful job.

All this implies a pretty "anemic" object model ... lots of data structure beans flying around and not much "rich" behavior in objects. That works pretty well for simple CRUD where the service layer doesn't do much except sequence a few inserts and queries.

If the service layer does some serious work, say computing payroll wages and taxes, it's likely to have very different inputs and outputs than the data access layer. It might even work with objects that take responsibility for validation and formatting and such, no longer just dumb beans.

Does that give you some ideas or raise some new questions?
[ July 08, 2007: Message edited by: Stan James ]

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
Let me ask this question: If your app would be accessing a DB, would you have a 3-tier architecture with a data storage layer which might have a DAO which hides the data source (the DB) from the client?

If yes, then how does a web service change this 3-layer architecture? I think it does not. After all, a client should know nothing about the data source, including how it is accessed. The web service can be viewed as just an implementation detail today, next year it might be replaced by calls to your own DB or file system.


SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Roger I fully agree with you!


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:
All this implies a pretty "anemic" object model ... lots of data structure beans flying around and not much "rich" behavior in objects.


How does it imply that? I've had very good success with doing that using true domain objects - instantiated by hybernate and used by both the domain and the presentation layer.
manish ahuja
Ranch Hand

Joined: Oct 23, 2003
Posts: 312
I get your point about a Data access layer.
With regards to creating wrapper business objects (application specific objects)
approach v/s using the domain objects (say Hibernate generated or in my case the
java classes representing the web services) what are the arguments in favour of and
against before adopting any approach.


Regards
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by manish ahuja:
With regards to creating wrapper business objects (application specific objects)
approach v/s using the domain objects (say Hibernate generated or in my case the
java classes representing the web services) what are the arguments in favour of and
against before adopting any approach.


I get the feeling that you misunderstood me. The domain classes that get instantiated by hibernate in my example are fully fledged business objects, containing business logic. Those business objects consist of abstract base classes that get generated from an xml description of the properties, and concrete superclasses - those that get instantiated and used throughout all layers - which add custom coded business logic.
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
I am not wholly sure what you mean by "wrapper business objects". To me, a business object contains business data and does business logic processing on that data. When you need to invoke the web service, you would build the request from your business object. When the web service returns its response, you would convert that into whatever object you need.

Is this what you are thinking of doing?
manish ahuja
Ranch Hand

Joined: Oct 23, 2003
Posts: 312
Ok Roger. Rather than saying wrapper business objects I should have said just wrapper objects.
As I said earlier all the business logic & data operations are handled on the web service side.

When you say
--------------------------------------------------------------
When you need to invoke the web service, you would build the request from your business object.

When the web service returns its response, you would convert that into whatever object you need.
--------------------------------------------------------------
My question is about going ahead with idea of creating these wrapper classes. What if I straightaway interact with the webservice specific java classes because I dont see the wrapper (app specific)objects add any value.

To give an illustration the web service generated class provides use 2 classes CustomerRequest & CustomerResponse
objects. We have to initialize the request objects before communicating with the webservice.

So should i be creating a wrapper object model to transmit & fetch data from the web service generated class.
The webservice classes are flat i.e. they don't belong to a inheritance model.
In a CRUD only no business logic app is it a good idea to build a totally new hierarchial model just to create a set of wrapper classes on top of the webservice representation java classes.



Regards
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
Suppose the web service provider were to make a change to the request or response class, or suppose you were to move from the web service to another provider. In either case, you may have to change some client code. I don't like clients being exposed to implementation details, which is why I like these details being hidden behind a DAO. The DAO also provides a single, consistent interface for the client.

All of this may seem overkill for what may be a simple CRUD application, and perhaps it is! However, I do like "proper" designs, even for small apps.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Ilja said: I've had very good success with doing that using true domain objects - instantiated by hybernate and used by both the domain and the presentation layer.


Neat. I've never (or not for a long time) gotten anything but dumb beans from the data access layer. Most recently those objects were generated from models and we were prohibited (by convention) from adding code to them because it would be lost on the next gen. I wonder if that isn't a typical side effect when building web service code from WSDL, too.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:

Most recently those objects were generated from models and we were prohibited (by convention) from adding code to them because it would be lost on the next gen. I wonder if that isn't a typical side effect when building web service code from WSDL, too.


The general solution is to derive subclasses from the generated ones. Not sure how you would convince a webservice framework to use those.
 
jQuery in Action, 2nd edition
 
subject: design approach - application specific business objects
 
Similar Threads
java xml bindings & transfer objects
In MVC, who stores the business logic
Hibernate Transactions
business delegate and service locator
Tutorial - J2EE for Beginners