Use of CORBA and UML pays off in many types of
applications, but here's where the benefits compound:
If you use CORBA in a small client-server type of
application, you'll get the benefits of a sound, standard infrastructure, and
if you use UML to design before you start to code, you'll be much more likely
to get a final application with the structure and functionality that you had
in mind (or would have asked for!) when you started. CORBA lets you build and
run client and server sides on different platforms and in different
programming languages, so there are a number of benefits that we can list even
for small applications run alone on a network. But these are purely compute-domain benefits; the business functionality of
this type of application is the same as if it had been written to sockets, or a
proprietary RPC mechanism. CORBA can give immense business-domain
benefits also, when it's used pervasively in your enterprise. Let's have a
look:
Businesses benefit when all of their applications, with
their diverse functionality and data, work together. For example, a salesman
on the road in a customer's office may need access to product description
information (from the catalog), product technical data (from engineering),
pricing (from the back office), stock (from the warehouse), production
schedule if there aren't enough in stock (from the plant), order placement,
customer credit data, sales department totals and his own totals, and more. In
the old days, he used to collect this by telephone and memo, moving to FAX as
technology advanced, but now computer networks give you an opportunity to make
the diverse systems in all of these departments work together to support your
salesman as he generates the income that, after all, keeps your company in
business.
So you wrap these legacy applications with OMG IDL
interfaces and put them all onto your network, accessible via CORBA object
references. This lets your IT department build a client that integrates
information from all of them into a sales application. Your salespeople,
on-line in their customers' offices via modem or wireless connection, can
answer questions immediately and make more sales. Orders enter into your
fulfillment system as they are taken, allowing you to schedule shipping (and
production, if you need to) and billing automatically and immediately.
Then it occurs to someone in your company that, with a
little tweaking, the salespeople's' application could become a web sales site,
allowing any potential customer with a browser to find and order your products
themselves. Because all of your supporting applications are available via
CORBA, it's easy to generate the application that drives the website, so you
do this, and the sales start rolling in.
With so many customers out there, the load of product support and
repair calls increases and, since support has always been a cost center, you
brainstorm to figure out a way to deal with it. You finally decide to design a
call-center support application around your CORBA enterprise infrastructure.
By standardizing response to trouble calls, you deal with these in less time,
but the real benefit comes in parts and repair: With all of the engineering
diagrams on-line, your telephone staff can sell and ship parts to customers
with one or two clicks of a mouse, and with another click or two, can
dispatch contracted repair vans to take care of the installation. Income from
parts and commission on repair calls turns this cost center into a profit
center, and customers satisfaction increases at the same time. Integration of
the many applications around your enterprise that connect to the call-center
application, a potential nightmare, is straightforward because they all have CORBA
wrappers already.
With success, the load on your e-commerce website
increases until it outgrows the capacity of the mainframe applications that
supported it at start-up. Since CORBA has been so successful for you on your
network, you decide to build your server's replacement object-oriented in CORBA from the ground up.
To start, you use UML for your
analysis and design: it helps you gather requirements, work through use-cases,
and set down the functionality that the new server will provide. Then, class
diagrams, object diagrams, and action diagrams let you picture how it will
work. By the time you're done, the UML diagrams that you've generated dictate
most of your OMG IDL and language code. To take care of both current and
anticipated load, you decide to buy an ORB that runs load-balanced on a
roomful of server machines. It's based on OMG's Portable Object Adaptor or POA,
which helps you take best advantage of your hardware when you run heavy loads,
like the ones that web-based applications generate. If your application needs
to stay up reliably (as it would if you're running stock or bond trades, for
example), you may decide to use CORBA Fault Tolerance also. More than just
load-balancing, fault tolerance runs every object on two or more separate
machines at the same time and automatically switches to the good one if one
fails. If you duplicate your hardware (computers, networks, even power
sources) also, you can set up a very reliable server indeed. By the way, you
haven't replaced all of your legacy systems (that is, the functional systems
that run your business!), and this server still needs to
access the ones that are still around. Since they all retain their CORBA
wrappers, of course, this is routine. To maximize sales, you design the
front-end for this server to be accessible from as many customer client types
as possible: Some customers come in via web browsers, using HTTP which your
web server translates into CGI invocations of your CORBA front end. Others use Java/CORBA clients for
more sophisticated programmatic access, while some users with direct network
connections use OMG's standard COM/CORBA bridge to come in straight from a
Microsoft desktop. Type-specific adapters condense your
screens, eliminating graphics and isolating key lines of text, enabling digital PDAs,
pagers, and browser-capable cell phones to place orders using your same
business-logic architecture and implementation.
To keep up with demand, you decide to automate your
plant. Because of the speed that parts travel around the assembly line, the
control program must run in Real-time so you build this system on an ORB and
operating system that conform to the CORBA Real-time specification. Computers
on your shop-floor equipment also runs CORBA (in Real-time where needed here
too), so your plant hums smoothly along; in fact, some of the processors on
your shop floor run minimal CORBA, OMG's standard for embedded ORBs. Of course
the plant doesn't run in isolation: it needs stock, which needs to be bought,
which cost money, and needs to be brought to the plant, which needs logistical
coordination, so your automation system also talks to your supply and
logistics applications over CORBA interfaces, of course.
We could go on, but you get the idea. The next addition
would be CORBA-based interfaces to your suppliers, automating your logistics
out to their warehouse (and, within their enterprise, hopefully to their plant
as well). This is not a purely hypothetical example; Boeing Aircraft automates
its manufacturing system from order entry, through production and delivery, to
maintenance, using CORBA. You can read about it here.
So where's the payoff? Just as the different departments
and divisions that make up your enterprise need to work together in order to maximize profit, their
computing applications need to work together too. CORBA lets you do this, and
that's where standards pay
off in a big way: You can't limit the diversity of computers in your
enterprise - you need to pick different computers for different uses. This is
clear on the shop floor, where equipment may come with a processor built-in,
or in the call center, where machines need to link up to the telephone system
computer for both voice and data to take advantage of ID information that
comes with incoming calls. So, you pick a standard interoperability
infrastructure - CORBA! - to tie your applications together. You'd like to use
it for all of your applications, but sometimes this just isn't
possible. For these cases, CORBA gives you the couplings you need: the COM/CORBA
interoperability standard to connect to the desktop that everyone uses (and to
Microsoft servers, too, if you have them); the reverse Java-to-IDL language
mapping and RMI/IIOP to connect to Java RMI objects and EJBs, and the mapping
from XML to OMG IDL, scheduled for June 2000.
There's a good example of how OMG's specifications work
together in the example we just covered, but here's a concrete description:
You'll want (and need, actually) to perform an analysis
and design before starting any substantial software development project. For
this, you buy and use a tool based on UML, the Unified Modeling Language.
Using XML Metadata Interchange or XMI, you transfer your model - which is the metadata
for your application- into a standardized repository based on the MOF, or
Meta-Object Facility.
Using XMI again, you transfer your model from your MOF
into a development environment that lets you implement it as a CORBA
application. You will generate OMG IDL interfaces, which will map into the
programming languages that you choose for your clients and objects, using the
OMG-standard language mappings. You may design a scalable server-side
architecture using features of the Portable Object Adaptor or POA, and augment
CORBA's support for load-balancing with a standard Fault Tolerant
infrastructure. You will surely want to design your overall application around
the CORBAservices and possibly the Domain CORBAfacilities to reap the major
gains possible from the buy-vs..-build philosophy.
If you're building a specialized application, you may
want to buy an ORB product based on one of the specialized CORBA versions,
either Real-time or Minimal (for embedded systems) CORBA.
