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.
