Rit 8.5.0 virtualization training slides

Virtualization with IBM Rational Integration Tester

© Copyright IBM Corporation 2001, 2013

Introductions
Your organization
Your role
Your background and
experience
 Software testing experience
 Service virtualization experience

Course expectations

2


Intended audience
Primary target audience:
 Software testers
 Test managers

Secondary target audience:
 System architects
 Software developers

3


Prerequisites
This course assumes that you have taken the following
courses or have a knowledge of them:
 IBM® Rational® Integration Tester Platform Training
 XML or other message schemas
 Web services, JMS, or IBM WebSphere® MQ

You might find it helpful to be familiar with the following
technology:
 Regular expressions
 ECMAScript

4


Service virtualization

Client
application

5

Transport

Live
service


Service virtualization

Client
application

6

Transport

Virtual
service


Why do we virtualize?
1.
2.
3.
4.

Isolating UI from rest of SOA architecture
Isolating business processes from mainframe
Forcing business process down predefined routes
Testing a database dependent application with
scrubbed and isolated data
5. Simulating a third party that costs money to call
during a performance test
6. Providing a test system where otherwise there is
none
7. Shielding a production system from test calls

7


Candidate system
Presentation tier

SOA/BPM

Database

8

ESB

B2B

Mainframe


Full environment virtualization
Presentation tier

Virtual Integration Environment (VIE)

• Virtualize entire set of applications
• Users unaware of virtualization
9


Creating and managing stubs
Traditional view
Complex to create
Requires coding knowledge
Developer only activity
Developers should be coding
Little reuse; poor ROI
Independently deployed
No standardization

10

New world view
Drag and drop
Capture traffic between components
Testers own and maintain
Managed centrally
Reuse across test phases and teams
Integrated with test automation tools
Universally understood


The Old World
Quality gate

Requirements

Big Bang
Unit tests
Sys tests
UAT

• Multiple defects introduced at once
• More unknowns; greater risk
• More expensive

11

OAT
Performance


The New World

Requirements

Big Bang

• Accelerates testing
• Reduces costs
• Lower risk

Unit tests
Integration tests

Sys
Sys tests tests
UAT
OAT
Performance

12


Incremental testing
Initial stage:
A single component can be
tested in the context of an
end-to-end environment,
supplied by a set of
virtualized components.

Actual component
Virtualized component
13


Incremental testing
As components are built:
The same end-to-end tests
can be run, replacing
virtualized components
with actual components.

Actual component
14


Incremental testing
As components are built:
This enables us to test
downstream dependencies
as they are built.

Actual component
15


Incremental testing
When the system is
complete:
End-to-end testing can be
carried out with fewer
surprises and lower risk.

Actual component
16


Architecture and setup


Virtualization workflow
1. Create

Rational
Integration Tester

Rational Test
Control Panel

2. Publish

3. Deploy

Rational
Integration Tester
Agent 2

Rational
Integration Tester
Agent n

Stub 1
18

Rational
Integration Tester
Agent 1

Stub 2

Stub n

Domains and environments

Stubs can be used by multiple projects, so we need a
way of keeping them organized.
Stubs can be used within particular business domains;
within those domains, they can also be limited to
particular environments.

19


Domains and environments: example
Core
Services

CRM

Billing

Shipping

Development

Dev

Development

• Service Stub A

• Account Update

• Address Lookup
• Dispatch Order

Integration
Testing

Testing

Test

• License
Creation

• Send Invoice

• Service Stub A

Performance

PreProduction

• Service Stub B

• Dispatch Order

UAT

UAT

• Service Stub B

20

UAT
• License
Creation

• Send Invoice


Lab: Creating the training project
Complete the following tasks:
 Module 4.3: Create a new project in
Rational Integration Tester to use
for this course.

21


Complex environments


Generating a system model
Previously, you have seen how to create a model of the
system under test by hand. Rational Integration Tester
provides two faster methods of modeling the system:
• Synchronization
• Creating a system model from recorded events
These techniques are only available for selected
technologies.

23


Flight bookings

24


Hotel bookings

25


Flight administration

26


Synchronization


Synchronization
Synchronization provides an interface for importing
project assets, and mirroring updates to those assets.

28


