• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

design approach - application specific business objects

 
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Roger I fully agree with you!
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic