Isn't Web services getting into some of the same areas that CORBA already explored?
I think most of (today's) interesting Web services implementations use CORBA. So here we go again--maybe we should look for a strategy that gives us some flexibility since the infrastructure keeps changing, instead of reinventing our architecture every 18 months.
So how will CORBA--and OMG's technologies in general--relate to Web services?
If you're going to implement a Web service, it's good to have some infrastructure to implement it, so you can get it done quickly. With DCOM (Microsoft's protocol for communications over the Internet) being pulled by Microsoft, you can use (Microsoft's) .Net or you can use C or all sorts of other technologies. But the only one that is still platform-, vendor- and language-neutral is CORBA. And that's why most of the Web services are built on top of CORBA. That's why you can take a CORBA implementation and easily turn it into a Web service.
Then why haven't we heard more about CORBA?
Well, there aren't that many Web services, period. But let's turn it around this way: If I wanted to build a Web service, how do I do that? The easiest way right now is to build a CORBA implementation and just push a button.
This is more than CORBA, though. That's only about 7 or 8 percent of what the OMG does today. A few years ago, we branched out in two major directions. One is that we adopted UML (Universal Modeling Language, a standard way to describe applications), and we have branched out into vertical markets, like health care and finance, telecom, manufacturing--there are about 15 areas at the moment. The architecture we are now building on, and have been for a year and a half, is something called the Model Driven Architecture, based on UML.
So, here we go again with a new infrastructure, with Web services, that people are pushing. And in 18 months, we'll probably have another new infrastructure. There will be another silver bullet in 18 months.
Where will that leave the people who buy and use these technologies?
Maybe the right thing to do is to model your architecture in a way that divorces it from any particular infrastructure. And make sure there are standards for generating most of the code from that architecture. Seriously, we could end up in the same mess that CASE (computer-aided software engineering, an overhyped method of software development popular in the early 1990s) made, with a thousand different modeling languages. The only thing we'll wind up doing is just moving the problem up one level.
That doesn't sound very encouraging. Is there reason for optimism?
We have this perfect point in time, when we understand that infrastructure continues to change, and there is one language that everyone is supporting--Hewlett-Packard, Sun Microsystems, Computer Associates, Microsoft, IBM--all of them support UML, and most of them support the development and maintenance of that language. MDA is not just UML. It's a bunch of core standards for other phases of development. The important thing is that UML is an open, neutral language, not controlled by one vendor.
How is MDA equivalent to Web services, and what are you thinking of when you use the term "Web services"?
OK, that's two different things. Web services to me is exposing software applications on the Web with a SOAP (Simple Object Access Protocol, the standard Web services communications protocol for use on networks) interface. That's it. And I realize there are dozens of other definitions, but that's nice and simple. That (Web services) gives you the ability to make use of that software from anywhere on the Web.
What MDA has to do with that is, if you are going to deliver a Web service, that means you are writing new software. And today, if you use the Web services infrastructure that has been defined so far, you are writing new software to a brand new infrastructure that isn't complete. Maybe you want to design that application in such a way that if that infrastructure changes, and when the new magic bullet technology comes along, you can still work with what you have.
So both ideas--MDA and Web services--will coexist?
CIOs understand this: You have to integrate what you have built, with what you are building, with what you will build. As much as we would like to believe that we know what we will build, we don't. That's the relationship of MDA to (Web services). And it's not just limited to Web services. People are using MDA to build flight-control systems at Lockheed Martin, for example.
Where will XML (Extensible Markup Language) play in that world?
XML is one tool for interoperability. It doesn't do anything for portability, unfortunately. But it is one way to get interoperability. It would be foolish to say it's the only way to do that.
Will Web services--in the way that IBM and Microsoft have defined it--reinvent some of the things that you have already tackled? And will that concept run into problems that CORBA has already solved?
Yes, and we are going to help solve those problems. Obviously, Web services address a lot of the same issues and have a lot of the same difficulties. One of the problems with CORBA adoption was connecting systems across firewalls. That's also becoming a problem in the Web services world. So we have addressed all of those issues.
More importantly, we have addressed a lot of issues the Web services world has not yet addressed, like transactional integrity (making sure transactions happen), security and authentication, persistent storage, and other areas. We can use the CORBA services in those areas and apply them to Web services. That's what MDA is about--capturing the model and generating the code for a given technology. We can take care of those areas, and you can just worry about writing the business logic. We will have to address these areas for Web services, hopefully through the standards that have been defined already.
One longstanding criticism of CORBA is that it is fairly complex and difficult to learn. And the conventional wisdom now is that XML and Web services are much easier to master. How will you convince developers to believe in CORBA and MDA?
The most obvious reply is to open the CORBA book, look at the code for doing anything, and then look at the Web services book and read the first few chapters on how to write using SOAP. There is no description for how to write (the equivalent) in the CORBA book, because why the hell would a developer care? I don't care what the packet looks like. That's CORBA's biggest breakthrough--as a developer, I didn't have to worry about protocols anymore. I have yet to find someone who has been a CORBA developer who says this was difficult to use or learn.
What value do you see in Web services, then?
Without question, the fact that everyone (in the software vendor community) lined up to support it. I think everyone has known that building and integrating distributed applications has been an issue for a very long time. I have to admit, I didn't even expect Sun to join the Web Services Interoperability Organization (a Web services standards body formed by Microsoft and IBM). I certainly would have liked to have seen that happen around CORBA 10 years ago. But it's happening, so that's fine.
What area will be most important in the coming six to 12 months--standards, skills development or tools?
I would say skills. Basic standards are there; others are coming. There are already more tools than we need, thank you very much. But developing the proper skills will be really tough, because of the recession. There are people who have been doing distributed application development, and there are people who haven't. Those who haven't have a big ramp-up. And those who have will need to sharpen their skills if they are going to develop with Web services.
Back to Vision Series
intro
