Skip navigation.
Downloads | Product Documentation | Support

Concepts Guide

# Modeling and a Service-Oriented Architecture

This section describes the role of modeling in building a data services layer for your enterprise. The following topics are covered:

- The Role of the Model
- Modeling Data Using XML Types
- Modeling Data Services

# The Role of the Model

Although never required, modeling can help mitigate complexity of large, intricate data systems. The BEA AquaLogic Data Services Platform provides loosely-coupled modeling services through a visual, representational view of data resources. It can present a high-level view of a complex system or it can break a complex problem into smaller pieces.

Modeling helps you to organize and document data services in all or a portion of your enterprise. It enables you to bridge the gap between the complexity of the underlying physical data landscape, on the one hand, and a logical, intuitive data model exposed by data services, on the other.

Modeling is often the first step in developing a data services layer. It provides a roadmap for the development of logical data services.

The DSP Modeller (shown in Figure 4-1) is a visual modeling tool for creating, managing, and modifying data services. You can create data services and define the relationships between them directly in the modeler.

Figure 4-1 Sample Model Diagram

# Modeling Data Services

Just as it does for database design, data modeling helps to ensure the optimal design of your data services layer. Modeling helps you analyze and develop data services efficiently. Often it can help turn a complex data landscape into a sensible, business-level data model. Modeling also serves to document data services for use by others.

Physical data services can be considered the building blocks for logical data services. In the case of a relational data source, for example, importing metadata results in a data service being created for each table. This data service, in turn, can be immediately represented in one or several models.

Modeling not only represents the data services in your DSP implementation, it also captures the relationships between data services. A relationship is a logical connection between two data services, such as between a Customers data service and an Orders data service, joined by a customer ID primary key.

The directionality of a relationship can be either:

- One way, in which data service a can navigate to data service b but b does not navigate to a (or vice-versa).
- Two way, in which data service a can navigate to b and b can navigate to a.

# Modeling Data Using XML Types

DSP uses the XML Schema language to model data. XML Schema (a standard, XML-based schema definition language) gives DSP a way to define normalized data, enabling consuming applications to use the data without regard for the inherent differences of its various underlying source representations.

Each data service has a data type, called an XML type, with a data shape defined in XML Schema. The schema defines the structure of the data service; that is, its elements, attributes, and rules. For example the following code defines CUSTOMER as having a sequence containing two elements: CUSTOMERID of type integer and CUSTOMERNAME of type string:

>     <xs:element name="CUSTOMER">
>        <xs:complexType>
>           <xs:sequence>
>              <xs:element name="CUSTOMERID" type="xs:int"/>
>              <xs:element name="CUSTOMERNAME" type="xs:string" />
>              ...
>           </xs:sequence>
>        </xs:complexType>
>     </xs:schema>

An XML schema file, named with a `.xsd` extension, is automatically generated when you import the metadata of a physical data source. For logical data services, you can create the schema automatically through the XQuery Editor, or using a schema editor built into the Modeller and Design View. Schemas can also be created externally through tools such as XMLSpy. In any case, a data service cannot be valid without an associated XML schema definition.