Synchronization sources
A synchronization source provides information
about the logical and physical parts of the system
under test.
Synchronization sources:
•
•
•
•
•
•
•
•
29

WSDL
UDDI (including WebSphere Service Registry and Repository)
WebSphere Message Broker
WebSphere Application Server
webMethods Integration Server
TIBCO BusinessWorks Project / Design Time Library
SAP System
Oracle SCA Domain

Initial synchronization
The synchronizer will interpret the logical and physical
components, as well as any dependencies, schemas,
and so on.

30


Checking synchronization
Check Synchronization
can look for updates to the
system, and reflect those changes in the test project.

31


Lab: Synchronization
 Module 6.2: Synchronize with
WebSphere Application Server to
generate a model of the system
under test.

32


Building a system model from recorded events


Not all systems provide a convenient synchronization
source.
However, as long as we can record traffic from the
system, we can build a model of the system under test
from recorded messages.

34


Queue.A
Queue.A.Reply
Queue.B
Clients

Queue.B.Reply

Application
servers

Queue.C
Queue.C.Reply

35


Recording MQ
Queue manager
MQ request
queue
Client
application

Live service
MQ reply
queue

Rational
Integration
Tester

36

Recorded events


Recording MQ
There are five different ways of recording MQ traffic.
The method you choose will depend on the level of
access you have to the queue manager:
•
•
•
•
•

37

Queue browsing
Proxy queues
Mirror queues
Dynamic mirror queues
Queue aliasing


Lab: Modeling the system from recorded events
 Module 7.3: Set up the WebSphere
MQ transport for recording.
 Module 7.4: Add the message
schemas that will be used.
 Module 7.5: Record events from
the system under test.
 Module 7.6: Build operations from
your recorded events.
 Module 7.7: Complete the model of
the system under test.

38


Managing recorded events


Filtering messages
Filters can be applied to the Events View.

Select an event monitor to show only events coming
from that source.
40


Save Recorded Events Wizard
The Save Recorded
Messages Wizard is
used to convert saved
messages into:
• Operations
• Tests
• Stubs
• Triggers
• Requirements
• Data sets
41


Lab: Working with recorded events
 Module 8.2: Record events for the
MakeBooking operation and create
requirements from those events.

42


Creating and running a simple stub


Stub types
Simple

Nondeterministic

One of n hard-coded responses.

Data driven

Input and/or output data specified in external
data source (Excel, file, database).

Model driven,
stateful

Input and/or output data kept in data model with
complex relationships. Supports CRUD and
other stateful behaviour.

Behavioural

44

Hard-coded response returned for given input.

Provides prepackaged functionality, such as
shopping baskets, real-time data feed, trading
exchange, and order matching.


The stub editor

45


Events
A stub has a set of event handlers. Each event handler
filters an incoming message. If the filter is passed, the
event handler is used; if not, the message is passed to
the next event handler in the list.

46


Input, Business Logic, and Output
Each event handler has 3 sections:
• Input deals with incoming data, filtering if necessary.
• Business Logic allows you to add your own custom
logic.
• Output sends back a response message.

47


Hard-coded stubs
Hard-coded stubs are the simplest type of stub. They
can only supply a single response.
A hard-coded stub will only handle a single event.

48


Stubbing MQ - architecture
Queue manager
MQ request
queue
Client
application

LiveStub
Service
MQ reply
queue

Stubbing MQ is quite simple – the stub reads messages
from the queues that the live service was using previously,
and responds to the same reply queues. No changes are
required to the client application or the infrastructure.
49


Lab: Building a simple stub
 Module 9.2: Build a simple stub
from the messages that you have
recorded.

50


Running stubs
Stubs can be run from the Test Lab and will be visible
in the Task Monitor.

The Task Monitor will not show progress, but the
number of events the stub has handled.

51


The Console

The console shows the execution status of the selected
stub. Logging information will be displayed here,
including filtering information for each event.

52


Running a stub
Stubs can be run immediately by double-clicking in the
execution tree, by clicking the Run button or by
pressing F5.
Scheduling and environment options can be selected
using the Run… option.

53


Modifying a running stub

Any stub can be edited while it is being run in
Rational Integration Tester.
When the stub is saved, Rational Integration
Tester will offer to stop the previous instance of the
stub and run the new version. This can also be
done automatically.

54


