There’s a perception that Service-Oriented Architecture (SOA) is

composed of Web services following a set of standards such as SOAP, Web Services Description Language (WSDL), and Universal Description, Discovery, and Integration (UDDI). While this is an approach to SOA, it certainly isn’t the only way of implementing an SOA. Part of the problem is that there isn’t an agreed upon definition of SOA. Searching Wikipedia.org for “service-oriented architecture” yields this: “There is no widely agreed upon definition of service-oriented architecture other than its literal translation that it is an archi-tecture that relies on service-orientation as its fundamental design principle.

Service-orientation describes an archi-tecture that uses loosely coupled services to support the requirements of business processes and users.” In spite of the vague definition of SOA, there are three important charac-teristics:

• Services are modular, granular com-ponents with the emphasis on creating a larger number of smaller services rather than a few large services. This is highly subjective, but like most things in this business, there’s a balance between generating too many or too few components to avoid having either performance suffer or making reuse of services difficult.

• There’s some mechanism (catalog) to allow consumers to find services. This is the crux of the “loosely coupled” concept. In the “old days,” components were compiled or link-edited during development. This forced static rela-tionships between components. In an ideal SOA implementation, compo-nents would never need to know the location of services until they needed them and then wouldn’t care where the service was located.

• Service users don’t need to know the actual location of the service. It may not be possible to allow any service consumer to call any service provider anywhere; the performance consider-ations and logistical difficulty of man-

5 2 • z / J o u r n a l • J u n e / J u l y 2 0 0 7

DB2: Centerpiece of a Service-oriented

architectureBy Ralph W. Crosby

2007

IDUG Europe

5-8 NovemberConference

9 NovemberOne-Day Educational Seminars

Hilton Athens

Athens, Greece

®

Europe’s premier, user-run educationalforum for DB2 professionals

Register at w3.idug.org/2007Europeby 21 September and save!

IDUG Takes You Further• Gain training on DB2 releases and platforms for all

experience levels

• Discover solutions and enhancements for your IT systems

• Understand the latest developments in IBM database technologies

• Network with your industry peers and leading vendorrepresentatives

• Benefit from optional, in-depth One-Day Seminars on Friday, 9 November

• Advance your career with free DB2 Certification Exams

IDUG Headquarters401 N. Michigan Ave. • Chicago, IL 60611-4267 USA • Phone: +1.312.644.6610 • Fax: +1.312.673.6688 • E-mail: idug@idug.org • Web: www.idug.org

The International DB2 Users Group (IDUG) is an independent, not-for-profit, user-run organisation whose mission is to support and strengthen the information services community byproviding the highest quality education and services designed to promote the effective utilisation of the DB2 family of products. The DB2 Product Family includes DB2 for z/OS; DB2 forLinux, UNIX, Windows; DB2 for iSeries; DB2 for VSE and VM; WebSphere Information Integrator; and DB2 Everyplace.

The IDUG conference boosted my confidence in makingdecisions and gave me tools to support those decisions tomy supervisors.”

“

IDUG_1190507_EUad 6/1/07 4:44 PM Page 1

aging this environment are daunting.

So, while it’s certainly possible to implement SOA using Web services, that’s only one of several possibilities that include:

• Using message queuing systems (e.g., WebSphere MQ)

• Accessing legacy CICS and IMS trans-actions

• Taking advantage of robust DBMS capabilities, including those available in the DB2 product line (the focus of this article).

Goals Technologies come and go; the suc-cessful ones have been those that pro-vide cost-effective solutions to real problems without a requirement for completely changing the world. So, with SOA, what problems are we solving and at what cost (time and money)? From a problem perspective, there are two key areas:

• Speed of development, maintenance, and evolution of applications

• Optimization of resources across the IT infrastructure to meet service requirements.

