I am designing a component based system using JSF2 on top of Spring's IoC Container.

It is to employ a service layer between a controller and the domain/business layer (I anticipate the controller is nothing more than the JSF Servlet binding in the web.xml file).

The rationale for the service layer (which conforms to an interface for each service) is to allow for the services to be changeable.

It has occurred to me that the return types of the objects from the service layer objects are likely to be business objects from the business layer, which would then be used in the backing beans for the JSF view to populate the UI components on the pages.


  • Is it acceptable as a standard practice for these business layers,
    say a Customer() object coming back from a FindCustomerService, to
    just be passed back to a Presentation Layer backing bean? Can the Presentation Layer know about the Business Objects or are these not a part of the Service/defined for use in the Service Interface and therefore part of the contract for a Service implementation?

  • Alternatively, should I be thinking about representing components on
    the UI using a generic set of UI classes within the backing beans, which are then mapped to the return types coming back from the Service Layer in another layer between the
    Controller and the Service Layer? (This would likely require re-engineering if a Service was changed?)

  • Perhaps it is a standard practice to return using standard language scalars and object return times from the service layer to avoid the need for a translation layer?

First SOA project. Figured this would make a nice question for archive and links to appropriate patterns would be greatly appreciated.

  • A very good question, one that has been burning in my head for quite a while! Commented Apr 3, 2012 at 12:12

1 Answer 1


Your assumptions are sound and are highly similar to my own in projects I am currently working on.

Here is roughly how I perceive the componentized architecture:

 JSF Page (.jsf, .xhtml, etc..) View

 Managed Bean - Controller, Presentation Logic

 Business Logic Layer

 Data Access Layer (Database DAO's, Web Service DAO's)

 Database, Web Service, File store persistence, etc...

To provide some insight into some of your points:

You are assuming that the web services in question are going to be returning Java objects? Perhaps they are ordinary Java data objects serialized as XML, perhaps they are not. If they are truly external from a third party then you cannot make that kind of assumption. Ideally in your example however that the web service returns a Customer object, you should define and control the Customer class in your project. If not and you simply pass this object through to the Presentation layer, then your application is exposed to the risk that the external web service may change this object in the future and this would be a point of failure at all layers.

I wouldn't pass a Java object like that where I do not control the source. In this case a Translation operation should occur on the data being returned from the web service in the Data Access Layer, that will make assumptions about the data being returned from the web service, and translate that data into Java beans that you control and are part of your project. In this way from the Business Logic layer on up, assuming that your Customer class remains the same, then these layers will be unaffected by a change in the external web service. The only affected layer will be the Translation layer. This is typically the way things are done with web services in SOA.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.