Paul: Will IIOP replace or work in tandem with HTTP?

Andrew: That's an interesting one. I think "work in tandem" is the answer. Technically, it could replace HTTP. But then, as we know, what's technically possible very rarely has anything to do with what actually happens in this industry.

There are things that HTTP doesn't do, or doesn't do well - particularly having to do with active content on the web. If I download a Java applet from a web page, HTTP handles the downloading into the web browser very nicely, because it's got an extensible content facility. It uses so-called MIME data types to identify the content of each component of a web page; there's a MIME datatype for a Java Applet, allowing you to download it into your Java-enabled web browser, and run it, even though Java didn't exist when HTTP was designed (by the way, there are other mobile code schemes - I'm just using Java as an example). The problem is, once that piece of mobile code is sitting in your web browser, although it can use the web browser to interact with you, it's isolated on the other side. It's difficult for the applet to get a communication channel back out to the other servers or applications out there on the net, and this is where IIOP comes in. IIOP is the underlying communication protocol for CORBA. CORBA provides a straightforward communications mechanism over the net that something like an applet can use to escape from this isolation so that it can then talk to other services. Some people have looked at schemes to allow that kind of communication from a downloaded applet to take place using HTTP, and that's sort of possible, but it's a horrible hack. Really you're making HTTP do something it wasn't designed for. The much neater solution is to use the IIOP protocol by way of using a CORBA ORB. So I think the short answer to your question is, IIOP and HTTP will work in concert with each other on the web in the near and medium term.

Paul: So how will you use an HTTP based site or page along with an IIOP based? What would be the specifics of how you would use them in tandem?

Andrew: OK, just for the sake of example let's imagine you've just fired up your Java-enabled web browser and you're surfing around the net, like you do, following links. All the time that you're doing this, you're using HTTP as the communication protocol with all these different web servers you're using from your web client. The web is a great way of basically looking at text and pretty pictures. It was tailor-made for people who want to put together things like mail order catalogs. Nice typography, nice pictures, and all the interaction is one way; the information goes from the server into the client.

So you reach some site that needs to do something more interactive with you as the "customer". An example might be a home banking service where you need to send requests to find out about your particular bank account or what checks have been paid, that kind of thing. If I was designing a site to do this I would write one or a number of applets in something like Java to handle the user end of interaction; to provider the user interface and do things like data verification; handling authentication and also encrypting the obviously quite sensitive data as it goes across the net. In my design I would download that applet into the client's web browser. And so far we're still talking about HTTP; you click on the link, you go to the bank's web site, the server downloads the applet using HTTP, and then this mobile code gets run and in a sense it takes over the web browser, so now you're not talking just using the pure web; instead you're interacting with this applet, and the applet is then mediating for you out to the resources you need to access at the bank.

That communication can't easily be done with HTTP, but it can be achieved using IIOP and a CORBA ORB. Now the question is, for it to work, you need to have a CORBA ORB at each end of the interaction. You need to have one at the bank's computers, and that's straightforward. The other half of the equation is how does the client end, the applet running in the web browser on your desktop PC, get access to a CORBA ORB to be able to communicate?

There are two answers. You can write an ORB in Java, and that's been done several times now. There are something like six or eight different implementations of ORBs in Java kicking about the net. Some by academic researchers, and a healthy number as commercial products. People like Iona and Expersoft have ones that they sell. People like Oracle and HP have them as internal products, and there are at least another two that I know of that are academic. So one way this hypothetical bank could get an ORB to you would be to download one written in Java along with the applet. And so all the technologies arrive in your Java enabled browser all at once; the custom-written applet that the bank needs in order to drive the user interface (or whatever), and the off-the-shelf technology, the Java-written ORB that then allows that custom code to talk to the rest of the world.

The other way to get access to an ORB in the browser is to build it in, and as I'm sure you know, this is what Netscape is doing at the moment. They're building CORBA into Netscape 4. And really the reason for that is for convenience. If the thing's already there it doesn't need to be downloaded.

