Page 463 - Handbook of Modern Telecommunications

3-254 CRC Handbook of Modern Telecommunications, Second Edition

Similar considerations come into play when we look at application-to-application communication.
First, we need to establish a method of communication. While this is important and can be complex, it
is far from sufficient; sadly, many specifications stop here. The more astute will realize that they need to
specify a common syntax. These two layers are also where much of the standardization efforts seem to
focus. Yet even when a common syntax is defined between applications, there is no guarantee that the
applications will be able to really communicate.
To understand why, we can look at an example. Two applications can share a common syntax for
“contact” and thus know how to exchange contact information. Yet unless there is common semantics
defined that indicate what contact means, application A may think contact is the billing contact while
application B may think that contact is the person reporting a fault—often very different people. So
defining a common semantics will ensure that the two applications apply the same meaning to the infor-
mation they are exchanging. But unless we define a common pragmatics, the two applications may not
have a common understanding of why they are exchanging the information in the first place. Often we
are asked how much it will cost to integrate two applications. The answer is always the same: “Anywhere
from $0 to millions of dollars, it all depends on what you want the integration to accomplish.”
Fortunately, methodology for building systems exists that, if used properly, provides the necessary
approach. This is what has come to be known as Service-Oriented Architecture.

3.10.5.1 SOA Approach
Service-Oriented Architecture (SOA) is an approach that considers the services provided by the differ-
ent organizations in an enterprise and the parallel services offered by the systems that support those
organizations. Properly done, the service decomposition is always based on the objectives and desired
business outcomes of the enterprise. By recognizing that any system can be decomposed as a system of
systems, this decomposition can be recursively refined to the necessary level of depth.
While the term SOA is relatively new, the concepts behind SOA have been around for a while. The
TMF’s NGOSS is defined using SOA principles, formalized through well-defined “contracts” or inter-
faces providing the service specification. The HP OSS solution, which was developed simultaneously with
TMF NGOSS (with some of the same people involved in both efforts), also follows the SOA approach.
These days, SOA is often equated with Web services. While Web services do provide a good mecha-
nism for implementing a SOA, it is important to recognize that SOA is a technology-neutral approach.
As we saw in our discussion of human-to-human communication above, the method of the communi-
cation, though important, is not the critical aspect of the communication. Similarly, while Web services
might make the implementation of SOA easier, there are other technical approaches that may make
more sense in some situations.
In its implementation of SOA interfaces for the OSS applications, HP has developed an approach that
allows us to create different integration profiles. These integration profiles provide the communication
mechanisms without affecting the semantics or intentions behind the communications. This approach
allows different technologies to be used, and even to change the technology used for communication,
without affecting the business processes or even the applications implementing the processes.

3.10.5.1.1 Governance and Standardized Interfaces (SOA Services)
Many years ago it was not uncommon to hear “Oh, you are building an application using DCE? So am
I. That’s great, they will be able to work together as a distributed system!” That thinking has remained
over the years, with only the technology changing from DCE to CORBA, EJB, JMS, XML, and so forth.
The same sentiments now exist with the technology discussed being Web services. While it is true that
these technologies facilitate building distributed systems, and each technology brings particular value,
these technologies, on their own, are insufficient to allow the definition of a distributed system. It does
not take too much effort to come up with examples of independently defined interfaces for similar
functionality that use sufficiently different syntax and semantics to make mapping between the two
problematic at best.