|
CT middleware? Isn't that the API -- the "driver" as it is
sometimes called -- that comes with a voice board? Well, perhaps. But
the term "middleware" is borrowed from enterprise client-server
computing. It denotes the "connectivity software that consists of a
set of enabling services and their APIs that allow multiple processes
running on one or more machines to interact across a network." So the
term is more appropriately used for the third-generation of CT
environments such as Commetrex's Open Telecommunications Framework
(OTF) and Dialogic's CT Media.
 But
if middleware is the software that comes with a voice board, what's left to
choose once you've picked your board vendor? A few years ago, the
answer was "nothing," since the two were bundled by the board vendor. But
open communications then created a second- generation layered value-adding structure.
Throughout the '80s and '90s there have been
three significant value-adding layers: an open computing platform, be it
PCI, CompactPCI, or VME; the media-processing and switching resources
(boards) bundled with their APIs (and drivers); and the application layer.
But that's changing, and the change is making the open-communications
industry more open and efficient.
In the last half of the '90s, new open interfaces have been published
that support further specialization -- this is the third generation of
value-adding layers. The ECTF
has published S.100, an open client-server system framework and API that
promotes application integration and portability. (That's middleware.) And
the MSP Consortium
has published M.100, an open specification for a multi-vendor media
processing software environment. It promotes the portability and
integration of media technologies from multiple vendors onto one
media-processing resource. The PCI
Industrial Computer Manufacturers Group has published specifications
that will bring the development efficiencies of the open communications
industry to carrier-class equipment.
What this means is that in the coming
decade vendors will enter the market without having to spread their resources
thin, focusing on just piece such as: an application, PC-based middleware,
boards and their environments, network interfaces, media-processing firmware, and
system-level hardware.
This list has expanded by 50 percent over what it was just
a few years ago. But why is that specialization good, and what's wrong
with the way it was done in the early '90s? The answer is that as the
technology shaping the industry changes, so must computer telephony.
In the days of first-generation open communications, life was simple. We
had DOS systems with four-port voice boards that supported voice
processing. (The second generation began with MVIP.) But now we have
affordable 550 MHz processors and high-function multi-threaded operating
systems. Industry-standard PCM highways, such as H.100 interconnect
DSP-resource boards with several DSPs, are each capable of supporting 60 voice
ports. The only way to effectively apply such power is to integrate media
and applications onto one high-function, high-capacity platform. With CompactPCI supporting open communications' move into the
carrier-equipment market, that platform must be easily scalable to support
thousands of ports. So far, the only practicable way to do that is with
client-server architectures.
Since media and application competencies are generally limited within
one company, value-adding interfaces are required to allow the integration
of multi-vendor products onto one platform, just as in the PC industry.
What this means is the system integrator can take media-processing
hardware resources from one vendor, fax from another, and high-speed data
modems from another to create an integrated-media resource on just one
board. And instead of one vendor having to develop each application for an
integrated-applications communications server, S.100-conforming
applications can be selected from companies that specialize in their
respective area -- such as voice, fax, or data -- and integrated onto one
common platform.
Matching Solutions To Needs
But there are applications that do not need CT middleware. The developer
of a low-density voice system has many choices of a simple cost-effective
platform if multiple media and scalability are not a concern. But as an
example of a more complex application, let's
look at the developer of a new system resource, such as a CompactPCI-based
media-processing resource or a PCI-based conference bridge.
Regardless of whether the developer wants to offer these products as
system building blocks on the open market or to use them as components in
an integrated system, a system environment will be required. That is the
reason few companies can justify the investment required for such
products. It is not the cost of the hardware, or even the DSP software,
it's the investment required in the total system software environment. If the product is brought to market, the environment that is developed to
support it is usually low in function to keep development costs down.
If you are developing a specific system you have definite
requirements. If you anticipate very large volumes of that one system, you
might be able to narrow your middleware selection to focus on just those
requirements. On the other hand, you may have a wide range of
requirements. In the former case, you need a platform for today's specific
application; in the latter case, you need a strategic platform that will
take you well into the future.
Strategic Control
Before the introduction of the 4-port voice board in 1984 there was no
make-buy decision for a strategic platform. But the investment that went
with "rolling your own" in the '80s was not as great as today
since voice, the only media processing required, was also the easiest to
implement. Today, with the requirement for media diversity in strategic
platforms, doing it all in-house can rarely be justified. However,
outsourcing the platform means ceding significant control of your
product's architecture to a third-party vendor. And the fewer
value-adding layers within that platform, the more control you give up.
If there is a value-adding interface between the media-processing
resource hardware and software (usually DSP software), the developer/OEM
can select from a variety of vendors. Indeed, with an MSP Consortium
M.100-conforming environment on the hardware resource, various media
technologies from different vendors can be easily integrated. Furthermore,
if there is an interface between the CT middleware and the media resources
then the choice of middleware can be made independently of the other
system components. And if the middleware supports multi-vendor application
integration, as does S.100, applications can be chosen from multiple
vendors. This opens the possibility of the developer of a PBX application,
for example, integrating it with fax server and voice messaging
applications from different vendors, dramatically lowering the cost of
developing an integrated communications server.
Extensibility
Today, the vast majority of systems fit within the resource boundaries of
one PC. This limit exists because running out of MIPS
or slots means a major investment in development must be made to expand to
a multi-PC system, unless a client-server middleware system is being
employed. With second-generation architectures, media resources must be in
the same PC as the controlling application. And if PCM highways are used
to transfer a call stream between media resources instead of packet
switching/routing, a significant investment in inter-chassis PCM highway
interconnection must be made. This means large multi-PC systems based on
second-generation architectures are disproportionately expensive.
The solution to this problem is to move to third-generation
architectures and embrace packet-based transport over PCI for
intra-chassis stream switching, and Ethernet infrastructure for
inter-chassis transport. Yes, the benefits of packet-based telephony in
the wide area apply just as well to scaling computer telephony systems.
And with client-server architectures, the media-processing resource does
not have to be co-located with its controlling application. One
application can utilize resources in multiple computers without the
application being located on the additional computers.
Resource Independence
With value-adding separation between media resources and the host-based
software, the system developer has the option -- only available with
third-generation architectures -- of choosing resources from multiple
vendors, all of which interoperate with common host-system software. CT
Media from Dialogic exposes CT Media resource-specific interfaces between
the server and the resource-provider entity. This allows a resource vendor
to substitute its media resource for the Dialogic resource provided the
third-party resource conforms to the exposed interface. Commetrex's OTF
exposes a transport interface, rather than a resource-specific interface,
allowing third-party media resources to be added to the system as long as
the vendor provides both the resource and the client API.
So the question is this: If your vendor does not supply the media-processing
resource you need now or may need for some future requirement, how do you
add it to your system? Don't forget to ask prospective
vendors the following questions:
1. Can the media-processing software be purchased or developed in- house
and easily integrated into the middleware environment?
2. Can that media-processing software be easily ported to the same
hardware resource you are using for other media, and still be supported by
the environment?
Application Integration
One of the promises of S.100 is multi-vendor application integration.
Because S.100 is relatively new, systems with cooperative multi-vendor
application integration are rare. Consider the current attempts by a dozen
or so start-ups to develop integrated-application communications servers.
They are developing all the applications themselves. Is it because they
believe they can do better than the vendors specializing in each
application, or is it because of the lack of multi-vendor integration at
the application level? Just as specialization in multiple media-processing
technologies is rare, so too is it rare in the application space. But few
organizations are really good in multiple applications, so an environment
that supports multi-vendor application integration is required. It means
the system integrator can choose one application from vendor A and a
complementary application from vendor B, finally bringing value-adding
market efficiencies to the integrated communications server.
The Decade Ahead
In the next decade, client-server CT middleware will give the application
and system-resource developer new options that will enable entry into new markets. The open-communications market is subsuming adjacent markets
because of its development efficiencies. Moreover, the advent of
next-generation architectures always accelerates the pace of innovation.
Expect to see this industry move vigorously into carrier-class network
equipment, including high-capacity gateways and integrated-access
equipment. Also expect to see affordable support for high-speed data and video
conferencing. Service platforms of all types will be almost exclusively
built on open-system components.
For the OEM interested in application integration, vendor independence,
resource independence, integrated media, multi-PC scalability, and
improved control of strategic platform, third-generation client-server
middleware offers the best solution.
Mike Coffee is the president of Commetrex Corporation. Commetrex
develops, produces, and markets business-enabling technology products for
the communications system developer. For more information on, visit
Commetrex's Web site at www.commetrex.com. |