Lab: Running stubs
 Module 9.3: Run a simple stub for
MakeBooking
 Module 9.4: Edit the stub while it is
running.

55


Publishing and deploying stubs


Rational Test Control Panel
Rational Test Control Panel allows us to manage all
parts of our wider system – agents, proxies, and stubs.

57


Publishing stubs
Stubs can be published from Rational Integration
Tester to Rational Test Control Panel. This makes
them available for deployment within the appropriate
environment, without requiring Rational Integration
Tester.

58


Deploying stubs

Stubs published to Rational Test Control Panel
can be deployed to Agents as required. Rational
Test Control Panel will then provide any users with
an overview of the currently deployed stubs.
59


Lab: Publishing and deploying a stub
 Module 10.2: Log into Rational Test
Control Panel and take a look at
the Agents and VIE tabs.
 Module 10.3: Publish a stub to
Rational Test Control Panel.
 Module 10.4: Deploy a stub from
Rational Test Control Panel to
Rational Test Virtualization Server.

60


WSDL synchronization


Lab: WSDL synchronization
 Module 11.3: Synchronize with the
HotelFinder WSDL.

62


Creating a stub from MEP


Web services: normal operation

Client
application

64

HTTP

Web service


Web services: adding the proxy

Client
application

65

HTTP

Rational
Integration
Tester Proxy

HTTP

Web service


Web service recording

Client
application

Rational
Integration
Tester

HTTP

Rational
Integration
Tester Proxy

Web service

Control link

Recorded events

HTTP

Rational Test
Control Panel

Control link

66


Stubbing a web service

Client
application

HTTP

Rational
Integration
Tester Proxy

HTTP

Control link

67

Stub

Rational Test
Control Panel


HTTP proxy in Vacation Booking
In the Vacation Booking example, we are concerned
with traffic between Tomcat and the web service.

Browser

HTTP

Tomcat

HTTP

Proxy

HTTP

Web
service

Within this setup, traffic between the browser and
Tomcat is not intercepted by the proxy.

68


Lab: Creating a web service stub
 Module 12.3: Create a stub for the
hotel search service using the
MEP.
 Module 12.5: Run the hotel search
stub and view the results.

69


Nondeterministic stubs
Nondeterministic stubs supply different hard-coded
responses for different inputs. A nondeterministic stub
will contain multiple event handlers.
Event handlers will normally provide a filter for
incoming data, so that each request message receives
the appropriate response.

70


Validation and filtering methods
Equality
Length

Checks string length within given range

Schema

Check that the message conforms to schema

XPath

User XPath 2 functions to validate embedded
XML

Regex

Use patterns for nondeterministic fields

Function

Custom validation or filtering

Is Null

Check for a null value

Not Null

Check for any value

XSD Type
71

Simple string validation

Checks field against XSD for message

Using multiple events
When using multiple events with different filters, the
console will show information regarding the filters used.
It will also show whether each filter passed or failed for
that message.

72


Message Differencing Window
The Message Differencing Window provides a
comparison between the configured message and the
received message. Go through each event handler
using the Previous Event and Next Event buttons.

73


Modifying stub events
If event handlers are not working as expected, the
message differencing window can be used to modify
the filters used for that event.

74


Lab: Working with multiple events
 Module 12.6: Add new cases to the
hotel search stub to handle other
cities.
 Module 12.7: Use the Message
Differencing Window to analyse
how the stub processes incoming
messages.

75


Storing and manipulating data


Tags

Tags are variables
internal to Rational
Integration Tester.
Tags available to the
current test can be
viewed in the Tag
Data Store.

77


Tags
System tags
 Commonly used system variables, such as time and date.

Environment tags
 Enable easy modification of test project.
 Used for queue names, and so on.

Test tags
 Pass data between test actions.

78


Special tags
Global tags
 Pass variables across tests in a test suite.

Java property tags
 Access Java properties using a tag with the same name.

Overridden Environment tags
 Environment tags that have been overwritten by test tags.

79


Environment tags
Environment tags can vary from environment to
environment. A default value can be set in the
Environments editor, then edited as needed for each
environment.

80


Creating test tags
Test tags can be created from the Tag Data Store or by
viewing a message and using the Quick Tag feature.

81


Storing methods

Copy
XPath

Use XPath 2 functions to extract data from XML.

