Business Object Document : Websphere Commerce Web Services

The WebSphere Commerce BOD command framework architecture uses well defined interfaces to decouple the implementation of the presentation layer, business logic layer and persistence layer. From the business logic layer perspective, OAGIS messages are used as the interface for making requests to retrieve business data or invoke business logic. The BOD command framework provides the capability to process these BOD requests and responses.

Found this really nice pictorial description of the various assets and processes involved in the BOD development in the  IBM Red Book (sg247619)

 

More to come to BOD Command Framework... 

On reader's requests -

See Also:

Debugging BOD 

 

Service Oriented Integration (SOI) - Websphere Commerce Web Services

As part of the WebSphere Commerce transition to SOA, there is an effort to decouple components to allow re-use of WebSphere Commerce business services in other environments besides the WebSphere Commerce application. In order to support this decoupling, the core infrastructure is the first piece that needs to run independently so it can be leveraged in other environments as well. The request handling has changed to create a lightweight runtime environment that new and existing components can use. This lightweight runtime focuses on the processing of business object documents (BODs). This new architecture paves the road to SOA adoption by standardizing on how clients will talk with SOA components.

WebSphere Commerce now provides 4 SOI service modules -- logical groupings of business objects that have been grouped to standardize communication. These service modules are:

• Member
• Order
• Catalog
• Contract

The SOI modules ultimately maps to the ControllerCommand. And you would often extend the OOB commands for your custom logic - use EJBs for persistance much as the way as you did in WCS 6.0
( I can see a lot of v6 developers expressing a huge sigh of relief ). Most of the time what the developers struggle is how to map a service to a command name. I have put together a small diagram showing the complete flow - Taking a very common scenario - extending the Registration process to store custom membership attributes.

I hope you find it easy to understand and helpful!

 

The sad part is that we may not be able to really see the "actionCode" being used in the method ( registerPerson in this example ) since we do not have the access to the source code ( I narrowed down the command by my past experience in v6 ) - but what IBM is done is help the developer community at large is provide the methodName to CommandName mappings directly in the following link:

http://pic.dhe.ibm.com/infocenter/wchelp/v6r0m0/index.jsp?topic=%2Fcom.ibm.commerce.component-services.doc%2Fconcepts%2Fcwvcs.htm

The following is a mapping for the MemberFacadeClient methods and the corresponding URL commands:

• Map registerPerson(Map) - UserRegistrationAdd
• Map updatePerson(Map) - UserRegistrationUpdate
• Map addAddressForPerson(Map) - AddressAdd
• Map updateAddressForPerson(Map) - AddressUpdate
• Map deleteAddressForPerson(Map) - AddressDelete
• Map registerOrganization(Map) - OrgEntityAdd
• Map updateOrganization(Map) - OrgEntityUpdate
• Map addAddressForOrganization(Map) - AddressAdd
• Map updateAddressForOrganization(Map) - AddressUpdate
• Map deleteAddressForOrganization(Map) - AddressDelete

If you really want to appreciate the actionCode concept , refer the below method used in the SOITutorialStoreFacadeClient.java 

( Find the details of the above in the Infocenter TutorialStore )

So, though you may not need to follow the entire web of configurations but I feel this is worth knowing.

Happy learning!