Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

Ideas:

  • 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.

share|improve this question

migrated from stackoverflow.com Feb 2 '12 at 9:06

This question came from our site for professional and enthusiast programmers.

1  
Hi 7SpecialGems, this is a more conceptual question and is fitting for Programmers.SE and not really suited for StackOverflow. I flagged a moderator to migrate it for you. –  maple_shaft Feb 1 '12 at 11:51
    
Thanks maple_shaft –  7SpecialGems Feb 1 '12 at 23:38
    
A very good question, one that has been burning in my head for quite a while! –  Gordon Murray Dent Apr 3 '12 at 12:12

1 Answer 1

This is a good question, while offtopic for SO, I hope this gets correctly migrated to Programmers.SE eventually. Regardless, here is my answer.

You seem to have a very good understanding of where JSF pages and managed beans fit into a componentized architecture. I really have nothing to add as your assumptions are sound and are highly similar to my own in projects I am currently working on. I really don't have a need in any of the applications I am working on currently to interact with external web services for data, but if I did, then a new DAO at my Data Access layer that interacts with the web service could be easily replaced with one, or put in conjunction with a DAO that interacts with a database.

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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