Cloud Computing and SOA Convergence in Your Enterprise: A Step ...

Testing from the Enterprise to the Clouds and Back 171
stance, a customer validation service may be part of a customer processing
service, which is part of the inventory control systems. Aggregations are clusters
of services bound together to create a solution; they should be tested holistically
through integration testing procedures.
Security-Level Testing
Security strategy, technology, and implementation should be systemic to an
SOA using cloud computing, and they bring along new concepts such as
identity management. When testing an SOA using cloud computing for security
issues, the best approach is to first understand the security requirements
and then design a test plan around those requirements, pointing at
specific vulnerabilities. Most IT folk are finding that black box testing is the
best way to test for security issues in the world of SOA using cloud computing,
including penetration testing, vulnerability testing, and so on, using existing
techniques and tools.
A further security concern is that an SOA using cloud computing architecture
allows services to be consumed outside the enterprise, which creates a
new set of vulnerabilities such as information security issues and denial-ofservice
attacks. We also make the reverse trip, allowing for the consumption
of services outside of the firewall. This opens the door for other types of attacks,
and the security must be tested in this case as well. Vulnerabilities in
this case include malicious services.
Process-Level Testing
As you may recall from Chapter 7, “Working from Your Processes to the
Clouds,” we can define processes using a standards-based mechanism that defines
how Web Services work together, including business logic, sequencing,
exception handling, and process decomposition, as well as service and process
reuse. Processes may span a few internal systems, systems among organizations,
or both. Some processes are long-running, multistep transactions, almost
always controlled by one business party, and are loosely coupled and
asynchronous in nature.
Processes are really functional services in the context of our architecture.
We test them as we do other services, including abstraction, reuse, granularity,
and so on. However, note that these processes sit above existing services, and
the testing should regress from the top-level services down to the bottom-level