SOA improves the speed of develop-ment by allowing for a higher degree of reuse. This is a goal IT has been chasing since the early days of object-oriented programming. By pushing the coupling between components to run-time, SOA facilitates a looser binding, making reuse more viable. SOA allows for better balancing between IT infrastructure components by eliminating some (or all) dependen-cy on the location of services. It becomes possible to move services around with-out having to change the applications using the services. So there are real problems SOA can address. The challenge of course is the cost of solving those problems. A key cost is infrastructure. In the case of a Web services SOA implementation, a number of the required components may not exist in the environment and, even if they do, they’re probably not configured for SOA use. On the other hand, chances are DB2 is available in the environment and is, of necessity, configured to allow for at least stored procedure access (and probably more). If you could use DB2 as the core of the SOA implementation, chances are you’d be able to leverage existing, well-

understood technology and infrastruc-ture. How could DB2 act as the core of an SOA implementation? You can map DB2 capabilities into the major areas of your SOA definition.

DB2 and Modular Components DB2 lets you build modular compo-nents in several ways. Besides stored procedures, there are capabilities direct-ly exposed by SQL that fit nicely in an SOA world. But let’s start with stored procedures. Database users have been packaging services as stored procedures since the facility became available almost 10 years ago. Stored procedures have several advantages from an SOA perspective:

• A stored procedure can be as granular as required. It could be a simple func-tion or an extremely complex set of operations.

• Stored procedures may be called from anywhere a database client exists: both locally and across a network.

• DB2 requires stored procedures to have robust information available in the DB2 catalog, including calling parameters.

• DB2 handles all details of transaction-al management with the stored proce-dure environment, including address space creation and request routing.

• Stored procedures may invoke other components in the SOA environment. Other stored procedures may be called, messages may be put on queues, and, with proper plumbing, CICS and IMS transactions can be invoked.

While using stored procedures seems an obvious choice for an SOA environ-ment, it’s also possible to use SQL to provide services with even less effort. Typically, users view SQL as a means of maintaining and accessing data, but a more general purpose of SQL is to pro-vide a common syntax for database queries and procedures. This may or may not have anything to do with stored data. You can write SQL statements to do math, string operations, or call vari-ous functions you’ve defined. This may not seem like SOA, but it may actually be the purest form of SOA. The request is, by nature, extremely granular and the actual location of the service that’s supplying the answer to the SQL statement is really irrelevant. The answer comes from the plumbing!

The DB2 Catalog We tend to forget the lowly DB2

catalog, but anyone who has worked with a non-relational DBMS that doesn’t have an integrated catalog knows the value of all that metadata. From an SOA perspective, the DB2 catalog can pro-vide similar capabilities to that of a WSDL directory in a Web services envi-ronment. You can find services and determine their calling conventions. Additionally, you can use the most pow-erful query mechanism known to search it: SQL.

DB2 and Location Independence With parallel sysplex and DB2 data sharing, it’s been possible for more than a decade to connect to a DBMS instance without knowing the exact name or location of the subsystem processing your requests. Since all members of a data sharing group share a common catalog, all those members have equal ability to run stored procedures and SQL. Of course, z/OS and the Workload Manager (WLM) provide a wealth of knobs, but-tons and dials to tune the environment, but for all practical purposes, these load management functions are hidden from the user of the stored procedure or SQL. This is a key point. The less the user of a service needs to know about the execu-tion environment of the service, the more loosely coupled (and SOA-like) the environment becomes. Other than knowing the name of the data sharing group containing the desired procedure and its calling conventions, the user of a stored procedure doesn’t care where the stored procedure is executing, what its priority is, or how many other instances are running simultaneously.

Hybrid Applications While we’ve focused on the use of DB2 as the centerpiece of an SOA envi-ronment, there are certainly other alter-natives. Most IT environments have a wide mix of components that have been built over years or, more likely, decades. Since no one has a particularly good justification for rewriting those compo-nents, the challenge is to make them available in new environments. A variety of technologies and prod-ucts have been developed to assist in this process; one of the most viable has been the generation of hybrid applica-tions using message queuing systems such as WebSphere MQ to knit together various disparate parts of a transaction. IBM and other vendors have pro-vided a pretty comprehensive set of capabilities to make MQ useful in near-

