SOA Web Services - Data Access ServiceService Data Objects (SDOs) have become a foundation technology for Service Oriented Architecture (SOA). Recently, BEA, IBM, Oracle, SAP, Iona, Siebel, and Sybase announced their support for an SOA-enabling framework specification named Service Component Architecture (SCA). SD O provides the primary data representation in this framework.
The Relational Database Data Access Service (RDB DAS) obviates the need for this custom development by providing a robust data access utility built around SDO. Because of its tight integration with SDO, the RDB DAS is also a perfect solution for data access in an SCA-based application. By employing the RDB DAS, applications avoid the details and complications of working directly with a relational database and also the complex transformation between relational rows/columns and Data Object types/properties. Background SDO provides the general case mechanism for moving data around an SCA-enabled application. However, the reality is that most of this data must originate in some database at one edge of the application and be stored in some database at another edge. Unfortunately, database access isn‘t currently either SDO or SCA. (An early version SDO Data Access Service specification is in progress.) This leaves the developer with a serious undertaking since there‘s a fundamental mismatch between the objects that an application works with and the tables and rows of a relational database that provide the persistent store for the object‘s state (see http://en./wiki/object-relational_impedance_mismatch). For example, let‘s consider a simple query against a relational database for customers in a certain age range and their related orders. An SDO-enabled application could most easily and naturally work with a normalized graph of Data Objects representing the query. Figure 1 illustrates this graph of connected Data Objects. This in-memory graph of data objects brings to bear all of the capabilities of SDO.
The transformation required to convert from tabular format to a graph of interconnected data objects is complicated and the reverse (transforming graph changes to a sequence of SQL inserts/updates and deletes) is even more so. Because of the difficulties inherent in the transformation between the database and the application object space, an application development project can easily spend a third of its development resources on functions related to moving object state in and out of the database. Business application developers shouldn‘t be burdened with this task and should instead be allowed to focus on business functionality. Solution
The DAS provides an intuitive interface and is designed so that simple tasks are simple to complete while more complicated tasks are just a little less simple. The application interface to the DAS is based on the familiar Command Pattern and interaction with the DAS consists of acquiring command instances and executing them (see Design Patterns by Erich Gamma, et al). The following example demonstrates the simplest possible read of data. Command read = Command.FACTORY.createCommand("select * from CUSTOMER where ID = 10021"); In this case the command is created programmatically from a Command factory and the only input necessary is the SQL SELECT statement. Executing the read command returns the root of the resulting data graph and data can be extracted from the graph using the SDO dynamic API. String lastName = root.getString("CUSTOMER[1]/LASTNAME"); Pushing changes back to the database can be equally straightforward. Continuing with this example we can modify the customer object and then direct the DAS to send the modifications to the database. This line uses the SDO dynamic API to change the last name of the retrieved customer. root.setString ("CUSTOMER[1]/LASTNAME", "Williams"); Now that we have a modified graph, we can synchronize the changes with the database by passing the data graph to an "apply changes command" and asking it to execute. ApplyChangesCommand apply = Command.FACTORY.createApplyChangesCommand(); As you may have noticed, the read and write examples each required three lines of code (except the code to get the connection object). So those of you familiar with O/R frameworks might be asking yourself a few questions. What is going on here? Where did you define all the configuration data? I didn‘t see a deployment descriptor? Where is the object-relational mapping information? Where are the static domain classes like Customer? The answers to these questions are based on two significant SDO capabilities and one design philosophy:
The reason you don‘t see a Customer interface or class used in this example is because the DAS can work with dynamic SDO data objects. This is a very powerful and often overlooked SDO capability. Many applications today use the Transfer Object(TO) pattern to move data around tiers within an application (see Core J2EE Patterns by Deepak Alur, et al). Since these TOs typically have no behavior, there‘s little justification for Java interfaces and classes to implement the TO. These artifacts just represent more code to write, maintain, and manage. One argument for TOs as Java interfaces/classes is the potentially cleaner API: Static API However, the SDO dynamic API is straightforward and can even be simpler to read than a static equivalent. For example, we can use the SDO XPath capability to access properties like this: amount = customer.getFloat("orders[17]/price"); The equivalent, with normal static Java APIs, would look something like this: amount = ((Order)customer.getOrders().get(17)).getPrice(); The dynamic API can also be useful in applications where the data model is likely to change often during development. It lets developers use the full breadth of Data Object function without having to generate a new static model (Java classes and interfaces) every time a change is made. SDO Change History The change history capability means that SDO data objects aren‘t dependent on a container or some persistence manager to track their state. In fact, since the change history is serialized along with the associated data objects, a graph of SDO data objects can flow through different tiers of a distributed application remembering all the changes that may occur along the way. Later, when it‘s time to reflect those changes back to the database, the DAS can process the change history and build the set of create/update/delete commands needed to flush the accumulated changes. The Change History tracks changes made to all data object properties including fields and relationships. Using this information, the DAS can handle the complex task of reflecting object graph changes back to the database without exposing this complexity to users. The DAS translates object property changes into database column updates and object relationship changes into database foreign key updates. Use of Convention over Configuration String lastName = root.getString("CUSTOMER[1]/LASTNAME"); Notice the path name: "CUSTOMER[1]/LASTNAME". This suggests that there is an SDO Type named CUSTOMER with a property named LASTNAME. If you remember, the command used to read this data was created like this: Command read = Command.FACTORY.createCommand("select * from CUSTOMER where ID = 10021"); The RDB DAS, by convention, creates an SDO Type for each database table represented in the query result. In addition, it creates a property for each table column represented in the query result. In the absence of any additional configuration data, the names of these Types and Properties will exactly match the names of the database Tables and Columns. So given the SELECT statement above and the knowledge that the CUSTOMER table has a column named LASTNAME, we can assume that the data graph returned will be populated with instances of Type CUSTOMER that have a property LASTNAME. This capability is made possible by using the metadata associated with the ResultSet returned from the query execution. If the application developer wants the names of Types and Properties to vary from the names of the Tables and Columns then he or she can override this convention with a bit of configuration. We‘ll get into the details of providing configuration to the DAS a little later. Another bit of convention that this example demonstrates is exploited when flushing graph changes to the database: ApplyChangesCommand apply = Command.FACTORY.createApplyChangesCommand(); In the absence of instruction (configuration) to do otherwise, the DAS will scan the change history and generate the create/update/delete (CUD) statements necessary to flush the changes to the database. Since we just changed a single property of a single data object, the change history processing produces a single statement to be executed: update CUSTOMER set LASTNAME = ‘Williams‘ where ID = 10021
There are a couple of things we‘d like to point out here. The first one has nothing to do with convention but it‘s very cool. What has been generated here is a "partial update." That is, rather than generating a complete update statement that covers every column in the table, the statement only updates columns that relate to changed data object properties (i.e., just the last name). Partial updates may not be the right way to go for some applications so CUD generation can be overridden with user-supplied CUD statements. However, partial update is a good fit for many applications and with it you can avoid a great deal of configuration or additional programming. Not only that, partial updates provide a performance boost for updates to tables with very wide rows and are also useful for avoiding database triggers. The other point we want to make has to do with the "where" clause ("where ID =") of the generated update statement. Since we mean to update the specific table row that‘s associated with the modified data object, we need to qualify the update statement with a unique row identifier. So this is where another piece of convention is used. If the DAS isn‘t provided with configuration that defines a unique identifier for the data object Type then the DAS will look for one. There‘s no magic here; if there‘s a property named ID then the DAS will assume it‘s unique and use it in the "where" clause. We‘ve provided a description of the convention currently employed by the DAS. But there‘s more on the way. We‘re currently looking to add more capability based on conventions for generated columns, optimistic concurrency control, and relationship definition. The use of convention isn‘t revolutionary or even new, but it is gaining renewed respect. This may be a reaction to the configuration-heavy frameworks we‘ve been using in recent years. Notably, Ruby on Rails, Maven, JUnit, Wiki and many other "agile" frameworks make considerable use of convention over configuration. It‘s amazing what can be done easily, and how much coding and configuration can be avoided with these tools by adhering to simple conventions. We‘ve explained how the DAS leverages the capabilities of SDO and makes use of convention to provide a progressive programming model. Now we‘ll walk through a complete example that demonstrates a few more RDB DAS capabilities. A Complete Example (CompanyWeb) The DAS Configuration can be built up programmatically or loaded via an XML file. In this example we‘ll use the XML file approach. We‘ll begin by accessing data from the Company table, defined as follows: COMPANY: We start by creating an XML file and add descriptive information for the database tables and columns. The snippet of XML below tells the DAS that the COMPANY table has a primary key column named ID that is auto-generated by the database: <Table name="COMPANY"> Notice that we do not define the NAME column. There‘s nothing special about this column so we‘ll just take the conventional behavior offered by the DAS. In the earlier examples we had the client pass a connection instance to the DAS for use during execution. An alternative is to define connection properties in the Config and have the DAS manage the connection for us. Here we choose to use a DataSource and provide the JNDI name: <ConnectionProperties dataSource="java:comp/env/jdbc/dastest"/> Finally, we‘ll define a Command that the DAS will use to access the data. The following command will retrieve all companies from the database: <Command name="all companies" SQL="select * from COMPANY" kind="Select"/> Now we can write an application to access the data and create a class called CompanyClient to handle interaction with the DAS. However, first we‘ll introduce a new DAS concept: the CommandGroup. A CommandGroup is a logical grouping of commands and associated configuration data that serves two main purposes. Applications will often define commands that require the same configuration information and a CommandGroup binds the defined commands and the provided configuration data. For example, commands in the same CommandGroup will share the same connection properties and relationship definitions. Secondly, a CommandGroup is initialized with Commands that it provides by name. Since the client retrieves commands by name and then executes them, the SQL-specific configuration can be contained in the group and isolated from the application. In theory, the same application could switch to using some other data store technology by changing the way the Config is initialized. For example, a Config could be initialized to use static SQL or even a non-relational back-end. Since our application will use commands that share configuration, we‘ll use a CommandGroup and create one CommandGroup instance in CompanyClient and initialize it with our XML file. private CommandGroup commandGroup = CommandGroup.FACTORY.createCommandGroup(getConfig("CompanyConfig.xml")); Now we‘ll create a method to return a List of Company DataObjects: public List getCompanies() { At this point, we have an application capable of returning a list of all companies in the database. Now let‘s add in another database table, Department: DEPARTMENT: The Department table is also using a primary key named "ID" that is auto-generated by the database, so its table definition will be similar to that of Company: <Table name="DEPARTMENT"> We have to define the relationship between Company and Department so that the DAS can construct a dynamic SDO model with a relationship between the two and correctly maintain those relationships in the database. The following XML snippet names the relationship, associates the keys, and specifies the cardinality: <Relationship name="departments" primaryKeyTable="COMPANY" Now we can add a command to return all companies and departments: <Command name="all companies and departments" Next we add a method to CompanyClient to access and execute this command. This method returns a list of Company data objects, but since the command employs a join with Departments, each Company will have its related Department data objects associated with it. public final List getCompaniesWithDepartments() { Next we‘ll add the ability to retrieve a single company and all its departments. The configuration file is updated with this command definition: <Command name="all departments for company" Note that we have defined a named parameter ":ID" in the SQL query. The CompanyClient uses the code below to access this command: public final List getDepartmentsForCompany(int id) { Now we‘ll add a write capability to CompanyClient. Since we‘ll let the DAS generate the CUD statements, no additions are necessary to the configuration file. public final void addDepartmentToFirstCompany() { A complete example based on this company and department scenario, including a Web application used to access the CompanyClient, is available at the Apache Tuscany incubator project. The readme is available at http://incubator./tuscany/samples/java/samples/das/companyweb/readme.htm. The complete source is here: http://svn./repos/asf/incubator/tuscany/java/samples/das/companyweb/ In the space of this article we‘ve shown some of the main capabilities of the Relational Database Data Access Service being developed at Apache‘s Tuscany incubator project. Here are other important supported capabilities:
Object-to-Relational Data Access - The RDB DAS provides a capable and flexible data access mechanism to applications integrating SDO technology. By employing the DAS, developers avoid developing a custom data access framework, a task that‘s tedious, complex, and error-prone. Integrated with SDO - The Transfer Object pattern is often used by applications to move persistent state from one part of the application architecture to another. This is especially true if the data movement requires serialization. Such an application can employ some object-to-relational technology (JDO, EJB, Entity beans, etc.) to retrieve the data from a back-end data store and then copy the data to the DTO for transfer around the application. The creation of separate TOs isn‘t necessary for an SDO-integrated application using the DAS because the SDOs themselves are easily serialized to XML. As a bonus to the TO pattern, the SDOs "remember" changes made to them and this memory is preserved through serialization/de-serialization. Conclusion Because the RDB DAS integrates SDO technology, it‘s a natural fit for data access in the SCA framework. In fact, an RDB DAS implementation is evolving as part of the "Tuscany" SOA Apache incubator project along with implementations of SCA and SDO. The DAS is also on the roadmap for the upcoming SDO 3.0 specification. The examples and code included in this article can be had from the Apache Software Foundation and licensed according to the terms of the 2.0 Apache License. More information about the RDB DAS and the implementation under development can be found at http://incubator./projects/tuscany.
© 2007 SYS-CON Media Inc. |
|
|
来自： shaobin0604@1... > 《SDO》
Although not addressed by the current SDO or SCA specifications, there‘s a definite need for a generic data access service that operates in terms of SDOs. The alternative to this service would be the tedious and error-prone development of a custom mapping between the back-end data representation and Service Data Objects.
