For many years, software development progressed by improving programming languages. More recently, that focus has shifted to programming processes; for example, the Java™ language eliminates the need to link compiled modules together. SOA is the most recent innovation in this trend. This article, although targeted mainly at mainframe software developers and architects, applies equally to pre-SOA software for other environments, such as the Linux® operating system.
Componentization and component assembly are key principles in SOA software design. SOA relies on ubiquitous and commoditized technology, such as the Internet, XML, and HTTP. It's defined by standards and is equally accessible to individuals and small and large enterprises. It's the best solution we have today for application construction.
SOA is described in the IBM® SOA Foundation white paper (see Resources for more information) in the following way:
What should be clear by now is that SOA is not just about technology. IBM views SOA as a holistic relationship between the business and the IT organization. SOA encompasses the tools and methodologies for capturing business design, and using that design information to help improve the business. It also encompasses the tools, programming model and techniques for implementing the business design in information systems. It encompasses the middleware infrastructure for hosting that implementation. SOA encompasses the management of that implementation to ensure availability to the business, and to ensure efficient use of resources in the execution of that implementation. It encompasses the establishment of who has authority and the processes that are used to control changes in the business design and its implementation in the information system. And ultimately, SOA accelerates the time-to-value for these benefits.
Some of these architectural processes -- business modeling and business process design in particular -- apply to mainframe applications just as they apply to the Java 2 Platform, Enterprise Edition (J2EE) environment or other types of applications. This guide concentrates on the tools, programming models, and techniques for SOA implementation that are especially adapted to the IBM mainframe environment. You should supplement this article with companion guides on SOA enablement of IBM mainframe applications for environments, such as batch, IBM CICS®, IMS™, and DB2® environments and additional articles on SOA development topics.
Technical changes that give software SOA capabilities without changing its function are referred to as SOA enablement. In general, the term SOA enablement isn't intended to apply to the design and construction of new software. Developers may elect to combine SOA enablement with functional changes to an application, but SOA enablement does not require functional change.
SOA application design offers many advantages to IT. The focus here is on three in particular:
- Near-universal connectivity that eliminates expense and complexity caused by proprietary technology and mediations that exist only to resolve technology mismatches
- Reuse through construction by aggregation that works well with Model Driven Architecture.
- Applicability to most programming languages and runtime environments.
Modern businesses are motivated to seize opportunities offered by new markets and to become ever more productive. Opportunity must be met with flexibility, and IT flexibility arises from the ability to reconfigure, modify, and create new software as needed. Productivity is primarily the result of reengineering and automating business processes. Software is malleable to the extent it can easily be altered to meet changing business needs.
Designing and implementing malleable software has been a challenge since stored-program computers were invented. Virtualization -- the replacement of static bindings between program elements with bindings that can be changed during operation -- is a key to malleability. Yet it must be used cautiously in high-performance computing environments lest it impact performance and resource usage.
We've learned to design software to separate process sequencing logic, policy, basic computation, human interface, and data management. This separation recognizes that sequencing logic and policy are most frequently affected by changes in business practices. Other separations (user interface and data) insulate application software from technology changes in data storage and user interface (UI) preferences, including access from portable devices. Binding these separate elements virtually and dynamically allows them to be quickly separated and rejoined in different ways. For example, a policy can be removed and replaced without stopping the overall software process in which it plays a part.
Construction of software components, whether process sequencing logic, policy, basic computation, human interface or data management, increases productivity by reuse. It also provides consistency across multiple business processes and simplifies maintenance by avoiding the need to change equivalent code in multiple software modules.
Reuse is a process of discovery that continues as long as shared components are employed in new scenarios. A component naturally evolves by accumulating capability, retaining all the old capabilities to avoid the pain of reengineering the clients. Periodically, however, components should be reengineered and refactored. Although this can often be done without impacting the users, you must be able to identify component users in the cases where reengineering and refactoring will impact them.
In SOA, components have service interfaces that are described by Web Services Description Language (WSDL). The WSDL for a component describes both the services provided by that component and the services required by that component. WSDL is one of the Web services interoperability standards. A service provider can be connected to a service requester if their WSDL descriptions match. This enables the two components to exchange messages.
The modern mainframe was born in 1964. It quickly became the epitome of enterprise computing, continuously evolving to maintain that position. Amazingly, application code written 40 years ago would likely still run today in most mainframe environments. There are probably tens or hundreds of billions of lines of COBOL code in use today, much of it originally written in the 1970s and 1980s. Buried within these applications is logic implementing valuable business procedures, calculations, and policies. SOA enablement for the mainframe environment includes practices, architecture patterns, tools, and middleware to uncover this logic and make it reusable.
IBM mainframes are highly scalable, capable of executing tens of millions of transactions daily. They are also highly tuned, achieving processor and I/O utilization rates in excess of 90%. Reliability is extremely high, and recovery from the rare outage is quick with little loss of information. System configurations support failover and disaster recovery, as primary and backup systems may be separated by many miles. IBM mainframes and their primary application hosting environments are uniquely scalable and reliable. These are qualities of computing necessary for continuous operation of critical IT in large enterprises. IBM mainframes have achieved these qualities by constant technical innovation in areas such as hardware virtualization, failover, self-diagnosis, large-scale shared memory multiprocessing, and remote resource sharing. Many of these technical innovations have been adopted by midrange servers. SOA for the enterprise environment is designed with these attributes as well, achieving reuse without losing efficiency and quality of service.
The three kinds of SOA enablement for the mainframe environment
Implementing an SOA for an enterprise requires three significant considerations:
- Changes in applications, including reengineering of existing applications and design changes in applications to be created
- Changes in IT skills
- Changes in IT infrastructure (hardware, systems, middleware, and communications)
Although this article focuses on application changes, bear in mind that the success of an SOA enablement project depends on changes of all three kinds. The most recent versions of hardware, systems, middleware, and communications -- particularly virtualization, software management, and communication -- that are designed to meet the needs of SOA work best. It's best to inventory the IT infrastructure before starting an SOA project and update any facilities critical to the project’s success. Also, inventory the available skills and arrange for training. On occasion, a services vendor, such as IBM Business Consulting Services, can be engaged to carry out a proof-of-concept project, and IT personnel participate, learning necessary skills along the way.
SOA skills are necessary for the initial implementation and maintenance of SOA systems. All component developers in the enterprise -- including COBOL language developers -- must practice SOA design, because components become reusable only to the extent the designer or implementer envisioned ways in which the component services might be used. Application architects, including those responsible for existing applications, must also understand and practice a new SOA skill -- integration design -- that includes component assembly, process automation, and data integration.
For most enterprises, the journey to SOA takes time and is accomplished by incremental change that provides both short- and long-term demonstrable value. Many IT organizations, especially in the financial services and insurance sectors, have already begun incremental development projects to SOA-enable parts of their existing software portfolios. They report that even modest degrees of SOA enablement make application integration, process automation, and rapid software reconfiguration easier to achieve.
We recommend planning SOA enablement as part of the incremental change process, not as a separate process whose deliverables would replace current systems. Major replacement projects are risky, expensive, and warranted only when the existing systems can no longer satisfy business needs. Reasons for this include cost, requirements that change as the project progresses, and organizational opposition by stakeholders of the current implementations. In contrast, incremental IT infrastructure change is a normal practice that causes little disruption, and incremental changes in skills and in application structures are easily made normal practice as well.
SOA-enabling existing applications
Our exploration focuses on how SOA supplies two kinds of value: access and reuse/flexibility. A new SOA application would exhibit both kinds of value. An existing application undergoing SOA-enablement generally follows one of three patterns:
- Wrapping -- The existing application and its existing interface are attached, unchanged, to a gateway that provides one or more SOA interfaces. This pattern provides access, but does not improve reuse or flexibility.
- Refacing -- The existing application is modified or extended to provide a new interface more suited to its use as a service. This pattern provides access and a measure of reuse/flexibility.
- Componentizing -- The existing application is deconstructed into components and then reassembled to facilitate reuse and expose previously inaccessible functions as service operations. This pattern provides the maximum value of both access and reuse/flexibility.
Each of these patterns presents advantages and disadvantages. Often an IT organization first attempts wrapping to gain low-cost access. If wrapping incurs higher operational costs, the IT organization refaces or componentizes heavily used applications to improve performance. A related motivation for refacing or componentization is to expose application services that were previously accessible only through a complex dialog that required information not directly relevant to the exposed service.
Let’s examine each of these in more detail.
Wrapping of mainframe applications began during the client/server era and is a mature practice with mature technologies. IBM gateway offerings such as WebSphere® Host Access Transformation Services (hereafter referred to as HATS) support wrapping of 3270 and 5250 applications. HATS were recently enhanced to offer Web services access. The most recent version of CICS provides direct access via Web services. When this feature is coupled with the linkable 3270 bridge and the service flow runtime features, CICS Basic Mapping Support (BMS) applications can be published as Web services. IMS offers a similar capability using a J2EE application server with support for Web services connected through IMS Connect software.
Mainframe applications may be designed with a terminal interface or a message interface. Sometimes they have both and separate the UI, code from the business logic. A best practice for CICS and IMS applications is to split the 3270 UI support from the business logic, then couple these two layers using the message interface. This design principle is similar to Model/View/Controller architecture but arose independently. It isolates changes in the UI from changes in the business logic and lets the UI execute in a separate container tuned for optimal UI processing efficiency.
Two limitations of the 3270 interface are especially significant when designing for SOA access.
First, the request and reply each may not exceed 1,920 bytes of information per transaction. Larger transfers require multiple transactions, adding path length and resource consumption. For example, an inquiry transaction for John Smith may return several hundred customers. If the first 3270 screen (showing only 15 customers at a time) does not display the right customer, the operator requests subsequent screens, each request being a new transaction consuming CPU, I/O, and memory overhead. A better interface, especially for program to program communication, would return all of the John Smith records at once.
Second, the 3270 terminal is conversational. This means there's a bundle of mainframe resources associated with each logged-in user, even for an idle terminal. In addition, some older applications are written to cache information (such as the entire list of customers named John Smith) requested by a particular terminal. While such application code improves performance for transactions like show the next 15 customers named John Smith, it adversely impacts other system characteristics. The user of such an application cannot change terminals or disconnect temporarily from the application, the middleware cannot perform load balancing, and the system cannot manage the information cache by swapping it out during user think time or absences to reduce memory consumption.
Larger message sizes permit more information per transaction, reducing overhead and improving response time. Mainframe middleware, such as CICS and IMS, supports message sizes up to 32KB per transaction in the message interface. Where an application is split between UI logic and business logic, SOA enablement can often be applied at the business logic’s message interface, bypassing the UI code entirely. Recent versions of this middleware have begun to support even larger message sizes; however, message sizes over 32KB require application program changes.
This leads to the next pattern: refacing.
The purpose of the refacing pattern is to add a message interface -- typically an SOA interface, suitable for use as a service, described in WSDL -- to an existing application. The interface might be implemented in several different ways depending on the type of user and the need for performance. The refacing pattern, requiring modest application changes, can be a useful step toward full componentization.
Refacing is typically done without redesigning the application.
You can introduce a message interface between the UI and the business logic. This approach, while possibly complex, can yield excellent improvements in performance, reusability, and flexibility.
Or you can duplicate and edit existing application code while leaving the original mixed UI and business logic in place. This adds the needed function without significantly altering the original code, possibly with lower cost and less risk.
Several software design issues can be addressed during refacing projects:
Mixed UI-, business-, and data-related code
For example, in creating an application to display and edit the contents of a master file, the simplest single-user design receives the query parameters from the user, queries the database, and displays the first 15 items found, leaving the database cursor open until the user either edits one of the previously displayed items or scrolls down the view the next 15 items. This design is difficult to change when the query results are returned in a message rather than being displayed. It's also difficult to change if the user wishes to receive more or less than 15 items. Creating an interface between the query logic and the UI logic can resolve most of these issues. The query results are returned in a message; the maximum number of results to be returned can be specified in an inbound parameter.
Maintaining user session-related state
The previous example held the database cursor open between user interactions, preventing other users from accessing database segments that are locked. For a multi-user system, caching the query output in process memory and releasing the database locks improves overall system performance. However, the application process with its user-specific cache contents is suspended until the user performs some action. Processes own threads, memory, and other resources, and these resources now become scarce as the user load increases. By adding code to manage query caches for multiple users at the same time in a single process, the process need not be suspended, but can be switched to perform work for another user. Advanced transaction manager middlewares, such as CICS and IMS, provide temporary storage areas (scratchpad, temporary storage queues) that can be used to cache application state across user interactions. In addition, the middleware can manage these caches to reduce pressure on main memory and copy them between processors to improve workload management.
Coupling of user session with user session state in the application
When a process is to serve multiple users, each time it's executed it must be able to identify the user who issued the current request in order to locate the user-related session state. In SOA applications, service users may be humans, computerized workflow scripts, or other components, so it's best to pass a single type of user key (a data value that identifies a user session) to the application process when it begins execution. Older applications may contain user keys (for example, TERMIDs) that don't meet this requirement. Introduction of user key parameters is particularly valuable when several components must be executed to satisfy a user request; this practice insures that the proper user session state is used in each component.
Isolating business and data logic
Although a few business processes (such as discount and sales tax calculations) are pure logic, most of them change persistent data (customer addresses, stock on hand) using the common Create, Retrieve, Update, Delete (CRUD) pattern. A simple program architecture would naturally mix the business logic with data access logic (like SQL). This dependency on data schemas and specific versions of SQL may inhibit the flexibility to reuse the business logic and the data. Placing the data manipulation logic into a data access service or procedure makes the business logic less dependent on the source of the data. In addition, the design and implementation of the data access service itself become reusable resources. If the highest performance is needed, the data access service can often be implemented as a database stored procedure.
Many other design issues could be added to this list and should be considered when contemplating a refacing project. The issues listed here can seriously impede the move to an SOA if they aren't addressed.
These suggested design changes facilitate componentization, the next SOA-enablement pattern discussed.
Componentization makes an application modular by creating interfaces to formerly inaccessible internal functions (such as discount computations in an interactive product-ordering application). Componentization is an extension of refacing because it introduces SOA interfaces inside an application, whereas refacing applies only to exterior interfaces.
Modern component architectures assume that components execute in middleware environments called containers. The container assumes much of the resource management responsibility that would otherwise have to be coded into the application (such as setup and teardown of resource connections, thread management, transaction control, and creation and deletion of data structure instances). The result is a component that is nearly free from dependence on specific resource types or operating systems. Redeployment of the component into another container with similar function becomes much easier. Thus, componentization also includes refactoring the application to remove the resource management functions from the application and replace them with equivalent functions provided by the container.
In modern component architectures, the developer explicitly specifies the component’s resource management needs in a resource management policy language. Examples of this include J2EE deployment descriptors and Enterprise JavaBeans Query Language (EJB QL). This information is read by deployment tools as the component deployment specialist prepares the component for execution in a specific middleware environment and associates it with the real resources it will use. In older middleware environments, software deployment was done by a system programmer using ad hoc practices (for example, where the application developer filled out a paper form and gave it to the system programmer). The resource management policy language was actually a configuration language that mixed application-level policies (such as database connections) with middleware policies (such as what transport to use for message exchange). The newer practices can be automated by tools and are less susceptible to error. For example, a deployment tool could detect an association with the wrong database before the application executes. Previously, the application would not have detected this error until execution, producing error messages and a storage dump.
Mainframe subsystems, such as the CICS, IMS, and DB2 middlewares that have long provided containers with resource management functions and a configuration language, are moving toward a modern style of resource policy management language and a standard set of container-provided services. Meanwhile, componentization of existing applications can still provide substantial benefits in reuse and flexibility.
There are a number of technical issues to be addressed in applying a componentization pattern. Some are listed here and will likely be discussed in greater detail in subsequent articles. Perhaps the most difficult challenge is collecting the related code from multiple source files; development tools can greatly expedite this task. Another challenge is redesigning the means to share information between two or more code segments that were previously part of a single module; passing the information in parameters, while feasible, is not always the best solution.
Much of the preceding discussion has focused on the technical requirements for a piece of software to be termed a component. This section begins to address how to identify potential components in an existing application. You'll learn about tools and best practices for discovering and creating components later in this article.
Component discovery is a design exercise to determine structure and logical boundaries: which data and behaviors to place in one component and which data and behaviors belong elsewhere. As components are created, registering them and their essential properties in a reuse database enables other developers to locate and reuse them.
Components have many similarities with objects in object-oriented programming. So it's not surprising the component discovery process resembles object-oriented design. At the most general level, a component provides services relating either to:
- A particular type of data, such as customer or product.
- A particular type of process (such as payroll, billing, or estimation). Such components typically use and integrate data of many types. Billing, for example, aggregates information from products, customers, orders, and other processes, such as shipping and financing. In practice, there are many different types of processes, and designers often create process-related component subcategories to take advantage of similarities in the process types.
While some experts identify data-related components first -- believing this facilitates the subsequent identification of process-related components -- we recommend moving between those two activities, adjusting your initial component definitions as you elaborate your design.
You start by mapping existing data structures and sequences to business-level concepts. Modeling tools like IBM Rational® Software Modeler -- a great improvement over simple tools like spreadsheets or databases -- aid the visualization of software relationships and facilitate validation and other analysis tasks. Comments or extensions to the metamodel link your models to the code being analyzed. These models contain initial definitions of both process- and data-related components, which you edit as you define components. The finished model is a blueprint for arranging existing code into components.
Developers can use the blueprint to edit the code for inclusion in components. In some cases, component shells are generated directly from the model; one can always hand-create the component shells from the model. The code to be reused is then extracted from the application sources and inserted into the component shells. Some final editing is needed to make this code compatible with code already in the component shell and with the interfaces defined by the component shell.
There is a good deal more to this process than this brief description may suggest. Be prepared for a lot of initial experimentation. Pick a componentization project that will have business benefit when it succeeds, but avoid complex projects or those with a hard deadline that are business critical or where there will be little toleration of experimentation (and mistakes). Getting advice from experts and collaborating with similar projects are almost always beneficial. Make sure you understand the rationale behind the advice you get and that it's relevant to your objectives.
You'll find that the process-related components aggregate (assemble) other data and process-related components. The service interfaces of these process-related components become the interfaces to the new, componentized service that replaces the old application. It may be more productive to write process components that change frequently in a process-specific language, such as the Business Process Execution Language (BPEL). Because BPEL can describe processes more compactly than the Java language or COBOL, the amount of change is reduced. The Java language, because it's an interpreted language that supports rapid change/test cycles, is better for this than COBOL as long as the processes aren't performance critical.
An SOA project generally contains significant new code that adds data integration or process automation that was previously done by human users; this new code should follow the componentization guidelines. It may be implemented in BPEL, the Java language, or COBOL depending on the needs of the project and the skills available.
The first step in an SOA reengineering project is typically to inventory the existing portfolio’s software and system artifacts, identifying their dependencies on one another. Because the SOA project is driven by a desire to make the IT realization of business processes more flexible, it's valuable to associate the artifacts with the business process they support. Linking the artifacts to their development history (change statistics, development investment, defects, and so on) can indicate the likely pattern for SOA-driven reengineering. Although a small SOA pilot project might not need this inventory, ongoing maintenance and future SOA projects will benefit from this excellent practice.
This portfolio inventory can be used to identify software that provides marginal or no benefit to the business. Such software can be replaced with commercial software or simply taken out of service. The inventory can also identify critical software elements that must be reengineered to achieve the project goals. For example, if the goal is reducing the time it takes to produce a bill after rendering a service, the billing workflow should be examined to identify activities that introduce delays and to redesign them. If you saw that the overall business process suspends until a key batch application executes and produces needed data, for example, you could redesign the batch application to run more frequently.
The portfolio management inventory helps IT managers and architects decide where and how to allocate development resources to maximize business benefit. IBM supplies the Rational Portfolio Manager tool that's very useful for this purpose.
Studies reveal the most costly aspects of software development and maintenance: change analysis, design, and testing. Testing alone can consume half the budget for an application maintenance cycle. For an existing application, change analysis tools, such as IBM WebSphere Studio Asset Analyzer (WSAA) and similar tools from other vendors, hasten the analysis phase and reduce errors. Their analysis of source code, Job Control Language (JCL), middleware configuration metadata, and other artifacts is captured in a database. A query to this database could determine what source modules and data files must change if an existing data element is altered or a new data element is added. Impact counts, and data item usages can help estimate development work effort.
Change analysis tools can also improve test planning by identifying changes for test data as well as unneeded tests that would not exercise any changed code. Other tools track test coverage of applications by test set.
A best practice includes refacing or componentizing activities in a normal application maintenance cycle, introducing changes gradually in the context of other changes. This approach, sometimes called in-place reengineering, reduces the risks from scope creep and unforeseen complications.
Modern, workstation-based development tools offer the best productivity and support good programming practices. Integrated tools eliminate error-prone steps, such as printing and copying information from one tool to the next. An integrated tool lets you transfer the results of an analysis project (for example, a list of impacted source code sites and data files) into an Integrated Development Environment (IDE) where a developer can access and edit the source code files. Developers experienced with 3270-based development tools are sometimes reluctant to move to an IDE, but the IDE tools have shown greater productivity, and once mastered, developers are quite happy with them. IBM WebSphere Developer for zSeries®, an IBM IDE offering targeted to mainframe developers, includes tools for SOA enablement of existing mainframe applications. WebSphere Developer for zSeries is an extension of the IBM Rational IDEs, IBM Rational Application Developer in particular, and includes that product’s J2EE component development capabilities.
Refaced and componentized services are typically aggregated into (parts of) business processes. Special tools to create BPEL processes and integrating mediators for an Enterprise Services Bus are provided in IBM IDEs, such as IBM WebSphere Integration Developer. WebSphere Integration Developer and WebSphere Developer for zSeries together constitute a complete IDE package for SOA development on the mainframe. Additionally, WebSphere Developer for zSeries contains tools for simple integrations, such as sequencing of CICS transactions within CICS.
Modeling and analysis could become indispensable parts of your process for software design and reengineering. Using information from WSAA, software architecture models can be built in Rational Software Modeler. The models can then be used to explore potential software changes. Subsequent analysis of the models can establish how much work is needed to make these changes and identify potential technical problems.
IBM offers a new programming language, Enterprise Generation Language (EGL), and an IDE for this language that is easy to use by application developers and supports SOA programming. This language and the IDE improve productivity by simplifying the programmer’s tasks and guiding him or her in the proper application of SOA design principles.
SOA applications are assemblies of multiple components. Traditional tools, such as debuggers and dump analysis tools, remain useful, but must be used in conjunction with application monitoring and management tools specifically designed for SOA applications, such as the IBM Tivoli® Composite Application Manager and the IBM Tivoli OMEGAMON® XE tools. Assemblies provide additional monitoring points at the component interfaces. These monitoring points can supply additional detail to accelerate problem determination and recovery.
Component developers quite naturally reason that because they cannot know how their components will be used, they should extensively check input data and references as well as the outputs and references they produce. Composing such components results in repetitively validating data passed between components with performance inferior to monolithic application structures. Moreover, data types chosen for a component’s input and output signature that a developer thinks may encourage the broadest reuse might not yield the best performance. Such components, when composed, may incur unnecessary conversion overhead as data passes between components. Conversion of COBOL data to and from XML, for example, is quite expensive -- and completely unnecessary -- when the client and the service are both written in COBOL and the transport is capable of conveying binary information.
Component development is always a compromise between the performance and quality of the applications’ service requirements and the reusability and generality of their constituent components. Considering the primary uses of components within application structures leads to more appropriate placement of data validity checking -- for example, only at managed trust boundaries. If a new primary use is anticipated for a component, consider whether this creates a new trust boundary and a need for additional validity checking outside the component. The same applies when defining input and output data signatures for components; design them to perform well in the primary application, and change them only when their use changes significantly.
SOA also includes adapters that change the input and output data signatures of component operations; adapters insulate a service’s clients from changes in its interface at a slight performance cost.
Component architecture for applications
IBM, in conjunction with its business partners, has begun to release information about design principles, best practices, and development tools for implementing components. This set of guidelines and tools is called Service Component Architecture (SCA) (see Resources for a link to an article on this topic). Though the design principles and practices are mainly described using Java and J2EE, almost all of these principles and practices can be implemented in other languages of interest to the mainframe developer (such as C, COBOL, and PL/I) and the resulting code deployed in middleware, such as DB2, CICS, and IMS. IBM is working with industry collaborators, software development organizations, and standards bodies to define SCA and Service Data Objects (SDOs) for these other languages and middleware and to publish these design principles and practices within the next year. SCA and SDO should be used for all new application development efforts. SCA is also intended as the primary target architecture for componentization activities on existing applications.
SCA will be the design basis for creating components and application aggregates that can include interoperable components written in many different languages. The technology components needed to facilitate this are being put in place now. For example, IBM Enterprise COBOL for z/OS® and IBM Enterprise PL/I for z/OS both support XML processing, and Enterprise COBOL for z/OS provides novel facilities for interoperating with Java. Rational Application Developer and WebSphere Developer for zSeries provide tools for creating data adapters to allow passing complex data types between Java and other languages. As a technology demonstration, IBM has released information allowing developers to create COBOL components that execute in the IBM WebSphere Application Server for z/OS container.
SOA offers tools, techniques, and best practices for tapping the business logic embodied within your enterprise’s existing software portfolio. SOA enables these valuable existing software assets to be recombined in new ways, to produce a more flexible IT realization of your business design that's adaptable to changing business needs. SOA principles offer a practical extension of existing reengineering best practices and apply equally to existing software and newly created software.
Learn
- Get more information about the IBM products discussed in this article:
- CICS Transaction Server for z/OS V3.1
- DB2 Universal Database for z/OS
- IMS
- WebSphere Message Broker
- WebSphere Developer for zSeries
- WebSphere Studio Asset Analyzer
- WebSphere Integration Developer
- Learn about the IBM SOA Foundation.
- Check out the IBM Service Component Architecture.
- Visit the developerWorks
SOA and Web services zone to expand your knowledge of this rapidly expanding area.
- Browse for books on these and other technical topics at the Safari bookstore.
Get products and technologies
- Download a free trial version of the following IBM products:
- WebSphere Application Server for z/OS
- WebSphere MQ
- WebSphere Host Access Transformation Services
- WebSphere Business Modeler
Discuss
- Participate in the discussion forum.
- Get involved in the developerWorks community by participating in developerWorks blogs.
Jim Rhyne is an IBM Distinguished Engineer and Chief Architect for IBM zSeries middlewares and tools, including CICS, WebSphere Developer for zSeries, Enterprise COBOL for z/OS, Enterprise PL/I for z/OS, and WebSphere Studio Asset Analyzer. He was previously a senior architect for WebSphere and IBM Component Broker software. Jim is an advocate for modernization of mainframe software and frequently advises users of IBM mainframes, industry analysts, and software services organizations.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.
- Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
- Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
- Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
- Buy: Rational Service Tester for SOA Quality
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
