Challenge 4: Persisting Data
A data access solution must provide proper transactional support allowing the application to apply changes to the data stores through the exposed operations and the supplied changes to the domain model, ensuring that the proper transactional semantics are obeyed, based on the data store's requirements and implementing any necessary concurrency protection (locking).

Especially with SOA, more than one application will use a certain service at the same time, so transaction protection needs to be considered. One possibility is that each operation can be reverted. Another option is to sacrifice loose coupling to allow clients to use transactional behavior. (Table 4)

Evolving a Multi tier Application into a Reusable Set of Services
The goal for the next generation of applications is to morph them smoothly into a SOA - and not force them to be completely rewritten. If a clean separation of layers was introduced earlier, this may sound harder than it actually is. Let's review two possible morphing approaches:

1. Traditional application (architectural model)
Following all the design patterns, a clean separation of concerns is desirable - especially moving forward to a SOA. In the model shown in Figure 1, the application (representing the business logic) talks to the persistence via a defined set of interfaces and transports its data through Plain Old Java Objects (POJOs).

2. Morphing into a hybrid model
Expose just the needed artifacts and functions into service interfaces (a k a service enablement). These can be further used in BPEL to orchestrate complex business processes. The application, on the other hand, still uses the native, in-memory approach and is not affected at all. The model stays the same (see Figure 2), and just certain pieces are exposed (the same interfaces!).

Integrating Data Through Services: A Use Case
Having discussed the pros and cons of various access technologies, such as JDBC, J2CA, Web Services, and Enterprise JavaBeans (EJB) as well as the challenges of accessing data, it's time to apply the information gained to a use case.

A large company runs its inventory system as a mainframe application that is maintained and updated through daily batch jobs. Due to the rising demand of a new front-end system, the company decided to develop a custom Java EE application, with a Java Server Faces front-end, capable of serving multiple clients but holding the mission-critical information in the back-end. Between those two systems, new items should be exchanged and enriched with external data from a supplier. The service for retrieving this information is offered through a secured Web Service (see Figure 3).

Connecting these applications - all using different technologies - serves as a perfect example to illustrate choosing the right data access, aggregation, and persistence approach to build a best-of-breed solution.

Applying the technologies discussed about, J2CA connectors, which provide native access to the underlying technology, can be used for the mainframe. Most of these adapters also provide a WSDL interface to the outside world, describing their exposed services. Each time a new item is triggered, the adapter fires an event.

The Java EE application consists of a data access layer built on top of EJB 3.0 to ensure flexibility in the mapping between domain objects and the actual database schema. These EJBs can either be exposed as real Web Services or offer just a WSDL interface but require native access.

In this case, an ESB can be used to provide the running infrastructure for orchestrating an overall flexible process. It not only contains rules for routing and aggregation but also offers error handling and ensures a high degree of data access and persistence performance by using native protocols.

Outlined Process Flow (ESB System Diagram)
As this example shows (see Figure 4), an ESB can support the loosely coupled principles of a SOA but also address common data access challenges.

Conclusion
A data service is a means of decoupling and encapsulating the access to one or more data stores. This concept offers an approach to sharing common functionality across multiple client applications or services. Its physical separation allows much greater flexibility in implementation and future independent evolution while guaranteeing that the consumer and the data service negotiate on a contract.

The benefits of this approach include the ability to transparently aggregate data and even completely change data stores without requiring changes to its consumers. Additionally, it allows for a data service that may have once been used only in a fixed set of applications to be used within a business process as a more dynamic service orchestrated with declarative processes.

Each technology that has been discussed has pros and cons (starting with performance and ending with transactionality). We believe that it is important to keep those in mind and that the more data-rich the application is (the more mass data it has) the more a native approach is appropriate. On the other hand, the more loose coupling is targeted, the more the approach should lean toward a Web Service-based architecture. In this sense, using BPEL seems like a great way to enable data sources into services and allow performance and, to some extent, transactionality.

The key to a successful transformation is a solid understanding of the purpose of the data service, including the pros and cons of each technology used. The use of proven data access frameworks makes exposing data as services simple while not sacrificing performance. Good performance is essential in multi-layered applications, because it is crucial to the user experience. The best SOA is worth nothing if the users are sick of using the consuming applications due to their poor performance.

Although having shared data services appears to be an obvious solution for shared access to the same enterprise data stores, it does not come without costs. As in all design and architectural abstractions, the benefits must be carefully weighed against the costs and challenges. A vision of the enterprise's SOA strategy must also be taken into consideration when deciding when and where to use data services. This article has attempted to alleviate the difficulty in addressing the challenges of making these decisions in a SOA by describing and assessing the characteristics of data accessibility.

Reference
http://webservices.sys-con.com/read/233667.htm