Cloud Computing and SOA Convergence in Your Enterprise: A Step ...
Cloud Computing and SOA Convergence in Your Enterprise: A Step ...
Cloud Computing and SOA Convergence in Your Enterprise: A Step ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
166 Chapter 9 Test<strong>in</strong>g from <strong>SOA</strong> to the <strong>Cloud</strong>s<br />
been prevented with adequate test<strong>in</strong>g. We need to take these lessons, hardlearned<br />
by others, <strong>and</strong> make sure that test<strong>in</strong>g is high on our priority list.<br />
How Do We Test Architecture<br />
The answer is, we don’t. Instead, we learn how to break the architecture down<br />
to its component parts, work<strong>in</strong>g from the most primitive to the most sophisticated,<br />
test<strong>in</strong>g each component, <strong>and</strong> then <strong>in</strong>tegrat<strong>in</strong>g <strong>and</strong> test<strong>in</strong>g the holistic<br />
architecture. In other words, we have to divide the architecture, which <strong>in</strong> this<br />
case is partly on-premise <strong>and</strong> partly <strong>in</strong> the clouds, <strong>in</strong>to doma<strong>in</strong>s, such as services,<br />
security, <strong>and</strong> governance, <strong>and</strong> test each doma<strong>in</strong> us<strong>in</strong>g whatever approach<br />
<strong>and</strong> tools are <strong>in</strong>dicated. If this sounds complex, it is. The notion of <strong>SOA</strong> us<strong>in</strong>g<br />
cloud comput<strong>in</strong>g is a loosely coupled complex <strong>in</strong>terdependence, <strong>and</strong> the approach<br />
for test<strong>in</strong>g must follow the same patterns.<br />
White Box <strong>and</strong> Black Box Test<strong>in</strong>g<br />
We use two major approaches to test<strong>in</strong>g our architecture: black box test<strong>in</strong>g <strong>and</strong><br />
white box test<strong>in</strong>g.<br />
Black box test<strong>in</strong>g is the process of test<strong>in</strong>g functions <strong>in</strong>to which we do not<br />
have complete visibility. For <strong>in</strong>stance, we might ask a system to perform some<br />
sort of behavior, such as to return <strong>in</strong>formation from an API call, <strong>and</strong> we would<br />
not be able to see what happened <strong>in</strong>side that system as it accessed the database<br />
<strong>and</strong> processed the <strong>in</strong>formation on behalf of the request.<br />
Black box test<strong>in</strong>g is most important when leverag<strong>in</strong>g cloud comput<strong>in</strong>g<br />
because we typically do not own, control, or have visibility <strong>in</strong>to the <strong>in</strong>side of a<br />
multitenant cloud comput<strong>in</strong>g system. Black box test<strong>in</strong>g is the typical approach<br />
<strong>in</strong> an <strong>SOA</strong> <strong>and</strong> cloud comput<strong>in</strong>g system, <strong>and</strong> we discuss how to approach black<br />
box test<strong>in</strong>g at the end of this chapter.<br />
White box test<strong>in</strong>g, <strong>in</strong> contrast, allows us to test a system while hav<strong>in</strong>g complete<br />
visibility <strong>in</strong>to the system. When we ask a system to perform some sort of<br />
behavior, such as return<strong>in</strong>g <strong>in</strong>formation from an API call, we can see how the<br />
request is <strong>in</strong>ternalized <strong>in</strong>to the program, how the database request is formulated,<br />
how the database is accessed, how the <strong>in</strong>formation returned from the<br />
database is processed . . . you get the idea.