Page 2 of 2   « previous page

Challenge 2: Enrich, Cleanse, Aggregate Data
In modern applications, data usually does not come just from one place and get presented directly to consumers. It often needs to be formatted (e.g., a date), aggregated or enriched, or cleaned.

For example, a big part of an employee record might come from the HR system but the employee's vacation time is stored in some other place requiring a merge of those two sources into one.

There are several ways aggregation or enrichment can be implemented. At the most basic level, it can be done natively in the application no matter what the technology. However, if the underlying data model changes (or just a column name changes), several places need to be updated, which can be time-consuming. This leads to the use of object-relational mapping solutions because the domain model is easily shared and the mapping can be changed just in one place. On the more sophisticated side the data service implementation could access multiple data sources using native results to compose the common domain model. (Table 3)

When multiple data sources return a variety of XML documents that comprise the common domain model then XML aggregation is the answer. Due to the evolution of orchestration and XML as a common data format, BPEL is the perfect tool for aggregating or enriching data that is already in XML and later serving it to consumers. Although for large payloads and results, using an Enterprise Service Bus might be a better choice.

Challenge 3: Distribute Data
When all components and layers reside within one application, access is native and in memory. In a SOA, however, services run in a decentralized manner and in different places, introducing the challenge of different protocols and even greater need for solid error handling. What happens if a service is down or not accessible - how will the application be affected? The use of BPEL offers a great way of composing these services into one process or composite service, which can be leveraged later. Using this approach brings more freedom to the service's consumers but also introduces another layer that needs to be maintained.

One purpose of this is data pulled into several UI technologies, such as a portal or BAM to monitor performance.

For example, a supervisor wants to see the performance of employees in real-time and wants to be able to take corrective actions (such as rerouting a request to other teams). In this case, the data from the business process (and its services) can be pulled out into a BAM instance to create a real-time dashboard.

Note: The technology mapping of this section has already been covered in the Access table.

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). (Table 4)

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.

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 following model, 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). (Figure 1)

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, 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. The architecture is laid out as follows:

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. (Figure 2)

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, 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

Page 2 of 2   « previous page