Concepts Guide
|
 |
 |
|
 |
 |
This chapter provides an overview of BEA Liquid Data for WebLogic®. It covers the following topics:
Information resources are often the most important assets an enterprise holds. Information can make or break an enterprise's ability to execute on its essential functions—from day-to-day operations to the marketing and delivery of products or services to strategic planning. The enterprise must be able to access, interpret, and use information as efficiently as possible.
Unfortunately, as enterprises evolve, their data resources tend to become increasingly fragmented. Corporate acquisitions and mergers, new technologies, and changing business strategies can all contribute to a state of data segregation, in which pockets of information become isolated by physical and technical boundaries. The information comes to reside in a variety of places, in databases and files, within applications, or even outside the organization, supplied by business partners, vendors, and clients as Web services. Figure 1-1 illustrates this fragmentation of data.
Figure 1-1 Direct Data Access Applications
As a consequence, the information becomes effectively lost—inaccessible to developers and, in turn, the customers, employees, and decision makers who need it. Developers who do attempt to use the information need to know a daunting variety of data access mechanisms and APIs. The applications are difficult to create and maintain. Their source code tends to be dominated by data management logic, making them intolerant to changes in the data layer.
When changes do occur, the applications must be revised and retested, because their business logic is embedded with data access code. In the worst case, an application must be significantly modified and redeployed as a result of the changes to the data source layer.
When it comes to developing applications, the costs of information fragmentation are quantifiable and significant. By many estimates, up to 70% of the time required to develop an enterprise application goes into data programming.
Other costs may be more difficult to gauge but are certainly as significant—from hampered decision making and poor responsiveness to lost information resources.
Liquid Data for WebLogic is the WebLogic Platform component for developing and deploying integrated data services. Data services give consumers an easy-to-use, uniform model for accessing heterogeneous, distributed data.
Liquid Data significantly simplifies the task of creating and deploying reusable data services. It has tools and frameworks for rapidly generating data services based on existing data sources and for creating logical data services based on those sources.
From the perspective of the data consumer, Liquid Data presents a sensible, uniform data model for getting and using information. The application simply instantiates a data service and retrieves or updates its data by calling one of the data service's public functions. The data may come from legacy applications, relational databases, Web services, delimited files, XML files, or any source from which a Java application can extract useful data. These data services can be viewed as a layer integrated between the data consumer and the data sources as illustrated in Figure 1-2.
Most data in an organization exists as queryable data or application data. Liquid Data lets you use all data together to compose a logical data model for the organization. The data model represents the business entities relevant to the organization, such as customers, orders, or products.
Figure 1-2 Data Integration Layer Between Data Users and Data Sources
Liquid Data is a virtual data layer in the sense that, except for caching, data is not kept in any Liquid Data or WebLogic component. Instead, data services dynamically retrieve data from the physical data sources. Dynamic access ensures that applications have access to current (that is, real time) information.
A data service represents a unit of information in the data model. Like a Web service, it exposes a public interface in the form of one or more accessor functions. A data service accessor function typically returns data in the form of the data service's datatype. It uses XML and XQuery to acquire, transform, and aggregate data from external sources.
The data is poured into the XML data shape defined as the return type for the data service. Because an individual data service represents a relatively small unit of information, response time from the client's perspective is minimized. Other features, such as caching and query optimization, help to ensure the optimal performance of the data services layer.
Liquid Data insulates data consumers from the complexity of disparate data sources. It encapsulates the details of data integration logic and gives consumers a sensible, coherent model for accessing and updating data. Data access and business or presentation logic are effectively decoupled, resulting in applications that are easier to develop and maintain, without data access plumbing code.
As it does for reading data, Liquid Data gives client applications a unified interface for updating data. Liquid Data allows client applications to modify and update data from heterogeneous, distributed sources as if it were a single entity. The complexity of propagating changes to diverse data sources is handled by Liquid Data.
From the data service implementor's point of view, the task of building a library of update-capable data services is considerably eased by the Liquid Data update framework. For relational sources, Liquid Data can propagate changes to the data source automatically. For other sources or to customize relational updates, you can use the Liquid Data update framework artifacts and APIs to quickly implement customized, update-capable services. Either way, data consumers are isolated from the details of updating the data sources.
A Service-Oriented Architecture is an architectural style for an IT environment. In this architecture, business processes are delivered as a set of loosely bound services. Web services provide an implementation of SOA. A web service is a modular, self-describing component that can be used in a platform-independent way.
Traditionally, applications are built as monolithic units. They impose platform dependencies on users and are not easily adaptable to new types of interactions. Web services break these applications into multiple reusable components that can interact with other independent components and services in meaningful ways. For example, instead of having a single financial application, an organization may deploy one or more services that expose the business activities of the application as self-contained, callable processes. That way other systems (such as Human Resource services or applications) can easily leverage financial computing resources. Thus, SOA breaks down barriers between applications. With SOA the IT infrastructure operates in an integrated, organic fashion like a virtual application that spans the organization.
Viewed as a whole, a data service deployment constitutes a data abstraction layer between data users and sources. It normalizes diverse data and exposes a uniform, well-defined interface that data consumers can use to access data. Client developers do not have to know how to connect to a data source, what its native format is, or even where it comes from, whether from one or many underlying sources. The application can simply call a public function of a data service.
SOA is considered a loosely coupled—not completely decoupled—architecture because, while the service provider has no knowledge of the interfaces or business concerns of its consumers, the consumers do include explicit references to the service provider interface, in the form of service calls.
The benefits of loose coupling include simplified data access, reusability, and adaptability. The effect of changes to the data source are localized, requiring only relatively few changes in the data services layer rather than in every application that uses the data source. New services can be exposed and used without requiring extensive changes to existing applications. The result is a data integration layer that is highly adaptive and change tolerant.
Liquid Data extends SOA to the realm of data. With Liquid Data, you can expose information as data services. A data services represents a self contained business entity—such as a customer, product, or order—that is reusable across the organization.
Simply put, Liquid Data disentangles the data provider from the applications that use the data.
Other benefits of Liquid Data include:
Liquid Data enables you to capture and deploy a data model specific for the needs of your organization. A data model typically organizes data in a way that represents business entities. Similarly, in your implementation, you can define the data model that makes sense for your organization. Business entities common to most organizations include, for example, products, orders and customers. A Customer object can have all of the attributes that are relevant to a customer in the deployed environment, such as contact information, shipping preferences, payment information, and so on. The data model can also specify security, caching, and other policies.
Instead of having to contend with multiple sources to acquire the information relevant to a customer, developers can simply use a Customer object from a data service. The policies relevant to the data are applied to the data consistently, without requiring developers to implement them in the various applications they develop.
To help you get from a complex, distributed physical data landscape into a sensible data model, Liquid Data supports a visual, model-driven approach to developing data services. Modeling provides a graphical representation of the data resources in your environment, providing a bird's eye view of a large system, or giving you a way to break a larger problem into smaller pieces.
The result is real-time access to externally persisted data through a logical data model (as illustrated in Figure 1-3) while providing a single point for applying policies, such as security and caching, on information used across applications and services.
In SOA, services are conventionally thought of in terms of processes. However, most SOA initiatives actually start with data. By its nature, data has broader, more generalized usage than typically does a business process. Data consumers can use the same piece of data in different ways. Once you have developed the data model for your enterprise data, the data types, as encapsulated by data services, can be reused by numerous data consuming applications.
The data model represented by a Liquid Data deployment is captured by metadata. In Liquid Data, metadata serves several purposes:
The metadata browser, a component of the Liquid Data administration console, provides an easy-to interface for searching and browsing through metadata.
A data service encapsulates the logic for normalizing, transforming, and integrating disparate data. A client uses a data service by calling one of its public functions. A data service can have any number of public functions, each of which returns data in the form of the data shape described by the XML Schema associated with the data service.
The logic encapsulated in a data service is in the form of queries written in the XML Query (XQuery) language. XQuery, based on an emerging standard specification, is a SQL-like language specifically intended for working with structured, XML data. As a declarative language, XQuery lends itself to compiler-based optimization techniques, alleviating data service developers from having to learn extensive rules and techniques for writing optimized XQuery functions.
Those familiar with SQL should find XQuery easy to learn. They have many features in common. Liquid Data provides an XQuery editor that allows you to get started with XQuery by using an easy-to-use, intuitive graphical tool.
Once the Liquid Data application has been deployed to a WebLogic Server, clients can use it to access real-time data. Liquid Data supports a number of different types of data clients with these mechanisms:
Liquid Data supports a service-oriented approach to data access through Java interfaces (the mediator API and the Liquid Data Workshop control) or through Web services that act as wrappers for the data services.
As an additional option, the Liquid Data JDBC driver gives SQL clients (such as reporting and database tools) and JDBC applications a traditional, database-oriented view of the data layer. To users of the JDBC driver, the set of data served by Liquid Data appears as a single virtual database. Note that, given the two-dimensional view of data inherent in SQL, SQL access is supported only for data services that provide a flat view of data.
The following are the basic steps for developing, deploying, and maintaining a Liquid Data implementation:
Liquid Data facilitates a team-based approach to application development. Instead of developers having to understand how to connect to and use numerous data sources—along with the business or presentation logic that needs to be implemented once the data is acquired—development tasks can be divided in ways that naturally correspond to the roles that often exist in an organization:
|
|
|
