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!
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 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.
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!
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
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!
Good one ..
ReplyDelete