Rational Integration Tester takes
a service-oriented approach to testing.
Using this approach, business logic is modeled as
one or more services, each one containing a number of operations with
which the system can interact.
Architecture School is Rational Integration Tester’s
initial view (or perspective). In this perspective, users (that is,
Architects) build the system to be tested in a simple, graphical fashion.
The Architect defines the logical and physical system components and
their relationships to one another.
Note: Logical components are bound to physical components
by using one or more environments.
When a new project is opened in Rational Integration Tester,
an empty palette is presented in Architecture School. How the system
is built varies, but it follows the same basic steps – create a service
component, add operations to the service component, add infrastructure
components, create physical components, create environments and bindings,
and so on
Rational Integration Tester considers
the following items when you are building a system under test:
- Service Components are named components
that expose one or more operations to be tested. A service component
can be simple (that is, has no child components) or composite (that
is, has one or more child components).
- Infrastructure Components are named components
(for example, a database, a JMS domain, an HTTP connection) that can
be bound to physical resources by using an environment. Infrastructure
components do not expose any testable operations.
- Operations are interfaces that define a
service component’s functionality. An operation is defined by a Message
Exchange Pattern (MEP) that describes the message pattern (Publish
or Request/Reply) required by the operation’s transport to establish
communications.
- Physical Resources are testable resources
within the enterprise (for example, a database or a web server) that
represent a single configuration of an infrastructure component. The
binding between the infrastructure component and the physical resource
is configured in one or more environments.
- Dependencies represent a reference from
one operation to another, or from an operation to an infrastructure
component. For example, if an operation’s output is stored in a database,
the operation would have a reference to the database (that is, it
would depend upon it). Outgoing dependencies are displayed in lavender,
and incoming dependencies are displayed in green. Dependencies are
only displayed for items in the diagram that are selected.
By itself, the logical system does not contain enough
information to be testable. To enable the creation and execution of
tests, the configuration details of the infrastructure components
that make up the logical system must be provided. These details are
stored in physical resources, which can be bound to infrastructure
components (by using an environment).
Note: An infrastructure component can have any number
of physical resource implementations, but only one binding can exist
when you are running a test.
Users can do the following in Architecture School:
- Create and edit Service and Infrastructure Components
- Define a Service Component’s operations and dependencies
to other operations and Infrastructure Components
- Create and edit Physical Resources
- Define the bindings of Infrastructure Components
to their Physical Resources for different testing environments