Front cover
z/OS Technical Overview
WebSphere Process Server and
WebSphere Enterprise Service Bus
Learn about SOA technologies
on System z
Read product overviews and
considerations for z/OS
Discover approaches to integrate
with backend applications
Martin Keen
Niall Betteridge
Diego Cardalliaguet
Andreas Groeschl
ibm.com/redbooks
Redpaper
International Technical Support Organization
z/OS Technical Overview: WebSphere Process
Server and WebSphere Enterprise Service Bus
September 2006
Note: Before using this information and the product it supports, read the information in
“Notices” on page vii.
First Edition (September 2006)
This edition applies to WebSphere Process Server for z/OS V6.0.1 and WebSphere Enterprise
Service Bus for z/OS V6.0.1.
© Copyright International Business Machines Corporation 2006. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
The team that wrote this Redpaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Chapter 1. Welcome to this Redpaper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 An introduction to this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 How to read this Redpaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Chapter 2. Key technologies of SOA implementation on System z . . . . . . 5
2.1 Using mainframes in today’s business environment . . . . . . . . . . . . . . . . . . 6
2.1.1 Mainframes in use today . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 The challenges of mainframe technologies. . . . . . . . . . . . . . . . . . . . . 6
2.1.3 Adoption of SOA capabilities for the mainframe . . . . . . . . . . . . . . . . . 6
2.2 SOA on System z . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 What is SOA and why adopt it . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 The business and IT benefits of SOA . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3 Service granularity and choreography . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.4 Service Component Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.5 System z and why is it appropriate for SOA . . . . . . . . . . . . . . . . . . . 20
2.3 Technology standards used for SOA enablement. . . . . . . . . . . . . . . . . . . 24
2.3.1 Web services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4 Enterprise integration with IBM products. . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4.1 The IBM SOA Foundation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.5 Overview of WebSphere Process Server and WebSphere Enterprise Service
Bus for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.5.1 WebSphere Process Server for z/OS . . . . . . . . . . . . . . . . . . . . . . . . 42
2.5.2 WebSphere Enterprise Service Bus for z/OS . . . . . . . . . . . . . . . . . . 46
2.5.3 Supporting products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.6 Tools for SOA enablement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.6.1 WebSphere Business Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.6.2 WebSphere Integration Developer . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.6.3 IBM Rational Software Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.6.4 WebSphere Developer for System z . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.7 Other considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.7.1 A successful business services architecture for SOA . . . . . . . . . . . . 56
© Copyright IBM Corp. 2006. All rights reserved.
iii
2.7.2
2.7.3
2.7.4
2.7.5
Patterns for SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
SOA security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
SOA governance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Management and monitoring an SOA environment . . . . . . . . . . . . . 63
Chapter 3. WebSphere Process Server and WebSphere Enterprise Service
Bus on z/OS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.1 Motivation for an SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.2 WebSphere Process Server for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.2.1 Architectural overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.2.2 Service components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.2.3 Supporting services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.2.4 SOA core. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.2.5 Component organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.2.6 Topologies for WebSphere Process Server for z/OS . . . . . . . . . . . . 78
3.3 WebSphere Enterprise Service Bus for z/OS . . . . . . . . . . . . . . . . . . . . . . 81
3.3.1 Architectural overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.3.2 Topologies for WebSphere Enterprise Service Bus for z/OS . . . . . . 87
3.4 WebSphere Process Server and WebSphere Enterprise Service Bus for z/OS
at the core of your business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
3.4.1 WebSphere Application Server for z/OS advantages . . . . . . . . . . . . 89
3.4.2 z/OS advantages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Chapter 4. Operational considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.1 Installing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.1.1 Prerequisites and packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.1.2 Installation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.2 Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.2.1 The Administrative Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.2.2 Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.2.3 Administration on an SOA level . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Chapter 5. Qualities of service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.1.1 Security technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.1.2 z/OS-specific security capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5.1.3 SCA security and message level security . . . . . . . . . . . . . . . . . . . . 123
5.1.4 WebSphere Process Server and WebSphere Enterprise Service Bus for
z/OS security overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.2 Transactionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.2.1 Transaction requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.2.2 z/OS transactional services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.2.3 SCA transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.2.4 Compensation and transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
iv
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
5.2.5 Fault handling in transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Chapter 6. Integration with backend systems . . . . . . . . . . . . . . . . . . . . . 131
6.1 Integration approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
6.1.1 The bottom-up approach to integration . . . . . . . . . . . . . . . . . . . . . . 132
6.1.2 The top-down approach to integration . . . . . . . . . . . . . . . . . . . . . . 134
6.1.3 The meet-in-the-middle approach to integration . . . . . . . . . . . . . . . 135
6.2 Enabling your core applications for reuse . . . . . . . . . . . . . . . . . . . . . . . . 139
6.2.1 Service enablement using the J2EE Connector Architecture . . . . . 139
6.2.2 Service enablement of core systems . . . . . . . . . . . . . . . . . . . . . . . 143
Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Contents
v
vi
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.
© Copyright IBM Corp. 2006. All rights reserved.
vii
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
developerWorks®
eServer™
z/OS®
z/VM®
z/VSE™
zSeries®
z9™
Cloudscape™
CICS®
DataPower®
Distributed Relational Database
Architecture™
DB2 Universal Database™
DB2®
DRDA®
IBM®
IMS™
MVS™
OMEGAMON®
OS/390®
Parallel Sysplex®
Rational®
Redbooks™
Redbooks (logo)
RACF®
SecureWay®
System z™
System z9™
Tivoli®
WebSphere®
™
The following terms are trademarks of other companies:
EJB, Java, JavaBeans, JDBC, JMX, JVM, J2EE, and all Java-based trademarks are trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.
Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States,
other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
viii
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Preface
System z™ and z/OS® continue to provide the highest levels of availability,
scalability, and reliability. System z also continues to host a wide variety of
mission-critical data and application logic. So, where better to host advanced
service-oriented architecture (SOA) features, such as business processes and
the Enterprise Service Bus (ESB), than z/OS?
This IBM® Redpaper describes how WebSphere Process Server V6 for z/OS
(used primarily to run business processes) and WebSphere Enterprise Service
Bus V6 for z/OS (used to implement an ESB) benefit from the strengths of
System z and z/OS.
The Redpaper begins by defining how SOA is emerging on the mainframe and
provides detailed product descriptions of WebSphere Process Server and
WebSphere Enterprise Service Bus. It then describes installation and
administration features, operational considerations such as security, and finally
describes how these products can integrate with other mission-critical
applications that are running in other subsystems on z/OS.
The team that wrote this Redpaper
This Redpaper was produced by a team of specialists from around the world
working at the International Technical Support Organization (ITSO), Raleigh
Center.
Martin Keen is a Senior IT Specialist at the ITSO, Raleigh Center. He writes
extensively about WebSphere® products, SOA, and Patterns for e-business. He
also teaches IBM classes worldwide about WebSphere, SOA, and business
process management. Before joining the ITSO, Martin worked in the EMEA
WebSphere Lab Services team in Hursley, UK. Martin holds a bachelor’s degree
in Computer Studies from Southampton Institute of Higher Education.
Niall Betteridge is a Senior IT Architect with IBM Australia and is currently the
Client IT Architect for a major financial institution in Sydney. He has 12 years of
experience with IBM in Europe and Asia Pacific, successfully architecting and
implementing enterprise-wide solutions for major financial, manufacturing, and
public sector clients. He covers strategic enterprise, component-based, and
service-orientated architectures and is a strong advocate of model-driven
solutions. Niall holds an MSc in Information Systems from Leeds Metropolitan
University.
© Copyright IBM Corp. 2006. All rights reserved.
ix
Diego Cardalliaguet is a Senior IT Specialist for the IBM Software Group in IBM
Spain. He works for the System z group in WebSphere for z/OS technical sales.
His areas of expertise include WebSphere Application Server for z/OS and
Linux® for System z. He holds an MS degree in Theoretical Physics from the
University of Salamanca in Spain.
Andreas Groeschl is an IT Specialist in the IBM Software Group in IBM
Germany. His responsibility spans business integration and process integration
on z/OS as well as WebSphere Application Server and Composite Application
Management for z/OS. He holds a diploma in IT and a Bachelor of Science of the
open university in London.
Figure 0-1 The IBM Redpaper team (left to right): Martin, Diego, Andreas, and Niall
Thanks also to the following people for their contributions to this project:
Eric Herness
IBM Software Group, Application and Integration Middleware Software
WebSphere Business Integration, Chief Architect
David Bonaccorsi
IBM Software Group, Application and Integration Middleware Software Program
Director
Warren Fung
IBM Software Group, Application and Integration Middleware Software Instructor,
WebSphere Education
Jack Woodson
IBM Software Services for WebSphere
Michael Poirier
Product Architect, WebSphere Process Server
x
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Isabel Arnold
IBM Technical Sales CICS® and WebSphere on z/OS
Dirk Ziesemann
IBM Germany Team Leader Technical Sales WebSphere on z/OS
Ron Lotter
WebSphere Enablement Team
Stephen Matulevich
IBM Washington Systems Center
Eugene Kuehlthau
IBM Advanced Technical Support
Geoffrey Reilly
IBM Information Developer, Software Group
Become a published author
Join us for a two- to six-week residency program! Help write an IBM Redbook
dealing with specific products or solutions, while getting hands-on experience
with leading-edge technologies. You'll have the opportunity to team with IBM
technical professionals, Business Partners, and Clients.
Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you'll develop a network of contacts in IBM development labs, and
increase your productivity and marketability.
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
Preface
xi
Comments welcome
Your comments are important to us!
We want our papers to be as helpful as possible. Send us your comments about
this Redpaper or other Redbooks™ in one of the following ways:
򐂰 Use the online Contact us review redbook form found at:
ibm.com/redbooks
򐂰 Send your comments in an e-mail to:
redbooks@us.ibm.com
򐂰 Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
xii
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
1
Chapter 1.
Welcome to this Redpaper
This chapter provides an overview for this Redpaper and some guidelines for
how to read it.
© Copyright IBM Corp. 2006. All rights reserved.
1
1.1 An introduction to this document
A warm welcome to this Redpaper, from the IBM Redpaper team. We all
assembled for three intense weeks in Raleigh, North Carolina, to put together
this resource. We hope you find it a useful read.
The content of this Redpaper is aimed at IT architects, integration developers,
and systems programmers who want to understand more about how WebSphere
Process Server and WebSphere Enterprise Service Bus are suitable subsystems
for running service-oriented architecture (SOA) implementations on System z.
For this Redpaper, we approach these two products from many different angles.
This Redpaper provides:
򐂰 A description of SOA and related technologies, with a focus on SOA
implementations on System z.
򐂰 A discussion of the role WebSphere Process Server and WebSphere
Enterprise Service Bus play in an SOA solution.
򐂰 A technical introduction to the capabilities of WebSphere Process Server and
WebSphere Enterprise Service Bus.
򐂰 A description of the advantages of running WebSphere Process Server and
WebSphere Enterprise Service Bus on z/OS.
򐂰 An overview of installation and administration tasks.
򐂰 A description of security and transactionality qualities of service that are
offered by WebSphere Process Server and WebSphere Enterprise Service
Bus.
򐂰 Coverage on how to integrate WebSphere Process Server and WebSphere
Enterprise Service Bus with applications that are running on System z in other
subsystems.
Because of the brevity of this document, we do not include detailed, step-by-step
guides on how to achieve these tasks here. Instead, this Redpaper provides a
technical overview of WebSphere Process Server and WebSphere Enterprise
Service Bus on z/OS with the goal of encouraging you to experiment with these
products.
2
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
1.2 How to read this Redpaper
We have organized this Redpaper into a logical order so that you can read it
cover-to-cover. However, if you are not able to read this Redpaper in its entirely,
this section will help you locate the chapters of most relevance to you.
This Redpaper includes the following chapters:
򐂰 Chapter 2, “Key technologies of SOA implementation on System z” on page 5
Introduces the key technologies relating to SOA implementations on
System z and z/OS, including Service Component Architecture (SCA) and
Web services. Provides a high-level overview of WebSphere Process Server
and WebSphere Enterprise Service Bus for z/OS and the related tools.
򐂰 Chapter 3, “WebSphere Process Server and WebSphere Enterprise Service
Bus on z/OS” on page 65
Provides an in-depth look at WebSphere Process Server and WebSphere
Enterprise Service Bus for z/OS. In addition, focuses on the advantages of
running these products on z/OS.
򐂰 Chapter 4, “Operational considerations” on page 99
Outlines the installation and administration tasks for WebSphere Process
Server and WebSphere Enterprise Service Bus for z/OS.
򐂰 Chapter 5, “Qualities of service” on page 119
Describes the security and transaction capabilities of WebSphere Process
Server and WebSphere Enterprise Service Bus on z/OS.
򐂰 Chapter 6, “Integration with backend systems” on page 131
Describes approaches for integrating WebSphere Process Server and
WebSphere Enterprise Service Bus on z/OS with other subsystems that are
running on z/OS. Uses CICS Transaction Server as an example.
Chapter 1. Welcome to this Redpaper
3
4
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
2
Chapter 2.
Key technologies of SOA
implementation on System z
This chapter introduces some of the key technologies that relate to an SOA
implementation on System z, specifically those that relate to WebSphere
Process Server and WebSphere Enterprise Service Bus for z/OS.
It includes the following topics:
Using mainframes in today’s business environment
SOA on System z
Technology standards used for SOA enablement
Enterprise integration with IBM products
Overview of WebSphere Process Server and WebSphere Enterprise Service
Bus for z/OS
򐂰 Tools for SOA enablement
򐂰 Other considerations
򐂰
򐂰
򐂰
򐂰
򐂰
© Copyright IBM Corp. 2006. All rights reserved.
5
2.1 Using mainframes in today’s business environment
This section gives an overview on the use of mainframes in today’s fast changing
business environments.
2.1.1 Mainframes in use today
Mainframes play a vital and indelible role in the IT makeup of enterprise-sized
organizations worldwide. Today, they still perform most of the core, critical
business functions, and it is estimated that 70% of the world’s data resides on
such systems. Due to their inherit strengths and on-going value, organizations
are maintaining and, where appropriate, increasing mainframe usage, especially
as cost of ownership continues to fall with new pricing models and technology.
Gartner accordingly sees continued investment in the mainframe, and IBM
predicts that the number of transactions that run on such systems will double by
2009 thanks to the introduction of new technologies, some of which we discuss
in this Redpaper.
2.1.2 The challenges of mainframe technologies
Many mainframe applications in use today were developed mainly in the 1970s
and have since been modified several times in keeping with changing business
needs. This has often posed the following strategic and architectural issues:
1. How to minimize the risk of replacing aging and complex core systems, which
are absolutely vital to business operations, through decommission or
migration to new platforms?
2. How to introduce core transaction capability into the dynamic, real-time era
which sees higher service invocation volumes and complex distributed
computing — parameters and environments that core systems did not have to
cope with as little as three decades ago?
2.1.3 Adoption of SOA capabilities for the mainframe
This paper describes how, by adopting and implementing the principles of SOA
and through the use of WebSphere Process Server and WebSphere Enterprise
Service Bus, it is possible to use mainframe technologies to extend the life of
core applications that are hosted within z/OS and other environments.
This chapter describes how application architects can maximize reuse of
business functionality and enable IT departments to build new capabilities
dynamically that meet the requirements of fast changing business environments.
6
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
The business drivers are:
򐂰
򐂰
򐂰
򐂰
Business flexibility
Responsiveness
Cost effectiveness
Focus
Note: This paper does not focus extensively on the benefits that mainframes
bring to SOA because these are offered in The Value of the Mainframe in
Service Oriented Architecture, REDP-4152.
Our paper takes a more technical view by showing how mainframe usage for
SOA is best optimized using the z/OS platform with WebSphere Process
Server and WebSphere Enterprise Service Bus
2.2 SOA on System z
Service-oriented architecture (SOA) is an architecture that organizations and
their IT departments are adopting, but what is it? This section gives an overview
of SOA, the benefits it introduces, and its positioning on System z.
2.2.1 What is SOA and why adopt it
This section covers the growing use of SOA and attempts to explain what it is
and how organizations can benefit from adopting it.
An introduction to SOA
Rather than being a revolution, SOA is an evolution of best practices and
technologies that have gone before. It takes advantage of developments in
Internet-based technology and interoperability standards to offer unrivalled
business and IT benefits. There have been many definitions for SOA, some
clearer than others, but all lead themselves to the concept of loosely coupled
business services that are provided in an interoperable and technology agnostic
manner.
SOA is an integration architecture approach that is based on the concept of
services. The business and infrastructure functions that are required to build
distributed systems are provided as services that deliver application functions
individually or collectively to either user applications or to other services.
Chapter 2. Key technologies of SOA implementation on System z
7
Note: SOA, as its name implies, is an architecture that allows you to
encapsulate business logic and separate it from application logic. It is not a
formal specification. To create an SOA implementation, you need to use a
technology such as Web services or Service Component Architecture (SCA)
to make this architecture a reality.
Taking the definition of SOA a little deeper, you can view it from the following
perspectives:
򐂰 A set of business aligned IT services that support an organization’s business
goals and objectives
򐂰 A set of architectural principles that address characteristics such as
modularity, loose-coupling, and separation of functions
򐂰 An architectural style that requires a service provider, a service consumer,
and a service description
򐂰 A set of services that can be combined and choreographed to produce
composite enterprise scale services
򐂰 A programming model that comes complete with standards, tools, methods,
and technologies, such as Web services
By adopting an SOA approach and implementing it using supporting
technologies, companies can build flexible systems that implement changing
business processes quickly and can make extensive use of reusable
components.
8
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Figure 2-1 shows how services are invoked to support a particular business task
or process.
Specific Business
Task of Function
Business
View
Business Process
Business
Task 2
Input
Procedure
Output
Business
Task 1
Business
Task 3
Service is able
to attend one
Business Task
The Process Choreography Layer is
responsible for connecting the Services
providing support to the Business Process
Process Choreography Layer
Published Service
Z
Specific Application
Object Classes
Encapsulation
Service
Computer
Science
View
Result
Figure 2-1 Mapping services with business tasks or functions
Defining a service
SOA is an architectural approach to defining integration architectures that are
based on the concept of services. A service can be described as a function that
can be offered or provided to a consumer. This function can be an atomic
business function or part of a collection of business functions that are wired
together to form a process.
There are many additional aspects to a service that must also be considered in
the definition of a service within an SOA. The most commonly agreed-on aspects
of a service are that:
򐂰 Services encapsulate a reusable business function
򐂰 Services are defined by explicit, implementation-independent interfaces
򐂰 Services are invoked through communication protocols that stress location
transparency and interoperability
Chapter 2. Key technologies of SOA implementation on System z
9
Ideally, a service should be reusable and should be accessible by more than one
consuming application in the architecture. It is, therefore, important to get the
service description and reusability correct. For example, a service that offers a
calculation such as a home insurance quote could be requested by multiple
consumers inside the enterprise and by third parties — as long as the interfaces
of the component that offers the service are defined clearly.
Services can be invoked independently by either external or internal service
consumers to process simple functions or can be chained together to form more
complex functionality to devise new functionality quickly.
Clearly defined interfaces
The interface for the SOA should encapsulate only those aspects of process and
behavior that are used in the interaction between the service consumer and
provider. An explicit interface definition, or contract, binds a service consumer
with the provider. The interface should specify only the mutual behavior that is
required for the interaction and nothing about the actual implementation of the
consumer or provider.
This arrangement means that those system aspects where the consumer and
provider are hosted (their platforms) are independent of the interaction and are
free to change. This abstraction allows for flexible improvements to the
underlying IT infrastructure.
Communication protocols that stress location transparency
The SOA does not specify that the consumer need any specific protocol to have
access to a service. A key principle in SOA is that a service is not defined by the
communication protocol that it uses but instead, should be defined in a
protocol-independent way that allows different protocols to be used to access the
same service. Ideally, a service should only be defined once, through a service
interface, and should have many implementations with different access
protocols. This type of definition helps to increase the reusability of any service
definition.
10
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
2.2.2 The business and IT benefits of SOA
This section gives a concise view on the business and IT benefits that an
organization can gain from adopting an SOA.
Business benefits
Organizations will always seek out innovative means in business and IT to gain
competitive advantages. SOA allows the typically heterogeneous IT environment
of an enterprise to be agile and responsive to fast changing business conditions.
Some of the business advantages to be gained from SOA are as follows:
򐂰 The concept of components and reuse, as described in 2.2.4, “Service
Component Architecture” on page 17, allows organizations to increase the
speed at which they can implement new products and services. By
introducing new processes and data, changing existing reusable elements, or
recombining them quickly enables technical support and provisioning of new
products and services in the marketplace.
򐂰 The increased abstraction of business processes from implementation and
runtime concerns and constraints means that there are fewer technical
inhibitors that can slow down progress and change.
򐂰 The modularity and reuse of components means that services are highly
optimized to business needs.
򐂰 The ability to extract more from what is already there means that
organizations are able to introduce new capabilities that bring business
advantages. For example, applications that were once siloed can now work
together behind the scenes and can help shorten human-based processes
and tasks.
򐂰 The ability to make available repeatable and reusable services across the
enterprise means less duplication of functions and, therefore, reduced
instances of duplicated data such as customer details — the ability to improve
service quality and retain customers increases with more accurate
information.
Chapter 2. Key technologies of SOA implementation on System z
11
IT benefits
Because SOA is an approach that specifically aligns IT capabilities to business
drivers and needs, the distinction between what is an IT benefit as opposed to a
business benefit becomes somewhat blurred. Nevertheless, the IT benefits that
an organization can realize by implementing SOA are as follows:
򐂰 The adoption of open standards, inoperability, and component-based
development brings about long-term reductions in development costs and
on-going maintenance.
򐂰 The sharing of services and improved consistency reduces duplication of
once siloed IT functions and consequently consolidation of hardware and
software is made possible, thus reducing costs.
򐂰 The revival of core applications through SOA capabilities reduces the need to
replace such systems, thereby minimizing risk, disruption, and replacement
costs.
Gartner quotes the following benefits of SOA for IT:
SOA will shift the focus from tools and packaged suites to modular offerings
from multiple vendors that can be assembled and combined by a systems
integrator. By 2008, SOA will provide the basis for 80 percent of development
projects. By 2008, simple object database access plus service-oriented
business applications (SOBAs) will enable Type A organizations to increase
code reuse by more than 100 percent. The distinction between software
integrators and vendors will blur because packaged applications will be
broken up and delivered as SOBAs. In 2006, more than 60 percent of the
$527 billion IT professional services market will be based on the exploitation
of Web services standards and technology.
Gartner also says “SOA shifts developer focus from software to business
functions, thereby transforming installed software from an inhibitor to a facilitator
of rapid business change.”
For more information, see Positions on the Five Hottest IT Topics and Trends in
2005, which is available at:
http://www.gartner.com
12
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Alternative ways of requesting services
This section describes the different technologies that you can use to request
services. Figure 2-2 illustrates the three methods to invoke services. These are:
1. Direct invocation of a provider and the resulting reply with service outcomes
(a point-to-point option). For example, the consumer has predefined details of
the service and where to obtain it. This option is not ideal because it means
service consumers often need to be modified whenever the service provider
interface changes.
2. A service request query is put to a service directory and is provided with
details on a particular service. Following the request, the consumer then
invokes the service and obtains results. This is the most common method of
requesting a service and is used by many organization using an
enterprise-wide registry.
3. A more sophisticated adoption of the second method that shows a service
broker calling out to various service directories
1
Service Request
Service Response
2
Service Query
Service
Registry
Retrieve Service Details
Contract Details
Service Request
Service
Consumer
Service
Provider
Service Response
3
Service Query
Retrieve Service
Details
Service
Broker
Service
Registry
Service
Registry
Service
Registry
Service Request
Service Response
Figure 2-2 Three methods of invoking services
Chapter 2. Key technologies of SOA implementation on System z
13
Figure 2-3 shows the high-level steps of the second method.
Service Registry &
Repository
FIND
2
1
Service
Consumer
PUBLISH
Service
Provider
3
BIND
Figure 2-3 Typical implementation of service interaction in an SOA
Figure 2-3 shows three stages:
1. Where it is decided to expose certain functionality that is provided by a
particular application for others to consume, the details are published and
stored within a service directory. The service itself is defined within the
interface of the component.
2. A service consumer seeking an appropriate service makes a query against
the registry. In response, the registry gives details of where to find such a
service
3. The consumer then creates a message to be sent to the provider, transported
via HTTP for instance, and gives details to the provider
14
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
2.2.3 Service granularity and choreography
As well as the different ways of obtaining services, we also have the different
types of services and the different levels of granularity found in service
composition and hierarchies.
Many descriptions of SOA refer to large-grained services. However, powerful
examples of successful, reusable, fine-grained services exist. For example,
getBalance is a useful service that is not large grained. More realistically, there
are many useful levels of service granularity in most SOAs:
򐂰 Technical functions (such as logging)
򐂰 Business functions (such as getBalance)
򐂰 Business transactions (such as openAccount)
򐂰 Business processes (such as applyForMortgage)
Some degree of choreography or aggregation is required between each
granularity level. It is unlikely that all organizations share identical definitions of
granularity, but each undoubtedly finds it beneficial to define their own. At each
level of granularity, it is important that service definitions encapsulate function
well enough that it is reusable.
Figure 2-4 shows an example of interactions between services of various
granularities.
Chapter 2. Key technologies of SOA implementation on System z
15
Submit
Self-service
application
4
Public createCustomerRecord {
Check and validate parameters...
Request a unique ID
Check postcode against address
Store and commit data
}
1
Implementation
Customer
management
system
Submit
createCustomerRecord
Service Infrastructure
2
a
c
Steps a and b
omitted for clarity
b
Authenticate and
authorize
Authorization and
authentication
services
Steps a and b
omitted for clarity
Check Postcode
Log
createMortgageAccount
Log
External
service
3
Service choreographer
1
9
createCustomerRecord
Figure 2-4 Service granularity and choreography
The interactions between services of various granularities in Figure 2-4 are:
1. A user submits a request to a self-service application to create a mortgage
account. The self-service application submits the business process service
request (createMortgageAccount) through the service infrastructure to a
service choreographer component, the purpose of which is to choreograph
business transaction services into business process services.
2. When the service infrastructure receives the request for
createMortgageAccount, the service infrastructure first invokes authentication
and authorization technical function services to ensure that the request is
valid, then a log technical function service, and, finally,
createMortgageAccount in the service choreographer.
16
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
3. The service choreographer executes createMortgageAccount. If the request
is valid, then, after the other process elements are finished, the
choreographer invokes the createCustomerRecord business transaction
service through the service infrastructure to store the details of the new
customer. (Before doing this, it might already have invoked
storeMortgageDetails.)
4. In the implementation of the createCustomerRecord service, it is necessary to
validate the information for the new customer. Part of this validation is
checking whether the post code and address match. To do this, a
CheckPostCode business function service is invoked through the service
infrastructure.
To summarize, three aggregations or choreographies are performed by distinct
components for distinct granularity levels:
򐂰 Service choreographer
Choreographs business transaction services into higher level business
process services.
򐂰 Service Infrastructure
Choreographs technical function services to control the invocation of
business process services, business transaction services, and business
function services (this might be an Enterprise Service Bus).
򐂰 Individual application components
Responsible for invoking business function services to implement business
transaction services.
Of course, this is just one hypothetical example. Real organizations must
formulate their own definitions.
2.2.4 Service Component Architecture
Service Component Architecture (SCA) is a set of specifications defined and
agreed between BEA, IBM, IONA, Oracle, and SAP that describe a model for
building applications and systems that implement an SOA. SCA offers an
approach for defining the interfaces, implementation and references in a
technology neutral manner, that allows for focus on the business need prior to
technology and product specific implementation.
Note: SCA is the foundation upon which the WebSphere Process Server and
WebSphere Enterprise Service Bus products are based.
Chapter 2. Key technologies of SOA implementation on System z
17
At its core, SCA provides an abstracted J2EE™ based implementation that
involves stateless session EJBs, Web services, Plain Old Java™ Objects
(POJOs), WS-BPEL processes, database access and Enterprise Information
System (EIS) access.
SCA is also a universal model for business services that publish or operate on
business data and Service Data Objects (SDO) provide the universal model for
this. SDOs represent the business data that forms the parameters and return
values of services, providing uniform access to business data to complement the
uniform access to business services offered by SCA. For more information, see
“Service Data Objects” on page 33.
SCA supports service implementations written using any one of many
programming languages, including conventional object-oriented and procedural
languages such as Java, PHP, C++, COBOL, and XML-centric languages, such
as WS-BPEL and XSLT, and also declarative languages such as SQL and
XQuery. SCA also supports a range of programming styles, including
asynchronous and message-oriented styles, in addition to the synchronous
call-and-return style.
SCA supports bindings to a wide range of access mechanisms used to invoke
services. These include Web services, messaging systems and CORBA IIOP.
Bindings are handled declaratively and are independent of the implementation
code. Infrastructure capabilities, such as security, transactions and the use of
reliable messaging are also handled declaratively and are separated from the
implementation code. SCA defines the usage of infrastructure capabilities
through the use of policies, which are designed to simplify the mechanism by
which the capabilities are applied to business systems.
18
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Figure 2-5 shows the following main elements of an SCA component:
򐂰 Interface
򐂰 Implementation
򐂰 Reference
Component
Java
Java
WSDL
Port Type
R
I
Interface
Reference
WSDL
Port Type
Implementation
Java
WS_BPEL
State
Machine
Business
Rule
Human
Task
Selector
Mediation
Flow
Implementation Types
Figure 2-5 SCA component main elements
The SCA approach divides up the steps of developing SOA capability into two
major parts:
򐂰 Implementing components which provide services and consume other
services
򐂰 Assembling sets of components to build business applications through the
wiring of service references to service interfaces.
Figure 2-6 shows an overview of a SCA implementation.
Chapter 2. Key technologies of SOA implementation on System z
19
Figure 2-6 SCA implementation overview
At the time of writing, the current SCA specifications are published at a version
0.9 level, indicating that the specifications are not in their final form. For more
information, we advise that you refer to the following:
http://www.ibm.com/developerworks/library/specification/ws-sca/
The technologies used for implementing SCA are described in 2.3, “Technology
standards used for SOA enablement” on page 24.
2.2.5 System z and why is it appropriate for SOA
This section gives an overview of System z and the benefits to be gained from
implementing SOA capabilities within a z/OS environment. We cover the
reasoning and benefits that we describe in this overview in more detail in 3.4.2,
“z/OS advantages” on page 91.
System z
IBM eServer™ System z9™ (formerly IBM eServer zSeries®) is built on more
than 40 years of industry leadership in mainframes. It uses a modular multi-book
design that supports one to four books per server. Multiple features such as
redundant I/O interconnect (RII) help avoid unplanned interruptions and outages.
By increasing secure transaction throughput (SSL), System z9 can improve
responsiveness while strengthening security through enhanced encryption and
hashing algorithms.
20
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
System z contains specialized engines such as z9 Application Assist Processor
(zAAP), z9 Integrated Information Processor (zIIP), Integrated Facility for Linux
(IFL), and Internal Coupling Facility (ICF), which can all be used for your
advantage. The virtualization and intelligent management features of System z9
109 help reduce management complexity and can facilitate a more efficient use
of system resources.
z/OS
IBM System z mainframes are supported by a multitude of operating systems,
such as z/OS, z/OS.e, z/VSE™, z/VM®, TPF, and Linux on System z. The
flagship operating system of this group is z/OS. z/OS, with its roots in MVS™ and
OS/390®, is the flagship mainframe operating system based on the 64-bit
z/Architecture. It is designed to deliver the high qualities of service for enterprise
transactions and data, making it appropriate for the larger enterprise.
Some highlights of z/OS v1.7 include the z/OS Workload Manager, which helps
balance resources, and Intelligent Resource Director (IRD), which extends
Workload Manager and makes it possible to manage resources dynamically
across multiple logical partitions. z/OS Parallel Sysplex® technology allows you
to balance workloads across multiple servers (up to 32) and is designed to
provide near continuous availability.
Why have an SOA framework on z/OS
In a sense, the mainframe environment has always led itself to the concept of
SOA because it regards all the resources within as providing services.
Resources specifically for SOA would be those that provide SOA capabilities
such as the Enterprise Service Bus (ESB), Process Management engines, and
supporting components such as a base J2EE application server and databases.
To offer the power of System z for SOA, IBM has developed specific z/OS
versions of its SOA product suite that is built upon WebSphere Application
Server V6 for z/OS. WebSphere Process Sever and WebSphere Enterprise
Service Bus are z/OS enabled, as are supporting components such as DB2® for
z/OS V8. This offers a clean and contained architecture within an z/OS
environment, one based upon open and interoperability standards.
The advantages of using System z and z/OS for SOA can be seen in three broad
categories:
򐂰 Quality of service
򐂰 Core system transaction capabilities for SOA
򐂰 Cost of ownership
Chapter 2. Key technologies of SOA implementation on System z
21
Quality of service
An SOA framework that incorporates an ESB and Business Process
Management (BPM) capabilities exploits well proven System z features such as
high scalability, availability, reliability, and security. System z clustering is
provided through Parallel Sysplex technology and workload management by
zWLM to offer:
򐂰 Less than five minutes downtime per year
򐂰 99.999% availability at the application level
System z has built upon four decades of development and collaboration to offer
unparalleled security in both its hardware and z/OS operating system. In
addition, the introduction of virtualization for z/OS helps to decouple actual
physical resources from users and services, bringing an additional layer of
protection. For more details about security on System z, refer to:
http://www.ibm.com/servers/eserver/zseries/security/features.html
Core system transaction capabilities for SOA
The source of most services that service consumers call upon is most likely core
systems such as CICS and IMS™ transactions. These core systems themselves
can actually be consumers as well as providers of services. The positioning of
these systems within a System z environment means that performance is
enhanced because of less network traffic and, in the case of z/OS, the
HiperSocket technology is leveraged. To facilitate connections to CICS and IMS
for a SOA architecture, the CICS Transaction Gateway and IMS SOAP Gateway
Version 9.1 are offered.
Web services can be developed with IBM WebSphere Developer for zSeries
tooling to generate Web services artifacts easily. For example, it generates a
Web Services Description Language (WSDL) file from COBOL copybooks of an
IMS application. (See 2.6.4, “WebSphere Developer for System z” on page 55).
Figure 2-7 shows the different ways to connect to IMS and how WebSphere
Enterprise Service Bus can route SOAP messages to the IMS SOAP Gateway.
22
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
IMS Web Services Connectivity Solutions
W
S
D
L
IMS Connect/
IMS Connect
Java Client
MQ to
IMS Bridge
W
S
D
L
JMS to
MQ
WebSphere ESB
W
S
D
L
W
S
D
L
IMS Distributed JDBC
WebSphere ESB
Mediation
Module
WebSphere II CF
Mediation
Module
WebSphere ESB
Java
Component
EJB/Bean
IMS SOAP Gateway –
Technology Preview
IMS
Connector for
Java
Mediation
Module
W
S
D
L
WAS
MQ
WebSphere
BCF JDBC
Client
IMS
Distributed
JDBC
IMS SOAP Gateway
TCP/IP
Queues
TCP/IP
RMI/
IIOP
TCP/IP
O
T
M
A
IMS
Connect
MQ
IMS
Appls.
IMS
DB
O
T
M
A
MQ-IMS
Bridge
(XCF)
IMS
Appls.
IMS
DB
WebSphere II
CF
D
R
A
IMS
DB
IMS
DB
WAS zOS
+ JDBC
Driver
O
D
B
A
IMS
DB
IMS
DB
IMS
Connect
O
T
M
A
IMS
Appls.
IMS
DB
Figure 2-7 IMS services connectivity options
Cost of ownership
As demand for computer usage increases year-on-year, organizations have
tended to introduce new boxes, systems, and applications to their widely
heterogeneous and distributed IT environments. Thus, managing these
distributed environments can introduce the following hidden costs:
򐂰
򐂰
򐂰
򐂰
򐂰
Increased complexity
Spiraling resource costs
Increased downtime costs
Suboptimized use of resources
Licensing costs
The Wall Street journal gives an interesting view:
Distributed server farms today generate as much as 3,800 watts per square
foot, compared to 250 watts per square foot in 1992, with thousands of dollars
of cooling capacity needed for each server. Assuming 1,000 distributed
servers producing 400 watts each, the electricity bill could hit more than USD
35,000 per month alone. By comparison, a single mainframe z9 generates
312 watts per square foot – one tenth the amount.
Chapter 2. Key technologies of SOA implementation on System z
23
The centralized architecture of the mainframe has always helped avoid such
issues, but initial purchase costs and operating costs were high. Recent
developments in new technology for System z help to reduce total operating cost
(TOC), as follows:
򐂰 Virtualization
Virtualization, which allows a single server or platform to support hundreds of
concurrent applications and share data and hardware resources across
heterogeneous environments, was invented by mainframes more than 35
years ago. Today, it is highly advantageous for enterprises that are looking for
ways to simplify their IT infrastructures and to reduce complexity and costs.
򐂰 System z Application Assist Processor (zAAP)
To help lower costs, IBM has introduced separate processing engines to
tackle a collection of mainframe workload types. These engines can free your
mainframe CPU for other tasks while lowering related capacity charges. The
System z Application Assist Processor (zAAP) engine, released in 2005,
reduces costs by processing Java-based application workloads.
򐂰 System z Integrated Information Processor (zIIP) engine
DB2 works in concert with z/OS to tackle workloads that originate on
distributed platforms (through DRDA® via TCP/IP) and access DB2 data
running on the mainframe. Together, DB2 and zIIP help improve resource
optimization for eligible workloads, including those from SAP or other ERP
applications, along with CRM and business intelligence initiatives. A zIIP
engine can be added for a one-time cost, then it can process up to 40% of
such tasks with no additional software or capacity charges.
2.3 Technology standards used for SOA enablement
This section gives a description of the main technologies that are used to bring
about SOA based capabilities. These technologies are based upon principles set
out by the SCA that we describe in 2.2.4, “Service Component Architecture” on
page 17. Although Web services are seen as intrinsically part of SOA, there are
alternative technologies that you can use to provide the same outcomes. We
discuss these alternatives also.
2.3.1 Web services
Web services are fast becoming the standard for basic SOA implementation.
More advanced SOA based requirements are seeing Web services used in
collaboration with SCA based capabilities, such as an ESB in meeting consumer
requirements. Web services take advantage of existing open-standard Web
24
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
technologies, such as XML, Uniform Resource Locator (URL), and Hypertext
Transfer Protocol (HTTP), and are themselves a set of standards that facilitates
open system-to-system communication.
By adhering to Web services standards applications, which are based invariably
upon differentiating platforms and technologies, can cooperate through well
defined interfaces. Web services follow the SOA philosophy of loose coupling
between service consumers and providers. Figure 2-8 illustrates how
loose-coupling is maintained within the Web services interaction model.
UDDI or WSIL: service registry
WSDL: service description
SOAP: service invocation
Service
Registry
Maintains repository of
business services
defined using WSDL
1 Publish
2 Find
Business functions defined in
WSDL and published to the
Services registry
Business functions
described in WSDL
within Registry
3 Bind
Service
Consumer
Business functions
using SOAP
Service
Provider
Figure 2-8 Web services invocation model
The interaction shown in Figure 2-8 works as follows:
1. The service provider publishes WSDL data that defines its interface and
location to a service registry. See the definition of “Web Services Description
Language” on page 26.
2. The service consumer contacts the service registry to obtain a reference to a
service provider.
3. The service consumer, having obtained the location of the service provider,
makes calls on the service provider.
Chapter 2. Key technologies of SOA implementation on System z
25
Basic Web services support provides three simple usage models:
򐂰 One-way usage scenario
A Web services message is sent from a consumer to a provider, and no
response message is expected.
򐂰 Synchronous request/response usage scenario
A Web services message is sent from a consumer to a provider, and a
response message is expected.
򐂰 Basic callback usage scenario
A Web service message is sent from a consumer to a provider using the
2-way invocation model, but the response is treated only as an
acknowledgement that the request has been received. The provider then
responds by using a Web service callback to the consumer.
Other Web service standards are built upon these basic standards and
invocation models to provide higher level functions and qualities of service.
Maturity of Web services protocols and specifications
As the world of Web services becomes increasingly popular, each aspect of the
Web services model, or stack, is broken down into elements that address
different protocols within the stack. Specifications for each are drawn up, with
some approved and others proposed. The following link provides details on the
positioning of the Web services stack:
http://roadmap.cbdiforum.com/reports/protocols/
Web Services Description Language
Web Services Description Language (WSDL) is an XML-based interface
definition language that separates function from implementation and enables
design by contract as recommended by SOA.
WSDL descriptions contain:
򐂰 A port type (the functional and data description of the operations that are
available in a Web service)
򐂰 A binding (that provides instructions for interacting with the Web service
through specific protocols, such as SOAP over HTTP)
򐂰 A port (that provides a specific address through which a Web service can be
invoked using a specific protocol binding)
Commonly, these aspects are defined in three separate WSDL files, each
importing the others.
26
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
The value of WSDL is that it enables development tooling and middleware for
any platform and language to understand service operations and invocation
mechanisms. For example, given the WSDL interface to a service that is
implemented in Java, running in a WebSphere environment, and offering
invocation through HTTP, a developer working in the Microsoft® .NET platform
can import the WSDL and easily application code to invoke the service generate.
The WSDL specification is extensible and provides additional aspects of service
interactions to be specified, such as security and transactionality.
The following link provides details on the WSDL V2.0 specification:
http://www.w3.org/TR/wsdl20/
Web Services-Business Process Execution Language
Web Services-Business Process Execution Language (WS-BPEL) provides a
means to specify business processes and interaction protocols formally at
runtime. It provides a language for the formal specification of business processes
and business interaction protocols. By doing so, it extends the Web services
interaction model and enables it to support business transactions. WS-BPEL
defines an interoperable integration model that facilitates the expansion of
automated process integration in both the intra-corporate and the
business-to-business spaces.
WebSphere Process Server has a process engine that executes WS-BPEL
based processes.
WS-BPEL V2.0 is the current specification. You can find more details about
WS-BPEL on the Web at:
http://www-128.ibm.com/developerworks/library/specification/ws-bpel/
Web Services Inspection Language
Web Services Inspection Language (WSIL) is an XML-based format used to
facilitate the discovery and aggregation of Web services in a simple and
extensible form. Its purpose is similar to that of the UDDI concept, but rather than
being a competitor to UDDI, it can compliment it as a simpler alternative. WSIL
enables a service consumer to inspect directly the services offered by a
provider. For more details refer to:
http://www-128.ibm.com/developerworks/webservices/library/
ws-wsilover/
Chapter 2. Key technologies of SOA implementation on System z
27
SOAP
SOAP is an XML-based format for constructing messages in a
transport-independent way and a standard on how the message should be
handled. SOAP messages consist of an envelope that contains a header and a
body. It also defines a mechanism for indicating and communicating problems
that occurred while processing the message, which are known as SOAP faults.
The headers section of a SOAP message is extensible and can contain many
different headers that are defined by different schemas. The extra headers can
be used to modify the behavior of the middleware infrastructure. The body
section contains the content of the SOAP message. When used by Web
services, the SOAP body contains XML-formatted data. This data is specified in
the WSDL that describes the Web service.
The most common transport that is used to communicate SOAP messages is
HTTP. This is expected because Web services are designed to use Web
technologies. However, SOAP can also be communicated using Java Message
Services (JMS) as a transport. Although using JMS provides a more reliable
transport mechanism, it is not an open standard, requires extra and potentially
expensive investment, and does not interoperate as easily as SOAP over HTTP.
The SOAP version 1.1 and 1.2 specifications are available from the W3C at:
http://www.w3.org/TR/soap/
Universal Description, Discovery, Integration
Universal Description, Discovery, Integration (UDDI) servers act as a directory of
available services and service providers. You can use SOAP to query UDDI to
find the locations of WSDL definitions of services, or you can perform the search
through a user interface at design or development time. The original UDDI
classification was based on a U.S. government taxonomy of businesses. Recent
versions of the UDDI specification have added support for custom taxonomies.
You can find the UDDI specification at:
http://www.uddi.org/specification.html
WS-Security
The Web Services Security protocol, WS-Security V1.1, has been accepted as
an OASIS standard. Specifically, WS-Security describes enhancements to the
existing SOAP messaging to provide quality of protection through the application
of message integrity, message confidentiality, and single message
authentication to SOAP messages. Additionally, WS-Security describes how to
encode binary security tokens and attach them to SOAP messages. You can find
the WS-Security specification at:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
28
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
The Enterprise Service Bus
The Enterprise Service Bus (ESB) is an important architectural element in an
SOA. When organizations integrate various systems on different platforms using
different protocols, it becomes vital to have in place a intelligent, distributed,
transactional and messaging layer that binds diverse services and data. This is
the responsibility of the ESB.
Broken down, the responsibilities of the ESB are:
򐂰 Routing of messages between services
򐂰 converting transport protocols between consumer and provider (where
necessary)
򐂰 Transforming requests between consumer and provider
򐂰 Handling of business events from disparate sources
Figure 2-9 shows how the ESB replaces direct connections between service
consumers and providers with a bus architecture.
Direct Connection
Service
Consumer
Service
Provider
Service
Consumer
Service
Provider
Service
Consumer
Service
Provider
Enterprise Service Bus Connections
Service
Consumer
Service
Consumer
Service
Consumer
Service
Provider
ESB
Service
Provider
Service
Provider
Figure 2-9 Direct connection and central hub integration styles
Chapter 2. Key technologies of SOA implementation on System z
29
Using an ESB to implement an SOA has a number of advantages. In an SOA,
services should, by definition, be reusable by a number of different consumers,
so that the benefits of reduced connections are achieved. In addition the ESB:
򐂰 Supports high volumes of individual interactions.
򐂰 Supports more established integration styles, such as message-oriented and
event-driven integration, to extend the reach of the SOA. The ESB should
allow applications to be SOA-enabled, either directly or through the use of
adapters.
򐂰 Supports centralization of enterprise-level qualities of service and
manageability requirements into the hub.
Services discovery and management
A successful SOA architecture is one that meets required business flexibility by
providing a well defined and managed set of business services. A services
registry and repository helps to maintain and to manage the business services. It
assists with the publication, discovery, subscription, and governance of these
services. The registry component helps record the definition of the services
(what they offer) and where they are located. In addition, the repository covers
details such as how the services used, by whom, and why.
If such capabilities are not in place, it is highly unlikely that organizations will get
the most out of investments in SOA because the services will be poorly
implemented and managed with low reuse and association with other services.
Figure 2-10 shows how a services registry and repository can benefit the SOA
life cycle from the definition and introduction of the services through ongoing
maintenance and monitoring.
30
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Service
Development
Lifecycle
Model
Service Endpoint
Registries /
Repositories
Services Registry and Repository
Build
Discover
Assemble
Change and
Release
Management
Mediate
Operational
Efficiency and
Resilience
Bind
Runtime Integration
Test
Manage
Deploy
Figure 2-10 Positioning of a services registry and repository
Figure 2-11 illustrates how a services registry and repository are called upon in
runtime to deal with a service request.
3
Service Registry &
Repository
Service Registry &
Repository
2
4
1
Mediation Module
5
Message
Enterprise Service Bus
Service
Service
6
Figure 2-11 Runtime selection and invocation interactions
The steps shown in Figure 2-11 are as follows:
1. The ESB receives a message (request)
2. A selection mediation is invoked within the ESB
3. The mediation receives the service description for the requested operation
from the service registry and repository
Chapter 2. Key technologies of SOA implementation on System z
31
4. The mediation receives service descriptions from candidate providers
5. The mediation executes a match to identify the most suitable service
6. The inbound message is transformed and routed to the selected endpoint
Alternative technologies to Web services used for SOA
Web services should not be seen as the only option for a SOA. The Web
services stack is still maturing. For reliable delivering of messages, you should
consider options such as the following:
򐂰 Message-orientated middleware with WebSphere MQ
Messaging and queuing has been in existence for over ten years, providing a
reliable, fast transport mechanism for passing data between applications.
Many IBM customers have adopted WebSphere MQ as a transport to call
remote functions on separate systems and in fact WebSphere MQ can be
used for transport of Web services SOAP messages.
򐂰 JMS
Java Messaging Service (JMS) is a cross platform Java API for accessing
message-orientated middleware. The JMS specification defines a set of
message types and APIs for sending and receiving those messages to and
from destinations. With J2EE v1.4, the JMS specification is upgraded to v1.1,
which includes support for domain neutral messaging.
򐂰 CORBA
The Common Object Request Broker Architecture (CORBA) has long been a
popular distributed object mechanism and is, in terms of principles and
philosophy, the basis for much of what is seen in SOA today.
The Object Request Broker is responsible for all of the mechanisms that are
required to find object implementations for a request, to prepare the object
implementation to receive the request, and to communicate the data making
up the request. The interface the client sees is completely independent of
where the object is located, which programming language it is implemented
in, or any other aspect that is not reflected in the object’s interface.
򐂰 The IIOP, RPC, and RMI protocols
Internet Object Request Broker Protocol (IIOP): This protocol makes it
possible for distributed programs written in different programming languages
to communicate over the Internet. IIOP is the low-level protocol for CORBA.
Remote Procedure Calls (RPC): This protocol is one of the original protocols
that introduced the concept of loose coupling and distributed computing. RPC
is a technique for constructing distributed, client-server based applications. It
is based on extending the notion of conventional, or local procedure calling,
so that the called procedure need not exist in the same address space as the
32
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
calling procedure. Many distributed protocols since, such as Web services,
have based their approach and concepts on RPC.
Remote Method Invocation (RMI): This protocol is a Java specification for
RPC (remote procedure calls). The client can invoke methods on objects
remotely residing in the server, possibly passing it primitives or objects as
parameters and receiving a primitive or object as a result.
Service Data Objects
Business data that is exchanged in an integrated application in both WebSphere
Process Server and WebSphere Enterprise Service Bus is represented by
business objects. The objects are based on Service Data Objects (SDOs), which
is a new data access technology.
SDOs are designed to simplify and unify the way in which applications handle
data. Using SDOs, application programmers can uniformly access and
manipulate data from heterogeneous data sources, including relational
databases, XML data sources, Web services, and enterprise information
systems (EIS).
The SDO proposal was published jointly by IBM and BEA as JSR 235. SDO
Version 1.0 support is introduced in WebSphere Application Server V6 and IBM
Rational® Application Developer V6. The SDO V2.0 specification is currently
available.
Both SCA and SDO (the basis of business objects) are designed to be
complimentary service-oriented technologies. Figure 2-12 illustrates how SCA
provides the framework to define service components and to compose these
services into integrated applications. It further shows that business objects
represent the data that flows between each service. Whether the interface
associated with a particular service component is defined as a Java interface or a
WSDL port type, the input and output parameters are represented by business
objects.
Chapter 2. Key technologies of SOA implementation on System z
33
Web
Service Module
BO
BO
BO
BO
BO
BO
= Business Object
Web
Figure 2-12 Exchanging data in an SCA runtime
SDO is based on the concept of disconnected data graphs. A data graph is a
collection of tree-structured or graph-structured data objects. Under the
disconnected data graph architecture, a client retrieves a data graph from a data
source, mutates the data graph, and can then apply the data graph changes
back to the data source.
The task of connecting applications to data sources is performed by data
mediator services. Client applications query a data mediator service and get a
data graph in response. Client applications send an updated data graph to a data
mediator service to have the updates applied to the original data source. This
architecture allows applications to deal principally with data graphs and data
objects.
For more details, see the IBM developerWorks® article about SDOs, which is
available at:
http://www-128.ibm.com/developerworks/java/library/j-sdo/
34
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
2.4 Enterprise integration with IBM products
This section discusses IBM position regarding SOA and the IBM products that
offer SOA capabilities for System z.
Chapter 3, “WebSphere Process Server and WebSphere Enterprise Service Bus
on z/OS” on page 65 describes the ability of these products to enable
enterprise-wide integration with core applications. For information about the role
of the mainframe and its continuing importance to organizations, see 2.1, “Using
mainframes in today’s business environment”.
2.4.1 The IBM SOA Foundation
The IBM SOA Foundation is an integrated, open standards based set of IBM
software, best practices, and patterns that are designed to provide what you
need to get started with SOA from an architecture perspective. The key elements
of the SOA Foundation are the SOA life cycle (model, assemble, deploy,
manage), the reference architecture, and SOA scenarios.
As part of the strategy and positioning on SOA from IBM, you should introduce
the SOA Foundation prior to coverage on specific products. For a better
understanding of the IBM SOA Foundation, we explore its elements as follows:
򐂰 SOA Foundation Life Cycle
򐂰 SOA Foundation Reference Architecture
򐂰 SOA Foundation Scenarios
Note: For a more detailed explanation of the SOA Foundation, refer to IBM
SOA Foundation: An Architectural Introduction and Overview Version 1.0
found at:
http://download.boulder.ibm.com/ibmdl/pub/software/dw/webservices
/ws-soa-whitepaper.pdf
The SOA Foundation Life Cycle
The SOA Foundation Life Cycle takes an iterative and incremental approach to
constant improvement of SOA capabilities and services provision. A premise of
the life cycle is that feedback is cycled to and from the phases in iterative steps of
refinement and that the architecture models can be built using
reverse-engineering techniques or others to facilitate the needs of the business.
The cycle is then layered on a backdrop of governance that ensures compliance
and operational policies are enforced and that change occurs in a controlled
fashion with appropriate authority as envisioned by the business design.
Chapter 2. Key technologies of SOA implementation on System z
35
Figure 2-13 illustrates the SOA Foundation Life Cycle.
ƒ Discover
ƒ Construct and test
ƒ Compose
ƒ Integrate people
ƒ Integrate processes
ƒ Manage and integrate
information
ƒ Gather requirements
ƒ Model and simulate
ƒ Design
ƒ Financial transparency
ƒ Business and IT alignment
ƒ Process control
ƒ Manage applications and services
ƒ Manage identity and compliance
ƒ Monitor business metrics
Figure 2-13 The SOA Foundation Life Cycle
The phases of the life cycle are:
򐂰 Model
Modeling is the process of capturing the business design from an
understanding of business requirements and objectives.
򐂰 Assemble
The business design is used to communicate the business objectives to the
IT organization that will assemble the information system artifacts that
implement the design.
򐂰 Deploy
The deploy phase of the life cycle includes a combination of creating the
hosting environment for the applications and the deployment tasks of those
applications. This phase includes resolving the application’s resource
dependencies, operational conditions, capacity requirements, and integrity
and access constraints.
򐂰 Manage
The manage phase includes the tasks, technology and software used to
manage and monitor the application assets such as services and business
processes that are deployed to the production runtime environment.
36
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Monitoring is a critical element of ensuring that the underlying IT systems and
application are up and running to maintain the service availability requirements of
the business. Monitoring also includes monitoring the performance of service
requests and the timeliness of service responses.
SOA Governance is also critical to the success of any SOA project. Governance
helps clients extend the planned SOA across the enterprise in a controlled
manner. SOA Governance has four core objectives or challenges:
򐂰
򐂰
򐂰
򐂰
Establish decision rights
Define high value business services
Manage the life cycle of assets
Measure effectiveness
For more information about governance, read 2.7.4, “SOA governance” on
page 61.
SOA Foundation Reference Architecture
Integrated
environment
for design
and creation
of solution
assets
Business Innovation & Optimization Services
Facilitates better decision-making
with real-time business information
Interaction Services
Enables collaboration
between people,
processes & information
Process Services
Orchestrate and
automate business
processes
Information Services
Manages diverse
data and content in a
unified manner
Facilitates communication ESB between services
Partner Services
Connect with trading
partners
Business App Services
Build on a robust,
scaleable, and secure
services environment
Access Services
Facilitates interactions
with existing information
and application assets
IT Service
Management
Development Services
This section describes the SOA Foundation Reference Architecture which
includes the components and middleware services that are used by applications
in the runtime environment. The architecture is a product agnostic view of what
IBM believes are the critical elements that make up a successful SOA
framework. Figure 2-14 gives a high-level view and description of each of the
components that make up the SOA Foundation Reference Architecture.
Manage
and secure
services,
applications
&
resources
Infrastructure Services
Optimizes throughput,
availability and performance
Figure 2-14 SOA Foundation Reference Architecture: middleware services view
Chapter 2. Key technologies of SOA implementation on System z
37
Core components of the logical architecture
The logical architecture includes the following core components:
򐂰 Interaction Services provide the capabilities that are required to deliver IT
functions and data to users, meeting their specific preferences.
򐂰 Process Services provide the control capabilities that are required to manage
the flow and interactions of multiple services in ways that implement business
processes.
򐂰 Business Application Services are called by service consumers. Service
consumers include other components in the logical architecture, such as
portal or a business processes.
򐂰 Information Services provide the capabilities that are necessary to federate,
replicate, and transform disparate data sources.
򐂰 Access Services provide bridging capabilities between core applications,
prepackaged applications, enterprise data stores, and the ESB to incorporate
services that are delivered through existing applications into an SOA.
򐂰 Partner Services provide the document, protocol, and partner management
capabilities for business processes that involve interactions with outside
partners and suppliers.
Supporting components of the logical architecture
The supporting components of the SOA Foundation logical architecture that are
used in support of the core components include:
򐂰 Enterprise Service Bus
Provides mediations between components. This element is covered in more
detail in “The Enterprise Service Bus” on page 29.
򐂰 Business Innovation and Optimization Services
Used primarily to represent the tools and the metadata structures for
encoding the business design, including business policies and objectives.
򐂰 Development Services
Encompass the entire suite of architecture tools, development tools, visual
composition tools, assembly tools, methodologies, debugging aids,
instrumentation tools, asset repositories, discovery agents, and publishing
mechanisms that are needed to construct an SOA based application.
򐂰 IT Service Management
Represents the set of management tools used to monitor your service flows,
the health of the underlying system, the utilization of resources, the
identification of outages and bottlenecks, the attainment of service goals, the
enforcement of administrative policies, and recovery from failures.
38
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
SOA Foundation scenarios
The SOA Foundation scenarios (or simply SOA scenarios) are representative of
common scenarios of IBM products and solutions for SOA engagements. The
SOA scenarios communicate quickly the business value, architecture, and IBM
open standards-based software that are used within the SOA scenario. You can
use the SOA scenarios as a reference architecture implementation (starting
point) to accelerate the SOA architecture and implementation of your scenario.
Figure 2-15 displays the SOA scenarios (Service Creation, Service Connectivity,
Interaction and Collaboration Services, Business Process Management, and
Information as a Service) and the relationship between the scenarios.
SOA Scenarios
Reuse:
Service
Creation
SOA
Design
People:
Interaction &
Collaboration
Services
Process:
Business
Process
Management
Connectivity:
Service
Connectivity
SOA
Governance
Information:
Information
as a Service
SOA
Security
SOA
Management
Figure 2-15 SOA scenarios and entry points
In this section, we detail the Business Process Management and Service
Connectivity scenarios because they are relevant to this paper. You can apply
and adopt them incrementally and use them in collaboration with other
scenarios. You can also use SOA Design, SOA Governance, SOA Security, and
SOA Management in each of the SOA scenarios based on customer
requirements.
Business Process Management scenario
Business Process Management leads to business innovation and optimization by
implementing business strategy through modeling, developing, deploying, and
managing business processes throughout the entire life cycle. The modeling of
processes helps to combine and to relate business processes, information, and
IT resources. This aligns the organization's core assets, people, information,
Chapter 2. Key technologies of SOA implementation on System z
39
technology, and processes to create a single integrated view of both its business
measurements and IT system performance.
The Business Process Management scenario includes the runtime products,
monitoring, and development tools that are used to implement custom artifacts
that leverage the infrastructure capabilities.
The core IBM products that are used for the Business Process Management
scenario are:
򐂰
򐂰
򐂰
򐂰
Model: WebSphere Business Modeler V6
Assemble: WebSphere Integration Developer V6
Deploy: WebSphere Process Server V6
Manage:
– WebSphere Business Monitor V6
– IBM Tivoli® Composite Application Manager for SOA V6
The additional IBM products that are used for this scenario, depending on
customer requirements, are as follows:
򐂰 Model: IBM Rational Software Architect V6
򐂰 Deploy:
– WebSphere Portal
– WebSphere Adapters
򐂰 Manage:
– IBM Tivoli Access Manager
– IBM Tivoli Federated Identity Manager
򐂰 Governance: WebSphere Service Registry and Repository
Note: For further details on the Business Process Management scenario,
refer to Patterns: SOA Foundation Service Connectivity Scenario,
SG24-7228.
Service Connectivity scenario
The Service Connectivity scenario is used to demonstrate the integration of
service providers and consumers, allowing for the reuse of existing and new
services across multiple channels. This scenario is appropriate for an enterprise
that has a set of core services or systems which are to be made available as
services to a variety of internal and external clients. Flexibility to make changes
to service providers and make changes to service clients independent from each
other is a requirement.
40
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
The focus of this scenario is on the underlying connectivity used to support
business-centric SOA. An enterprise service bus provides decoupling between
clients and providers, providing the flexibility to implement applications more
quickly.
Specific connectivity and integration requirements for an enterprise will ultimately
drive product selection of the ESB and supporting products. The choice of
runtime products can include one or more of the following:
򐂰 WebSphere Message Broker
򐂰 WebSphere Enterprise Service Bus
򐂰 IBM DataPower® SOA Appliances
򐂰 Web Services Gateway (WebSphere Application Server Network
Deployment V6)
򐂰 WebSphere Adapters
򐂰 WebSphere Service Registry and Repository
The choice of SOA life cycle products depends largely on the runtime products
that are selected. You can use the following products to support the runtime
environment:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
WebSphere Message Broker Toolkit
Rational Application Developer
WebSphere Integration Developer
IBM Tivoli Composite Application Manager for SOA
IBM Tivoli Composite Application Manager for WebSphere
IBM Tivoli Composite Application Manager for RTT V6.0
OMEGAMON® for Messaging
IBM Tivoli Access Manager
IBM Tivoli Federated Identity Manager
Note: For further details on the Service Connectivity scenario, refer to
Patterns: SOA Foundation Service Connectivity Scenario, SG24-7228.
2.5 Overview of WebSphere Process Server and
WebSphere Enterprise Service Bus for z/OS
This section gives an overview of WebSphere Process Server and WebSphere
Enterprise Service Bus for z/OS. Both are members of the product suite from
IBM for integration capabilities within organizations, and each offers an
implementation of principles laid down by SOA and the SCA. For a more detailed
Chapter 2. Key technologies of SOA implementation on System z
41
introduction to the two products and how to optimize both within an SOA
architecture, read Chapter 3, “WebSphere Process Server and WebSphere
Enterprise Service Bus on z/OS” on page 65.
Figure 2-16 shows how the two products are based upon WebSphere Application
Server with its J2EE runtime and proven quality of service strengths such as
clustering, scalability, and security. At the time of writing, the current versions of
both WebSphere Process Server and WebSphere Enterprise Service Bus for
z/OS are V6.0.1, and both rely on WebSphere Application Server for z/OS
V6.0.1.
WebSphere Process Server
Choreography
WebSphere
Enterprise Service Bus
Mediation
WebSphere
Application Server for z/OS
Clustering
WebSphere
Application
Server
App Server
Figure 2-16 Relationship and services between the products
2.5.1 WebSphere Process Server for z/OS
This section gives an overview of WebSphere Process Server on z/OS.
Business Process Management
To stay ahead of the competition, companies are constantly striving for
differentators. A common practice is to review and to refine business activities.
Processes evolve over time as a company reacts and adapts to market
conditions, and any method that codifies and automates processes quickly will
help bring about competitive advantages.
Thanks to improvements in graphical tools and business friendly notations, the
bridge between business and IT departments is narrowing, and both parties can
work closely in redefining and developing new processes and workflows. In
42
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
addition, SOA promotes the building of business process models, business rules
definition, business rules implementation, and technical workflow models. With
these enablements, Business Process Management brings processes, people,
and information together to increase efficiency for the entire enterprise.
WebSphere Process Server
WebSphere Process Server is an SCA compliant runtime element that provides
a fully converged, standards-based process engine that is underpinned by
WebSphere Application Server. It is, along with WebSphere Enterprise Service
Bus, a strategic product for integration and modernization of IT assets, including
core systems using SOA. Following the principles of SCA, there is a single
invocation model, a single data model, and a component-based framework.
Everything in WebSphere Process Server is a component. These components
have an interface and can be wired together to form a module. This modular
arrangement enables the changing of any part of an application without affecting
the other parts. For example, a human task can be replaced with a business rule
without the need to modify the business process.
Figure 2-17 shows the major components that make up WebSphere Process
Server.
Business
Processes
Mediation
Mediation Flows
Flows
(ESB)
(ESB)
Human
Tasks
Interface
Maps
Service Component
Architecture
Business
State
Machines
Business
Object
Maps
Business
Rules
Relationships
Business
Objects
Dynamic
Dynamic
Service
Service
Selection
Selection
Common Event
Infrastructure
WebSphere Application Server
Figure 2-17 WebSphere Process Server V6 components
Chapter 2. Key technologies of SOA implementation on System z
43
Business Processes component
The Business Processes component contains a WS-BPEL compliant process
engine. Users develop and deploy business processes with support for long- and
short-running processes and also make use of a robust compensation engine.
WebSphere Process Server supports dynamic business processes as follows:
򐂰 Visually describes processes that span people, systems, applications, tasks,
rules, and the interactions among them
򐂰 Supports long- and short-running business processes
򐂰 Provides transaction rollback-like functionality for loosely coupled business
processes that cannot be undone automatically by the application server
򐂰 Integrates fault handling for easy, in-flow exception handling
򐂰 Accepts Java snippets and artifacts as part of a business process
Human Tasks component
This component helps to describe and to implement automated tasks and
role-based human tasks as part of automated business processes. Business
processes involving human interaction can be interruptible and persistent and
there is management of role-based task assignment, invocation, and escalation.
For example, users can pause long or complex tasks and resume them later for
completion. You can use existing Lightweight Directory Access Protocol (LDAP)
directories (and operating system repositories and the WebSphere user registry)
to access staff information and authorization.
Business State Machine components
These components provide an alternative to modeling a business process.
Business can represent their business processes on states and events that
sometimes are easier to model than a graph-orientated business process model.
These event-oriented scenarios are sometimes hard to model in a WS-BPEL
model, but can be very easy to model in a state-machine diagram. The
WebSphere Process Server state machine is designed to emulate Unified
Modeling Language (UML) state-machine diagrams.
There is an event catalog with four main categories detailing types of events to
be managed by WebSphere Process Server for z/OS:
򐂰
򐂰
򐂰
򐂰
44
Common Base Event standard elements
Business Object events
Business Process Choreographer events
Process Server events
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Business Rules component
This component provides support for rule sets (if-then rules) and decision tables.
Business rules are categorized into rule groups which hide implementation
details from the consumer and which are accessed just like any other
component. This capability allows dynamic changes of a business process for a
more responsive business environment. They contain policies and conditions
imposed by the business.
Additionally there are a number of supporting components that deal with the
differences that come with various applications and systems in a heterogeneous
IT environment. These servicing components are as follows:
򐂰 Interface maps: very often interfaces of existing components match
semantically but not syntactically (for example, updateCustomer versus
updateCustomerInDB2). This is especially true for already existing
components and services. Interface maps translate these calls so that these
components can be invoked. Additionally, business object maps can be used
to translate the actual business object parameters of a service invocation.
򐂰 Business object maps: Used to translate one type of business object into
another type, these maps can be used in a variety of ways (for example, as
an interface map to convert one type of parameter data into another).
򐂰 Relationships: A common problem with keeping business objects in sync is
that different back-end systems use different keys to represent the same
objects. The WebSphere Process Server relationship service establishes
relationship instances between objects in these disparate systems. These
relationships are typically accessed from a business object map while one
business object format is being transformed into another.
򐂰 Selector: Different services that all share the same interface can be selected
and invoked dynamically by a selector. For example, a customer support
process might use different human task implementations during different
times of the day. Work is routed to different support centers (Americas,
Europe, and Asia-Pacific) based on the time of day.
The key tools for modelling and assembling processes for import into the
Business Process Choreographer are WebSphere Business Modeler and
WebSphere Integration Developer. With these development tools, the developer
can adhere to specification rules and switch off all the extensions or use them as
desired.
Chapter 2. Key technologies of SOA implementation on System z
45
You can find details about WebSphere Business Modeler and WebSphere
Integration Developer in 2.6, “Tools for SOA enablement” on page 52. For more
information about WebSphere Process Server, see 3.2, “WebSphere Process
Server for z/OS” on page 66. You can find information about WebSphere Process
Server for z/OS online at:
http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/topic/
com.ibm.wsps.z.doc/welcome_wpsz.htm
2.5.2 WebSphere Enterprise Service Bus for z/OS
WebSphere Enterprise Service Bus compliments WebSphere Process Server by
introducing enhanced integration capabilities. Services should, by definition, be
reusable by a number of different consumers, so that the benefits of reduced
connections are achieved. This would apply to WebSphere Process Server, itself
as a consumer or provider.
WebSphere Enterprise Service Bus is the mediation layer that runs on top of the
transport layer within WebSphere Application Server. As such, WebSphere
Enterprise Service Bus provides prebuilt mediation functions and easy-to-use
tools to enable rapid construction and implementation of an ESB as a value-add
on top of WebSphere Application Server. From this definition, we realize that
WebSphere Enterprise Service Bus for z/OS is a defining element, an integration
pillar, that needs from the qualities of z/OS and WebSphere Application Server
for z/OS to offer availability as the transport, transformation, and mediation layer.
Figure 2-18 shows the WebSphere Enterprise Service Bus for z/OS
programming model and features.
46
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Messaging:
MQ
Interoperability
Clients:
C++
Client
JMS 1.1
.Net
Client
Java and C/C++
Web Services
Client
WebSphereEnterprise Service Bus
Custom
Mediation
WebSphere
Integration
Developer
XSLT
Web
Services:
Message
Logger
Mediation
Function
Message
Router
DB
Lookup
WebSphere Application Server
Tivoli Access Manager DB2 Universal Database
Edge Components
UDDI Web Services Gateway
SOAP/
HTTP
WebSphere
Adapter
Support
SCA
Programming
Model:
SCA
SOAP/
JMS
WS-*
UDDI
Registry 3.0
SMO
SDO
Figure 2-18 WebSphere Enterprise Service Bus components and associations
To do integration properly, SOA states the need of having a single invocation
model and a single data model. WebSphere Enterprise Service Bus uses SCA
as its invocation model and that is why SCA is part of the first layer of elements
shown in Figure 2-18. Also CEI, the foundation for monitoring business
performance, is part of this layer. The ESB is basic for the integration strategy
and there’s the need to know how it behaves. The event definition is
standardized using the OASIS specifications.
From the ESB definition given by SOA, there are four basic tasks that an ESB
has to perform:
򐂰
򐂰
򐂰
򐂰
Route messages among services
Transform message formats when necessary
Convert protocols for the consumer and the provider
Handle events from different services
Chapter 2. Key technologies of SOA implementation on System z
47
WebSphere Enterprise Service Bus conforms to all Web services standards to
achieve those basic capabilities. It uses SOAP either with JMS or HTTP. It can
also talk to WebSphere MQ or WebSphere Message Broker or an adapter.
The modules in charge of doing the operations for WebSphere Enterprise
Service Bus are called mediation components. These mediation components are
built using WebSphere Integration Developer. This tool has features to aid
developers similar to an assembly diagram editor, a mediation flow editor, and a
visual debugger. When created, the mediation modules are deployed to
WebSphere Enterprise Service Bus.
2.5.3 Supporting products
This section contains brief details on the elements that are required to support
the operation of both WebSphere Process Server and WebSphere Enterprise
Service Bus.
WebSphere Application Server
WebSphere Application Server V6 is the IBM implementation of the J2EE (Java
2 Enterprise Edition) platform, which conforms to V1.4 of the specification.
WebSphere Application Server is available in several different configurations that
are designed to meet a wide range of customer requirements. Each configuration
is packaged with other components that provide a unique environment.
Figure 2-19 on page 49 shows the main components that make up WebSphere
Application Server Network Deployment.
The Network Deployment configuration offers central administration and
workload management. A Network Deployment environment consists of one or
more Base installations and a Deployment Manager installation. The Base
application servers are added to the cell in a scalable manner and are managed
by the Deployment Manager. The Network Deployment package also includes
the Web Services Gateway, a UDDI Registry and J2EE Connector Architecture
services.
48
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Application server
Scripting client
Server configuration
Console
Admin application
Web browser client
Web container
EJB container
WebSphere extensions
Application (EAR)
Administrative infrastructure
Configuration
files
Class loader
Web server, plug-in
Caching proxy *
Client container
Java client
JCA services
Application
database
managed by external provider
(MQ)
Messaging engine
manages
Service integration bus
Web services engine
Naming and directory
Message queues
Web services
provider or
gateway
Transactions
Performance infrastructure
PD infrastructure
WLM and HA *
* Available only with
Network Deployment edition
Security infrastructure
Ports
Environment settings
Figure 2-19 WebSphere Application Server Network Deployment components
For more information about Base Server and Network Deployment, refer to:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topi
c=/com.ibm.websphere.zseries.doc/info/welcome_nd.html
For more information about the J2EE 1.4 specification, refer to:
http://java.sun.com
Chapter 2. Key technologies of SOA implementation on System z
49
IBM DB2 Universal Database
IBM DB2 Universal Database™ Enterprise Server Edition is a version of DB2
Universal Database that allows you to create and manage single partitioned or
partitioned database environments. Partitioned database systems can manage
high volumes of data and provide benefits such as high availability and increased
performance.
DB2 Universal Database V8.2 delivers new features to address the ever
increasing demands and requirements on important data, which include:
򐂰 Broadened autonomic computing solutions that automate and simplify
potentially time consuming and complex database tasks
򐂰 A significant amount of new capabilities as well as further integration of DB2
tooling into the Microsoft .NET and WebSphere Java environments
These new capabilities simplify the development and deployment of DB2
applications and allow application developers to take advantage of the
openness, performance, and scalability of DB2, without regard to the
back-end database or the chosen application architecture.
򐂰 Integration of industry proven high availability disaster recovery technology,
allowing line-of-business managers and the enterprise to benefit because
applications face less risk of downtime
For more information, refer to the IBM DB2 Universal Database Web site:
http://www.ibm.com/software/data/db2/udb
IBM Cloudscape
IBM Cloudscape™ is an open source Java relational database management
system (RDBMS) that can be embedded in Java programs and used for online
transaction processing. IBM Cloudscape features include:
򐂰 Rapid application development through the Java-based RDBMS that is built
from the ground up for the embedded environment
This platform independent, small footprint database integrates tightly with any
Java based solution, allowing shortened development cycles.
򐂰 Support for Java technology standards
Single application versions can be created that run on any standard Java
Virtual Machine (JVM™).
򐂰 Does not require database administration or resource management and is
invisible to non-technical users, eliminating the need for database
administration at each client installation site
IBM Cloudscape can also be deployed anywhere, for example, from notebook
or desktop applications to robust server solutions.
50
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
򐂰 Tuned for high performance as well as efficient use of resources, with a
straightforward migration path to various IBM DB2 versions
򐂰 Supports international characters and formats as well as a rich set of RDBMS
features that are based on SQL-92E, including row locking, triggers, and
stored procedures
򐂰 Available access to IBM Cloudscape from inside Java programs using Java
Database Connectivity (JDBC™) and the ability to embed the IBM
Cloudscape database inside Java applications on the server
The Cloudscape Network server comes as part of the IBM Cloudscape package.
It provides multiuser connectivity to IBM Cloudscape databases within a single
system or over a network using Standard Distributed Relational Database
Architecture™ (DRDA) protocol.
For more information, see the IBM Cloudscape Web site:
http://www.ibm.com/software/data/cloudscape
WebSphere Business Monitor
WebSphere Business Monitor is a Web-based client/server application that
measures business performance, monitors processes and work flow, and reports
on business operations. The information captured can help identify problems,
correct faults, and change processes to achieve a more efficient business.
It is an optional inclusion and helps monitor business processes at runtime by
monitoring event-emitting runtime engines. It does so having calculated Key
Performance Indicators (KPIs) and metrics using collected events, based on a
given model. The Business Measures editor is used to open the process models
created in WebSphere Business Modeler and business measures models are set
up. For each business measures model, you can define the metrics and KPIs,
event emission points, event filters, event composition rules, and situations that
will trigger specific actions at runtime.
Only applications that are running on WebSphere Process Server Version 6.0.1
are currently supported.
For more information, see the WebSphere Business Monitor Web site:
http://www.ibm.com/software/integration/wbimonitor/
Chapter 2. Key technologies of SOA implementation on System z
51
2.6 Tools for SOA enablement
This section describes the various tools that are used as part of building SOA
capability within an organization. It focuses on IBM products that adhere to the
principles laid out by SOA and SCA and are based upon Eclipse.
Eclipse is an open source, Java-based, extensible development project aimed at
providing an integrated tool framework. At the heart of Eclipse is an extensive
tool framework offering a set of core capabilities that supports extension through
a plug-in architecture.
Note: For more information about Eclipse and tutorials, visit the following Web
site and explore the Getting Started pages:
http://www.eclipse.org
The section takes a top down approach, following the SCA programming model
principles, using tools that help model the business process flows, the
associated data elements and the service interface definitions. Included also are
the tools that are used for defining and constructing routing and transformation
mediation modules.
2.6.1 WebSphere Business Modeler
Defining and modeling business processes is a critical factor in improving
business performance. A business process is a variable pattern of interactions
that occur between an organization's components and its environment as the
organization pursues its business objectives and competitive advantage.
WebSphere Business Modeler is the Eclipse based business process modeling
tool that enables modelling, design, analysis and generation of business
processes and reports. It supports Business Driven approaches by assisting with
integration and evolvement of new and revised workflows, and helps define the
organization structure, resources, and business items.
As business processes are often complex due to numerous incremental
changes, a well-constructed business process model can help locate and
eliminate hidden inefficiencies, costs, and delays. WebSphere Business Modeler
helps by having various modes that offer different but interrelated perspectives of
business models, as follows:
򐂰 Process modeling
Process modeling mode facilitates the creation of robust business process
models by describing and building a sequence of tasks and processes linked
52
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
by connectors. A process can contain multiple branching paths based on
decisions made during the process execution. A process can also contain
subprocesses.
򐂰 Business item modeling
Process models can include any business document, work product, or
commodity that is used for a particular business operation. A business item is
anything that is created, assembled, inspected, tested, modified, or worked
upon. Business items can also undergo changes as they are passed from one
step to the next in process models.
򐂰 Resource modeling
WebSphere Business Modeler helps model the company's resources, such
as employees, computers, vehicles, or electricity. Any person, equipment, or
material used to perform a task or a project can be represented and used in
the process models. Depending on the level of complexity, details such as
roles, costs, and timetables can also be documented.
򐂰 Organization modeling
An organization is an entity where people cooperate to accomplish specified
objectives. For example, an organization can be an enterprise, a company, or
a factory. A typical company consists of one or more organizations; the larger
the company, the more organizations it will normally have. With WebSphere
Business Modeler, such details of an organization and its sub-elements can
be captured.
򐂰 Structure modeling
Structures define the relationships between different entities in an
organization. Using WebSphere Business Modeler, structures will show how
different types of business entities interact with one another in relationships of
varying complexity, and allow for different relationships among the same
divisions within the same company.
򐂰 Business Modeler and SOA
The tool is also a key component of an SOA implementation and gives a
direct link from business process modeling to the implementation of software
services, and the inherent modularity of service-oriented applications helps to
ensure that both current and future business requirements will be met.
You can export generated WS-BPEL to WebSphere Integration Developer to
build and to deploy business processes that are based on SOA.
Chapter 2. Key technologies of SOA implementation on System z
53
2.6.2 WebSphere Integration Developer
WebSphere Integration Developer is the development environment for building
integrated business applications that are targeted for WebSphere Enterprise
Service Bus and WebSphere Process Server. One of the primary purposes of
WebSphere Integration Developer is to provide the appropriate tools to build and
test SCA based solutions easily.
WebSphere Integration Developer is built on the Rational Software Development
Platform, which is based on Eclipse 3.0 technology.
Figure 2-20 illustrates the relationship between WebSphere Integration
Developer and the other Rational Software Development Platform products.
IBM Rational
Software Architect V6
IBM Rational
Application Developer V6
IBM WebSphere
Integration
Developer V6
IBM Rational
Web Developer V6
Rational Software Development Platform
(Eclipse 3.0)
Figure 2-20 Development tools overview
WebSphere Integration Developer includes most functions provided by IBM
Rational Application Developer, but not all of them. For example, the Crystal
Report tools and WebSphere Portal development tools are not included in
WebSphere Integration Developer but in IBM Rational Application Developer.
Because both products are based upon the IBM Rational Software Development
Platform, they can be combined in a single development environment.
54
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Figure 2-21 presents an overview of the common tasks that are carried out using
WebSphere Integration Developer. It shows the main stages in the mediation
module development process and provides assistance in navigating this section.
Workspace
configuration
Interface
definition
Mediation
module
development
Running
mediation
modules
Exporting
resources
Figure 2-21 Common tasks in WebSphere Integration Developer
If a single user assumes both the integration developer role and the application
developer role, the user can either use the J2EE development tools in
WebSphere Integration Developer or both development products, WebSphere
Integration Developer and IBM Rational Application Developer
2.6.3 IBM Rational Software Architect
IBM Rational Software Architect is part of the Rational Software Development
Platform. It allows architects to design and to maintain application architectures.
The tool is built on Eclipse, so developers and architects can leverage the
usability features of the Eclipse platform.
For SOA, IBM Rational Software Architect helps support service-oriented
modeling and design with tools for software architects to visually model and
design SOAs using the open standard UML to document SOAs as well as
support for patterns, customizable, and repeatable solutions for development
tasks. The resulting outcomes of work with UML will be a set of components with
services defined in WSDL.
2.6.4 WebSphere Developer for System z
WebSphere Developer for System z consists of a common workbench and an
integrated set of tools that support end-to-end, model-based application
development, runtime testing, and rapid deployment of on demand applications.
WebSphere Developer for zSeries V6 is based on the Rational Software
Development Platform and facilitates the development of both Java- and
z/OS-based applications. It includes capabilities that make traditional z/OS
mainframe development, Web development, and integrated composite
development faster and more efficient.
Upgraded XML and Web services support, enabling SOA access to CICS
Transaction Server V3.1 and IMS V9 are now included.
Chapter 2. Key technologies of SOA implementation on System z
55
2.7 Other considerations
This section covers topics that you should take into consideration when
developing an SOA implementation. These topics apply particularly to those
larger enterprises that plan to introduce a comprehensive and flexible SOA
framework into their heterogeneous IT environment.
2.7.1 A successful business services architecture for SOA
An SOA is only as successful as the business optimization and reusability of the
services that it provides. This theory applies to business services, such as
getBalance or updateCustomerDetails, and more technical services, such as
user authorization. For a successful SOA, it is important to identify and to
construct a well-defined framework of business services from new capabilities
and existing assets.
An SOA is driven principally by business drivers. Therefore, it is logical to
consider requirements as top-down, coming from strategic decisions and
changing business conditions.
What is equally important however, is recognizing that through new technologies,
existing assets are now less constrained in terms of providing the functionality
that is required for enterprise-wide usage. This important point helps reduce the
need to purchase new applications or to build new functionality.Any approach or
methodology for SOA should always have both top-down and bottom-up steps
as well as a meet-in-the-middle task that can help to optimize existing assets.
These steps should also be done in the context of a model-driven development
(MDD) approach. We use the term model-driven development to describe
approaches where automation generates artifacts from models. Model-driven
development has a profound effect on the way we build business application
software. It captures the expertise and decisions of your top technical people,
making them available to the rest of the team through tooling that is customized
for your project's needs. The cost of development and testing the business
software is reduced significantly because much of the low-level coding work is
automated. The number of errors are reduced, and there is an increase in the
consistency with which work is accomplished.
56
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Figure 2-22 illustrates how top-down and bottom-up tasks are drawn together.
Flexible Business
Transformation
Business Process Outsourcing
Mergers, Acquisitions & Divestitures
Composable
Processes
(IBM
Component
Business Modeling)
Requires
ServiceOriented
Modeling
Flexible IT
On Demand Operating Environment
Service-oriented Architecture (SOA)
Development
Software
Development
Infrastructure
Integration
Management
Composable
Services
(SOA)
Infrastructure
Management
Figure 2-22 Top-down and bottom-up relationship between business and IT
These approaches have the following benefits and drivers:
򐂰 Top-down approach
This approach takes business drivers and requirements for services to
produce service specifications. The collection of specified services are
captured within a services model which undergoes a series of iterative steps
with input of work from the bottom-up tasks.
򐂰 Bottom-up approach
Here the existing IT assets of the organization are examined and their
suitability and compatibility for required services assessed. They are
expected to meet SLAs (Service Level Agreements) and be technically
capable of fitting into the SOA architecture.
򐂰 Meet-in-the-middle approach
Combining the work of top-down and bottom-up approach produces a gap
analysis of what can be provided by the existing IT assets and what new
functionality needs to be developed. The meet-in-the-middle approach is a
continuous refinement of the required processes and services and helps with
optimal leverage of existing assets.
Chapter 2. Key technologies of SOA implementation on System z
57
The eventual outcome of this work sees a set of well-defined, domain based
components that contain within them services that realize business needs.
For more information about these business drivers, see Patterns: Model-Driven
Development Using IBM Rational Software Architect, SG24-7105.
2.7.2 Patterns for SOA
The introduction of SOA, and with it the ability to collaborate with and to call upon
services that are offered by third-party providers outside of the organization,
means there are now new extensions to patterns for SOA integration.
Architecture patterns are the end-result of harvesting assets and best practices
from engagements to enable IT architects to architect future solutions based on
proven and successful results. This reuse saves time, money, and effort.
IBM has the IBM Patterns for e-business, which are a group of proven, reusable
assets that you can use to increase the speed of developing and deploying
business applications.
Note: For information from IBM on Patterns for e-business, refer to:
http://www.ibm.com/developerworks/patterns/
Integration patterns
Integration patterns allow you to tie together multiple business patterns to solve a
business problem and are subdivided into the following patterns:
򐂰 Access Integration patterns
򐂰 Application Integration patterns
Table 2-1 gives high-level descriptions of these two patterns.
Table 2-1 Integration patterns
Integration patterns
Description
Examples
Access Integration
Integration of a number of
services through a common
entry point
Portals
Application Integration
Integration of multiple
applications and data sources
without the user directly invoking
them
Message brokers, workflow
managers, data propagators,
and data federation engines
58
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
With the introduction of improved process integration capabilities and
sophistication, the Application Integration pattern can be implemented further by
WebSphere Process Server and WebSphere Enterprise Service Bus.
WebSphere Enterprise Service Bus is able to implement the Broker application
pattern while WebSphere Process Server implements the Serial Process
application pattern and the Parallel Process application pattern.
Note: For more information about these patterns, refer to:
򐂰 Patterns: Building Serial and Parallel Processes for IBM WebSphere
Process Server V6, SG24-7205
򐂰 Patterns: SOA Foundation Service Connectivity Scenario, SG24-7228
Broker application pattern
The Broker application pattern allows a single interaction from the source
application to be distributed to multiple target applications, reducing the
proliferation of point-to-point connections. With the Router variation, each
interaction is forwarded to, at most, one of the target applications, rather than all
of them.
Serial Process application pattern
The Serial Process application pattern, shown in Figure 2-23 adds sequencing to
the one-to-N topology of the Broker application pattern. It enables the
orchestration of a serial business process.
Source
Application
Serial Process
Rules Tier
Target
Application
Target
Application
Target
Application
WIP
Intermediate
Results
R/O
Process
Execution Rules
Figure 2-23 Serial Process application pattern
Chapter 2. Key technologies of SOA implementation on System z
59
Parallel Process application pattern
The Parallel Process application pattern, shown in Figure 2-24 adds concurrency
to the Serial Process application pattern. The process orchestration can include
paths that lead to parallel invocation of target application services.
Parallel Process
Rules Tier
Target
Application
Target
Application
Target
Application
Source
Application
WIP
Intermediate
Results
R/O
Process Execution
Rules
Figure 2-24 Parallel Process application pattern
2.7.3 SOA security
The introduction of SOA brings with it additional considerations in terms of
security. As well as new technologies being introduced, the very concept of SOA
itself, with its principle of loosely coupled and abstracted services means identity
validation of both consumers and providers is made harder to manage.
Any application plugged into an SOA architecture is likely to have different
identity mechanisms and security policies. Users will most likely have different
privileges for different applications, and thus they will need to be authenticated
for each of the applications that are used via the SOA framework.
IT security for SOA therefore requires an end-to-end Identity Management and
Authorization capability – one that is able to determine access rights for every
application and user involved.
z/OS offers comprehensive security features with a security server providing not
only RACF®, but the z/OS LDAP server, the z/OS firewall technologies, Network
Authentication Privacy Service (Kerberos), z/OS Open Cryptographic Services
Facility (OCSF), and the z/OS DCE server.
60
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
For information about the security that is provided by the WebSphere Process
Server and WebSphere Enterprise Service Bus, see 5.1, “Security” on page 120.
Digging deeper, security is required at different levels of the SOA infrastructure
down to message (or object) level where you require entity authetication.
Web services security is rapidly maturing and has the WS-Security specification
which provides facilities such as WS-Trust, a token based authetication service
for use with SOAP messages.
Note: Refer to the following for specification details on Web services security:
http://www.oasis-open.org/committees/download.php/16790/wss-v1.1spec-os-SOAPMessageSecurity.pdf
2.7.4 SOA governance
According to Gartner, lack of governance within SOA brings about significant
project failures:
In 2006, lack of working governance mechanisms in midsize to large (more
than 50 services) post-pilot SOA projects will be the most common reason for
project failure (0.8 probability).1
SOA is cross organization by nature, even extending outside of the organization.
This agility can only be attained when each part of the business maintains and
controls the services they offer to other parts. Figure 2-25 shows service A within
BU1 as being dependant on the integrity, performance, availability, and reliability
of services that are managed by other BUs.
Business Unit 1
Business Unit 2
Business Unit 3
A2
A3
Service A
A1
Figure 2-25 Interrelationships between services offered by different business units
1
Gartner Research ID #G0013197, 27/10/2005
Chapter 2. Key technologies of SOA implementation on System z
61
This assurance and control only comes about through a proper governance plan.
Effective governance of SOA covers the processes, practices and organizations
that ensure that services and associated IT capabilities are in alignment with
business needs. This is done by ensuring compliance of projects to the defined
SOA.
Figure 2-26 is a proposed Governance Framework that defines the principles,
processes and roles required to use, update and manage the SOA. The key
points are:
򐂰 The primary goal is to derive maximum value from the SOA by promoting its
implementation, use and evolution
򐂰 The Framework defines how the SOA (and its associated models) should be
managed and updated in response to changes in business needs and available
technologies
򐂰 The Governance processes are fundamental to enabling the business to
make conscious decisions about IT, the acquisition of IT assets, and the
design and implementation of new IT solutions to meet business needs
Strategy
Enterprise wide focus
Business
Opportunity
Information
Technology
Strategy
Business
Strategy
Enterprise Architecture
Planning
Business
Architecture
IT
Architecture
- Processes
- Information
- People
- Locations
- Applications
- Data
- Technology
Project focus
Transition Plan
Design and
Delivery
Business Operating Environment
and IT Infrastructure
IT Solutions
Technology
Availability
En
sur
es
Practices
Ali
gn
me
Ensures Vitality
nt
Effective
Governance
ce
lian
p
om
sC
Organization
e
r
su
n
E
Processes
Strategic Directions
Governance Principles
Figure 2-26 SOA Governance Framework showing alignment with business strategies and goals
62
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
For more details on the position of IBM on SOA Governance, see:
http://www.ibm.com/software/solutions/soa/gov/
The following site gives independent views on IT governance:
http://www.itgi.org/
2.7.5 Management and monitoring an SOA environment
An SOA environment means business processes increasingly depend on a
disparate set of applications spanning multi-tiered architectural layers to provide
the services they require. There needs to be efficient management and
monitoring of SOA composite applications and the supporting infrastructure. The
following are the challenges faced in SOA management:
򐂰 Manage and monitor the end-to-end view
򐂰 Manage service as resources
򐂰 Understand The Associations Between Services
򐂰 Ensure that Service Level Agreements (SLAs) and non-functional
requirements are achieved and adhered to
Business processes management and monitoring
The ability to optimize business processes is a key aspect of SOA. Misalignment
of the business processes or a bottleneck in workflows can have severe impacts.
Therefore, it is vital that you do the following:
򐂰 Monitor key performance indicators against targets
򐂰 Track process flows
Services monitoring
As with processes, you need to monitor services with respect to SLAs to ensure
their availability is not impacted.
Transactions monitoring
In order to implement a viable method of integration between a modern
enterprise solution and an existing enterprise system the required design should
keep to a minimum transport and protocol overheads, especially so for high
volume transactional processing. Analyzing transactions in design time makes
management and monitoring of such more precise.
Chapter 2. Key technologies of SOA implementation on System z
63
Middleware monitoring
In an SOA, the middleware layer is one of the most vital. Constant monitoring of
mediation components, their message flows and associated tasks such as
transformation is required as these elements create high overheads. It is
therefore important that the health of the middleware layer be monitored
constantly.
Security management and monitoring
There needs to be comprehensive security monitoring, given that service
consumers and providers can be sited across boundaries. Security monitoring
and management should cover:
򐂰 Consistent authorization handling across the infrastructure components
򐂰 Mapping of identities across various security subsystems
򐂰 Compliance to security policy and auditing
64
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
3
Chapter 3.
WebSphere Process Server
and WebSphere Enterprise
Service Bus on z/OS
In this chapter, we present WebSphere Enterprise Service Bus, WebSphere
Process Server, and their relationship with z/OS. We depict how z/OS advanced
features and design enhances the possibilities of the service-oriented
architecture (SOA) strategy for your business.
This chapter contains the following sections:
򐂰 Motivation for an SOA
򐂰 WebSphere Process Server for z/OS
򐂰 WebSphere Enterprise Service Bus for z/OS
򐂰 WebSphere Process Server and WebSphere Enterprise Service Bus for z/OS
at the core of your business
© Copyright IBM Corp. 2006. All rights reserved.
65
3.1 Motivation for an SOA
SOA strategy emphasizes the idea of reuse and componentization. Companies
make large investments every year to enforce and to enlarge their existing IT
assets. Using SOA, you can reuse your core developments to make new
applications by recombining different components.
Consider all the transactions, applications, and queries that you exploit in your
z/OS installations. By making services of all these assets, you can use and
combine each asset in a specific order to achieve a goal, otherwise known as a
business process. Now, think about all those services that you have created with
your valuable core code. These services can communicate with other
subsystems — no matter where they are and no matter which transport and
message protocols are used — using an Enterprise Service Bus (ESB).
When we consider the new paradigms and value propositions of SOA, and at the
same time realize the value of the existing IT assets and qualities of the
System z, the potential of the combination of the System z strengths and the
SOA concepts becomes clear. The combination can bring a fast return on
investment when transitioning to an SOA, while building the SOA on the platform
that provides the high qualities of services that an SOA requires.
3.2 WebSphere Process Server for z/OS
WebSphere Process Server provides process choreography capabilities to
construct business processes conforming to an SOA. Business integration
solutions can be created using integration mechanisms, such as the Service
Component Architecture (SCA) programming model and the Service Data
Objects (SDO) data model. SDO business objects can be defined, transformed,
routed, and mapped using SCA components.
In this section, we introduce the major components of WebSphere Process
Server and study each one in further detail.
3.2.1 Architectural overview
WebSphere Process Server is an integration platform built on a uniform
invocation programming model and a uniform data representation model. It
provides integration capabilities with a composite application platform to deliver
an integration platform with a fully converged, standards-based business
process engine, underpinned by WebSphere Application Server for z/OS.
66
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Because WebSphere Process Server for z/OS is built on top of WebSphere
Application Server for z/OS, it benefits from the common code policy kept by IBM
with application servers for all platforms. WebSphere Process Server for z/OS
has the same programming model on both System z and multi-platforms. Thus,
the components and product design is the same, with the same features and
administration model.
Figure 3-1 shows WebSphere Process Server hosted on the WebSphere
Application Server J2EE runtime, which offers proven qualities of service such as
clustering, scalability, and security. The J2EE server also includes a built-in
messaging provider, Java Messaging System (JMS), that you can configure to
connect to a existing WebSphere MQ network.
Business
Processes
Mediation
Mediation Flows
Flows
(ESB)
(ESB)
Human
Tasks
Interface
Maps
Service Component
Architecture
Business
State
Machines
Business
Object
Maps
Business
Rules
Service
Components
Dynamic
Dynamic
Service
Service
Selection
Selection
Supporting
Services
Common Event
Infrastructure
SOA Core
Relationships
Business
Objects
WebSphere Application Server
Figure 3-1 WebSphere Process Server V6.0.1 components
Figure 3-1 illustrates a number of layers:
򐂰 SOA core
To implement an SOA properly, it is necessary to have a single invocation
model and a single data model. This invocation model is based on Service
Component Architecture (SCA) — every integration component is described
through an interface. These services can then be assembled in a component
assembly editor thus enabling a very flexible composite application.
Also in this layer we have business objects and the Common Event
Infrastructure (CEI) that provide the implemented tools for the management of
services and monitoring.
Chapter 3. WebSphere Process Server and WebSphere Enterprise Service Bus on z/OS
67
򐂰 Supporting services
Allows for integration inside a flow. Very often, processes contain services
from different providers that have to be connected. These supporting services
provide this level of integration.
򐂰 Service components
These are SCA components that provide the heart of the WebSphere
Process Server functionality. These components provide the ability to define
WS-BPEL business processes, and to incorporate human tasks and business
rules into these processes.
3.2.2 Service components
In this section, we define each of the components in the service component layer
that are identified in Figure 3-1 on page 67:
򐂰
򐂰
򐂰
򐂰
Business processes
Human tasks
Business state machines
Business rules
Business processes component
This component implements a WS-BPEL compliant process engine. Users
develop and deploy business processes with support for long- and short-running
processes and also make use of a robust compensation engine. WS-BPEL
models are created from scratch in WebSphere Integration Developer or
imported into WebSphere Integration Developer from a model developed in
WebSphere Business Modeler.
68
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Figure 3-2 shows a WS-BPEL business process.
Choreographed
Services
Figure 3-2 Constructing a dynamic process using WS-BPEL
A business process has two modes of execution:
򐂰 Short-running process
򐂰 Long-running process
Chapter 3. WebSphere Process Server and WebSphere Enterprise Service Bus on z/OS
69
Figure 3-3 shows these two modes of execution.
Short-running process
Long-running process
Receive
Receive
T1
Invoke
T2
Invoke
T4
T0
Invoke
Invoke
T5
Invoke
Reply
Invoke
T4
Fault Reply
Reply
Fault Reply
T7
T0
Figure 3-3 Short-running and long-running processes
Short-running processes
These processes are expected to execute in a short period of time, contain only
automated activities, and operate under a single unit of work. Although a
short-running process can contain parallel branches, these branches will not be
executed in parallel at runtime, because a short-running process runs under a
single thread of execution. Intermediate states for a short-running process are
not persisted, so they are not recoverable in the event of failure.
The main advantage of short-running processes is that they execute using fewer
resources than a long-running process and therefore are considerably more
efficient.
Long-running processes
These processes are defined by their execution time, that ranges from hours or
days to months. Several transactions are usually involved in the definitions of
these processes. Transaction behavior for some activities can be configured.
Parallel activities are usual in long-running processes and blocking activities are
allowed. For several instances of the same process running at the same time,
70
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
intermediate states are persisted and there is the need of using correlation sets.
Correlation sets are necessary to match a message with its process instance to
guarantee that the message arrives to the correct place.
Human tasks component
The human task components are used to assign work to be completed by a
person. Additionally, the Human Task Manager supports the ad-hoc creation and
tracking of tasks.
Invocation for these components is not restricted to WS-BPEL processes. There
are three sorts of human tasks:
򐂰 Machine-to-human, where a component creates a work task for human
interaction. Also called a participation task.
򐂰 Human-to-machine, where a human creates the invocation for a component.
Also called an originating task.
򐂰 Human-to-human, where a human creates an invocation for a component that
creates a work item for a human.
Existing LDAP directories (as well as operating system repositories and the
WebSphere user registry) can be used to access user and group information.
WebSphere Process Server supports multi-level escalation for human tasks
including e-mail notification.
Actions that you can take on human tasks depend on the authorization role. This
role can be a J2EE role or and instance-based role. A role is a group of
employees that share the same level of authority. J2EE roles are set up when the
human task container is configured. Instance-based roles are assigned to human
tasks and escalations when the task is modeled.
In the case of WebSphere Process Server for z/OS, you can use Security
Authorization Facility (SAF)-based authorization (for example, using the RACF
EJBROLE profile) to control access by a client to J2EE roles in EJB™ and Web
applications, including the WebSphere Application Server for z/OS
Administrative Console application.
If you choose an LDAP as user registry you can also use it in z/OS. In this case,
you can choose whether this LDAP uses a DB2 database or SAF authorization.
Note: Using SAF authorization with LDAP or custom user registries requires
both a change in the user registry SAF authorization setting and the
installation of JAAS system login pluggable identity mapping modules to map
WebSphere Application Server for z/OS principals to SAF user IDs.
Chapter 3. WebSphere Process Server and WebSphere Enterprise Service Bus on z/OS
71
Using LDAP can also permit IBM Tivoli Access Manager as a repository because
WebSphere Application Server contains an embedded client for IBM Tivoli
Access Manager. To use IBM Tivoli Access Manager, you must also configure
the IBM Tivoli Access Manager server.
WebSphere Process Server also includes an extensible Web client that can be
used to work with tasks or processes. This Web client is built based on a set of
reusable Java Service Faces (JSF) components that can also be used to create
custom clients or embed human task functionality into other Web applications.
Business state machine component
A business state machine is an implementation of a business model that moves
from one state to another state based on real time events. It is an alternative to
modeling a business process. Using a business state machine, you can model
the behavior of a business process by focusing on the different states the
process can move through in response to incoming events known as transitions.
You should use business state machines when a process is heavily event driven.
One example is an ordering process where the order can be cancelled or
modified at any time during the order process.
Business rules component
Business rules are a means of implementing and enforcing business policy and
process rules. These rules allow dynamic changes of a business process for a
more responsive business environment. WebSphere Process Server includes a
Web-based runtime tool for business analysts so that business rules can be
updated as business needs dictate without affecting other SCA services.
Business rules are offered in graphical view as decision tables. A decision table
functions as a condition with a corresponding action. If a condition is met, then
the corresponding action or actions are performed.
3.2.3 Supporting services
In addition to the core service components, there are a number of supporting
components that deal with the differences that come with various applications
and systems in a heterogeneous IT environment. These supporting components
are the second layer pictured in Figure 3-1 on page 67. We discuss them in this
section.
Interface maps
Very often interfaces of existing components match semantically but not
syntactically (for example, updateCustomer versus updateCustomerInDB2). This
is especially true for already existing components and services. Interface maps
72
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
translate these calls so that these components can be invoked. Additionally,
business object maps can be used to translate the actual business object
parameters of a service invocation.
Business object maps
Used to translate one type of business object into another type, these maps can
be used in a variety of ways (for example, as an interface map to convert one
type of parameter data into another).
Relationships
In business integration scenarios, it is often necessary to access the same data,
such as customer records, in various back-end systems, for example, Enterprise
Resource Planning (ERP) and Customer Relationship Management (CRM). A
common problem with keeping business objects in synchronization is that
different back-end systems use different keys to represent the same objects. The
WebSphere Process Server relationship service establishes relationship
instances between objects in these disparate systems for two or more data
types. These relationships are typically accessed from a business object map
while one business object format is being transformed into another.
The relationship data is stored in a database. In the case of WebSphere Process
Server for z/OS, DB2 V7.x and DB2 V8.x are supported as the database
managers for deployment.
WebSphere Process Server for z/OS also offers stored procedures support for
dynamic relationships management. It is possible to use cross platform stored
procedures for DB2 z/OS. DB2 provides a procedure that is used for compiling
SQL into C functions.
Dynamic service selection
WebSphere Process Server offers the possibility of using a dynamic selection
mechanism interposed between the service consumer and the target provider
when several versions of the same service share their interface. This selector
allows new implementations, according to SCA, to be added dynamically without
the need of an outage of the application server.
For example, a customer support process might use different human task
implementations during different times of the day. Work is routed to different
support centers (Americas, Europe, and Asia-Pacific) based on the time of day.
WebSphere Process server offers a Web-based interface for dynamic updates to
selection criteria and target services.
As in previous cases, WebSphere Process Server for z/OS supports DB2 V7.x
and DB2 V8.x as target for the deployment of the selection rules.
Chapter 3. WebSphere Process Server and WebSphere Enterprise Service Bus on z/OS
73
Mediation flows
Mediation flows act as a middle tier for messages sent between a service
consumer and provider. The messages can be mediated, to permit activities
such as dynamic routing, and message or protocol transformation.
Mediation flows are part of WebSphere Process Server and are the core
functionality in WebSphere Enterprise Service Bus. We discuss mediations flows
in more detail in 3.3, “WebSphere Enterprise Service Bus for z/OS”.
3.2.4 SOA core
The base functionality underlying the other services in WebSphere Process
Server is the SOA core (shown as the bottom tier in Figure 3-1 on page 67). We
discuss this functionality in this section.
Business objects
Business objects are the universal data description that follow the SOA model,
which requests a single data model and a single invocation model. They are
used as data going in and out of services and are based on the SDO standard
described in “Service Data Objects” on page 33. Figure 3-4 shows a simple view
of the WebSphere Process Server programming model.
Composition
Invocation
Data
WS-BPEL
(plus extensions)
Service components (SCA)
(plus extension)
Service Data Objects (SDO)
(plus extensions)
Figure 3-4 The WebSphere Process Server programming model
74
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
The business object framework provides support for disconnected use of the
data objects by keeping a change history. It also assures relationship integrity
and validation. Figure 3-5 illustrates the layers of this business object framework.
Business Object definition
Business Object Metadata definition
Business Graph definition
Business Object Services
Figure 3-5 Business framework structure
Service component architecture
Service component architecture (SCA) bindings describe the physical description
of components. Services that can be accessed include Plain Old Java Objects
(POJOs), EJBs, Web services, JMS messages and adapters. We discuss SCA
in 2.2.4, “Service Component Architecture” on page 17.
Common event infrastructure
The common event infrastructure (CEI) provides facilities for the generation,
propagation, persistence, and consumption of events. When you plan how to use
the event infrastructure in your system design, you need to understand the
business concepts that are relevant, and map them to the appropriate
components of your system design. You should provide the semantics of event
management by defining event types and event groups, in the context of an
architecture of event sources and event consumers.
WebSphere Process Server supplies a default event group that is defined to
include all events. This event group is called All events.
Chapter 3. WebSphere Process Server and WebSphere Enterprise Service Bus on z/OS
75
Figure 3-6 shows the event infrastructure.
Event Source
Submit
Distribute
Complete
Event Consumer
Event Consumer
Event Consumer
Event Consumer
Query
Store
Event Data
Figure 3-6 Event infrastructure
Events within WebSphere Process Server occur when, for example, a new
process instance is created or a fault has been issued. All event objects are
passed to the event infrastructure to enable tracking of the progress of a
business process, audit, and monitoring.
CEI is the base for monitoring and all events can be sent to the WebSphere
Business Monitor to measure business performance.
In WebSphere Process Server for z/OS both DB2 V7.x and DB2 V8.x are
supported as the event data repositories.
3.2.5 Component organization
This section introduces how the components of WebSphere Process Server are
organized into deployable units.
Modules
A module is a basic deployment unit for a WebSphere Process Server
application. A module contains one or more component libraries and staging
modules used by the application. A component can reference other service
components. Developing modules involves ensuring that the components,
staging modules, and libraries (collections of artifacts referenced by the module)
required by the application are available on the production server.
76
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
WebSphere Process Server supports two types of service modules:
򐂰 Business service modules
򐂰 Mediation modules
Business service modules implement the logic of a process. A mediation module
allows communication between applications by transforming the service
invocation to a format understood by the target, passing the request to the target,
and returning the result to the originator.
With WebSphere Process Server, a service module can either export a service
component for use by other modules or import a service component for use. To
invoke a service component, a calling module references the interface to the
service component. The references to the interfaces are resolved by configuring
the references from the calling module to their respective interfaces.
Note: You can deploy mediation modules to the WebSphere Enterprise
Server Bus or the WebSphere Process Server. You can only deploy business
service modules to WebSphere Process Server.
Business service modules
Business service modules are developed using the WebSphere Integration
Developer's assembly editor. The building blocks of the business solution are
SCA components wired together to form modules that can be deployed to
WebSphere Process Server.
Components are business services that operate on business data. The
WebSphere Integration Developer tools generate implementations that the
assembly editor can use for components. For example, the implementations
include business processes, state machines, human tasks, and so forth. The
structure of the component is simple. It has the following parts:
򐂰 An implementation
򐂰 Optionally, one or more interfaces
򐂰 Optionally, one or more partner references
Components are reusable. That is, they can be wired to new and existing
components to create new applications. Business service modules can contain
all of the components offered by WebSphere Process Server, with the exception
of mediation components.
Mediation modules
Mediation modules are used to create mediation flows. They typically contain a
mediation flow component. For more information about mediation modules, see
“Mediation modules” on page 85.
Chapter 3. WebSphere Process Server and WebSphere Enterprise Service Bus on z/OS
77
3.2.6 Topologies for WebSphere Process Server for z/OS
WebSphere Process Server for z/OS is a complex subsystem that will drive
strategic business for your enterprise. It is very important to plan how and where
it will be implemented. You need to think about your present and future needs
and take the necessary steps to have an stable, reliable and secure
implementation. You need a detailed plan for availability, scalability, failover,
repository and, of course you have to design a topology to achieve your goals.
Clustering in WebSphere Application Server for z/OS
The underlying support for the WebSphere Process Server for z/OS is
WebSphere Application Server for z/OS (see 3.4.1, “WebSphere Application
Server for z/OS advantages” on page 89 for hints about its benefits). Thus, the
application server dictates the possible topologies that you can use. You need to
know how many cells you need, how many nodes in each cell and how many
servers in each node, if you need clusters, and in what logical partitions (LPARs)
you need those clusters.
WebSphere Process Server for z/OS takes advantage of the design of
WebSphere Application Server for z/OS. You have to plan more for failover and
redundancy than for scalability. Workload Manager (WLM) takes care of the
server instances scalability by starting servant regions when needed and
stopping them to free resources and to make them available for other tasks.
A typical WebSphere Application Server for z/OS base runtime includes a cell
with a location service daemon and a single node that includes an application
server made of a controller and one or more servants. After you have installed
the WebSphere Application Server runtime and associated business application
servers on a monoplex, you can migrate the runtime and associated application
servers to a sysplex configuration. A sysplex is the best configuration possible to
obtain full availability and failover.
The benefits of migrating to a sysplex include:
򐂰 You can balance the workload across multiple systems, therefore providing
better performance management for your applications.
򐂰 As your workload grows, you can add new systems to meet demand,
therefore providing a scalable solution to your processing needs.
򐂰 By replicating the runtime and associated business application servers, you
provide the necessary system redundancy to assure availability for your
users. Therefore, in the event of a failure on one system, you have other
systems available for work.
򐂰 You can upgrade the application server from one release or service level to
another without interrupting service to your users.
78
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
The technique used in WebSphere Application Server to associate applications
with groups of servers that execute them and are able to do failover among them
is called clustering. When you create a cluster, you make copies of an existing
application server template. The template is most likely an application server that
you have configured previously.
You are offered the option of making that server a member of the cluster.
However, it is recommended that you keep the server available only as a
template, because the only way to remove a cluster member is to delete the
application server. When you delete a cluster, you also delete any application
servers that were members of that cluster. There is no way to preserve any
member of a cluster. Keeping the original template intact allows you to reuse the
template if you need to rebuild the configuration.
A vertical cluster has cluster members on the same node, or physical machine. A
horizontal cluster has cluster members on multiple nodes across many machines
in a cell. You can configure either type of cluster, or have a combination of
vertical and horizontal clusters.
A sysplex is a way to obtain ultra-reliable horizontal clustering.
Clustering in WebSphere Process Server for z/OS
Consider the following before creating a clustered environment for WebSphere
Process Server for z/OS.
򐂰 Ensure that you have adequate resources to implement clustering
successfully.
򐂰 Analyze the service applications that you will deploy into the clustered
environment. Some of the optional steps you perform depend on the needs of
the service applications.
򐂰 Ensure that the application logic is tolerant of a clustered environment.
Familiarize yourself with network deployment and clustering as described in
the WebSphere Application Server for z/OS information center.
򐂰 Configure WebSphere Application Server for z/OS to support a WebSphere
Process Server for z/OS clustered environment.
You can find a detailed description of all these tasks at:
http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/index.jsp
Chapter 3. WebSphere Process Server and WebSphere Enterprise Service Bus on z/OS
79
There are some interesting configurations worth considering:
򐂰 Support of WebSphere Process Server applications from another server or
cluster
In this scenario, the cluster or server does not host WebSphere Process
Server applications. However, it can host the business rules manager and
JMS queues (destinations) used by applications running on remote servers or
clusters. The JMS destinations are hosted in the messaging engines that
execute in the server or cluster.
򐂰 Support of WebSphere Process Server applications without supporting bus
members
A cluster or server can be configured as a deployment target for WebSphere
Process Server applications. The destinations for the applications can be
hosted on the same cluster or server as the applications or on a remote
cluster or server. Note that when you set up a cluster or server to host
applications, the SchedulerCalendar application is automatically installed as
part of the configuration.
If you are planning to use WS-BPEL business processes on this cluster or
server, you must also use the Business Process Container wizard to perform
the necessary configuration.
If you are planning to use applications that contain human tasks or if you plan
to use the Business Process Choreographer Explorer in this cluster or server,
you must also use the Human Task Container wizard to perform the
necessary configuration.
򐂰 Support of WebSphere Process Server applications and bus members
A cluster or server can be configured to both host WebSphere Process
Server applications and support WebSphere Process Server applications that
are installed on remote clusters or servers. In this configuration scenario, the
application buses are configured for the current cluster or server. In addition,
the SchedulerCalendar application is automatically installed to provide
support for hosting WebSphere Process Server applications. In this scenario,
the destinations for the applications can be hosted on the same cluster or
server as the applications themselves or on a remote location.
It is especially easy to use this kind of configuration with WebSphere Process
Server for z/OS because application server instances in WebSphere
Application Server for z/OS have built-in clusterization using WLM and
starting and stopping servants as needed.
Since WebSphere Application Server for z/OS V6.0, the architecture of an
application server instance has been improved with the control region adjunct
(CRA), which adds a newly started task to the ones that an application server
instance already has. The control region (CR) and the multiple servant regions
80
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
(SR) each contain a JVM. This CRA is now in charge of all messaging tasks
within an application server instance. This means that the messaging engine for
a process server is separated in application server instances in WebSphere
Application Server for z/OS and scalability for a process server is done by the
system without additional tasks. The number of connections is managed in the
CRA and you can control them through variables.
There are a number of considerations to be made about the bus and how to
manage buses in the environment of a process server. We discuss these in
3.3.2, “Topologies for WebSphere Enterprise Service Bus for z/OS” on page 87.
3.3 WebSphere Enterprise Service Bus for z/OS
Using an ESB to implement an SOA has a number of advantages. In an SOA,
services should, by definition, be reusable by a number of different consumers,
so that the benefits of reduced connections are achieved. In addition the ESB:
򐂰 Supports high volumes of individual interactions.
򐂰 Supports more established integration styles, such as message-oriented and
event-driven integration, to extend the reach of the SOA. The ESB should
allow applications to be SOA-enabled either directly or through the use of
adapters.
򐂰 Supports centralization of enterprise-level qualities of service and
manageability requirements into the hub.
3.3.1 Architectural overview
This section gives an overview of the WebSphere Enterprise Service Bus
product. This product shares many of the same concepts as WebSphere
Process Server because both products adhere to the principles and philosophy
of an SOA and the SCA.
Note: For more details on the WebSphere Enterprise Service Bus V6, refer to
Getting Started with WebSphere Enterprise Service Bus V6, SG24-7212.
The WebSphere Enterprise Service Bus for z/OS is built upon WebSphere
Application Server for z/OS and provides the capabilities of a standards-based
ESB.
WebSphere Enterprise Service Bus is the mediation layer that runs on top of the
transport layer within WebSphere Application Server. As such, WebSphere
Enterprise Service Bus provides prebuilt mediation functions and easy-to-use
Chapter 3. WebSphere Process Server and WebSphere Enterprise Service Bus on z/OS
81
tools to enable rapid construction and implementation of an ESB as a value-add
on top of WebSphere Application Server.
Figure 3-7 shows the components in WebSphere Enterprise Service Bus.
Mediation Flows
(ESB)
Service Component
Architecture
Business
Objects
Common Event
Infrastructure
WebSphere Application Server
Figure 3-7 WebSphere Enterprise Service Bus V6.0.1 components
Because WebSphere Enterprise Service Bus is based upon WebSphere
Application Server, it leverages WebSphere Application Server attributes such
as clustering, failover, scalability, security, and a built-in messaging provider.
WebSphere Enterprise Service Bus itself provides the following capabilities:
򐂰 Provides built-in mediation functions, which can create integration logic for
connectivity.
򐂰 The SCA programming model supports rapid development of mediation flow
components.
򐂰 Leveraging WebSphere Application Server, WebSphere Enterprise Service
Bus offers JMS messaging and WebSphere MQ interoperability for
messaging, as well as a comprehensive clients package for connectivity.
򐂰 Offers support for J2EE Connector Architecture based WebSphere Adapters.
82
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
WebSphere Enterprise Service Bus supports connectivity between endpoints
through a variety of protocols and application programming interfaces (APIs):
򐂰 Java Message Service (JMS) 1.1, provided by WebSphere Application
Server. Applications can exploit a variety of transports, including TCP/IP,
SSL, HTTP, and HTTPS.
򐂰 Web services standards that enable applications to make use of Web service
capabilities.
– SOAP/HTTP, SOAP/JMS, WSDL 1.1
– UDDI 3.0 Service Registry, Web Services Gateway
򐂰 For back-end applications (such as SAP), several IBM WebSphere Adapters
(based on the J2EE Connector Architecture) are available.
As with WebSphere Process Server, to implement an SOA properly it is
necessary to have a single invocation model and a single data model. Service
Component Architecture (SCA) is this invocation model — every integration
component is described through an interface. These services can then be
assembled in a component assembly editor thus enabling a very flexible and
encapsulated solution.
WebSphere Enterprise Service Bus introduces a new component type to the
SCA model — the mediation flow component. From the perspective of the SCA,
a mediation flow component is not different from any other service component.
Business Objects are the universal data description. They are used as data
objects are passed between services and are based on the SDO standard. In
WebSphere Enterprise Service Bus a special type of SDO is introduced, the
Service Message Object (SMO).
Mediation capabilities
The mediation capabilities of WebSphere Enterprise Service Bus are performed
in SCA mediation flow components. Mediation flow components operate on
messages exchanged between service end points. In contrast with regular
business application components, they are concerned with the flow of the
messages through the infrastructure and not just with the business content of the
messages. Rather than performing business functions, they perform routing,
transformation and logging operations on the messages. The information that
governs their behavior is often held in headers.
Mediation flow components manage the flow of messages between
SCA-described interaction endpoints and enable the quality of interaction these
components request. Mediation modules within the ESB handle mismatches
between consumers and providers, including protocol or interaction-style
mismatches and interface mismatches. In an overall SCA-based solution,
Chapter 3. WebSphere Process Server and WebSphere Enterprise Service Bus on z/OS
83
mediation modules are a type of SCA module that perform a special role, and
therefore, have slightly different characteristics than other components that
operate at the business level.
To summarize, mediation flow components:
򐂰 Centralize the routing logic so that service providers can be exchanged
transparently
򐂰 Perform tasks like protocol translation and transport mapping
򐂰 Act as a facade in order to provide different interfaces between service
consumers and providers
򐂰 Add logic to provide tasks such as logging
Figure 3-8 illustrates how mediations customize the protocol and the details of a
request and also modify the results of the reply.
WebSphere
Enterprise Service Bus
Service
Consumer
Service
Provider
Request
Service
Consumer
Service
Provider
Mediation
Reply
(optional)
Service
Consumer
Service
Provider
Figure 3-8 Mediation component in the WebSphere ESB
84
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Mediation modules
The mediation module is a new type of SCA component that can process or
mediate service interactions. As illustrated in Figure 3-9, the mediation module is
externalized or made available through an export, which specifies the interfaces
that are exposed. These interfaces are defined in a WSDL document.
The mediation module typically invokes other service providers. These providers
are declared with the creation of an import, which represents an external service
to be invoked.
Data Types
Library
Interfaces
Mediation Module
Exports
Imports
Service
Consumer
SCA
Client
Stand-alone
References
Data Types
Interfaces
Service
Provider
Bindings
Service
Provider
Reference
Figure 3-9 Mediation modules
Mediation primitives
Mediation primitives are the smallest building blocks in WebSphere Enterprise
Service Bus. They are wired and configured inside mediation flows. They let you
change the format, content, or target of service requests; log messages; do
database lookups; and so forth.
WebSphere Integration Developer and WebSphere Enterprise Service Bus
V6.0.1 provides the following standard mediation primitives:
򐂰 The MessageLogger primitive logs a copy of a message to a database for
future retrieval or audit. The integration developer can customize the primitive
by, for example, naming the database.
򐂰 The DatabaseLookup primitive retrieves values from a database to add them
to a message.
Chapter 3. WebSphere Process Server and WebSphere Enterprise Service Bus on z/OS
85
򐂰 The MessageFilter primitive compares the content of a message to
expressions configured by the developer, and routes the message to the next
mediation primitive based on the result.
򐂰 The XSLT primitive transforms messages according to transformations
defined by an XSL style sheet.
򐂰 The Fail primitive throws an exception and terminates the path through the
mediation flow.
򐂰 The Stop primitive silently terminates the path through the mediation flow.
򐂰 The Custom mediation primitive allows the user to implement their own
mediate method using Java. The Custom mediation, like the other primitives,
receives a Service Message Object and returns a Service Message Object. It
can be used to perform tasks that cannot be performed by using the other
mediation primitives.
Figure 3-10 shows how mediation primitives are used.
Data Types
Library
Interfaces
Mediation Module
Mediation Flow Component
Service
Consumer
Exports
Stand-alone
Reference
SCA
Client
Service Message Object
Interfaces
Context
Headers
Input
Response
Input
Fault
Service
Provider
Request Flow
Input
terminal
Mediation
Mediation
Primitive
Primitive
Input
Response
Imports
Mediation Flow
Body
Partner
Output
References
terminal Callout(s)
Fall
terminal
Fault
Response Flow
Mediation
Mediation
Primitive
Primitive
Service
Provider
Callout
Response
Wires
Figure 3-10 Mediation primitives (in the complete overview)
86
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
3.3.2 Topologies for WebSphere Enterprise Service Bus for z/OS
As for WebSphere Process Server for z/OS (see 3.2.6, “Topologies for
WebSphere Process Server for z/OS” on page 78), topologies for WebSphere
Enterprise Service Bus for z/OS are mainly imposed by those of WebSphere
Application Server for z/OS: sysplex and server clustering are the main
considerations when you need high availability for your WebSphere Enterprise
Service Bus for z/OS.
Internally, messages passed through mediations in WebSphere Enterprise
Service Bus are stored in a service integration bus. These service integration
buses are made out of messaging engines that live inside application servers.
These application servers might, or might not, be part of a cluster of servers, as
shown in the examples in Figure 3-11 on page 87.
Bus
Cluster
Application server
Application server
Messaging
engine
Messaging
engine
Data
store
Bus
Bus destination
Cluster
Application
server
Application
server
Application
server
Messaging
engine
Messaging
engine
Messaging
engine
Q1
Q1
Bus destination
Application
Application
Q1
Partitioned
destination
Application
Figure 3-11 Service integration buses with clustered servers
Chapter 3. WebSphere Process Server and WebSphere Enterprise Service Bus on z/OS
87
When you configure a server bus member, that server runs a messaging engine.
For many purposes this is sufficient, but such a messaging engine can only run
in the server it was created for. Therefore, the server is a single point of failure. If
the server cannot run, the messaging engine is unavailable. By configuring a
cluster bus member instead, the messaging engine has the ability to run in one
server in the cluster, and if that server fails, the messaging engine can run in an
alternative server.
High availability and workload sharing topologies
The configuration of service integration buses is very flexible. You can have
individual messaging engines, or clusters containing multiple messaging engines
that can share workload, be highly available, or both.
The type of bus member that you create affects the options that you have
available to you. You create a bus member by adding either a server or a cluster
to a bus. Creating a server bus member creates a single messaging engine. For
many purposes, this messaging engine is sufficient, but such a messaging
engine is a single point of failure and cannot share workload. If you want to avoid
a single point of failure by allowing failover or if destinations need to be
partitioned (to allow sharing of the messaging workload), use a cluster bus
member.
After you have created a bus member, you configure a policy to control the
availability behavior of the messaging engine on that bus member. If you want
high availability, use a cluster bus member and the default policy (one of N),
which allows the messaging engine to failover. You can customize your policy to
specify other availability behavior, such as a preference for particular servers.
If you want workload sharing but not high availability, use a cluster bus member
and create a static policy for each messaging engine. This policy is useful for
scalable express messaging, where there is no persistent state associated with
any one messaging engine so no failover is required.
With these options, it is possible to achieve either failover, workload sharing, or
both. The following provide some useful configurations:
򐂰 Simple configuration: Single messaging engine running inside an
application server. In WebSphere Enterprise Service Bus for z/OS there is the
advantage of having several servants in the application server and the last
level of workload balancing provided by the WLM at servant level.
򐂰 Workload sharing configuration: Multiple messaging engines (one per
application server) clustered together, message engines are restricted to
running in their application servers. Same considerations as before apply to
WLM.
88
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
򐂰 High availability message engine configuration: Single messaging engine
running in a cluster. It lives in more than one application server so that there
is failover to the rest of servers in the case of maintenance or a system crash.
If the cluster is horizontal and sysplex wide, WLM policies for workload
through the sysplex apply.
򐂰 High availability messaging engines with workload sharing: A
combination of the two previous options. Multiple messaging engines running
in a cluster with messaging engines being able to failover to one or more
application servers in the cluster. Both, local WLM policy for servants in an
application server and sysplex-wide policy for the cluster apply here.
3.4 WebSphere Process Server and WebSphere
Enterprise Service Bus for z/OS at the core of your
business
System z and z/OS can help execute and keep your business data secure. Now,
SOA brings the possibility of reusing these assets, re-engineering your
applications, and establishing new business processes. WebSphere Process
Server and WebSphere Enterprise Service Bus for z/OS can connect and exploit
your core data. They can manage transactions inside and outside your business
processes.
In this section, we outline how you can take advantage of the System z and z/OS
platform and operating system advantages when using WebSphere Process
Server and WebSphere Enterprise Service Bus for z/OS.
3.4.1 WebSphere Application Server for z/OS advantages
WebSphere Application Server for z/OS is the underlying technology for many of
the new generation products that IBM has released in the last few years. Some
of the most significant products that build upon WebSphere Application Server
for z/OS are:
򐂰
򐂰
򐂰
򐂰
WebSphere Process Server for z/OS
WebSphere Enterprise Service Bus for z/OS
WebSphere Portal Server for z/OS
Host Access Transformation Services on z/OS
Chapter 3. WebSphere Process Server and WebSphere Enterprise Service Bus on z/OS
89
These products inherit the unique characteristics that make this application
server unique in the family. Figure 3-12 illustrates its critical capacities for the
business logic tiers.
Ultimate
scalability &
performance;
functional
depth &
breadth
Customer
Needs
Multiple
Multiple Business
Business Models,
Models,
Multiple
Deployment
Multiple Deployment Options
Options
WebSphere Application
Server for z/OS
WebSphere
Application Server
Network Deployment
WebSphere
Application Server
WebSphere
Application Server Express
Reduced
acquisition
costs;
Small
footprint..
WebSphere Application
Server Community
Edition
Built on common WebSphere code
Built on open source technology
Fast deployment of single app;
low transaction volumes…
Capabilities
High transaction volumes, High
Availability, Advanced Web Services…
Figure 3-12 The WebSphere Application Server family
The most important things to keep in mind about WebSphere Application Server
for z/OS are:
򐂰 It is a multi-process server. Each application server instance is made of a CR,
a CRA that provides the home for the WebSphere Platform Messaging
components, and one or more SR providing one JVM each to the application
server instance.
򐂰 Dynamic workload management and priority selection. WLM is in charge of
this task. It works at three levels of decisions to make the most of your
resources. It works in the middle of the CR and CRA and all the SRs of an
application server instance. It works at system, z/OS, level to apply execution
priorities and velocity goals to be sure that the system responds as you want.
And finally, it works at a sysplex level when several systems are involved and
working together as though they were one; in this case there is workload
management and failover if one of the systems in the ring is stopped for
maintenance or, less probable, hardware failure.
90
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
򐂰 Transactional behavior managed by the Resource Recovery Services (RRS).
RRS is an exit manager. That means RRS itself does not perform tasks such
as commit changes to a DB2 database or back out changes to a process
transaction. Instead, RRS triggers resource manager-supplied exits based on
certain events. An application can request RRS to commit a unit of recovery
(UR), and RRS then invokes the commit exits for all the resource managers
involved in the UR. It is a prerequisite for WebSphere Application Server for
z/OS and therefore also for WebSphere Process Server and WebSphere
Enterprise Service Bus for z/OS.
򐂰 zAAP engine for the execution of Java. It is a central processor (CP), much
cheaper than general CPs in System z, that you can enable in z/OS to
execute all Java loads wherever they come from in z/OS (such as the CICS
EJB container, stand-alone Java programs in USS, WebSphere Application
Server, and so forth).
򐂰 Proximity to data. Accesses from an application server, a process server and
an ESB to resources running in environments such as DB2, CICS, or IMS is
much quick and secure if all subsystems are in z/OS.
򐂰 Stringent centralized security. See 5.1, “Security” on page 120.
3.4.2 z/OS advantages
IBM System z has, for a long time, run the core IT systems of many successful
businesses, from medium size to very large. During these years, IBM has
invested consistently in the evolution of the System z. System z has incorporated
new technologies and computing models, from the Centralized model to the Web
model, from the Assembler and Cobol languages to Java. Today, System z
provides the necessary capabilities to form the backbone in an enterprise SOA
solution.
In this section, we describe some of the key advantages of z/OS that are relevant
to a solution using WebSphere Process Server or WebSphere Enterprise
Service Bus on z/OS.
Well-known advantages
The z/OS operating system provides a comprehensive set of capabilities and
tools ready to use without modification that provide several well-known qualities.
The z/OS operating system is able to provide high levels of qualities of service in
combination with the System z hardware and Parallel Sysplex capabilities.
Chapter 3. WebSphere Process Server and WebSphere Enterprise Service Bus on z/OS
91
The generally recognized z/OS strengths fall into a number of broad categories:
򐂰 Centralized computing model
Server consolidations brings advantages in fewer administration and
maintenance staff required to manage systems. Hardware duplication and
reliable systems such as System z are desirable for this model.
򐂰 Security
z/OS provides deep security integration. RACF and SAF are centralized and
can provide overall security for your sysplex and LPARs.
RACF security extends beyond z/OS. You can use RACF for other platforms
including Virtual Machine (VM) and Linux for System z if it executes on VM.
Other services are provided for security, such as auditing and logging,
accountability, cryptography and network security.
򐂰 Manageability
The z/OS operating system has been designed to manage multiple workloads
in a single system image; so, z/OS has evolved along the years and it
equipped with features that make the most of workload managing. It also has
tools and subsystems to manage and monitor the system and all the existing
applications running in it.
򐂰 Virtualization and workload management
z/OS Parallel Sysplex capabilities allow configurations of large numbers of
partitions to be run as a single system sharing resources. Workload Manager
(WLM) controls the workload among partitions and prioritization of work.
Intelligent Resource Director (IRD) can dynamically assign central processor
(CP) resources for all partitions in that hardware so that each LPAR gets the
resources virtually assigned to it.
򐂰 Reliability
The combination of hardware redundancy, in only one box, and virtualization
gives extraordinary possibilities for application recovery and availability.
Hardware failures and software failures can be recovered: transactional
integrity is mandatory. Proper configuration can lead to a solution with no
single points of failure.
򐂰 Availability and scalability
System z can be vertically scaled up to 54 CPs. The z/OS Parallel Sysplex
can cluster up to 32 images with geographic dispersion possibilities, up to 100
km. Horizontal scalability is not limited for any kind of workload being
executed in z/OS.
92
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
򐂰 Transaction processing
Many subsystems on z/OS are transactional resource managers working in
collaboration with Recoverable Resource Services (RRS). These subsystems
include CICS Transaction Server, IMS, WebSphere Application Server for
z/OS, WebSphere Process Server for z/OS, WebSphere Enterprise Service
Bus for z/OS, and DB2.
򐂰 Batch processing
Job Entry Subsystems (JES2 and JES3) are batch managers in z/OS. They
can work in combination with Tivoli products to schedule batch and manage
workload.
Less well known advantages
Much effort has been made to achieve new capacities for z/OS. In addition to the
well known values that we have described, some interesting characteristics are
now part of the platform:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
Open standards and technologies
Integral architecture
New interfaces for the user
Built-in solutions
Unified skills for new subsystems
Full control
Open standards and technologies
Since the emergence of the Internet as a multipurpose network and the
generalized use in all our homes and workplaces, multiple needs for users and
enterprises have emerged. The development of new technologies increases the
need for communication and exchange of data. To achieve this, institutions and
providers usually adhere to standards.
z/OS has evolved to support all the main standards for enterprise servers with
the goal of continuing to be the core for new and well established businesses.
The introduction into z/OS of the UNIX® System Services (USS) and TCP/IP
was the first step. With these strategical update, z/OS was opened up to
communications within the Internet where TCP/IP is the de facto standard. USS
is compliant with the POSIX 1003.2 specification opening a whole world of
application and interface exchange with UNIX-based systems.
Other standards have emerged within a z/OS environment:
򐂰 HTTP protocol support, which is a widely adopted standard for internet
communication.
Chapter 3. WebSphere Process Server and WebSphere Enterprise Service Bus on z/OS
93
򐂰 Full J2EE compliance, through a stand-alone JVM implementation, and JVM
implementations provided with products such as WebSphere Application
Server for z/OS and CICS Transaction Server.
򐂰 Web services, initially present in WebSphere Application Server, and now
extended to traditional execution environments such as CICS and IMS. The
XML Toolkit for z/OS enables subsystems and applications to work with the
XML markup language.
򐂰 SCA support to implement an advanced SOA solution. WebSphere Process
Server and WebSphere Enterprise Service Bus for z/OS support this.
Integral architecture
Several operating systems can be installed and executing on a System z. With
the combination of z/OS, VM and Linux for System z we can have users coming
to and from the internet to execute transactional applications and services in a
secured, fast, reliable one box solution.
Figure 3-13 on page 95 shows a possible architecture for the use of multiple
operating systems on System z. We might have some Linux for System z images
on a VM operating system. The Linux farm is composed of proxies and Web
servers in a demilitarized zone (DMZ) and might contain some presentation layer
applications such as WebSphere Application Server for multi-platforms. Behind
this, we have z/OS images with transactional applications such as WebSphere
Application Server for z/OS, CICS, and IMS. On top of WebSphere Application
Server for z/OS we can install WebSphere Process Server to manage business
processes and WebSphere Enterprise Service Bus to perform the role of an
ESB.
Given that there are specialized engines both for Java execution on z/OS (zAAP)
and Linux on System z (IFL), the combination seems to be especially powerful.
94
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Linux images
S
J
WebSphere Process
Server for z/OS
or
WebSphere Enterprise
Service Bus for z/OS
DB2
CICS
WebSphere Application
Server for z/OS
z/VM
IMS
z/OS image
System z
Figure 3-13 Integral architecture in one box
New interfaces for the user
Some years ago, there were two main ways of using applications executed on a
System z: 3270 screens or fat clients managing the screens and
communications.
The situation is quite different today. Thousands of users can execute
applications on the System z, at the same time, from their desktops or mobile
computers using a preferred browser:
򐂰 IBM HTTP Server comes with the z/OS package for those who want to make
simple informative sites.
򐂰 WebSphere Application Server for z/OS gives the full J2EE power for
presentation and transactional layers needed to put enterprises’ businesses
on the Internet.
򐂰 WebSphere Portal Server for z/OS completely changes the user experience
by providing applications based on a user profile. A user’s browser screen
can include a customized set of portlets that allow the user to complete a
specific task.
򐂰 Host Access Transformation Services (HATS) wraps 3270 screens offered by
CICS and IMS and makes them available in a Web browser.
Chapter 3. WebSphere Process Server and WebSphere Enterprise Service Bus on z/OS
95
򐂰 Host on Demand makes life easier for those who have to manage and to
install screen emulators throughout the whole enterprise. It makes the
emulation available from a browser.
Of course all the traditional access ways to the System z continue valid.
Built-in solutions
z/OS is not just an operating system, but a package that includes the operating
system itself and more than 30 built-in solutions. The full package comes with
everything that is required to build a robust IT software infrastructure. It includes
security services, communication services, performance and accounting
services, compilers, storage management services, an HTTP server, clustering
capabilities, and more.
z/OS also offers advantages in monitoring, accounting and auditing. For
example, if you would like to know with whom and when users have been
consuming services in your integration structure through a process executed in
WebSphere Process Server for z/OS, you can use SMF for the accounting and
billing for that services. Doing this in other platforms might require specific
application coding.
Unified skills for new subsystems
WebSphere Application Server V5 was the first application server release to use
a common code base, no matter which platform the application server is installed
on. This common code base ensures that any WebSphere Application Server
application developed for one platform should be able to run, unchanged, on any
other WebSphere Application Server platform.
This same principal applies to WebSphere Application Server V6, and also the
following products that are built on top of WebSphere Application Server V6:
򐂰
򐂰
򐂰
򐂰
WebSphere Process Server on all platforms
WebSphere Enterprise Service Bus on all platforms
WebSphere Portal Server on all platforms
Host Access Transformation Services
This common code policy unifies administration tasks. A person administering on
WebSphere Process Server on Linux can also be the administrator for
WebSphere Process Server on Windows® or z/OS.
96
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Full control
z/OS is a powerful versatile system. You can adapt it to your needs in thousands
of different configurations. This is also applicable to the products and
subsystems you can run on it. Hundreds of combinations of variables can make
the overall system, or just one of the subsystems, behave exactly as you want. It
is fully customizable.
When you make changes to the system, you can update the whole system or just
update one executable module. You get exactly what you want from the
operative system and its installed features.
Chapter 3. WebSphere Process Server and WebSphere Enterprise Service Bus on z/OS
97
98
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
4
Chapter 4.
Operational considerations
In this chapter, we discuss the operational considerations of installing and
administering WebSphere Process Server and WebSphere Enterprise Service
Bus for z/OS.
Note: We do not provide step-by-step instructions on how to complete all of
the tasks that we discuss here. Instead, we provide an overview of the entire
process and point to additional resources for a more in-depth discussion.
© Copyright IBM Corp. 2006. All rights reserved.
99
4.1 Installing
In this section, we discuss actions that you should consider when installing
WebSphere Enterprise Service Bus and WebSphere Process Server for z/OS.
You have the choice between several architectural options. For each of these
options, there is a different path that you should follow for installation.
This chapter does not provide a step-by-step installation tutorial, but it does point
you to items that you should know when installing the product and special
aspects of the z/OS environment.
4.1.1 Prerequisites and packaging
This section details the software and hardware requirements that are required for
installation.
Software requirements
The following software is required to run WebSphere Enterprise Service Bus and
WebSphere Process Server on z/OS:
򐂰 z/OS or z/OSe version 1.4 or higher with the following features:
– z/OS Communications Server (TCP/IP) or equivalent
– z/OS UNIX System Services and the hierarchical file system (HFS)
– SecureWay® Security Server (RACF) or equivalent security management
product
– System logger
– System SSL security required when using SSL
– Workload management in goal mode
– Resource Recovery Services (RRS)
You can run WebSphere Enterprise Service Bus and WebSphere Process
Server without needing any additional software. However there are some
software products that are highly recommended to use in production
environments:
򐂰 z/OS(e) 1.6 or higher
For best system performance and features.
򐂰 IBM HTTP Server for z/OS or equivalent
To place the HTTP handling in its own tier.
100
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
򐂰 DB2 Universal Database Server for z/OS, Version 7 or higher
WebSphere Enterprise Service Bus and WebSphere Process Server need
the stored procedure builder enabled (DSNTPSMP) if you use relationships.
򐂰 CICS TS v2.2 or higher
If you want to integrate CICS applications, you should have at least CICS TS
v2.2. However, we recommend CICS v3.1, which provides features for Web
service enablement capabilities.
򐂰 Information Management System IMS v8.1 or later; IMS Connect v2.2
For integration of IMS applications you need IMS Connect, even if you plan to
connect to IMS using Web services, because it delivers the TCP/IP features
needed for Web service enablement.
򐂰 LDAP
The suitable backend for identity management needed for integrating human
tasks.
On a distributed platform, you should also install at a minimum WebSphere
Integration Developer, v6.0.1.1. It is the only development environment that
provides full feature support for WebSphere Enterprise Service Bus and
WebSphere Process Server.
Hardware requirements
WebSphere Enterprise Service Bus and WebSphere Process Server run on any
hardware that supports z/OS or z/OSe from version 1.4.
However, for optimal performance, the following hardware features are
recommended:
򐂰 zAAP
The zSeries Application Assist Processor (zAAP) is an inexpensive way of
processing high volumes of Java workload. WebSphere Process Server and
WebSphere Enterprise Service Bus use Java at their core.
򐂰 Crypto Engine
The crypto engines are special processors that handle cryptographic
calculations, which are needed for many security tasks.
򐂰 DataPower appliances
XML appliances from DataPower can be used as a security gateway for XML
or Web service based messages.
Chapter 4. Operational considerations
101
Note: You can run the products without these features. However,
WebSphere Enterprise Service Bus and WebSphere Process Server are
products that use the value of these hardware features.
4.1.2 Installation considerations
The installation of WebSphere Enterprise Service Bus and WebSphere Process
Server consists of two separate steps:
1. Installing and customizing WebSphere Application Server.
2. Installing the additional product, which is either:
– WebSphere Enterprise Service Bus
– WebSphere Process Server (which contains WebSphere Enterprise
Service Bus)
Although we do not discuss WebSphere Application Server installation in detail,
you have to consider some architectural options when planning the installation.
Depending on the purpose, there are various architectural options that you can
realize when installing WebSphere Enterprise Service Bus and WebSphere
Process Server. We mention the most important options for the most common
usage scenarios. Furthermore, we discuss some aspects of the installation of
WebSphere Enterprise Service Bus and WebSphere Process Server on top of
WebSphere Application Server.
Installing WebSphere Application Server for z/OS
The installation of WebSphere Application Server for z/OS consists of two parts:
1. Installing the program code from tape using System Modification
Program/Extended (SMP/E).
2. Customizing WebSphere Application Server to create a configuration of your
choice. You have the choice between two architectural configurations:
a. Base server: a stand-alone application server. On z/OS, you have the
opportunity with even a stand-alone server to spread the workload over
several servant regions. A base server is made of a cell and a node that
contains one application server instance.
A cell is an administrative domain from which server instances can be
administered. A node is a bunch of application server instances that share
some properties and configuration.
An application server instance is made of three basic started tasks in the
system: a controller region (CR), a controller region adjunct (CRA) that is
in charge of messaging, and JMS (this task can be stopped if no
102
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
messaging is used) and one or more servant regions (SRs). These SRs
effectively contain the applications and are where the JVMs live.
You can join the base servers to a node in a broader configuration similar
to WebSphere Application Server Network Deployment. This process is
called federation.
b. WebSphere Application Server Network Deployment: A Network
Deployment architecture contains at least two nodes in one cell. One is for
the Deployment Manager, with an application server instance. It is where
the administration console application is deployed at installation time.
The second node contains at least one application server, used to deploy
J2EE applications.
You can have several nodes in this cell and they can expand through
several other systems.
With this configuration you can also make clusters of application server
instances. These clusters consist of two or more servers created from a
common template. They might have different configurations, but the
applications executed on them have to be exactly the same.
Attention: Currently, it is not possible to federate WebSphere Enterprise
Service Bus or WebSphere Process Server based on a stand-alone
WebSphere Application Server into a Network Deployment cell to become
part of a Network Deployment configuration after installation.
For more information about the installation of WebSphere Application Server for
z/OS, consult:
ftp://ftp.software.ibm.com/software/webserver/appserv/library/v60/BO
S5A102.pdf
Installing WebSphere Enterprise Service Bus or WebSphere
Process Server for z/OS
WebSphere Enterprise Service Bus and WebSphere Process Server rely on
WebSphere Application Server and, therefore, need WebSphere Application
Server already installed.
Note: The installation of WebSphere Enterprise Service Bus and
WebSphere Process Server on top of WebSphere Application Server for
z/OS does not use the Interactive System Productivity Facility (ISPF) but is
completely based on USS shell scripts.
Chapter 4. Operational considerations
103
The installation of WebSphere Enterprise Service Bus or WebSphere Process
Server has several steps:
1. Install WebSphere Enterprise Service Bus/WebSphere Process Server into
your WebSphere Application Server profile. The installation is done by the
UNIX System Services (USS) shell script zSMPInstall.sh.
The script performs the following steps:
– Links the <WAS_HOME> variable to the WebSphere Process Server SMP/E
code
– Updates the Administrative Console for WebSphere Enterprise Service
Bus/WebSphere Process Server
– Runs PTF to apply any available product updates
2. Create the database and storage groups. You need to create these groups
now, because you will use them in the next step to create the SQL and DDL
scripts.
3. Augment the WebSphere Application Server profile to use the WebSphere
Process Server or WebSphere Enterprise Service Bus function. This step is
performed by the zWPSConfig.sh or zWESBConfig.sh shell script respectively.
These scripts require response files providing the necessary configuration
information. The following definitions are created:
– Resource definitions
– Resources (databases, buses, queues)
Database information in the response file must match the names that you
used to create the database and storage groups.
4. If you chose not to run the .sql/.ddl scripts automatically through the response
file property setting, run the .sql/.ddl scripts that are generated by script of
step 3 to configure the databases.
5. Create the DB2 datasources for Service Integration Bus (SIB) resources
using the WebSphere Application Server Administrative Console (if DB2 is
used). For a simple initial installation, we recommend that you use
Cloudscape for persistence instead of DB2.
6. Configure Business Process and BPEL/HTM containers using the
bpeconfig.jacl script or the WebSphere Application Server Administrative
Console installation wizard.
104
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Note: The installation wizard configures WebSphere Application Server
resources only. If you choose to configure the business process container
by using the installation wizard, you still need to run the corresponding
manual steps to create a database (using Cloudscape or DB2 ) and to
create the WebSphere MQ queues (if you are using WebSphere MQ as
your JMS provider).
7. Configure the Common Event Infrastructure (CEI) using the
event-message.jacl script or the WebSphere Application Server
Administrative Console.
To learn more about scripting, refer to 4.2.2, “Scripting” on page 110.
Note: Installing WebSphere Enterprise Service Bus and WebSphere Process
Server is not trivial. Therefore, to reduce the complexity of troubleshooting, we
recommend installing and configuring these products in three stages:
1. Install a stand-alone server, with Cloudscape.
2. Install a stand-alone server, with DB2.
3. Install a network deployment cell with DB2.
By getting the simplest configuration running first and then adding additional
complexity later, you can better solve installation and configuration issues.
4.2 Administration
In this section, we discuss administrating WebSphere Process Server and
WebSphere Enterprise Service Bus on z/OS. Unless explicitly mentioned, there
is no difference in the administration between the distributed versions of these
products, which is an advantage of the common code base that each of the
products shares through all of the platforms on which they are available.
Note: Administration looks similar on every platform on which you use
WebSphere Process Server or WebSphere Enterprise Service Bus.
Chapter 4. Operational considerations
105
When talking about administration, we must consider two different levels of
administrative tasks:
򐂰 The technical layer, which includes connections to data sources or network
interfaces, supported protocols, and the right use of available resources.
򐂰 The administration of business processes and mediation flows themselves.
You must have the opportunity to start a business process, complete human
tasks, or stop a running process if necessary.
For each of these administrative tasks, you can use the standard toolkit or create
your own tools.
When using the standard toolkit, you can perform every basic task that you need.
When performing complex tasks such as bringing up servers conditionally or
completing a human task of a business process by using external data, you will
likely want to write tools that provide better support than the standard tools.
Note: You always have the choice between performing an administration task
by using the standard administration interfaces or building your own
customized tools.
4.2.1 The Administrative Console
The Administrative Console is a Web-based tool that you use to manage
WebSphere Application Server as well as WebSphere Enterprise Service Bus
and WebSphere Process Server. In addition to performing basic tasks that affect
the features and behavior of WebSphere Application Server, the Administrative
Console provides functions to administer special features of WebSphere
Enterprise Service Bus and WebSphere Process Server.
Note: The Administrative Console provides a single point of administration for
both WebSphere Enterprise Service Bus and WebSphere Process Server.
Basic tasks
You can use the Administrative Console to create and to manage objects in the
WebSphere Process Server and WebSphere Enterprise Service Bus
configuration, such as resources, applications, and servers. Additionally, you can
use the Administrative Console to view product messages.
106
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
The main areas of the Administrative Console include:
Taskbar
The taskbar offers options for logging out of the console,
accessing product information, and accessing support.
Navigation tree
The navigation tree on the left side of the console offers
links to console pages that you use to create and to
manage components in a WebSphere Application Server
administrative cell.
Workspace
The workspace on the right side of the console contains
pages that you use to create and to manage configuration
objects such as servers and resources. You can select
links in the navigation tree to view the different types of
configured objects. Within the workspace, click configured
objects to view their configurations, runtime status, and
options.
Figure 4-1 The Administrative Console
Chapter 4. Operational considerations
107
The tasks you can perform in the Administrative Console are divided into the
following categories:
Guided activities
Guided activities that lead you through common
administrative tasks that require you to visit multiple
Administrative Console pages.
Servers
Configure application servers, clusters, generic
servers, Web servers, and core groups.
Applications
Install applications onto servers and manage the
installed applications.
Resources
Configure resources and to view information about
resources that exist in the administrative cell.
Security
Access the Security Center, which you use to secure
applications and servers.
Environment
Configure hosts, variables, and other components.
System Administration Configure console settings, and manage components
and users of a Network Deployment product.
Troubleshooting
Check for configuration errors and problems, view log
files, and enable and disable tracing on a distributed
platform.
Monitoring and Tuning Monitor and tune your application server performance
and analyze performance data.
Service Integration
Implement message-oriented and service-oriented
applications.
UDDI
Publish and discover information about Web services.
Administrative Console pages are formatted in one of three ways:
Collection pages
A collection page manages a collection of existing
administrative objects (for example relationships,
failed events, or resource adapters).
Detail pages
A detail page is used to view details about an object
and to configure specific objects (such as an
application server or a listener port extension).
Wizard pages
Wizard pages help you complete a configuration
process comprised of several steps.
Attention: Be aware that wizards can show or hide certain steps, depending
on the characteristics of the specific object that you are configuring.
108
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Special options for WebSphere Enterprise Service Bus
The Administrative Console of WebSphere Enterprise Service Bus (in addition to
the basic tasks that we have described) allows you to view and to change
aspects of service applications. Service applications provide services and have
an associated SCA module. The type of SCA modules that are supported by
WebSphere Enterprise Service Bus are mediation modules.
After you have deployed an EAR file that contains an SCA module, you can view
the SCA module details. You can list all your SCA modules and their associated
applications, and you can view details about a particular SCA module. Properties
that you can view are:
򐂰 SCA module name
򐂰 Associated application
򐂰 SCA module imports
– Interfaces
– Bindings
򐂰 SCA module exports
– Interfaces
– Bindings
You can change the SCA module’s import bindings at runtime. All other
properties are read only. The option to change the import binding brings the
ability to change the behavior of a particular SCA module so that it interacts with
an SCA module other than the one that you specified at development time.
The Administrative Console also lets you configure and manage the bus
behavior and topology of your WebSphere Enterprise Service Bus. Because the
WebSphere Enterprise Service Bus relies on the Service Integration Bus of
WebSphere Application Server internally, you find the available properties and
settings under the following menu options:
򐂰 Servers → Service Integration → Buses
򐂰 Servers → Application Servers → Server messaging
Special options for WebSphere Process Server
WebSphere Process Server administration offers features specific to business
process choreography, which include the ability to:
򐂰 Start the compensation service automatically, when the application starts,
and specify the location and maximum size of the recovery log.
򐂰 Check for and replay any messages for business processes or human tasks
that could not be processed.
򐂰 Use the Administrative Console to refresh staff queries. The results of a staff
query are static.
Chapter 4. Operational considerations
109
򐂰 Enable Business Process Choreographer events to be emitted to the
Common Event Infrastructure as Common Base Events or stored in the audit
trail.
4.2.2 Scripting
In all WebSphere Application Server based products, you have a non-graphical
alternative to administer all provided functions. This alternative provides the
opportunity to encapsulate complex tasks that you have to perform frequently
within a single command or script, which you can then simply call from a terminal
window instead of having to use the Administrative Console. Scripting also gives
you the opportunity to integrate administrative tasks with an automation
mechanism that you perhaps already use for other tasks such as system-wide
resource management or failover management.
WebSphere Enterprise Service Bus and WebSphere Process Server support the
following scripting languages:
Jacl
Java Command Language (Jacl) is an alternate
implementation of tool command language (TCL) and is written
entirely in Java code.
Jython
Jython is an alternate implementation of Python (which got its
name from the English television series Monty Python’s flying
circus) and is also written entirely in Java.
For our discussion, we focus on Jython, because Jython provides the broadest
set of programming possibilities and is the strategic scripting language for
products based in WebSphere Application Server.
Introduction to scripting
Scripting languages are not to compiled at build-time like other programming
languages such as C or C++ but are interpreted during runtime like Java.
Therefore, Jacl and Jython for products based in WebSphere Application Server
need a runtime interpreter that also provides the interfaces necessary to access
the WebSphere Application Server based objects that you want to configure.
This runtime interpreter is called wsadmin, and the scripts are often called
wsadmin scripts.
In z/OS, there are two different types of scripting that you can use. The first type
is wsadmin. It uses a Hierarchical File System (HFS), because the supported
languages are optimized on that type of data organization and most configuration
information and editable properties of WebSphere Application Server based
products on z/OS are held in an HFS structure, which is provided by the z/OS
UNIX System Services (USS).
110
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
The second option to automate tasks in z/OS is writing scripts which are
executed via the z/OS Job Entry Subsystem (JES). These scripts, in z/OS terms
usually called jobs, are written in the Job Control Language (JCL), in which you
can add supporting scripting languages such as the Restructured Extended
Executor Language (REXX). The capabilities of editing WebSphere Application
Server configuration files are limited, but JCL is the standard way to start tasks
and processes such as WebSphere Process Server or WebSphere Enterprise
Service Bus on z/OS.
Note: Although the standard scripting languages for modifying WebSphere
Enterprise Service Bus and WebSphere Process Server configuration are Jacl
and Jython, the standard language to start and to stop your WebSphere
Application Server infrastructure on z/OS is JCL.
Things you can script
The wsadmin runtime interpreter provides the following objects:
AdminControl
Use to run operational commands.
AdminConfig
Use to run configurational commands to create or modify
WebSphere Application Server configurational elements.
AdminApp
Use to administer applications.
AdminTask
Use to run administrative commands.
Help
Use to obtain general help.
The scripts use these objects to communicate with MBeans that run in
WebSphere Application Server processes. MBeans are Java objects that
represent Java Management Extensions (JMX™) resources. Figure 4-2 shows
the abstract architecture pattern that wsadmin uses.
Java virtual machine
External tools
and programs
Connector
Connector
Connector
Resources
M Bean
Server
M Beans
M Beans
Figure 4-2 The architecture of WebSphere Application Server scripting
Chapter 4. Operational considerations
111
4.2.3 Administration on an SOA level
In 4.2.1, “The Administrative Console” on page 106 and 4.2.2, “Scripting” on
page 110, we discussed the administration considerations from an IT
perspective. However, when administering an SOA environment, you have to
consider the business view as well.
Similar to the IT administration aspects, you have the choice between two ways
of processing the business administrative tasks: graphical user interfaces and
APIs, which can be used by scripts or self written programs.
Note: These administration capabilities apply primarily to WebSphere
Process Server, where a business process or business process-related
artifacts have been deployed.
Administration of process and human tasks templates
Process templates and task templates are created for WebSphere Process
Server enterprise applications containing business processes and human tasks,
respectively. In the Administrative Console, you can start and stop process
templates or task templates similar to J2EE programs. Stopping the process or
task template instead of stopping the entire application with which it is deployed
ensures that long running process or task instances can finish properly before
the task or process becomes obsolete.
Note: You can stop or uninstall J2EE applications that contain business
processes or human tasks only when the business process or task template
that they contain is stopped properly and all instances have finished.
Table 4-1 shows the menu commands to start or to stop a process or task
template.
Table 4-1 Menu commands to start/stop process and task templates
Option
Menu commands in the Administrative Console
Start/stop process template
Applications → Enterprise Applications → your application →
EJB Modules → the EJB-Module → additional properties →
Business Processes → the process template
Start/stop human task template
Applications → Enterprise Applications → your application →
EJB Modules → the EJB-Module → additional properties →
Human Tasks → the task template
112
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
You can also start and stop process and task templates using wsadmin. You can
find a sample jacl script in the following directory:
install_root/ProcessChoreographer/sample/bpcTemplates.jacl
Use the syntax described in Example 4-1 to start and to stop the templates.
Example 4-1 Starting and stopping process and task templates using a Jacl script
cd install_root/ProcessChoreographer/sample
install_root/bin/wsadmin -f bpcTemplates.jacl
-stop application_name
install_root/bin/wsadmin -f bpcTemplates.jacl
-start application_name
In the install_root/ProcessChoreographer/sample/ directory and the
install_root/ProcessChoreographer/util/ directory, there are more ready made
Jacl scripts that you can use to administer the business process choreographer
using the wsadmin script, such as:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
deleteAuditLog.jacl
deleteInvalidProcessTemplate.jacl
deleteInvalidTaskTemplate.jacl
queryNumberOfFailedMessages.jacl
replayFailedMessages.jacl
refreshStaffQuery.jacl
cleanupUnusedStaffQueryInstances.jacl
You can also leverage the edition management for business processes (often
called the valid-from feature) to deploy new releases of business processes into
a running environment. You can set the valid-from date for a business process or
task template in WebSphere Integration Developer.
Note: You can deploy as many templates with the same name as you like,
each in their own J2EE enterprise application. However, none of these
templates can share the same valid-from date.
Administration of process instances
For the administration of process or task instances WebSphere Process Server
provides a special administrative Web client, the Business Process
Choreographer (BPC) Explorer.
Chapter 4. Operational considerations
113
The BPC Explorer, shown in Figure 4-3, looks familiar if you already know the
WebSphere Administrative Console. It is divided in the following areas:
Taskbar
The taskbar offers options for logging out of the BPC
Explorer, using the search option, and accessing support.
Navigation tree
The navigation tree on the left side of the BPC Explorer
offers links to administer process templates, process
instances, tasks, instance and compensation data and
many more features.
Workspace
The workspace on the right side of the BPC Explorer
contains pages that you use to access items in lists (such
as the process instance list), manipulate the state and
data of processes and tasks and view general process
data.
Figure 4-3 The BPC Explorer
When you start the BPC Explorer, the objects that you see in the user interface
and the actions that you can take depend on the user group that you belong to
and the authorization granted to that group. For example, if you are an
administrator, you are responsible for the smooth operation of deployed business
processes and tasks. As an administrator you have the following options:
My Process Templates Shows a list of available process templates. You have
the option to view all instances of a particular template
that are currently active or to create a new instance.
Process Instances
114
Shows you a list of currently running process
instances. Depending on the link you choose in the
navigation tree the list will show a subset of all
instances. You have the option to trigger
compensation, terminate the process instance, delete
the process instance (which, in addition to terminating
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
it will also delete the process data), suspend or resume
the process instance, restart it or show a list of
activities (process steps) or human tasks.
Failed Compensations If compensation of a business process failed, you have
to take specific manual actions to solve the problem.
This page provides you the option to retry a certain
compensation step, skip it and continue with the next
step, or stop the compensation processing.
Task Instances
Human tasks can have various states such as being
claimed by a certain user, being completed or being in
escalation mode. In this page you can manipulate the
state of a human task and also complete it (which
means that you have access to the data provided as
task input data and give the data needed for the task
response).
The BPC Explorer provides all these options in a generic way so that it will work
with all standard human tasks generated in WebSphere Integration Developer. It
is not intended for production environments, but you can use it as a sample
application of the business process choreographer generic interface provided by
session beans. Table 4-2 shows the names of the remote and local session bean
interfaces.
Table 4-2 Bean interfaces for generic task and business process control session beans
Generic human task session bean
Generic business process session bean
Local
interface
com.ibm.task.api.LocalHumanTask
Manager
com.ibm.bpe.api.LocalBusinessFlow
Manager
Remote
interface
com.ibm.task.api.HumanTaskManager
com.ibm.bpe.api.BusinessFlowManager
We recommend that you implement your own business process client or human
task client by using these session beans or by customizing the BPC Explorer to
your own needs.
Administer business rules with the Business Rules Manager
The Business Rules Manager is a Web-based tool that allows business analysts
to modify deployed business rules dynamically on a running server. This tool is
an optional tool that is not installed by default. You can use the business rules
manager to do the following:
򐂰 Open a copy of a business rule from the repository
򐂰 Browse and edit a business rule
򐂰 Publish a business rule to the repository
Chapter 4. Operational considerations
115
Figure 4-4 shows the Business Rules Manager, which includes the following
sections:
Taskbar
Offers options for logging out of the Business Rules
Manager, accessing product information, and support.
Navigation tree
Enables you to drill-down to the rule level you need. This
area is not displayed in any page that is in edit mode.
Top-right section
Contains path information for the business rule, the rule
title and several options to edit, save, copy, publish, or
revert the business rule.
Bottom-right section Provides the content of the business rule. If the Business
Rule Manager is in edit mode you can also edit the data
of the business rule in this section.
Figure 4-4 The business rules manager in edit mode
116
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Monitoring Common Base Events with the CBE Event browser
Common Base Event (CBE) Event browser allows you to view all the Common
Event Infrastructure (CEI) and CBE events that are generated by the server.
Figure 4-5 shows the CBE Event browser.
Figure 4-5 The CBE Event browser
Attention: The CBE Event browser can be empty, even with CEI events
enabled in your module. CEI has to be turned on explicitly in the runtime
containers of the component implementations.
Chapter 4. Operational considerations
117
Monitoring SCA messaging with the Failed Event Manager
You use the Failed Event Manager to view SCA messages that could not be
delivered to their intended destinations. Messages cannot be delivered when a
Web service invocation cannot complete because the service is offline or a Java
Message Service (JMS) queue is full. Rather than discard the messages, SCA
places them in the Failed Even Manager. With the messages in the Failed Event
Manager, the system administrator can resubmit or discard the events as
appropriate.
Figure 4-6 shows the Failed Event Manager.
Figure 4-6 The WebSphere Process Server Failed Event Manager
Important: Failed events are created only when asynchronous invocations
fail. If your invocation is synchronous, then an exception is thrown but the
event is not placed in the failed event manager.
118
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
5
Chapter 5.
Qualities of service
This chapter addresses the security and transactionality quality of service
concerns for WebSphere Process Server and WebSphere Enterprise Service
Bus for z/OS. It discusses the security that the z/OS operating system provides,
and the security that the underlying WebSphere Application Server for z/OS
provides. This chapter also addresses SCA security. Finally, it discusses
WebSphere Process Server and WebSphere Enterprise Service Bus for z/OS
security features .
© Copyright IBM Corp. 2006. All rights reserved.
119
5.1 Security
In this section, we introduce some basic security technologies and describe how
z/OS provides strong security capabilities. We also address security concerns
that are specific to SCA and how security is implemented with WebSphere
Process Server and WebSphere Enterprise Service Bus for z/OS.
5.1.1 Security technologies
WebSphere Process Server and WebSphere Enterprise Service Bus for z/OS
are built on top of WebSphere Application Server for z/OS and, therefore, inherit
the security capabilities of this application server. WebSphere Application Server
is based upon an open architecture and provides many plug-in points to integrate
with enterprise software components to provide end-to-end security.
Figure 5-1 illustrates the security organization in WebSphere Application Server.
WebSphere security layers
– Naming
– HTML
– User registry
– Servlet or JSP file
– JMX message
beans
– Enterprise beans
WebSphere Application Server resources
– Web services
Access control
WebSphere security
WebSphere Application Server security
J2EE security API
CORBA security (CSIv2)
Java security
Java 2 security
Java virtual machine (JVM) Version 1.4
Operating system security
Platform security
Network security
Figure 5-1 WebSphere Application Server security layers
120
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
There are four concepts in security that an infrastructure has to cover:
򐂰 Authentication and authorization
Users (people and processes) must verify to the subsystem who they are.
򐂰 Access control to resources
Different users have different permissions to access resources or to execute
code.
򐂰 Data integrity
Verification that the data exchanged across a network has not been tampered
with or altered.
򐂰 Single sign-on
The fewer times clients have to be authenticated, the better it is for the user.
When authenticated, the security context should flow through subsequently
accessed subsystems.
In the case of WebSphere Process Server and WebSphere Enterprise Service
Bus for z/OS, these considerations are supplemented by SCA qualifiers, as
shown in Figure 5-2.
Chapter 5. Qualities of service
121
WebSphere security layers
– Naming
– HTML
– User registry
– Servlet or JSP file
– JMX message
beans
– Enterprise beans
SCA components
– Web services
SCA
WebSphere Application
Server resources
with
WebSphere Process Server
or WebSphere Enterprise
Service Bus
Access control
WebSphere security
WebSphere Application Server security
J2EE security API
CORBA security (CSIv2)
Java security
Java 2 security
Java virtual machine (JVM) Version 1.4
Operating system security
Platform security
Network security
Figure 5-2 New components in the security stack
5.1.2 z/OS-specific security capabilities
z/OS security has special features that make it one of the most secure systems
available. Products such as WebSphere Process Server and WebSphere
Enterprise Service Bus for z/OS take advantage of these security capabilities
through WebSphere Application Server for z/OS in the following ways:
򐂰 In WebSphere Application Server for z/OS the operating system identity of
the servant, controller, and daemon started task, as established by the
STARTED profile, is the identity that is used to control access to system
resources such as files or sockets.
򐂰 Operating system security can provide authentication services using the User
Registry of the local operating system, or authorization services using SAF
Authorization for the WebSphere Administration console and for applications
running under the application server.
122
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
򐂰 Administrators must be familiar with general security technologies such as
Secure Sockets Layer (SSL) and Transport Layer Security (TLS).
Administrators must also be familiar with System Authorization Facility (SAF)
and Resource Access Control Facility (RACF), or an equivalent SAF based
product.
򐂰 The identity and verification of users can be managed by using a Local
Operating System as the User Registry, RACF or equivalent SAF base
product. Alternatively, an LDAP, Custom, or Federated User Registry can be
used.
򐂰 WebSphere Application Server can be configured to use SAF Authorization,
which will use RACF or an equivalent SAF based product to manage and
protect users and group resources. Alternatively, WebSphere Application
Server can be configured to use WebSphere Authorization or a Java
Authorization Contract for Containers (JACC) external authorization provider.
򐂰 When using either Local Operating System as the User Registry or using SAF
Authorization, security auditing is an inherit feature of RACF or the equivalent
SAF based products.
򐂰 At the network layer WebSphere Application Server for z/OS provides
SystemSSL for communication using the Internet. SystemSSL is composed
of the Secure Sockets Layer (SSL) and Transport Layer Security (TLS),
which enable secure file transfer by providing data privacy and message
integrity.
5.1.3 SCA security and message level security
SCA provides its own capabilities for security. These capabilities can be used in
WebSphere Process Server and WebSphere Enterprise Service Bus.
SCA security
SCA definitions are observed by WebSphere Process Server and WebSphere
Enterprise Service Bus everywhere in their architecture and development. Thus,
SCA security has a major role in the security definitions of these products. SCA
applies security by defining quality of service qualifiers. The two SCA qualifiers
for security relevant to WebSphere Process Server and WebSphere Enterprise
Service Bus are:
򐂰 SecurityIdentity
The J2EE role under which a component will be executed - regardless of the
invoking J2EE role.
򐂰 SecurityPermission
The required J2EE role to invoke an operation.
Chapter 5. Qualities of service
123
Message level security
Message level security is concerned with the flow of messages in transit. There
are many ways to secure these messages, including using the WS-Security
specification that is supported within WebSphere Process Server and
WebSphere Enterprise Service Bus for z/OS.
With regard to message level security, consider the following aspects:
򐂰 Authentication of users when they attempt to connect to a service integration
bus.
When you attempt to establish a connection, you might have to provide a user
ID and password. These are authenticated against the same registry that the
application server uses. Further access checks on the user name are
performed when the connection accesses a destination (to send or to receive
a message), creates a temporary destination, or accesses a foreign bus.
򐂰 Confidentiality and integrity of the message in transit
To ensure that communications are secure, you must, in addition to enabling
security, set up secure transport chains and select secure transports to
protect the data transmitted along the link using SSL or HTTPS. For
System z, hardware cryptographic acceleration ensures that these operations
are quick and with high encryption levels. WS-Security can also be used for
SOAP messages, especially if they are asynchronous, because no
handshake is needed with it.
򐂰 Control of which message engines can connect to a bus
When messaging security is enabled, only authorized messaging engines are
allowed to create a connection to a secure bus. Use this task to control which
messaging engines are allowed to connect to a selected secure bus.
5.1.4 WebSphere Process Server and WebSphere Enterprise Service
Bus for z/OS security overview
This section outlines some security considerations that are specific to
WebSphere Process Server and WebSphere Enterprise Service Bus for z/OS.
Securing the runtime environment
Security in WebSphere Process Server and WebSphere Enterprise Service Bus
is controlled from the Administrative Console, because it is in WebSphere
Application Server. The first thing you have to do is enable global security.
All WebSphere Application Server security concepts are applicable to
WebSphere Process Server and WebSphere Enterprise Service Bus. In addition,
there are some details about the security of installed components in WebSphere
124
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Process Server and WebSphere Enterprise Service Bus that are worth
consideration.
Several important components of WebSphere Process Server and WebSphere
Enterprise Service Bus have a default security configuration. This configuration
includes aliases to which default users are mapped and security roles to which
users must be granted access in order to invoke these components. The
components with predefined aliases and roles are:
򐂰
򐂰
򐂰
򐂰
Business process choreographer — aliases and roles
CEI — aliases
SCA (described in “SCA security” on page 123) — aliases and roles
Human tasks engine — roles
Securing applications
Applications in WebSphere Process Server and WebSphere Enterprise Service
Bus are secured by authentication, access control, data integrity and privacy.
Securing applications assumes that global security is enabled. When global
security is on, clients must be authenticated.
The main authentication methods for clients are:
򐂰 Web clients: HTTP basic authentication.
򐂰 Java clients: Java Authentication and Authorization Service (JAAS.)
򐂰 Web services: WS-Security/SOAP authentication.
Additionally all of these clients can use SSL authentication.
You can use Lightweight Third Party Authentication (LTPA) for authentication.
This mechanism allows you to choose between two different authentication
possibilities, as shown in Table 5-1.
Table 5-1 Options for the user registry
User registry
Action
Operating system
If you choose Local OS, then the user registry is implemented
by SAF.
LDAP
You need a configured LDAP. It can be either a local or
remote registry.
Access control
Access control is implemented usually by assigning J2EE roles to components.
This control is often specified at development time. For example, SCA security
can specify a SecurityPermission qualifier to limit access control for an SCA
component.
Chapter 5. Qualities of service
125
Data integrity and privacy
The integrity and privacy of data can be achieved in WebSphere Process Server
and WebSphere Enterprise Service Bus using one of the two following solutions:
򐂰 Secure Sockets Layer (SSL)
򐂰 WS-Security
Securing adapters
Adapters usually exchange important information when they communicate with
specific enterprise information systems. Therefore, the security mechanisms
used with these adapters is important. Within WebSphere Process Server or
WebSphere Enterprise Service Bus, an adapter is an SCA import or export. This
import or export can have SCA security qualifiers defined for it to determine the
role under which the adapter runs and the role that is required to be authorized to
access the adapter.
Enterprise information system specific security information (such as the user ID
that the transaction in the enterprise information system should run under) can
usually be specified in the connection factory of the adapter.
5.2 Transactionality
This section introduces the subject of transactionality and how you can
implement it on z/OS for WebSphere Process Server and WebSphere Enterprise
Service Bus.
5.2.1 Transaction requirements
Transaction management is one of the strong requirements for the new
subsystems and has always been critical for the success of new technologies.
The classical and well-known ACID properties for transactions are of great
importance. ACID stands for the four required properties for a transaction:
򐂰 Atomic
Operations within a transaction are considered an indivisible unit of work. If
the transaction completes successfully, all of the operations are executed and
committed. If the transaction is rolled back, then all of the actions within the
transaction are reversed.
򐂰 Consistent
When a transaction operates on data it must be in a way that data remains
consistent.
126
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
򐂰 Isolated
The effects of concurrently running transactions are invisible to the others
until transaction is committed.
򐂰 Durable
When a transaction is running, changes must be resistant to system failures.
All these considerations are taken for granted when transactions execute against
a single resource: writing to a volume or updating a database. When several
resources are involved either we need to use a transactional resource manager
or manually program a transaction in an application.
5.2.2 z/OS transactional services
z/OS provides a variety of products and resources that make of it one of the most
reliable transactional platforms. The Resource Recovery Service (RRS) on z/OS
provides best-of-breed performance for two-phase commit transactions. RRS
manages resources in a way that they are registered in a global transaction only
when they attempt to make changes to resources under its control.
WebSphere Process Server and WebSphere Enterprise Service Bus for z/OS
take advantage of the underlying z/OS RRS service. WebSphere Application
Server for z/OS has advanced controls, which are not available in other
platforms, for the control of transactions in application server instances. You can
assign privileged to specific transactions to increase their priority. You can select
which JVMs execute heavy weight transactions and which JVMs control faster
transactions. All these capabilities are under the coordination of WLM and RRS.
5.2.3 SCA transactions
SCA presents all elements of business transactions – access to Web services,
Enterprise Information System (EIS) service assets, business rules, workflows,
databases and so on – in a service-oriented way.
WebSphere Process Server transactions
For business processes, WebSphere Process Server offers support for
transactions involving multiple resource managers using the two-phase commit
process to ensure ACID properties. This capability is available for both
short-running processes (single transaction) and long-running processes
(multiple transactions). You can group multiple steps in a business process into
one transaction by modifying transaction boundaries in WebSphere Integration
Developer.
Chapter 5. Qualities of service
127
Because not all service invocations support two-phase-commit transactions,
WebSphere Process Server also includes recovery capabilities. If a failure
occurs in the middle of running an integration application, the server detects it
and allows an administrator to manage the failed event from the failed event
manager.
WebSphere Enterprise Service Bus transactions
Mediations in WebSphere Enterprise Service Bus have also transactional
properties. You can configure a mediation handler to run within a global
transaction. A global transaction is required when:
򐂰 Mediating and routing messages must be coordinated into a single
transaction.
򐂰 Several mediation handlers in a mediation handler list must be coordinated
into a single transaction.
Setting the global transaction property ensures transactional integrity between a
mediation that accesses the resources owned by other resource managers, and
the messaging engine.
A global transaction encompasses all the mediation operations that are run
within the bus for the duration of the mediation. The global transaction ends
when the mediation completes its processing.
If a mediation transaction rolls back, all transactional changes also roll back.
When the transaction rolls back, the mediated message remains on the
pre-mediated part of the bus destination and becomes eligible to be mediated
again. The redelivery count assigned to a message increments each time a
mediation transaction rolls back. If the redelivery count exceeds the limit
configured for the bus destination, the message is sent to the exception
destination.
5.2.4 Compensation and transactions
Transactional behavior for business processes depends on the type of process
being executed:
򐂰 Short-running processes are made of some services integrated into a
non-interruptible unit of work. They run all services under one global
transaction. This means that resources are blocked for the transaction
execution time and that is why short-running processes should execute for
only a short period of time.
򐂰 Long-running processes allow for interruptions and can involve asynchronous
tasks. These services are grouped into several global transactions along the
process.
128
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
If all the resources are accessible for the global transaction there is no problem
with the execution and the transaction guarantees integrity.
If any of the individual services belonging to the transaction do not allow the
transaction manager, WebSphere Application Server in this case, to control the
transaction, these services are out of the global transaction.
Transaction boundaries for long-running processes can be optimized. At
development time, transaction behavior can be declared for some activities and
can be set to:
򐂰 Commit before. The activity runs in a new transaction.
򐂰 Commit after. The running transaction is committed immediately after the
activity is completed.
򐂰 Requires own. The activity runs in a new transaction and is committed
immediately after its execution.
򐂰 Participates. The activity runs under an existing transaction.
WebSphere Process Server offers compensation as a way to undo services that
are not part of a global transaction, cannot rollback, or to undo the effects of an
already committed transaction. Compensation is specified by defining a
compensating service that should be run to undo the original service.
5.2.5 Fault handling in transactions
For business processes, faults can occur when a process instance is created or
when operations that are invoked as part of the navigation of a process instance
fail. Mechanisms exist to handle these faults. These handlers are catch or catch
all, and they include features to do the following:
򐂰 Pass control to corresponding fault handlers.
򐂰 Stop the process so it can be repaired (force-retry, or force-complete).
򐂰 Compensate the process.
򐂰 Pass the fault to the client application as an API exception. For example, an
exception is thrown when the process model from which an instance is to be
created does not exist.
These faults can be thrown by the process choreographer or an activity called
throw inside the business process.
Chapter 5. Qualities of service
129
There is a default handler, which is not available in the process editor, that
defines some fault handling rules for the case that catch and catch all are not
there. If there are no fault handlers defined or no catch or catch all elements the
engine uses the default handler rules.
For mediation flows, faults can be caught in the response flow of a service call
and handled through the use of mediation primitives.
130
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
6
Chapter 6.
Integration with backend
systems
This chapter discusses approaches for integrating business processes in
WebSphere Process Server and mediation flows in WebSphere Enterprise
Service Bus with backend systems such as CICS Transaction Server.
Integration with backend systems is an important part of SOA implementation.
According to Phil Murphy with Forrester Research:
The irony is that host applications are probably better suited for exposure as
part of an SOA than many applications based on more modern 4GL
object-oriented languages. When folks wrote screen-based transactions
many months ago, they wrote it at a business function viewpoint: I add a
customer, I add an order for that customer, I check backlogs for that
customer, etc. So in many respects, those CICS screens of 15 years ago are
better suited to service orientation than a lot of the newer, distributed code
that’s been written over the last several years, because of their affinity with a
business function, what did the object-oriented guys do? They took those
screens and they broke them down into a thousand different objects.1
1
Phil Murphy, Forrester Research, from Enterprise Systems Journal, 7/26/2005, which is available
online at: http://esj.com/enterprise/article.aspx?EditorialsID=1457
© Copyright IBM Corp. 2006. All rights reserved.
131
6.1 Integration approaches
When integrating services into a business process, we think about two different
conceptual approaches according to the business view:
򐂰 We implement the process steps for an existing business process (perhaps
designed by the line of business or some business architect) from scratch.
We will call this approach top-down.
򐂰 We take existing software assets and expose their business logic as services
in an extend and granularity that we consider as the best. We will call this
approach bottom-up.
In many real-world situations, you have an existing business process similar to
the top-down approach and have to assign the process steps to services that
represent business logic that is provided by existing software assets. This case
requires a combination of the two approaches that we have mentioned. We call
this combination approach the meet-in-the-middle approach.
Note: When it comes to examples or concrete implementation in this chapter,
we always use CICS Transaction Server V3.1 as a reference backend system
and Web services as a reference SOA interaction pattern. There are
comments about other backend systems when concepts or implementation
patterns differ significantly.
6.1.1 The bottom-up approach to integration
In the bottom-up approach, we assume that the process architect builds a
business process by choosing the process steps out of a pool of existing
services. We now discuss that approach and how to implement it in practice.
Implementing the bottom-up approach in CICS
This approach is usually the starting point when we have an existing CICS
application that is fully functional, already implemented, and has a COMMAREA
or channel interface available. We now want to expose this application as a Web
service.
Note: The COMMAREA is the language structure (represented in the native
language; COBOL, PL/I, C, and so forth) that is used in CICS applications to
pass both input and output parameters for calls to and from CICS applications.
In CICS TS v3.1, a new facility called containers was introduced to overcome
some limitations of the COMMAREA concept.
132
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
The following input data is needed to generate a Web service interface:
򐂰 Programming language data structure
– in COBOL or PL/I or C or C++
– Interface to the program can be COMMAREA or a channel
򐂰 Control statements (SYSIN)
The following output data is generated:
򐂰 Web services binding file
򐂰 Input and output data conversion COBOL files (optional, if option selected)
򐂰 Web services description (WSDL)
After generating the service interface the service is available to any service
consumer.
To ensure that our service is used, we likely want to publish the service
description (in this case the WSDL file) in a service repository. The process
architect accesses this service repository and composes a business process
based on the set of available services.
Advantages and disadvantages of the bottom-up approach
The bottom-up approach has some obvious advantages and disadvantages that
emphasize the idealized character of the approach.
The main advantages of the approach are:
򐂰 There are no changes in the CICS transaction required. You do not even
have to read the source code.
򐂰 The generation of the Web service interface is straight forward, very
deterministic and is done in minutes.
򐂰 A service repository for the process composition can be easily combined with
a runtime service repository.
However, there are some severe disadvantages in the approach that complicate
the implementation of the approach in a substantial extend, such as:
򐂰 The process composition is remarkably restricted by the pool of available
services. Not only the availability of a certain business function might be in
dispute but the business function a certain service provides might not fit fully
the requirements of the process architect.
򐂰 There is a reasonable risk to fail the goals of a service-oriented architecture
(SOA). SOA describes a service as atomic business functions that executes
Chapter 6. Integration with backend systems
133
one particular task. Your existing CICS interface data structure might perhaps
not be in a form that supports this requirement.
򐂰 To avoid unnecessary work due to preparation of unneeded services you
have to plan very carefully. Most likely there has to be a close interlock
between the process architect and the host programmer that provides the
services. This delays the development process and protracts the SOA
project.
򐂰 The interface data structure of host applications usually follows other
requirements than the desired Web service data structure. If the interface
data structure of an existing host application is used without modification the
data structure for the response will also be part of the request.
6.1.2 The top-down approach to integration
The top-down approach assumes that the process architect designs a process
without any thought about the implementation of the process steps (with the
possible exception of human tasks). The business requirements for each
process step determine its interface structure and therewith its service definition.
On the basis of this service definition a service implementation is written from
scratch.
Implementing the top-down approach in CICS
We just have the WSDL file as input data, which is the Web services description
(WSDL). The output of the interface generation wizard is just the CICS interface
data structure, the binding file for data transformation, and a skeleton source file:
򐂰 Web services binding file
򐂰 High-level language data structure
– In COBOL or PL/I or C or C++
– Interface to the program can be COMMAREA or a channel
We then have to write the service implementation using the skeleton file. We can
reuse existing code, but because the service interface and the interface data
structure are already given, we have to comply with certain restrictions.
Advantages and disadvantages of the top-down approach
The main advantages of the top down approach are:
򐂰 The process architect has the opportunity to design the business process
solely from a business point of view. Therefore, the business process can be
designed by the line of business and by a person without deep knowledge of
the IT infrastructure that will support the process.
134
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
򐂰 The SOA architectural approach can fully be implemented without having to
care about the structure of the backend systems as it is now.
The main disadvantages to this approach are:
򐂰 There must be a lot of rewriting of code to fit the service interface
requirements. This is expensive and does not leverage the biggest value of
your mainframe assets: that the business logic already exists!
򐂰 Leveraging existing business logic can be a challenge. Often the mainframe
assets are running for years without change. If you do not have the developer
or the developer’s documentation still around you have to perform
sophisticated code and structural analysis, which makes the approach of
reuse probably as complex and expensive as the rewriting approach.
6.1.3 The meet-in-the-middle approach to integration
As we have discovered, there can be disadvantages in the bottom-up approach
as well as in the top-down approach. Thus, we must look for a new approach that
can leverage the advantages of the two approaches but minimize the issues that
they raise.
Note: The meet-in-the-middle approach is a compromise of the two idealized,
one-way approaches.
The major advantage of the top-down approach is the opportunity for the process
architect to design the business process to meet business needs without having
to care about the underlying IT infrastructure and the applications that will
provide the implementation for the services the process will consume.
The major advantage of the bottom-up approach is opportunity to reuse your
existing backend systems without having to touch or edit their source code. You
just have to know the exact interface data structure.
Obviously, a mediation layer or wrapper that makes use of both of these
advantages in one approach can be most helpful. Figure 6-1 illustrates this
concept.
Chapter 6. Integration with backend systems
135
1
Business Process
Mediation
Layer
Backend
System
Service
Interface
App.
Interface
Backend
Backend
Application
Application
2
Business Process
Backend System
Wrapper
Service
Interface
Backend
Application
Figure 6-1 Two architectural styles of the meet-in-the-middle integration approach
Ways to implement the meet-in-the-middle approach
Figure 6-1 shows two different styles of implementing the meet-in-the-middle
approach:
򐂰 Using a mediation layer
򐂰 Using a wrapper
Using either of these two styles gives the opportunity of not having to change the
code that resides in the backend applications, which is one of the major
advantages of the bottom-up approach. Additionally, either style provides the
freedom to design the service interface in a form that is appropriate for this
business process (as opposed to a service interface that is fixed, based on the
backend application that you are calling). This option allows you to expose only a
subset of the business logic of your backend application or to tie several backend
applications together to create a single service, which is an advantage of the
top-down approach.
136
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Using a mediation layer
The first architectural style uses a mediation layer. There are a number of
options for which product could implement this mediation layer:
򐂰 WebSphere Application Server
This mediation layer could be a J2EE component (such as an EJB session
bean) that transforms the service interface protocol and data structure into
the backend application interface protocol and data structure. This option
requires manual programming.
򐂰 WebSphere Enterprise Service Bus
The mediation layer could be an ESB implemented in WebSphere Enterprise
Service Bus. This option provides the advantage of not having to write the
mediation logic yourself. You simply have to define the data structure
mappings by customizing pre-build mediation primitives. In addition to data
transformation, WebSphere Enterprise Service Bus can perform other
mediation functions such as protocol transformation and dynamic message
routing.
This option is most appropriate when accessing back-end systems using Web
service invocations or through a J2EE Connector Architecture implementation
such as the CICS ECI resource adapter supplied with the CICS Transaction
Gateway.
See 6.2.1, “Service enablement using the J2EE Connector Architecture” for
more details.
򐂰 WebSphere Message Broker
The mediation layer could be an ESB implemented in WebSphere Message
Broker. This provides similar capabilities to an ESB implemented in
WebSphere Enterprise Service Bus, and additionally provides support for a
wider range of data transformation services for a more diverse set of backend
systems.
Using a wrapper
The second architectural style does not use additional middleware. It requires
that you enable the backend system in such a way that it accepts and
understands messages directly from the business process. You achieve this by
creating wrapper code around an existing application in a backend system. All
z/OS core systems such as IMS, CICS, and DB2 support this option.
The wrapper code is nothing other than the generated language structure
skeleton file, which in our example will receive the Web service request, build the
native interface data structure (COMMAREA or Channel) from the data in the
service request and pass them on to the backend application. The response
goes the opposite way, which allows a business process that runs in WebSphere
Chapter 6. Integration with backend systems
137
Process Server to make a direct Web service call to an application that runs in
CICS TS.
The wrapper code in the backend system is only a thin layer and written in the
native language of the backend system, which has two advantages:
򐂰 The layer works with a minimal performance overhead while the additional
mediation layer in the first architectural style is a thicker layer with a
potentially higher performance overhead.
򐂰 The wrapper code communicates directly with the backend application
without making use of language independent interfaces or network stacks. So
the throughput like the response time are maximized.
Note: The second architectural style to implement the meet-in-the-middle
approach provides a simpler architecture by leaving out an additional layer for
data mapping and protocol transformation, which makes it attractive for small
or very performance critical projects.
For more information about this option, see 6.2.2, “Service enablement of core
systems” on page 143.
Backend integration using the CICS Service Flow Runtime
The CICS TS v3.1 Service Flow Runtime (SFR) and its modeling tool, the
WebSphere Developer v6.0 Service Flow Modeler (SFM) is a special
architectural option for integrating CICS backend applications into your business
process.
Integrating multiple applications into a single service has advantages over
assembling a composite service by explicitly chaining services together. At a
high level (integration and modeling) it reduces complexity for the caller who
does not have to be concerned with managing call-outs of individual applications
in the chain and at a low level (implementation and runtime) it reduces the
execution cost of the transaction, because the SFR calls CICS applications
through their native application interface (COMMAREA or Containers) or even
via using the 3270 interface to the application. SFM generates self-contained
code for such integrated services that can be run in the SFR.
Figure 6-2 illustrates the Service Flow Runtime. It shows a variation of the meet
in the middle approach leveraging the SFR. The SFR and the SFM allow you to
assemble multiple backend applications in one service call using a graphical
user interface. It allows you also to call an application several times with different
purposes and parameters without having to expose several separate service
interfaces for this application.
138
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Business Process
CICS TS v3.1 Backend System
SFR
Backend
Application
Application
Backend
Backend
Application
Application
Backend
Application
Application
Figure 6-2 The CICS TS V3.1 Service Flow Runtime
Note: The CICS TS v3.1 Service Flow Runtime allows you to execute a flow
of multiple CICS applications using their native language structure interfaces
directly in the CICS transaction container and to expose the whole flow as a
single service.
6.2 Enabling your core applications for reuse
This section discusses service enablement using the J2EE Connector
Architecture and service enablement of your core systems.
6.2.1 Service enablement using the J2EE Connector Architecture
The J2EE Connector Architecture (J2C) is part of the J2EE specification and
defines how an application server can communicate with backend systems. Each
backend system wanting to take advantage of J2C must provide a resource
adapter specific to that backend system that performs the message and protocol
transformation necessary to allow the application server and backend system to
communicate, as shown in Figure 6-3.
Chapter 6. Integration with backend systems
139
Container-Component
Contract
Application Component
Client API
System Contracts
Resource Adapter
Application Server
EIS specific interface
Backend system
Figure 6-3 Architecture overview of J2C
The resource adapter for CICS is supplied with the CICS Transaction Gateway.
The resource adapter for IMS is supplied with IMS Connect. JCA resource
adapters also exist for a wide range of other application servers (such as SAP
and PeopleSoft).
Using these resource adapters we can connect business processes running in
WebSphere Process Server and mediation flows running in WebSphere
Enterprise Service Bus to backend systems.
Using J2C resource adapters with SCA
SCA runtime environments (such as WebSphere Process Server and
WebSphere Enterprise Service Bus) can incorporate calls to J2C resource
adapters. These calls are represented as SCA imports and SCA exports. For
example, an SCA export can be created which uses the CICS ECI resource
adapter. This SCA export could be wired to a business process in WebSphere
Process Server or a mediation flow in WebSphere Enterprise Service Bus to
permit access to an application running in CICS.
At runtime the SCA import or export uses a J2C resource adapter to perform the
communication with the backend system.
140
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
The Enterprise Service Discovery wizard
The Enterprise Service Discovery Wizard, provided with WebSphere Integration
Developer, is used to create SCA imports and exports that use J2C resource
adapters to access backend systems.
This wizard contains a number of stages, including:
򐂰 Importing or selecting the J2C resource adapter to use
򐂰 Selecting the service type (inbound to create an SCA export or outbound to
create an SCA import)
򐂰 Finding and discovering enterprise services: for example specify the CICS
program to access and COMMAREA structure to use
Therefore, in order to use this wizard, you need the following resources:
򐂰 A J2C resource adapter (which is packaged as a Resource Adapter Archive
(RAR) file). This resource adapter must be installed into the WebSphere
Process Server or WebSphere Enterprise Service Bus runtime.
򐂰 A file representing the application interface data structure (for example a
COBOL copybook in CICS).
Figure 6-4 shows an example of the Enterprise Service Discovery wizard, which
is used in this case to enable access to a CICS application.
Chapter 6. Integration with backend systems
141
Figure 6-4 Enterprise Service Discovery wizard
An alternative approach to using SCA imports/exports
Instead of using SCA and the Enterprise Service Discovery wizard to work with
J2C resource adapters, you can develop a JavaBean to make calls to resource
adapters. This approach uses only J2EE standards (it does not make use of
SCA) and, therefore, you can deploy it to a WebSphere Application Server
runtime as well as WebSphere Process Server and WebSphere Enterprise
Service Bus.
In this approach, a J2C wizard in Rational Application Developer is used to
create a JavaBean that invokes a J2C resource adapter. This JavaBean can
then be exposed as a Web service (using another Rational Application
Developer wizard), so that applications such as WebSphere Process Server and
WebSphere Enterprise Service Bus can invoke it by sending SOAP messages.
142
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Figure 6-5 shows this approach, using a CICS example.
Figure 6-5 Enabling of a CICS transaction using JCA and JavaBeans™
6.2.2 Service enablement of core systems
An alternative to using a J2EE Connector Architecture resource adapter to
access backend systems is to service enable a backend system. By doing this, a
business process running in WebSphere Process Server or a mediation running
in WebSphere Enterprise Service Bus accesses the backend system using
standard message and protocol formats supported by these products.
For example, if we service enable an application running in CICS Transaction
Server with a Web services wrapper, then a business process running in
WebSphere Process Server can use SOAP over HTTP to communicate directly
with the application running in CICS.
Note: In this section, we continue to use Web service and CICS Transaction
Server V3.1 as the example used for service enablement of core systems.
The service enablement within your backend systems reduces complexity and
gives you the opportunity to revise your backend applications to prepare them for
reuse.
Chapter 6. Integration with backend systems
143
Identifying reusable units
There are various approaches to identify pieces of business logic in your
applications that are predestined for reuse and find code which could use some
adjustment before being exposed as a service.
There are several requirements with which the backend business logic must
comply:
򐂰 The request must be stateless. That means that after processing data and
giving the response there must be no request related data left.
򐂰 A service should be atomic. That means that the processing of a request
should never be interrupted by something that could change any request
related data.
򐂰 The aspect of being atomic can also be seen from the business point of view.
A service shall always perform one particular task like adding a set of data to
a database or performing a particular calculation.
򐂰 The implementation should always do exactly what is defined in the interface
description. That aspect might sound simple, but it is not. If for example the
service description has no capabilities to define a very sophisticated
constraint to some input data, the application must be able to handle input
data that do not comply with this constraint. In general there should be no
implicit interface or processing policies.
򐂰 The particular task you have identified to comply with the above mentioned
requirements should provide an interface to be called as a single application
or transaction. Therefore, you might have to perform minor changes to your
backend system code
You can use several products like WebSphere Studio Asset Analyzer or the IBM
Asset Transformation Workbench to analyze the application code, define code
you want to expose as a service, or avoid duplicate code when creating
additional functions.
Bottom-up Web service enablement deep dive
There are two facilities that help you create the Web service interface for your
CICS (or IMS) applications:
򐂰 The XML Services for the Enterprise (XSE) capability of WebSphere
Developer for System z.
򐂰 The DFHWS2LS application for the top-down approach and the DFHLS2WS
application for the bottom up approach. As you might guess from their names,
these two applications are z/OS applications, which run in batch mode.
We discuss the bottom-up approach as an example to provide a closer look at
the facilities that are involved in the service enablement process.
144
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
The Web Services Enablement wizard is the XSE tool that supports the
bottom-up approach for creating Web services based on existing CICS COBOL
programs. It takes as input the COMMAREA copybook as well as several input
parameters CICS needs for Web service enablement like the URI name that tells
where the Web service is located in CICS.
The XML structure and data types are then derived from the COBOL data
declarations. Based on these, the Web Services Enablement wizard generates
the set of artifacts that you need to build the pipeline (Figure 6-6).
Figure 6-6 Architecture of a CICS Web service provider
The artifacts that the Web Services Enablement wizard generates are:
򐂰 Input converter
A COBOL program that takes an incoming XML document and maps it into
the corresponding COBOL data structure that the existing CICS application
expects.
򐂰 Output converter
A COBOL program that takes the COBOL data results returned from the
CICS application and maps them to an XML document.
򐂰 Converter driver
A COBOL program that shows how the input and output converters can be
used to interact with the existing CICS application.
򐂰 Input document XML schema definition (XSD)
XML schema that describes the incoming XML document.
򐂰 Output document XML schema definition (XSD)
XML schema that describes the outgoing XML document.
Chapter 6. Integration with backend systems
145
򐂰 WSDL
Web service description file.
򐂰 WSBind
Web service binding file.
Suppose that we have an existing CICS application that we want to expose as a
Web service that uses the HTTP transport. We go through the following steps:
1. Generate the WSBIND and WSDL files.
a. Create an Hierarchical File System (HFS) directory in which to store the
generated files. For example, we might create a directory named
/u/SharedProjectDirectory/MyFirstWebServiceProvider.
b. Use the Web Service Enablement wizard from WebSphere Developer for
System z (or the z/OS applications) to generate the necessary files. Input
data includes:
•
The data set members that contain the high-level language structures
used by the application program to describe the Web service request
and the Web service response
•
The relative URI that a client will use to access the Web service
•
How CICS should pass data to the target application program
(COMMAREA or container)
2. Create a TCPIPSERVICE resource definition.
The resource definition should specify PROTOCOL(HTTP) and supply
information about the port on which inbound requests are received.
3. Create a PIPELINE resource definition.
a. Create a service provider pipeline configuration file.
A pipeline configuration file is an XML file that describes, among other
things, the message handler programs and the SOAP header processing
programs that CICS will invoke when it processes the pipeline.
b. Create an HFS directory in which to store installable WSBIND and WSDL
files.
We call this directory the pickup directory as CICS will pick up the
WSBIND and WSDL files from this directory and store them on a shelf
directory.
c. Create an HFS directory for CICS to store installed WSBIND files.
We call this directory the shelf directory.
146
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
d. Create a PIPELINE resource definition to handle the Web service request.
•
•
•
Specify the CONFIGFILE attribute to point to the file created in step 3a.
Specify the WSDIR attribute to point to the directory created in step 3b.
Specify the SHELF attribute to point to the directory created in step 3c.
e. Copy the WSBIND and WSDL files created in step 1 to the pickup
directory created in step 3b.
f. Compile and link the COBOL files (only if you want to use the COBOL
input and output converters).
4. Install the TCPIPSERVICE and PIPELINE resource definitions.
When you install the PIPELINE definition, CICS scans the pickup directory for
WSBIND files. When CICS finds the WSBIND file created in step 1, CICS
dynamically creates and installs a WEBSERVICE resource definition for it.
CICS derives the name of the WEBSERVICE definition from the name of the
WSBIND file. The WEBSERVICE definition identifies the name of the
associated PIPELINE definition and points to the location of the WSBIND file
in the HFS.
CICS uses the WSBIND file to create main storage control blocks to map the
inbound service request (XML) to a COMMAREA or a container and to map
to XML the outbound COMMAREA or container that contains the response
data.
Note: For every WSBIND file (that contains the data mapping information),
there is always one URIMAP (to locate the business logic) and one
WEBSERVICE resource definition generated.
5. Publish WSDL to clients.
Customize the location attribute on the <address> element in the WSDL file
so that its value specifies the TCP/IP server name of the machine hosting the
service and the port number defined in step 2.
In our case, the client might be a WebSphere Process Server business
process that wants to call the CICS application using a Web service interface.
For more information about this process, consult Implementing CICS,
SG24-7206 and Application Development for CICS Web Services, SG24-7126.
Chapter 6. Integration with backend systems
147
148
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Abbreviations and acronyms
APIs
application programming
interfaces
J2C
J2EE Connector Architecture
JACC
Java Authorization Contract
for Containers
BO
Business Objects
BPM
Business Process
Management
JCL
Job Control Language
JES
Job Entry Subsystem
CBE
Common Base Events
JMS
Java Message Service
CEI
Common Event Infrastructure
JSF
Java Service Faces
CORBA
Common Object Request
Broker Architecture
KPIs
Key Performance Indicators
CP
Central Processor
LDAP
Lightweight Directory Access
Protocol
CR
control region
LTPA
CRA
control region adjunct
Lightweight Third Party
Authentication
CRM
Customer Relationship
Management
MDD
model-driven development
ND
Network Deployment
DMZ
demilitarized zone
OCSF
DRDA
Distributed Relational
Database Architecture
Open Cryptographic Services
Facility
POJOs
Plain Old Java Objects
EIS
Enterprise Information
System
QoS
Quality of Service
ERP
Enterprise Resource Planning
RACF
Resource Access Control
Facility
ESB
Enterprise Service Bus
RAR
Resource Adapter Archive
HATS
Host Access Transformation
Services
RDBMS
relational database
management system
HFS
Hierarchical File System
REXX
HTTP
Hypertext Transfer Protocol
Restructured Extended
Executor Language
IBM
International Business
Machines Corporation
RII
redundant I/O interconnect
RMI
Remote Method Invocation
ICF
Internal Coupling Facility
RPC
Remote Procedure Calls
IFL
Integrated Facility for Linux
RRS
Resource Recovery Service
IRD
Intelligent Resource Director
RRS
Resource Recovery Services
ISPF
Interactive System
Productivity Facility
SCA
Service Component
Architecture
ITSO
International Technical
Support Organization
SDO
Service Data Object
SFM
Service Flow Modeler
© Copyright IBM Corp. 2006. All rights reserved.
149
SFR
Service Flow Runtime
SIB
Service Integration Bus
SMO
Service Message Object
SOA
service-oriented architecture
SOBAs
service-oriented business
applications
SR
Servant Regions
SSL
Secure Sockets Layer
TLS
Transport Layer Security
UDDI
Universal Description,
Discovery, Integration
UML
Unified Modeling Language
URL
Uniform Resource Locator
USS
Unix System Services
VM
Virtual Machine
WLM
Workload Manager
WSDL
Web Services Description
Language
WSIL
Web Services Inspection
Language
XSD
XML schema definition
zAAP
z9 Application Assist
Processor
zIIP
z9 Integrated Information
Processor
150
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Related publications
In this section, we list the publications that we consider particularly suitable for a
more detailed discussion of the topics that we cover in this Redpaper.
IBM Redbooks
For information about ordering these publications, see “How to get IBM
Redbooks” on page 151. Note that some of the documents that we reference
here might be available in softcopy only.
򐂰 Getting Started with WebSphere Enterprise Service Bus V6, SG24-7212
򐂰 Patterns: SOA Foundation Service Connectivity Scenario, SG24-7228
򐂰 Patterns: SOA Foundation Service Connectivity Scenario, SG24-7228
򐂰 Patterns: Model-Driven Development Using IBM Rational Software Architect,
SG24-7105
򐂰 Patterns: Building Serial and Parallel Processes for IBM WebSphere Process
Server V6, SG24-7205
򐂰 The Value of the Mainframe in Service Oriented Architecture, REDP-4152
How to get IBM Redbooks
You can search for, view, or download Redbooks, Redpapers, Hints and Tips,
draft publications and Additional materials, as well as order hardcopy Redbooks
or CD-ROMs, at this Web site:
ibm.com/redbooks
Help from IBM
IBM Support and downloads
ibm.com/support
IBM Global Services
ibm.com/services
© Copyright IBM Corp. 2006. All rights reserved.
151
152
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Index
Numerics
4GL 131
A
access control 121, 125
adapters 126
Administrative Console 104, 106–107, 109
managing the bus 109
navigation tree 107
pages 108
taskbar 107
tasks 108
workspace 107
aliases 125
authentication 121, 124–125
authorization 121
automation using scripts 110
B
benefits of SOA 11
BPC Explorer 80, 114
failed compensation 115
navigation tree 114
process instances 114
session beans 115
task instances 115
taskbar 114
templates 114
workspace 114
Broker Application pattern 59
business functions
SOA 15
business object maps 73
business objects 67
business process 15, 27, 68
formal specification 27
Business Process Choreographer Explorer. See
BPC Explorer.
business process management 42
middleware monitoring 64
services monitoring 63
transactions monitoring 63
© Copyright IBM Corp. 2006. All rights reserved.
business processes
management 63
SOA 15
business rule 43, 72
Business Rules Manager 115–116
bottom-right section 116
navigation tree 116
taskbar 116
top-right section 116
business service 18
architecture 56
modules 77
universal model 18
business state machine 72
business transactions 15
SOA 15
C
CBE 117
CEI 67, 117
Channel 132
CICS 101, 131
Channel 132
CICS Transaction Gateway 137
COMMAREA 132
Converter driver 145
copybook 141
DFHLS2WS 144
DFHWS2LS 144
Input converter 145
Output converter 145
PIPELINE 147
Service Flow Modeler (SFM) 138
Service Flow Runtime (SFR) 138
TCPIPSERVICE 147
WEBSERVICE resource definition 147
WebSphere Developer for System z 144
WSBIND file 146
XML Services for the Enterprise 144
COBOL 132
copybook 141
WebSphere Developer for System z 144
COMMAREA 132, 147
153
Commit after 129
Commit before 129
Common Base Event. See CBE.
Common event infrastructure
CEI 75
Common Event Infrastructure. See CEI.
communication protocols
SOA 10
Compensation 128
Confidentiality 124
CONFIGFILE 147
container 147
controller 122
controller region
CR 90
controller region adjoint
CRA 90
CORBA 32
core system transactions capability 22
custom mediation primitive 86
Federated User Registry 123
G
global security 124–125
global transaction 128
governance
See SOA governance
H
HFS
directory 146
Hierarchical File System. See HFS
HTTP
transport 146
HTTP basic authentication 125
HTTPS 124
human task 43, 71
templates 112–113
I
D
daemon 122
data graph 34
data integrity 121, 126
data mediator service 34
DatabaseLookup 85
Datapower 101
DB2 Universal Database 50, 101
multi-user version 50
definition of SOA 7
deploy 36
dynamic service selection 73
E
EIS 33
EJB 137
end-to-end security 120
Enterprise Information System. See EIS.
Enterprise Service Bus. See ESB.
Enterprise Service Discovery wizard 141
event group 75
F
fail primitive 86
Failed Event Manager 118
fault handling 129
154
IBM
Contact us xii
IBM Asset Transformation Workbench 144
IBM Cloudscape 50
IBM HTTP Server 100
IMS 101
IMS Connect 101
integration approaches 132
bottom-up 132
meet-in-the-middle 132
top-down 132
integration patterns 58
integrity 124
Intelligent Resource Director
IRD 92
interface maps 72
interfaces
SOA 10
Internet Object Request Broker Protocol (IIOP) 32
J
J2C 139
J2EE 112
JAAS 125
JACC 123
Jacl 110, 113
Java 75, 110
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Java Authentication and Authorization System
JAAS 71
Java clients 125
Java Command Language. See Jacl.
Java Management Extensions. See JMX.
JCA
ECI resource adapter 137
J2C 139
resource adapter archive (RAR) 141
JCL 111
JES 111
JES2 93
JMS 28, 67, 83, 118
JMX 111
Jython 110
O
open architecture 120
P
parallel activities 70
participates 129
patterns for SOA 58
PL/I 132
WebSphere Developer for System z 144
plain old Java Objects (POJO) 75
POJO 75
privacy 126
process
starting and stopping 113
PROTOCOL(HTTP) 146
Python 110
L
languages, scripting 110
LDAP 71, 101, 123, 125
local OS 125
long-running 127
long-running flow 128
long-running processes 70
LTPA 125
M
mainframe
in use today 6
SOA capabilities 6
managing SOA 63
mediation 128
flow 74
handler 128
layer 136
module 77, 85
primitives 85
mediation flow 83
Mediation Flow component 83
message orientated middleware 32
MessageFilter 86
MessageLogger 85
Model-driven development (MDD) 56
Modules 76
monitoring 63
monitoring SOA 63
multiple application 58
Q
Quality of Service (QoS) 22
R
RACF 92, 100, 123
RAR file 141
Rational Software Architect 55
Redbooks Web site 151
Remote Method Invocation (RMI) 33
requesting services
SOA 13
resource adapter 137
Resource Recovery Services
RRS 91
Restructured Extended Executor. See REXX.
REXX 111
RRS 100, 127
S
SAF 92, 125
SAF Authorization 122–123
SCA
bindings 109
component 19
interfaces 109
messages 118
module exports 109
module imports 109
module name 109
qualifiers 123
Index
155
security 123
scripting 110
Jacl 110
JCL 111
Jython 110
objects 111
REXX 111
SDO 83
security 64, 124–125
authorization facility (SAF) 71
management and monitoring 64
organization 120
roles 125
security, end-to-end 120
SecurityIdentity 123
SecurityPermission 123
serial process
application pattern 59–60
servant 122
servant region (SR) 90
Service Component Architecture. See SCA.
service components 68
Service Connectivity scenario 40
service consumer 25
Service Data Objects (SDO) 66
service granularity and choreography 15
Service Integration Bus (SIB) 104
Service Message Object (SMO) 83, 86
service provider 25
service-oriented architecture. See SOA.
services
SOA 9
Services Discovery and Management 30
Services Registry and Repository 30
SHELF 147
short-running flows 127–128
short-running processes 70
single sign-on 121
SMP/E 102
SOA 7, 66–67
administering 112
alternative ways of requesting services 13
business and IT benefits 11
communication protocols 10
definition 7
interfaces 10
management 63
managing 63
monitoring 63
156
patterns 58
service granularity and choreography
business functions 15
business processes 15
business transactions 15
technical functions 15
services 9
SOA Foundation 35
Life Cycle 35
Assemble 36
Deploy 36
Manage 36
Model 36
reference architecture 37
access services 38
business application services 38
information services 38
middleware services view 37
partner services 38
scenarios 39
SOA Governance 37
Framework 62
SOAP 28, 124, 143
authentication 125
envelope 28
faults 28
message 28
message, headers section 28
over HTTP 143
SSL 100, 123–126
stand-alone reference 85
starting a process 113
stop primitive 86
stopping a process 113
supporting services 68
System z Integrated Information Processor (zIIP)
24
T
task template
starting and stopping 112
TCP/IP
server name 147
TCPIPSERVICE 146
technical functions
SOA 15
tool command language (TCL) 110
transaction 126
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
transaction properties
ACID 126
atomic 126
consistent 126
durable 127
isolated 127
Transport Layer Security 123
U
U.S. government taxonomy 28
UDDI 108
Universal Description, Discovery, Integration (UDDI)
28
UNIX System Services (USS) 110
using wsadmin 113
V
virtualization 24
W
Web clients 125
Web service 118
Web services 24, 125
SOAP
body 28
header 28
UDDI 28
usage models 26
basic callback 26
one-way 26
synchronous request/response 26
Web Services Inspection Language (WSIL) 27
WebSphere Application Server 48
WebSphere Authorization 123
WebSphere Business Monitor 51
WebSphere Developer for System z 144
XML Services for the Enterprise 144
WebSphere Enterprise Service Bus 46
administering 105
WebSphere Integration Developer 101
WebSphere Message Broker 137
WebSphere Process Server 43, 112–113
administering 105
WebSphere Studio Asset Analyzer 144
Workflow Manager 58
Workload Manager 78
wrapper 136
wsadmin 113
WS-BPEL 68
WSDIR 147
WSDL 133
WS-Security 124–126
X
XML 101
XML Services for the Enterprise (XSE) 144
XSLT primitive 86
Z
z/OS
administration of WebSphere Process Server
and WebSphere Enterprise Server Bus 105
ISPF 103
JCL 111
JES 111
RACF 100
REXX 111
RRS 100
SMP/E 102
SSL 100
System logger 100
transactionality 126
UNIX System Services 100
z/OS Communications Server 100
z/OSe 100
zAAP 91, 101
zAAP (z Series Application Assist Processor) 24
zIIP 24
Index
157
158
z/OS Technical Overview: WebSphere Process Server and WebSphere Enterprise Service Bus
Back cover
®
z/OS Technical Overview
WebSphere Process Server and
WebSphere Enterprise Service Bus
Learn about SOA
technologies on
System z
Read product
overviews and
considerations for
z/OS
Discover approaches
to integrate with
backend
applications
Redpaper
System z and z/OS continue to provide the highest levels of
availability, scalability, and reliability. System z also
continues to host a wide variety of mission-critical data and
application logic. So, where better to host advanced
service-oriented architecture (SOA) features such as
business processes and the Enterprise Service Bus (ESB)
than z/OS?
INTERNATIONAL
TECHNICAL
SUPPORT
ORGANIZATION
This IBM Redpaper describes how WebSphere Process
Server V6 for z/OS (used primarily to run business processes)
and WebSphere Enterprise Service Bus V6 for z/OS (used to
implement an ESB) benefit from the strengths of System z
and z/OS.
BUILDING TECHNICAL
INFORMATION BASED ON
PRACTICAL EXPERIENCE
The Redpaper begins by defining how SOA is emerging on
the mainframe and provides detailed product descriptions of
WebSphere Process Server and WebSphere Enterprise
Service Bus. It then describes installation and administration
features, operational considerations such as security, and
finally describes how these products can integrate with other
mission-critical applications that are running in other
subsystems on z/OS.
IBM Redbooks are developed by
the IBM International Technical
Support Organization. Experts
from IBM, Customers and
Partners from around the world
create timely technical
information based on realistic
scenarios. Specific
recommendations are provided
to help you implement IT
solutions more effectively in
your environment.
For more information:
ibm.com/redbooks