The two approaches are interchangeable. If you have a Java-enabled browser that doesn't have an ORB in it already, you can download one. It takes a little more time, especially over a slow modem, but if I was designing a scheme like this for somebody like a bank I would actually want to exploit both approaches. I would make the code check out whether there was some facility available already, if there was use it, and if there wasn't, download it.

Paul: There's a lot of industry support for CORBA at a technology level, but how is OMG and the industry going to overcome the non-technical issues? For example, how will parts vendors get paid? How will virus concerns be overcome and so on?

Andrew: Yes, those are all interesting questions. All of the solutions are to some extent rooted in authentication and encryption technology, in my view. The virus issue really only has a bearing on mobile code. If you're not moving code around, if the client that is being run is installed in the normal way (read off a diskette or CD ROM or whatever) then the virus issue is exactly the same as it would be if we weren't talking about CORBA technology.

If we're concerned about secuity and mobile code, well we're looking at the same kind of solutions that mobile code technologies have today. There are basically two approaches being advocated. One is the sandbox technology that Java uses, to defend against downloaded code which you don't trust, because you don't know precisely where it's coming from. The code runs inside what Java refers to as the sandbox, which is a protected area. If the applets running inside that protected area run amuck and starts trying to do naughty things, well, basically it's just not allowed to. It doesn't have access to critical resources (such as files) that could be damaged. That's the approach used by Java, and I have a lot of faith in it. There are certainly problems, but it's basically stopping the problem at the crucial point, at the point where the applet tries to go out and trash your hard drive. It just doesn't have access to do it. That gives me a lot of confidence.

The other approach to protecting yourself against viruses is to have these pieces of mobile code that move about the net certified. In this approach, you as a software provider, writing a piece of code that would be downloaded to somebody's browser, have to get it certified by a trusted authority, the equivalent of a bank - somebody who the user trusts. They put the stamp on the applet that says "this code is legitimate, and it's not going to damage anything". When the code is downloaded into the browser, the browser automatically checks for that stamp of confidence. If it's present, then the browser's happy to run the applet. If the stamp is not present, then it starts ringing bells and flashing lights and saying "Don't run this - it hasn't got the stamp of authority". You don't know that the code's malign, but you have no evidence that it's not. However, the problem is that you're really relying on a train of trust, because actually although the auditors at the intermediary could have a quick look at the code, anybody with any ingenuity could write code that appeared to be benign, but then under the right circumstances covertly did damaging things, and get it certified as safe. So you're relying on the fact that if anything goes wrong and you're sitting there looking at the smoking ruins of your hard drive you can phone up the certifying authority and say "this applet did this to me" and they will then get onto the chap who wrote the code and basically drop on him the full force of the law. And I must say knowing that would be of great consolation to me if my last year's data just went up in smoke. So I have a lot less confidence in this approach. I think it has merits, but it shouldn't be the only thing that we rely on to protect ourselves against virus problems.

Paul: Building CORBA-standards compliant software is more difficult than building client-server systems using other techniques, such as Java RMI. Are there plans to simplify the effort?

Andrew: It would be interesting actually to do a comparison of using CORBA against using other client/server techniques; it is significantly easier than with many other techniques. The question refers to one particular example, Java RMI. The thing I would say about Java RMI is that it's a great solution if you're using Java everywhere. If both the client and the server - all client programs and all server programs - are written in Java, then there are significant design simplifications that the RMI designers can, and in fact did, make use of.

CORBA is designed to cope with heterogeneity - multiple programming languages, multiple operating environments. So some of those design shortcuts that the Java RMI designers took aren't available in CORBA. We have to cope with differences between programming languages. Let's pick an example: COBOL. There are still something like three million COBOL programmers on this planet and the majority of heavyweight business applications are still written in COBOL. Probably the next most popular languages are C and C++ with about 1.1 million programmers. If there are 100,000 Java coders, I'd be surprised. But CORBA can be used with all these languages. If the CORBA designers had tied themselves into one programming language, they would necessarily have been limiting the applicability of the technology.