Regex

82

Copies the entire string.

Use patterns for nondeterministic fields.


Retrieving data from tags
Tagged data can be
referred to after it has
been created – for
example, %%tag_name%%

Within ECMAScript, a tag
can be referred to as
tag_name or as
tags["tag_name"]
83


Lab: Tags
 Module 13.4: Use a tag in a hotel
search stub.

84


Scripting
Scripts can be written in ECMAScript.
These allow for further data manipulation and for
accomplishing tasks that cannot be done through
the test actions.

85


Lab: Scripting
 Module 13.6: Write a simple script
for the addNumbers web service

86


Guards
Guards can be set up on events to provide extra
filtering options.
For example, we can check that a start date comes
before an end date, and respond appropriately.

87


Lab: Guards
 Module 13.8: Use a guard to check
the inputs of a hotel search request
before sending a response.

88


Data driven stubs


Data driven stubs
Data driven stubs will react to incoming events based
on data supplied by an outside data source.
This allows us to quickly change or extend the behavior
of the stub without opening Rational Integration Tester.

90


Test Data Sources
Files
 CSV, delimited, fixed width

Excel
 Including 2007 and 2010 support

Directory
 Iterate over files with patterns

Database
 Tables or result sets

91


Lab: Data driven stubs (1)
 Module 14.2: Create a data driven
stub using recorded messages and
run it.

92


Create or Edit Test Data
Generate spreadsheets from tests using a group of
test tags as column headings.

93


Repeating elements
Multiple elements can be gathered when looking up
test data:
Corresponding items can then be marked in the
message as repeating elements (in green):

94


Lab: Data driven stubs (2)
stub using the MEP and run it.
stub that uses repeating elements
in the response message.

95


Sift and pass through


Sift and pass through
Under some scenarios, it might not be desirable for a
stub to handle every incoming message.
In these scenarios, a stub can be set up to filter
incoming messages. It can then handle those
messages, or pass them through to the live system.

97


WebSphere MQ: with intercept installed, no stubs

Client makes
request

98

Intercept
passes
message to
request queue

Live service
processes
request

Live service
sends reply to
client via reply
queue


WebSphere MQ: with stub processing message

Client makes
request

Request
diverted by
intercept to stub
queue

Message passes
stub filters

Client picks up
reply message

Stub posts
message to
reply queue

Stub processes
message

99


WebSphere MQ: with stub, discarding failed requests

100

Message fails all
stub filters

Client receives
no response

Client makes
request

Request
diverted by
intercept to stub
queue

Stub discards
request
message


WebSphere MQ: with stub and pass through

Client makes
request

Request
diverted by
intercept to stub
queue

Message fails all
stub filters

Reply message
goes to client via
reply queue

Live service
processes
original
message

Intercept posts
original
message to
request queue

101


Lab: Sift and pass through on WebSphere MQ
 Module 15.2: Create a stub for
MakeBooking that responds to all
messages for a single flight
number, passing anything else to
the live system.

102


Web services: with stub processing messages

Client makes
request

Message passes
stub filters

Stub sends reply
to client via proxy

103

Request diverted
by proxy to stub

Stub processes
message


Web services: with stub, discarding failed requests

Client makes
request

Request diverted
by proxy to stub

Message fails
stub filters

Client receives
no response (or
error if one was
generated)

Stub can
optionally send
back an error
message

Stub discards
request message

104


Web services: with stub and pass through

Client makes
request

Request diverted
by proxy to stub

Message fails all
stub filters

Reply message
forwarded by
stub to client via
proxy

Live service
processes
original message,
replying to stub

Stub forwards
request message
to live service

105


The Pass Through action
The Pass Through action can be used to discard
messages, pass them through to the live system, or
simulate errors at any point in a stub’s business logic.

106


Lab: Sift and Pass Through for a web service
 Module 15.4: Create a stub for the
hotel search using the Pass
Through action.

107


Stub configuration


Configuration at deployment time
Stubs can be configured when deployed. Options
include:
- Version
- Agents to deploy to
- Input tags
- Logging
- Response times
- Environment tasks
- Sift and pass through

109


Selecting agents
When deploying, you can choose which agents will run
the stub. At this stage, you can filter available agents
based on attributes.
Most attributes are set in the agent’s configuration files;
an operating system attribute will be set automatically.

