Persistent Objects for Service Oriented Architectures

Contents PRO-SOA™ Technical Brief Rationale The Challenges The Result Extensibility and Flexibility Compatibility and Interoperability Matrix The Next Step: Six Choices, Not Mutually Exclusive TriCoron PRO-SOA allows you to easily publish your relational data as a transactional web service. Without having to write any code to create, deploy and run the persistent object web service.

PRO-SOA™ Technical Brief

Write precisely zero lines of code to create and deploy your persistent object web service using PRO-SOA.

Rationale

There are many reasons why you would want to access relational databases as a web service. To name but a few:

• Relational data can be accessed and updated by any language that can understand WSDL and can communicate using SOAP.
• The actual database access mechanism and update intricacies are hidden from the developers. The result is a very short learning curve and a single control and maintenance point for the database experts.
• Intercommunication between different hardware and vendor platforms is totally transparent. Your web service can run on any server platform (Linux, Windows, Solaris, IBM Mainframe). The client platform can be Windows, a web app that communications to a web browser, or a networked application.
• >Using XML-based Web Services to access relational data is becoming very popular. Over a third of companies in a recent survey are either building or using web services for relational database access.[1]

The Challenges

In short: the amount of time, labor and material to write the code to translate SOAP requests into operations that can access and update the relational databases is considerable, especially if your databases have more than a few dozen tables and inter-table relationships, or you are combining multiple databases into a single, logical web service. Edit rules have to be written to ensure the inbound data is congruent to a strict set of edit rules to make sure the data that is persisted is clean and accurate. You have to make sure the web service will not interfere with current and future applications that are accessing and updating the underlying, shared relational databases.

It is also very advantageous from a design standpoint to present an industry standard and familiar interface over SOAP to the consumers of the persistent object web service. Given the intricacies of each database vendor implementation, varying SQL dialects, dozens of column data types, the technical challenges are not inconsiderable if the objective is a solution that is both flexible and efficient.

Over time, the persistent object web service must also be able to adroitly accommodate structural database changes without breaking existing web service clients. The server-resident web service code should also be vendor independent: you should be able to migrate from Oracle to SQL Server or SQL Server to Oracle without any changes at all to your web service clients. Your web service should run on any platform, be it Windows, Linux, Solaris, HP-UX or zSeries. Databases from different vendors should be able to be combined to form one logical web service, the differences between the vendor implementation details must be transparent to, and abstracted away from, the web service client or service consumer.

You must also make sure that all character sets used in user interfaces can be persisted in the relational databases and can be transmitted cleanly over SOAP. Binary data types (BLOBs, IMAGEs, VARBINARY, etc.) also need to be accommodated and configurable dynamically from the web service client., depending, for example, on available bandwidth and response time service level agreements.

The bottom line: Building coherent web service from relational databases is a labor intensive process and requires a considerable amount of up-front research and prototyping to get right.

Enter PRO-SOA: A prebuilt and operational expert system to create, typically in less than a day, a transactional web service from any number of databases.

The Result

PRO-SOA can distill any number of databases into a common set of operations, as set forth by Sun's well known and generally accepted Enterprise Blueprints[2]. In Visual Studio .NET, for example, you will see these web service operations published through PRO-SOA:

This web service view of your relational data is a DYNAMIC INTERFACE. Meaning: >

• The web service view of your relational databases stays the same, even when the database content and structure changes
  
• The Web Service is independent the vendor of the database. Microsoft and Oracle databases, to the application software, appear and operate the same. [3]
  
• This Web Service view of relational data Is also independent of the physical relational schemas and table organization.
  

Extensibility and Flexibility

In most persistent object interfaces, if the underlying database changes, the programming interface seen by consumers of objects built from the database changes. Clever design of the persistent object interface can avoid hard wiring the application logic to physical database characteristics. PRO-SOA takes this concept one step further by presenting normalized metadata and column values to the web service client. As a result, the above screen shot from Visual Studio .NET is seen for all possible relational database schemas. This is a significant technical accomplishment as this simple, dynamic interface cuts the learning curve for database access and update to almost zero.

Further assume you determine that you need additional service operations to be included in your web service. How easy is it to extend PRO-SOA and add domain-specific web service operations? Three steps from concept to deployment:

1. Determine the class name for the enhanced web service object and subclass the default, generated PersistentObjectService class noted above in the Visual Studio .NET screen shot.
2. Recompile, package and redeploy the extended web service using the generated XML scripts.
3. Alter the web service deployment descriptor XML to reference the new derived classname (a one-liner) and rerun the generated deploy-web-service.cmd/sh script.

Your favorite web service-aware development tools will now see the new SOAP operations. It is that easy.

Compatibility and Interoperability Matrix

PRO-SOA has been certified with the following technologies. Choices are not mutually exclusive. For example, you can use PRO-SOA to create a transactional web service that access any number of Oracle and SQL Server databases concurrently.

The Next Step: Six Choices, Not Mutually Exclusive

We offer you several no cost, time efficient options to explore the extensive capabilities of PRO-SOA first hand.

1. Run a pre-built C# SOAP client. Intercommunicate to TriCoron's servers to access and update the familiar Oracle DEMO schema or Microsoft SQL Server Northwind database over SOAP using the Internet.
2. You can also get, at no charge, a Visual Studio .NET C# project workspace and build this C# SOAP client yourself with one stroke of the F5 key.
3. In addition, deploy and run a pre-built persistent object web service on one of your servers. We have pre-built deployments for the Oracle DEMO schema, along with SQL Server Northwind (both in one deployment, actually). We can also send you the source code and documentation as well, just ask.
4. For the motivated technical expert, generate, build, deploy and run a persistent object web service from scratch. Perform a first-hand source code and architecture review of PRO-SOA.
5. PRO-SOA Community Edition allows you to generate a web service using your databases. Examine all of the generated source code through your favorite IDE and see how PRO-SOA works. You won't need to write any code to get your persistent object web service running.
6. Discuss other options and capabilities of PRO-SOA with a TriCoron Technical Business Consultant.

If you have any questions, would like to learn more, or would just like to give some feedback, please contact service@tricoron.com or call TriCoron Service at 1-866-SOATODAY.

[1] BZ Research LLC survey of 943 companies, as reported in SD Times, 1 July 2004, Page 12
[2] Sun's Enterprise Blueprints are online at http://java.sun.com/blueprints/enterprise/
[3] A relevant exception are web service operations that permit you to run direct SQL DDL, DML and ad hoc queries through the persistent object web service. Direct SQL is generally infrequently used in the web service clients (if at all). Direct SQL execution is typically reserved for very complex queries where object-based queries through an object-based SOAP interface proves cumbersome. The SQL passed to a database is, and always will be, vendor dependent. However, the object-oriented load(), store(), create(), remove() and other PRO-SOA web service operations are vendor independent and dynamic, by design. Run the example C# client on your desktop and see first-hand.

Copyright © TriCoron 2004 All Rights Reserved Worldwide