Now, with that said, we do have efforts afoot at the moment to help with some specific languages. Java is one of them. If you're assuming a Java-only CORBA environment, then you can do some of the things with CORBA that the Java RMI designers did. So there is a thing that's currently being worked on inside OMG called, perhaps confusingly, the Java to IDL mapping. Anyway, we're in the process of requesting this technology from our members, for taking interface definitions written in Java and mapping them back onto CORBA IDL, to help provide something like Java RMI for Java-only environments. So we are doing our best to make life easier for people who believe there is no other programming language except Java.

Paul: The most obvious holdout for IIOP support is Microsoft. How do you see the alternatives between the CORBA standards (including IIOP) and DCOM being resolved? Will they coexist or must one win and the other lose?

Andrew: Well, OMG is an organization of several hundred members, including at least several hundred software vendors. Obviously all of those companies' major interest is in solving problems and shipping solutions to customers, rather than running a religious war. If there is a religious war going on, it's not coming from our side. OMG has been working for several years now on interworking with other technologies, of which the Microsoft technology is one, and RPC is another. There is a specification in the currently published CORBA document set for standard interworking between CORBA and COM, and we're also currently working on interworking between CORBA and DCOM, which of course has only been available since September of last year, in contrast to CORBA which has been available for six years. So, despite the fact that the Microsoft technology is five years behind CORBA, we're still doing our bit to facilitate interworking with it. It would be interesting to ask the same question of the Microsoft people.

Paul: Do you feel that it's more on the Microsoft side of the court now for an agreement on this issue?

Andrew: Looking at it from their point of view, if they are going to continue to advocate their technology, never mind what exactly it is, there are really only three possible outcomes: One, they get beaten, and their technology doesn't get used. I really don't think that's going to happen, and I'm sure they don't believe that either. Two, they manage to completely unseat all other technologies and become the only network inter-object solution that's used anywhere. Well, I don't believe that either, and I don't think they can possibly believe that. So, three, they must realize there is going to be more than one distributed object technology for a decade at least to come. In the face of that, what are they going to do?

We have recently heard statements from people at Microsoft acknowledging that there's going to have to be coexistence between their distributed object technology and CORBA, and so I'm hopeful that they are going to start helping people to do this, given that they must recognize their customers are going to want it. It would be nice for them to supply some support, but even if they don't then the CORBA vendors are already shipping technology that does and have been for a couple of years. So I think the practical answer is they've got to coexist, and I think everybody knows that, including Microsoft. It's only a question of to what extent they are actually prepared to help.

Paul: Is the OMG working in a coordinated fashion with the World Wide Web Consortium (W3C)?

Andrew: Reasonably coordinated. You have to bear in mind that both of these organizations are in fact fairly loose membership clubs. Anyone can join OMG. You just have to put up the money. The same is true of the WWW consortium . There's no entrance requirement. You don't have to swear allegiance to the goals of the organization or anything like that. You just join. And so to the extent that it's possible to speak of coordinated cooperation between two such broad churches, yes. To give some examples of how; we held a joint workshop on mobile code last year in Boston. I'm running a panel next week at the WWW conference in Santa Clara. I just came back last week from attending another W3C-organized meeting on distributed objects within the evolving web architecture. So, yes, there is certainly lots of dialog going on between us.

Paul: When could a company realistically plan to make use of IIOP? How would they? Are tools, infrastructure, and so on in place today?

Andrew: When we talk about IIOP, we're not talking about something that the developer who's using CORBA technology ever sees. There are no direct API's for IIOP. There are no IIOP development tools per se. IIOP is a standard for intercommunication between ORBs. Where there are ORBs produced by separate companies, there are two sets of standardization we need to achieve in order to make ORB technology truly portable. We need to have standardized interfaces between the client applications and the ORB so that the client application can ask the ORB to do the communication on its behalf. And you need to have standardized interfaces between the ORBs so that they can talk to one another, so that if I buy one made by HP and you buy one made by Digital, they can communicate over the wire. That second standard is IIOP. So as a programmer using an ORB, you never see it, but you do want the reassurance of knowing that it's there and that your ORB complies with it. If we recast the question in terms of CORBA, it should be asked as "Are there CORBA ORBs that use IIOP?". Yes there are, and have been for a couple of years. Interoperability between them has been demonstrated, for instance, at Object World in 1995 in San Francisco. "Are there tools for using those ORBs? Are they widely available?" Yes to both. The technology is mature.

