Thursday, February 6, 2014

BOD, What is it? Should I use it?

WebSphere Commerce BOD, this architecture in WCS is not as straight forward to follow at first, unlike the NVP Command framework.  As WebSphere Commerce is transitioning to SOA, there is a need to ensure decoupling of the various components and allow re-use of the WebSphere Commerce business services. The result is a change to the frameworks driving development within WCS.  This is where the BOD framework comes in.

So what is BOD?
The Open Applications Group (OAGIS) defines Business Object Documents (BODs) with nouns and verbs (the services that interact with the nouns).

From the info center:
The Business Object Document (BOD) is an open standard for a common horizontal message architecture developed by the Open Applications Group (http://www.openapplications.org).  BODs are business messages exchanged between software applications or components.
... 
The data area contains the service operation (Verb) and the business object of the operation on (Noun). The verb will indicate what operation to perform or the response of the service operation. In the case of a request, it will contain details of the operation and in the case of a response, it will contain information pertaining to the response.  The noun represents the data contained in the business object pertaining to the request or response.




Now what does that mean?  Well for WebSphere Commerce, BOD is a Business Object Document command framework.  It is a set of well-defined interfaces providing the decoupling of the presentation, business, and persistence layers.  The BOD commands process the request and response messages to invoke business logic and retrieve data.

From the info center:
  • BOD commands deal with service data objects instead of name-value pairs
  • BODs can represent a complex request, that performs multiple actions instead of just one.
  • BOD commands deal with a persistence interface called the data service layer using an object called the Business Object Mediator, and are independent of the persistence technology.
Following is a somewhat simplified view using some of the terms for this framework.



The business logic layer implementation uses the BOD commands and works with nouns.  Nouns are logical service data objects (SDOs).  These java representations of business objects define each element of data in the logical model.  The design patterns implemented here are Get, Change, and Process, which seem core to the BOD framework.

The persistence layer is responsible for the CRUD (create, read, update, and delete) activities.   Separating this layer from the business logic allows new data elements to only effect this layer.  You can add or subtract data through modified SQL and not be required to make any changes to the other layers.




When should you use it?  Well, there are advantages of using the BOD framework over the older NVP command framework.  One advantage is the decoupling of the presentation, business, and persistence layer.  For example, in a scenario where you need to add a new column to a custom table, with the NVP command framework you would need to regenerate the EJB and Access Beans, now with the DSL part of the BOD framework you would just need to update the configuration files.

Unfortunately, there is no real WCS Best Practice found to help answer the question of when you should use it.  This does complicate making architectural design decisions.  I would say that you could decide to use the BOD framework based on the following.
  1. You could decide to do a complete rewrite and convert all of your NVP command based custom code to the BOD command based framework.  This could be a large chunk of work to bite off, and it is not necessary from a technical stand point.  Although, doing this would give you a consistent programming model throughout your code.
  2. You can take a slower approach where you base the BOD command vs NVP command framework decision on your current tasks.
    • Are you customizing an existing module or feature that is custom or customized?
      • If this is the case then look at the programming model for that area.  If it is already using the BOD framework then continue developing with that framework.  
      • However, if it is the NVP Command framework then you have more questions to answer.
        • How much of a change to the existing code base will you be making?  If you are planning on making large or complex changes, then you should consider converting it to the BOD framework.  If you are planning on making minor alterations then you could stay with the NVP command framework or decide to add converting to your task and take on the BOD programming model.
    • Are you developing a new module or feature based on an existing one?
      • In this case, you should likely be utilizing the BOD programming model.  However, if the existing component model is the NVP command framework then time considerations may leave you with customizing within the NVP command framework.
    • Are you developing a new feature that does not?
      • Here you should use the new BOD programming model.
So obviously, the decision is not straight forward if you have a lot of customization within WCS.  This could lead some to say it doesn't sound worth the effort to change.  This may lead you to question whether you should care to use the BOD programming model at all.

Should I use it?  The BOD, SDO, and DSL framework is not going away in WCS.  IBM is still using this framework in their new features and enhancements to existing features.  The NVP commands and EJB's are still present in the system due to not being able to refactor the entire system at one time.  Some components (like order and member) have BOD/SDO wrappers, but the underlying implementation remained the original NVP commands.  Therefore, you can use a consistent programming model (BOD).  It is clear that over time you will see those areas rewritten to use the BOD framework.  Even the sample stores shipped with WCS are using the BOD services where available.

IBM is continuing to move WCS to service oriented architecture (SOA) so we will continue to see more development with the BOD programming model.  So in short, you should become familiar with the framework if you plan to continue developing with the WCS environment.


Resource Links:



4 comments:

  1. Thanks For Your valuable posting, it was very informative. i am working in Erp Software company In India

    ReplyDelete
  2. can u please give any example of custom BOD

    ReplyDelete
    Replies
    1. I looked around for simple example that I could send. The layout contains a number of files so providing a simple example would entail a little more time. I will try to work on putting one together.

      Delete
    2. Yup , BOD is still in use , i have written a custom sample functionality for BOD and integration of new BOD service with REST .

      http://ravirajputgroup.com/technology/ibm-websphere-commerce/bodrest-framework/create-a-new-bod-service-module-and-testing-it-with-junit

      Delete