This blog talks about a technology that acts as a data provider service – Service Data Object – Which provides a framework as well as an API
This blog talks about SDO’s in SOA context. For a complete info on SDO, you may just google!
Service Data Object(SDO) is a technology that allows data from heterogenous systems/technologies to be accessed in a uniform way.
SDO’s lets the underlying data layer to be accessed in a technology-agnostic manner
SDO is a J2EE data programming model which takes care of dealing with various technologies associated with the underlying data layer, and provides the developer to focus more on the business logic
SDO’s abstracts data in a Service Oriented Architecture(SOA)
With SDO, you do not need to be familiar with a technology-specific API in order to access and utilize data.
You need to know only one API, the SDO API, which lets you work with data from multiple data source which includes relational databases, entity EJB components, XML, Web services, JCA, JSP, etc.
Normally, most of the data is manipulated by using XPath functions. But you can even specify BPEL data operations to be performed by an underlying data provider through use of entity variable
The data provider service performs the data operations in a data store behind the scenes and without use of other datastore related features provided by SOA Suite like the database adapter
This feature enhances performance and incorporates native features of the underlying data provider service during compilation and runtime
SDO or Service Data Objects is designed to simplify and unify the way in which applications handle data.
Oracle made it very easy with its Application Development Framework – Business Components(ADF BC) layer to make sdo webservices. You only have to edit the application module, Go the service definitions link and enable support for service definitions. Select the viewobjects and the operations you want to use. Deploy this to the Application Server and we have SDO WebService.
Working with a data provider service can overcome the following problems
1. Extensive data conversion
IF the underlying data cannot be represented as XML, then the data have to be converted to XML format before working with SOA components. This feature affects the performance as if the data is too huge, it would take time during this conversion
2. Variables in BPEL are disconnected, in the sense that it contains a snapshot of the data. So, not always a data represents the current data, but stale data.
In prev releases, any access to the datastore is done using the database adapter. And this data is stored to the dehydration store when the instance is dehydrated, thus duplicating the data. And if there was any change in the database meanwhile, we do not have the latest one, rather the one stored in the dehydration store which is now stale. And, data is in DOM form.
This is overcome in the current release where when we use the Entity Variable to fetch the data, while dehydration, the data is not stored but rather the key(done by using the bindEntity activity) to it is persisted(like a pointer). So, when this data is required after rehydration, current data is fetched using that key
This way of doing things aviods duplication as well as always you are made sure of having the latest data. Data in EV is in SDO form, which provides for a simpler conversion compared to DOM, especially when the data provider service understands SDO forms. Basically in this case, data is maintained outside the BPEL process(in this case, in an Oracle ADF BC component). Just a reference key is maintained in the BPEL process to deal with the data.
Only BPEL service components can understand SDO forms in the current release. If you wire a SDO provider service to a mediator, the data form defaults to DOM.
Hope this gave you a basic understanding of SDO. The next step is to know about EnityVariables in Oracle SOA Suite 11g, after which we would be working with SDO’s in BPEL
Thanks for going through my post, feel free to provide a feedback!