Paul: What are the immediate and long-term future directions for IIOP and CORBA in general?

Andrew: The emphasis within OMG is shifting somewhat away from the platform. When people talk about OMG they have tended in the past to think only in terms of CORBA, because CORBA was the first and in some ways most the important thing that we have done; it provides the common interoperability bus. However, if you look at it from a different direction, CORBA is in some ways actually the least interesting thing that OMG is going to do. It's just the enabling technology. All it does is provide the ability for the distributed components to talk to each other. The interesting thing from the user's point of view is what they do with it, the applications they build on top of it. A couple of years back in order to help facilitate building applications in particular application domains, OMG reorganized itself and included what's called a domain-technology committee which has a number of umbrella groups for work in particular application-specific areas. Off the top of my head, some of the active ones at the moment are healthcare, finance, manufacturing, telecommunications, geographical information systems, and document management. In each of these areas, there are common technologies that everyone that's working in that area needs to have available, and we're working on specifications for these common objects.

For instance, for healthcare, consider patient information systems - a very hot topic in healthcare at the moment. How to manage the interoperability between separate patient information systems, but maintain data on the same patient so that as I move around the country the hospitals that treat me (if I have the misfortune to need it) can share information from an exam I might have here when I'm on the other side of the country. That kind of information is of critical importance to people in the healthcare business and not of particular interest at all to someone in, say, finance. So what OMG has done is to organise into these vertical domain-specific areas where people with shared interests can set specifications relevant to those vertical market segments. We're seeing activity at OMG rising in these areas, and it remaining at about the same level in the platform technologies such as CORBA and the object services. So that's quite definitely where the future lies. The platform is certainly mature and deployable and is being deployed very widely, so we're now shifting more effort into domain-specific areas.

Paul: What languages are supported today? And how many will be in, say, a year?

Andrew: I should preface the answer by saying there's a difference between supported and standardized. OMG does not, as you know, produce product. OMG just sets specifications. You could call them standards - I would not presume to do so, but I think many other people in the industry probably would term them that.

The languages whose mappings have been "standardized" are C, C++, Ada, Smalltalk, Cobol, and Java. As to which ones are coming down the pike…well, we know there are people who are working on an Eiffel mapping. Eiffel is a language that has a devoted following, although it's not a widely used programming language. It will interesting to see if they will submit their proposed mapping for adoption. So Eiffel is supported, in the sense that if you want a solution using Eiffel today, you can go out and buy it from ICL. OMG is a very open organization from that point of view. We print in all of our specifications a little paragraph inside the front cover in legalese which basically says "You can use this specification for whatever you like and nobody is going to come and sue you for IPR infringement". So the people who did the Eiffel mapping basically picked up the CORBA specification and said "Yes, we can do a mapping from Eiffel onto this" and did it. And the first we heard about it was essentially when it was already finished. People were already using it. And that is actually happening a number of places. I know of efforts to do things like mappings to the Dylan programming language, to Common LISP, to the PERL scripting language. These languages are supported by some implementations, but OMG doesn't necessarily know about them.

For the ones that have been "standardized", you can guarantee that you can go out, buy an implementation from CORBA Vendor A, write code for it and then at a later point port your code across to CORBA Vendor B with minimum trouble. For the mappings that haven't been standardized, you are risking getting yourself locked into a particular vendor's approach. But if you want the solution, it's there none the less.

Andrew Watson - In between flying gliders, Andrew Watson funds his aviation habit by working as the Object Management Group's Architecture Director. As chair of the OMG Architecture Board, he coordinates the group of ten distinguished OMG technical contributors responsible for maintaining the overall technical coherence of OMG's Object Management Architecture. Previously, Andrew chaired the OMG's CORBA 2 Task Force for five years while working with the ANSA team in Cambridge, UK. Andrew can be contacted by sending email to andrew@omg.org.

Home Page