Talking DB2 and SOA in Big D

Howdy, folks. I'm posting today from Dallas, Texas, site of the 2008 IDUG North American Conference (IDUG is the International DB2 Users Group). I've had the opportunity here to participate in some extensive discussions about Service-Oriented Architecture (SOA), one of my favorite subjects (on Sunday I taught a day-long seminar titled "SOA in the Real DB2 World," and yesterday I moderated a Special Interest Group session on "Mainframes, COBOL, and SOA"). Following are capsules of some of the more interesting (to me) exchanges that proceeded from the aforementioned discussions. I'll probably elaborate on several of these in future posts.

• SOA is way more than Web services. The topic of Web services often dominates conversations about SOA, to the extent that some people might have the impression that use of the former suffices as an implementation of the latter. Such, of course, is not the case. Web services - essentially, application services that are described by a standardized form of XML called Web Services Description Language, aka WSDL - are indeed important, because they can be understood by service-consuming programs and can be invoked in ways that are not dependent upon technical details of service-providing program implementation (i.e., a person coding a service-consuming program can use a Web services call to utilize the functionality of a service-providing program, and he doesn't have to know about things like the hardware platform and operating system on which and under which the service-providing program runs). Abstraction of the "plumbing" of an application system, as provided via Web services, is a key characteristic of an SOA (good for programmer productivity and for application change isolation), but so is service reuse, and the exposure of application functional components as Web services does not necessarily lead to a situation in which those components will be reused to speed up application functionality extension efforts. If functional components are not being reused - if wheels are being reinvented to extend application functionality - then you don't have an SOA, regardless of whether or not you're utilizing Web services.

• An Enterprise Service Bus (ESB) is not just about inter-application information exchanges. Quite often, an ESB is a foundational part of an organization's SOA, and an ESB is frequently justified as way to facilitate communication between different application systems (often running on different server platforms and implemented using different programming languages and database management systems) for purposes of information exchange (in other words, an ESB make sit easier for data and functionality to be shared across an organization's application systems). There's nothing wrong with this justification (it's a good one), but it suggests that an ESB is just about inter-system data sharing. In fact, another key benefit of an ESB has to do with service reuse (which, as mentioned in the preceding bullet item, is not at all guaranteed through the use of Web services). You see, if application service components are going to be reused, people have to be aware of them, and it really helps people with respect to their awareness of existing application services if those services are registered somewhere. How can you get developers of service components to register same? One way is to make an Enterprise Service Bus THE interface to an organization's application services, and to restrict the services available via the ESB to those cataloged in a registry associated with the ESB (as one discussion participant put it, "if an application service isn't in our ESB registry, it doesn't exist"). An ESB can therefore be of significant value as a means of establishing discipline in an application development environment (e.g., services WILL be accessed via this interface, and they WILL be registered in this repository), and that kind of discipline is important because SOA success often depends as much on process as it does on technology.

• Code reuse is good, but so is code elimination. If you're going to write code, it's good to take steps that will maximize opportunities to reuse that code, and SOA is certainly about that. Here's another potential benefit of an SOA: code elimination. I'm thinking particularly about rules engines, which are often implemented as part of an Enterprise Service Bus (ESB) solution. The concept here is pretty simple: the ESB is the entry point through which requesters gain access to an organization's portfolio of application services. But how will requests be properly routed to application systems accessible via the ESB? In the case of a relatively complex transaction that will require access to the services of multiple different application systems, and in a certain sequence, to boot, how will the workflow be properly orchestrated? Enter the rules engine, and associated ESB functionality that could be formally referred to as a process engine but which users might call "the traffic cop" or "the control tower." Organizations can use this technology to insert into the process flow rules that specify the way in which various transactions will be handled upon interfacing with the ESB. The ESB can act upon these rules to make sure that work gets done the right way and on the right application systems, and the beauty of it shows when a rule has to be changed (perhaps because of an application system modification or because an extra processing step has been added for a complex transaction): the rules engine is updated accordingly, and that's that. No user code has to be written or altered in order to effect the processing change. You simply inform an intelligent piece of software that the workflow orchestration rules have been updated, and the process engine does the rest. This non-reliance on user-written code to alter transaction processing flows has both an agility advantage (it can be done more quickly versus the user-coded way) and a quality-of-service advantage (user-written code tends to increase the odds of a programming error getting introduced into the production environment). The point is not, of course, to take work away from programmers - it's to get talented programmers working where they deliver the greatest value to the organization: in the development of code modules that deliver functionality to serve the needs of customers and clients. Let process and rules engines take on the work of connecting service requests with service-providing components as needed.

• Absolutely, COBOL is a good language to use in an SOA. Two different people, in two different discussions, expressed concerns related to the use of COBOL in an SOA. One mentioned that because he almost always heard of object-oriented (OO) programming languages (e.g., Java, C#) in talk about SOA, he'd pretty much concluded that SOA was incompatible with procedural languages such as COBOL. This is, of course, not at all the case. COBOL - a very CPU-efficient language that is familiar to a large number of application developers - can be used very effectively in an SOA. I'm particularly keen about the use of COBOL for programs that are part of an application's data-access layer (logically distinct and loosely coupled presentation, business, and data layers are characteristic of an SOA). On mainframes running DB2, you might be talking about CICS or IMS transactions - or DB2 stored procedures - written in COBOL and containing embedded SQL statements (note that CICS and IMS transactions, and DB2 stored procedures can easily be exposed as Web services - the latter via IBM's Data Studio product). And hey, keep in mind that today's COBOL is not your dad's (or your mom's) COBOL. If you haven't checked out the enhanced XML and Unicode support (and other SOA-friendly goodies) in IBM's Enterprise COBOL for z/OS V4.1, you might want to do so. The other person with the COBOL concern was worried about young people coming put of college without COBOL skills. Would his organization be able to bring in new COBOL programmers as people retired or otherwise left the business, and if not, should they start cutting back on their use of COBOL? I liked the answer provided by one of the other people in the room: "We hire college grads and train them in-house to become proficient with COBOL. In three months they're ready to go." Message: relax.

That's it for now. As previously mentioned, I'll probably expand on at least some of these items in future posts. Thanks for visiting my blog. Y'all come back.