110


Input tags
Tags can be marked as input tags.
When the stub is deployed from Rational Test Control
Panel, the user has the option of setting new values for
these tags, allowing them to change the behavior of the
stub.

111


Logging
Stubs have three different levels of logging, which can
be set when creating the stub or at deployment time:
- None: no information.
- Normal: log each filter and test action that is
processed.
- Debug: same as default, but include information on
each tag that is read from or written to.

112


Response Times
The response time for the stub can be varied at
deployment time.
Note that this is global for all event handlers; more finegrained control can be gained by editing the stub inside
Rational Integration Tester.

113


Environment tasks
Environment tasks can be run to prepare test data or
run commands in the system under test before the stub
starts.

114


Pass Through
If using a default Pass Through action for the stub, this
can be changed at deployment time.
Criteria for filtering inside the stub can also be set with
input tags, allowing you to change which messages are
handled by the stub.

115


Lab: Stub configuration
 Module 16.2: Use an input tag to
change the way a stub works after
it is deployed.
 Module 16.4: Combine input tags
with sift and pass through to
configure which messages are
handled by a stub when it is
deployed.

116


Managing stubs


Scenarios
Scenarios provide a way of launching a group of stubs
at once, including configuration details for those stubs.

This means any virtualization for the environment can
be launched in one step prior to testing.
118


Lab: Scenarios
 Module 17.2: Create and use a
scenario to manage a group of
stubs.

119


Environment locking
When testing, a stable environment is necessary.
If a stub is launched, shut down, or otherwise altered
by another user, tests running in that environment
could generate different results.
To make sure that conditions are reproducible, the
environment can be locked.

120


Locking the environment in Rational Test Control Panel
A user can lock the environment in Rational Test
Control Panel to prevent interference from other users.

Once the environment is locked, only that user can
start or stop stubs within that environment.

121


Lab: Environment locking
 Module 17.4: Lock and unlock your
environment using Rational Test
Control Panel.

122


JDBC recording and virtualization


JDBC recording and virtualization
Rational Integration Tester can record JDBC calls
made to a number of databases; the data from this can
later be used to create simulation databases.
Three tools are used in this process:
• Rational Integration Tester JDBC proxy (added to
the client application)
• Simulation database
• Rational Test Control Panel (controls the JDBC
proxy)

124


JDBC proxy modes
The JDBC proxy has several different modes, allowing
us to change how we are dealing with requests sent to
the live database – not just for recording, but also for
stubbing:
• Live mode
• Learn mode
• Simulate mode

125


Simulation databases
A database is required to simulate the real database.
This can be another database of the same type, or the
integrated Derby database.
• Using the same database requires extra
configuration and administration, but allows use of
SQL that is native to that database type.
• Using the integrated Derby database is much
simpler, but only supports more generic SQL.

126


Database stubbing and recording (Live mode)
Application core

Rational
Integration
Tester

Recording (optional)

Rational Integration
Tester
JDBC driver

Third-party JDBC
driver

127


Database stubbing and recording (Learn mode)
Application core

Rational
Integration
Tester


Tester
JDBC driver

Third-party or Derby
JDBC driver

128


Database stubbing and recording (Simulation mode)
Application core

Rational
Integration
Tester


Tester
JDBC driver

Third-party or Derby
JDBC driver

129


Editing database stubs
After their creation, the data set used by the database
stub can be edited through a spreadsheet or through
database tools. This allows you to add rows, columns,
or even tables.
These will then be used by the simulation database the
next time it is loaded.

130


Persistent and nonpersistent data
Database stubs can be persistent or nonpersistent.
If you want to reuse data that was entered in previous
sessions, use a persistent database stub. It will save
and reload its data for each session.
If you want to be able to test against the same data
every time, choose a nonpersistent stub. This will
reload the same set of data every time you start the
database stub.

131


Lab: JDBC recording and virtualization
 Module 18.4: Record database
interactions from the system under
test.
 Module 18.5: Create a database
stub from recorded events.
 Module 18.6: Modify your database
stub using a spreadsheet.

132


Alternative message formats


Alternative message formats

Once you have learned
to use one, you can use
many formats in similar
ways.

SOAP

XML

SWIFT

COBOL Copybook

DTD

XSD

