Most it executives never think of service-oriented architecture (SOA) as applying to batch applications. How could they possibly fit?But SOA is about reuse. And a business function used in online transactions may be the same business function used in batch processes, so organizations should think about their IT modernization strategy and consider SOA as a standardized application integration mechanism if nothing else.
SOA provides a common mechanism for varying technology environments to interact. As companies move toward a more modern IT infrastructure, batch processing may be a way of life, and SOA should be part of that strategy. Many applications cannot execute until after the workday has ended or, perhaps, the financial markets have closed. Batch processing is inevitable. But modernization strategies may create a broader and mixed technology base, and SOA is a growing and common integration strategy.
When does SOA make sense for batch applications? As organizations continue to evolve their application portfolios to leverage packaged software and new development, business rules will move to a myriad of places. Reusing those newly located business functions in batch jobs can make sense.
For example, organizations faced with changes driven by government legislation often struggle with how to implement the changes, particularly when the data in question is processed in a batch mode. The insurance industry may be forced to verify certain data with outside agencies. And, when that agency provides some kind of Web or Web service interface, it is possible to implement this solution for batch processing.
Then there are considerations of what's required for SOA to work for batch applications. Wrapping technology has a significant impact when a company has a need to use Web services from a batch environment. Technologies that leverage IBM's CICS infrastructure and operate within the CICS address space, such as HostBridge, Seagull or IBM, can be used, but batch jobs must interact with these regions, adding substantial processing overhead.
Besides the microflow processing needed to interact with a single transaction or a series of transactions, connectivity is necessary to communicate to the consumer of the Web service. IBM's CICS and IMS provide HTTP connectivity, as well as message queue to satisfy this requirement. Consequently, batch jobs could use those runtime environments to provide this connectivity.
A second option, provided by two vendors (Atltanta-based GT Software Inc. and Bedford, Mass.-based DataDirect Technologies Inc.) uses an independent address space to implement the navigation and communication support for Web services. Batch jobs could now interact with these address spaces through external CICS interface or IBM's Hypersockets capability, reducing the path length to support the Web service connection. A batch job communicates with this address space, and this address space uses its connectivity to communicate with the external Web service.
Also, these Web services could be provided from a non-mainframe environment, providing information back into a mainframe-based batch process. Ensuring satisfactory performance is critical in such an approach.
The main advantage SOA has for batch applications is consistent use of business function across both online and batch processing. SOA does separate the technology of publishing services from the technology of consuming those services, but the payoff is reuse.
Commercial off-the-shelf solutions are becoming more common as organizations choose to decrease investment in bespoke code. The availability of a variety of technology solutions leads many companies to ask why you'd ever write an application from scratch again. Reusing these acquired solutions is where SOA shines and batch processing may be inevitable in certain situations. So why not consider SOA in your batch strategies?
The biggest downside to SOA for batch applications is performance. Batch jobs have historically processed large volumes of data in defined batch time windows overnight. If service calls introduce a level of delay or dramatic performance hits, then batch processing won't finish in time. Transaction volumes occur over the course of the work day and, while there are peak processing times in any organization, the volumes of processing in batch and the limited time windows leaves no room for error.
Organizations must make broader modernization decisions before embarking on any effort to enable batch process use of services. Although we do see advantages to using Web services as a modernization approach, it's more important that companies decide their longer-term approach to enhancing or reusing existing applications and consider Web services as one option.
A decision to evolve increasingly toward Java might lead a company to the WebSphere XD solution. A decision to continue to leverage existing CICS or IMS workloads on an IBM mainframe might lead a company to evaluate the various wrapping options. This decision will drive the batch option.
Gartner recommends organizations evaluate the use of services from a batch process, measuring performance and CPU use. Use the results to help tailor the broader modernization decisions.
Dale Vecchio is a research vice president at Gartner Inc., Stamford, Conn.
