Challenges of Data and Service Integration

Data Access technologies are highly complex because they must provide several mapping options for flexibility and performance. They rely on relatively consistent database engines to publish convenient APIs to manipulate data at the appropriate levels (transactions, tables, views, rows, columns, cells) and imply business data consistency and concurrency. Improperly managing this, e.g. with transactions, caches, etc. could quickly result in severe performance bottlenecks or data corruption.

The other complexity of Data Access is that it requires significant development effort with a mix of different skills among development team members (object design and development, database and transaction programming).

But accessing Services (not only Web Services) is even more complex than accessing Data. Services do not rely on convenient APIs and are defined and constrained by business or technical logic. Services do not provide direct data handling; they are procedural and sequential by nature.

Data Access can be seen as a transformation from one data structure to another, while Service Access involves transformation from a data structure to a sequence or chain of command invocations at application runtime.

Data and Service integration differences

Valuable business data, particularly in high-volume transactional environments, is unavailable for reuse in traditional integration scenarios and is even more difficult to access by applications being deployed with Service-Oriented Architectures. This approach to building and deploying applications is driving the need for a new way to access and integrate heterogeneous resources to compose new applications .

The first generation of orchestration tools typically rely on workflows or specific languages like BPEL (Business Process Execution Language) or visual connections of services (where services are visually assembled using a graphical editor). The early technology approaches like workflow and BPEL to access services (newly developed Web services or existing legacy or mainframe services) are not suitable for working with fine-grained services. BPEL and workflow are convenient for coarse-grained Enterprise Services because they facilitate the development and deployment of large business processes (BPM). Conversely, they are not at all suited for mission-critical, highly transactional business applications that create and manipulate large amount of data.

• ++ Learn more on Xcalia's innovative Patented technology enabling unified Data Access
• ++ Discover Xcalia's product line to build, assemble, deploy and manage composite applications on the Java and Microsoft .Net development platforms
• ++ Understand Xcalia's vision and technology leveraging the SDO standard
• Ask Xcalia how they can help deliver today the foundation of SOA in your enterprise through universal Data Access.
•