WSDL

EDI

JSON

FIX

Text

Tester and Rational Test
Virtualization Server
support a wide range of
messaging formats.

MIME

Byte Array

Java Objects

SAP BAPI/RFC/IDOC
TIBCO ActiveEnterprise
webMethods IB and IS Documents
Custom…

134


Lab: Alternative message formats
 Module 19.2: Create an operation
and a stub for a service that uses
COBOL Copybook messages.

135


Data masking


Data masking
Not all data should be recorded and displayed to users.
Some data should be sanitized before use; for
example, data that contains secure or private
information.
Data masks allow us to substitute other values in place
of this data.

137


Data masking methods
Fixed value substitution
•

Replace data with a fixed value.

Data source substitution
•

Replace data with a set of values taken from a data
source such as an Excel spreadsheet.

Automatic value creation
•

138

Automatically generate data replacements based on a
regular expression.


Lab: Data masking
 Module 20.2: Use a fixed value
substitution data mask.
 Module 20.3: Use a data source
substitution data mask.
 Module 20.4: Use an automatic
value creation data mask.

139


Data model stubs


Tracking data for a stub
Sometimes, nondeterministic or data driven stubs will
not be enough. In order to virtualize some systems, we
might need to track the state of data within the system.

In order to track the data held by the system, we will
use a data model.

141


Data models
A Data model allows us to track the state of data for a
stub, providing the ability to Create, Read, Update, and
Delete data (CRUD).
Data is tracked as a set of entities,
each with their own set of attributes.

142


Data model stubs
A data model stub is a stub with access to the entities
and attributes held within a data model, and it can
perform CRUD or other stateful operations as required.

143


Tags for data models
There are two methods to access data models
through tags:
Data Model Tags (Store Mode)
 Write to entities and attributes in the current data model.

Data Model Tags (Lookup Mode)
 Look up entities and attributes in the current data model.

144


Use of data models
Data described within a data model is managed by
Rational Integration Tester, and persists between
executions of any stubs that access the data model.
Data models can be shared between multiple stubs.

145


Lab: Data model stubs
 Module 21.2: Record interactions
with the system to provide enough
data for the creation of a data
model stub.
 Module 21.3: Create a data model
stub from recorded messages.
 Module 21.4: Edit the data model
stub in the Test Factory.

146


State and sessions


State
Stubs can track state. This can be a global state for the
stub, or it can be on a session by session basis (using
a conversation key)

Event handlers can then act differently depending on
the state of the stub.

148


Lab: Stateful stubs
 Module 22.2: Create a stateful stub
based on recorded messages.

149


Behaviours


Behaviours
Advanced stubs can be programmed with behaviours.
These allow for events other than messages to trigger
the stub.
Examples:
• Lifecycle
• Timer
• Message feed *
• Shopping basket *
(* Suggestions only, not supplied with Rational
Integration Tester)
151


The timer behaviour

The timer behaviour allows the user to set one or more
timers, and to have the stub react when a time limit
expires.

152


Lab: Behaviours
 Module 23.2: Add a timer
behaviour to your stateful stub to
log the user out after 30 seconds of
inactivity.

153


154


Course legal notices
 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.
 If you are viewing this information in softcopy, the photographs and color illustrations may not appear.
 Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained
in other operating environments may vary significantly. Some measurements may have been made on developmentlevel systems and there is no guarantee that these measurements will be the same on generally available systems.
Furthermore, some measurements may have been estimated through extrapolation. Actual results may vary. Users
of this document should verify the applicable data for their specific environment.
 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.

155


Course legal notices (cont.)
 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.
 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. The sample programs are provided "AS IS", without warranty of any kind.
IBM shall not be liable for any damages arising out of your use of the sample programs.

Trademarks and service marks
 IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp.,
registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other
companies. A current list of IBM trademarks is available on the web at www.ibm.com/legal/copytrade.shtml.

 Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its
affiliates.
 Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both.
 Linux is a registered 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.

156


Rit 8.5.0 virtualization training slides

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (14)

Similaire à Rit 8.5.0 virtualization training slides

Similaire à Rit 8.5.0 virtualization training slides (20)

Plus de Darrel Rader

Plus de Darrel Rader (6)

Dernier

Dernier (20)

Rit 8.5.0 virtualization training slides