December 11, 2006

Core and Render Services

While implementing software systems you have two different major issues.
  • Implementing Core Functions: Can be considered as commit transactions( Insert records, transfer files to legacy systems, batch imports) . These methods are atomic and can change the entire data for the whole system.
  • Rendering data as Human Readable Form. All Forms, lists, Reports can be considered in this case. There is no data change in background system but only export of this system.
When you distinguish these two system you can separate the implementation of these functionality. CoreService,RenderService.

  • CoreService: have transactional service methods. Each method is a atomic unit and as a whole the services capture whole system functions.So they are reusable
  • RenderService: Can be implemented depending on the domain. Either Web Technologies, reporting or desktop applications. Each domain have its own constraints so unlike CoreService these methods are hardly reusable.
Here is sample Dependency Diagram.

Sample Flow would be like:
  1. User request page with a GET method
  2. Render Service render the html and form.
  3. User fills the forms and POST the data
  4. Core method reads the data from request and commit the transaction
  5. Redirect the request to and URL
  6. Another GET and render Case

With this pattern you support and increase the separation of concern and increase the abstraction layer.

For java web applications, it would be best to use a action oriented framework like Struts suits well for the pattern