5 � • z / J o u r n a l • J u n e / J u l y 2 0 0 7

ly any environment with minimal recoding required. This lets an applica-tion developer connect new code run-ning in new execution environments such as Microsoft .NET to access ser-vices running in existing environments such as CICS. While this may not fit a purist’s defi-nition of SOA, it does fit the more prag-matic model that most of us in IT need to follow. Using messaging middleware allows for component reuse at whatever level of granularity the user desires (and can afford in terms of performance). It doesn’t provide a service catalog, but it provides location independence in the sense that all the user of a service needs to know is a queue name (or two) and the message format.

XML, DB2, and SOA With DB2 9 on z/OS, a rich new set of XML capabilities extends SOA con-cepts to another realm: document pro-cessing. Again, the key is granularity. In traditional environments, the developer who needed to work on a whole busi-ness document usually needed to either make multiple calls to services for dif-ferent portions of the document or hack

together some proprietary way of han-dling the whole document. With XML, it’s easy for services to work with entire documents. Documents can be passed as XML in single param-eters to and from services. With DB2 9 XML capabilities, these entire docu-ments can be stored, indexed, and man-aged in the database. From an SOA perspective, this lets you build services around documents. This is the natural way business tends to think of process-es. You don’t pass invoice lines around in a business process, you pass invoices! While using XML this way doesn’t depend on DB2; DB2’s ability to man-age whole documents makes the process seamless. You don’t have to decompose the document to put it into the data-base. The unit of storage (XML docu-ment) becomes the same as the process unit your services are using.

The Case for DB2 and SOA In conclusion, DB2, by itself, can provide a robust, effective SOA environ-ment. While purists can argue over the details, the reality is that DB2 can facili-tate development of small, granular, ser-vices as stored procedures (and SQL).

DB2 also provides a comprehensive services catalog via the DBMS catalog and can make those services available with a high degree of location indepen-dence through data sharing and parallel sysplex capabilities. Moreover, chances are all these capabilities are already installed and, to some degree, imple-mented in most IT environments. Finally, with the availability of sophisti-cated XML storage capabilities integrat-ed into DB2, it’s easier than ever to build services around business docu-ments rather than the rows, columns, and fields we’ve spent so much time fighting with over the years. Z

About the Author Ralph W. Crosby is the CTO for the Mainframe Service Management Business Unit at BMC Software. He’s responsible for setting the strategic technology direction for the entire portfolio of IBM mainframe products. Prior to joining BMC, he worked as a database administrator, applications architect, and systems programmer in a variety of environments centered on the IBM mainframe but also including Windows and Unix platforms. He has a BS in Computer Science from the California Polytechnic State University and an MBA from Fordham University. Email: Ralph_crosby@bmc.comWebsite: www.bmc.com

CDB Software, Inc.

Data management solutions should be priced based on the data they manage, not on overall power of your system. Unlike traditional mainframe MIPs based pricing, CDB Value Based Pricing allows you to tailor your software purchase to meet any object, application, system or budgetary need. At CDB, software pricing has a direct relationship to the value you derive from our solutions. Don’t pay more. Solve your DB2 software pricing problems today.

Tired of MIPs Based Pricing?

Problem Solved.

800-627-6561For more information and a whitepaper go to:www.cdbsoftware.com/valuebased.htm

© Copyright CDB Software, Inc. All rights reserved. CDB/, CDB product names and the CDB logo are trademarks or registered trademarks of CDB Software Inc. DB2 and z/OS are registered trademarks of International Business Machines Corporation. The IBM logo and the Business Partner emblem are trademarks of International Business Machines Corporation in the United States, other countries, or both.

Discover CDB Value Based Pricingfor DB2 for z/OS Data Management Solutions.

z / J o u r n a l • J u n e / J u l y 2 0 0 7 • 5 5