Mark

Object technology (OT) has been the subject of keen interest in the software industry for the last five to ten years. What are the major obstacles that have been overcome and what are the biggest hurdles awaiting in the near future?

Daryl

It is interesting the way that objects have been portrayed in the past - the way they've been thought about - and I think that's one of the biggest obstacles that it's had to overcome: the way some people think about it and approach object-orientation. One of the ways that characterizes the way people think about it is that they think about object-orientation as some magical panacea. They're looking to OT to help them do several things:

One, they're looking to reduce the cost of their projects and to gain some sense of reuse of code in the organization that would solve their management problems. So, they've had some unrealistic expectations of the technology itself and too little expectation of their own participation in the use of the technology to ensure that the things that they value in the technology will actually occur. These unrealistic expectations led them down some roads that didn't pan out for the things that they'd like to see.

Secondly, there was a level of commitment that was a little scattered. The level of commitment was too much or too little. On the "too much" side, there was a belief that OT was going to do stuff that it couldn't do on its own; on the "too little" side, there was a move to make all projects use OT when it wasn't used for very long.

We also have the issue of technological immaturity of OO tools and languages in that they haven't always been ready to perform at levels that we expect - Smalltalk being a perfect example. Smalltalk has come of age for server-side applications building because the tools have matured to provide the kinds of performance that we like to see as well as the APIs and template necessary to do complex calculations and business applications. Besides the tools, there's the infrastructure - having the right kinds of people, knowing where objects are to reside as well as how they will be used and reused - is something that has to grow within an organization. As we go through that, we increase the skills and the understanding of what OT really is and what it can do for the organization. Through that understanding, we can finally get over some of the hurdles that we've seen in the past.

Some of the things that still remain are things like the object-relational mapping that needs to go on between complex relational data and a complex object model. This is still unclear to many organizations. That mapping is going to have to improve over time.

We also have the issue of components - helping to gain the kinds of abstractions as well as to simplify the process of developing and maintaining applications that are growing increasingly complex in a networked world. So, OO components in a distributed world is something that is going to have to be dealt with. That is certainly a hurdle yet to come.

Mark

That leads me into the interest we've seen in the Internet and Java. Do you see dealing with this complexity as the main way that OT and Java will help companies capitalize on the Internet, Intranets, and even Extranets?

Daryl

The interesting thing about Java is that its acceptance in the industry is not necessarily centered around the fact that it's object-oriented. There's so much market hype surrounding Java that a lot of organizations are looking to it as the answer to many of their problems without even realizing that it is object-oriented. However, when you look at the platform that is Java - and we think of Java as more than just a language; it is more of a specification for a source language which has object-oriented capabilities which is more well-specified as an OO language than is C++. Java is simple and concise in its syntax and semantics for specifying business logic, as opposed to C++. So, we'll see Java affect the object-oriented world in a major fashion because it is almost purely object-oriented and it moves a step beyond C++ in that respect. I think, though, it is difficult to suggest that Java is going to solve many more problems than we have been able to solve with C++ or Smalltalk. However, the unprecedented rise of this language and platform's popularity is helping to drive organizations toward object-orientation in ways that we haven't seen them driven in the past. Many people are trying to get COBOL developers to go directly into the Java world. Once they get their people understanding OO concepts, they are finding that Java is a very good language and platform for supporting those concepts and it enables them to get to OT a little more easily. The companies that are looking to doing this on the Internet, Extranets, and Intranets are going to find that Java is going to be a large part of their world and in dealing with the complexity of this networked world. Increasingly, in this network computing style world, we will find that Java is tied through its language to a decent object model and that that object model is tied very closely to a component model - the JavaBeans specification. This will indeed help with the complexity, considering the fact that many organizations are finding Java a bit easier to deal with than they found Smalltalk in the past.

Mark

Why do you think that is?

Daryl

I think one of the reasons why that is is a better level of understanding of OO in the world. Another reason is the hype surrounding the language - it is certainly something that has been pushed. Add to that the excitement of the web which has been generated over the last two or three years in groups that were not traditionally OO in nature - in other words, Smalltalk was being used in groups that we would consider "Type A" companies; we like to say that "Type A" companies are ones that jump off the cliff and hope they survive the fall. They are the ones on the leading edge. They have been using languages like Smalltalk, but now the excitement of the web and the hype surrounding Java has pushed most every business into the consideration of this new OO tool. Smalltalk wasn't associated with that kind of excitement - that kind of fast-growing entity. Smalltalk didn't have that to support it. In addition, Smalltalk came at a time when OO was not well-understood by organizations. It's not that much better understood today, but it is certainly something that is much more visible and viewed as an acceptable technology.

Mark

So, you see the web focus in the last couple of years as being the biggest driving force to pull Java and therefore indirectly OT?

Daryl

Yes, indirectly OT has been pulled forward by Java and Java is a part of the major excitement going along with the web and the Internet. This is not the only reason why OT is still around - it is a very useful technology.

Mark

Where do you see Java today, as well as in two and five years down the road?

Daryl

Today, the real value of Java is in providing some degree of mobile code to a browser client. That being applets delivered though web browsers. That's something that can be done without fully understanding all of the implications of Java - its platform and OT. There are many tools out there to help organizations get there. They're experimenting with Java today and understanding how to deliver applets. The "Type A" companies are moving beyond applet experimentation into server experimentation - understanding how Java will play on the server side of the network. We believe it will be as important on the server side as it is in clients. We also talk about "peer" code - Java code that will operate across clients and servers and be mobile within a distributed architecture. So, if we at "today" we see that the Java client is key and building Java applets is the primary goal.

Two years from now, we're seeing Java becoming much more dominant for peer code. Using peer code requires certain middleware options and the organizational infrastructure to support code in many locations as opposed to the traditional tiers of the application architecture.

Finally, server code will appear in the two to five year timeframe. Server Java will become much more significant, where the building of complex business logic through an object model is going to be much more important. Not so much for building infrastructure-type software, such as lower-level systems software or the more high-performance middleware that is necessary. But certainly for the building of application logic - the primary means of stitching together a large, complex system is going to be something we expect to see.

Mark

Where do you see Java moving from what you call a "Type A" company to a "Type B" company?

Daryl

We are already moving from an applet to a server application with Java. The companies that are "Type B"s today could benefit greatly from using Java as a front-end technology to any back-end system. One of the things we see a lot of, and we expect to see "Type B"s using more, is the traditional client-server enterprise-class tool vendors - vendors such as Forte, Dynasty, or Progress Software. Using their traditional enterprise-class back-end and front-ending them with Java applets. Companies like Unified and Oracle have delivered this kind of functionality. Seeing these front-ends available for Java, we can take advantage of them to produce "self-service" applications - more complex ones than could be built with HTML. Self-service applications allow the user to do the job without needing help. This is an area where "Type B" companies could gain a great deal of value today. They're less likely to be looking at "servlets" - enterprise JavaBeans architecture on the server side. They're going to be less likely to be looking at the protocols that bypass the web server, such as IIOP and DCOM in the Microsoft world. But certainly "Type A" companies are getting into using those things today and are beginning to understand what the pitfalls are.

Mark

So, when do you see "Type B"s starting to use JavaBeans and perhaps even considering something like IIOP?

Daryl

Well, "Type B" companies, in contrast to the "Type A"s, "Type B" will look over the cliff and ask the question "Will I survive the fall if I jump?" What they're doing right now is looking at those technologies - they're looking at IIOP and beans. Expect "Type B"s to adopt beans as rapidly as the tools to support beans are available in the industry. The component idea is embraced by type "A"s and type "B"s. As far as the connection-based protocols - IIOP, RMI, DCOM - they're just looking at them right now and they're saying "well, how can we get the usage of these types of protocols without having to deal with the complexity of them?" Because coding of object references through IIOP is not as trivial as using HTTP with HTML. They're using HTML in web technology. What's going to likely help them get over the hurdle is the incorporation of these technologies in every suite of tools that's available. IIOP has already become available in the Netscape Communicator. It is being touted as the future of all applications that currently use some type of proprietary socket communications. By the way, proprietary socket communications are right now the dominant means of getting client to server communications to happen over the web for complex messaging. When you look at the tools being built, it is expected that organizations will adopt those technologies as they become more a part of the tools.

There is one hurdle they have to overcome that many of these organizations are not even familiar with yet: security mechanisms that have to be compromised within the user's organization because of these protocols. IIOP calls have to go through a firewall over a port and opening another port or sharing a port that's already open is something that security administrators are not happy about doing.

Mark

This world that you're portraying in the next few years - what part do you see C++, Smalltalk and other OO languages playing in the future?

Daryl

Smalltalk has snuck in and is being used by some organizations to build server side applications that have been successful for them, even though it hasn't had that much hype. It's likely to continue within a small niche of the industry, but certainly not as widespread as C++ or Java.

The interesting thing about C++ is that it's not going anywhere. We expect Java and C++ to be good companions. Java has difficulty with performance with the lower-level functionality that C++ has typically had - C++ can be used as a supplement to Java and is being used by anyone who is serious about creating a Java-based environment. C++ native modules linked to Java over the next few years is going to be very important. So, C++ is not going anywhere and will be used as-needed for more high-performance systems, more solid and reliable systems than Java is able to provide in the near term.

Another language that is overlooked a great deal and is being looked at in large measure by the vendor community is COBOL. There is a very large desire in the business community to have COBOL developers still be able to use COBOL to develop newer-style systems. This means COBOL needs to be updated for today's component world. It certainly needs to get more OO capabilities than it has today. And it needs to be incorporated into the plans of the major vendors - the IBMs, the Microsofts, and the Fortes. The vendors need to incorporate COBOL into their plans and I see a very large market for any vendor that steps up to the plate and turns COBOL into a "Java for the legacy developer", who's been very effective with COBOL in the past.

Mark

Switching gears slightly, you've hinted at some of the key choices that make companies successful using OT. Do you see some of these choices and the things that are going to be key to success changing in this world of Inter/Intra/Extranets?

Daryl

If we look at some of the choices, we said that one of key choices was the way they looked at OO - the kind of strategy for using and reusing objects. That strategy often included repositories for persistent objects. That also included the use of middleware options that filtered requests to object request brokers. This is beginning to show that OO can be extended to the entire architecture, as opposed to being just a language-specific issue. These are some of the choices that are being made by organizations that are being successful with OT.

Also, the idea that an OO environment was going to be a complete, abstract environment that modeled a user's behavior in the user's world has sort of been broken up by the component technology that I mentioned. This makes it easier to understand for a lot of organizations.

All three of those areas will be used within Inter/Intra/Extranets and with using Java. It will differ in that a lot of it will have to be more distributed. That's the key word with regards to network computing - that processes are distributed, people are distributed. Architectures will have to accommodate distribution. This means that the usage of some of the same things we've had in the past in OT will be useful again in the future. Repositories will become more robust and distributed across different areas as well as servers. The usage of components is growing by leaps and bounds and it is going to simplify the concepts of thinking about an OO environment in an abstract way. We're going to continue to improve in our organizations the ability to administer objects by using tools that are a lot more object-focused in their implementation. A perfect example is Microsoft's transaction server. When you consider that product, it pulls together the execution of objects, the plug in and execution of components, with the transaction idea, which is more than to provide business function. This tool now brings together those three areas in one tool to be able to manage complex applications. Without this tool, those applications would have been extremely difficult. That tool has grown from a desire of organizations to be able to take advantage of those three areas: the components, the objects, and the transactions.

Mark

So, what I'm hearing you say is that the world has always been and will continue to be a client-server world. The web is certainly putting a different spin on that, but nevertheless the needs of the customers out there are largely the same. It's a matter of when and how can they most easily build these more and more complicated systems. Along those lines, you've mentioned things such as Java, Smalltalk, and COBOL. Can you relate the VisualAge family of products to this discussion - how do they meet up to this challenge?

Daryl

The VisualAge line of products is certainly one that is well-respected in the industry and in many cases is driving a lot of people's excitement about some of these languages. VisualAge for Smalltalk has certainly become a defacto tool to look at, considering the decline of Smalltalk vendors in the market and the rise of IBM to some degree of language dominance has moved it to the forefront of tools that are going to be considered when you're talking about Smalltalk.

IBM has expanded the reach of languages through this VisualAge concept - the idea that they can share parts, they have generators that can be used across all these languages, and they share a certain "vision" from the company. I think that "vision" for the VisualAge line is one of the best advantages that it has. When you consider the other components to that - you've got VisualAge for Java, VisualAge for Smalltalk, BASIC, C++, COBOL - all the bases are covered. The thing that really gets me is this idea that third generation languages like these are still extremely important. IBM, being a company that has support for large-scale, big iron, transaction processing, and very good middleware options for gateway processing really brings credibility to some of the tools that might not otherwise have credibility in this vein. For instance, looking at VisualAge for COBOL - it is a tool that is providing more support for today's COBOL than we would've seen from other versions of COBOL. I think that's being carried through across all the VisualAge tools. They are saying "we are going to put our force behind it and we're going to update these languages to today's architectures, projects, and people." So, we're going to use code generators and visual wiring techniques from visual palettes to build applications. We're going to use these visual builders alongside a nice componentized architecture with the correct number of APIs and libraries to support it. That means that you can now select your tool and you won't have to reselect your architecture or your framework for using the tool. That's a useful thing for people looking to use languages across the suite of products that IBM offers.

VisualAge for Java has really entered the marketplace with a lot of fanfare. It immediately jumped up into the top three or four Java development tools to be evaluated by companies, along with its competitors like Cafe and VisualJ++. VisualAge for Java has been seen as a tool that's going to allow us to build the application quickly, but has one thing the others don't have as much of: the support of IBM. This pushes it into a larger framework. The San Francisco project is offering more vertical market templates for complex processing, as well as the integration of this product with their transactional middleware and the support of their component broker and web component technology. This pushes beyond just simple applet building and beyond simple wiring and visual building into an area where we expect to see a lot more growth - that being complex Java-based applications. So, across the board they have done a pretty good job with the VisualAge line of being able to say "we can push these languages into the future and make them usable with one another to get a lot of benefit.

Mark

Do you see all three of those pieces you mentioned before being met here? For example, IBM's support for CICS, RMI, JavaBeans, Distributed Smalltalk, and so on across this product family. Do you see that, along with the language support built into the tools, as meeting all three of those key pieces?

Daryl

Yes. Certainly IBM's support for network computing is as large as anyone else. Support for Java is very large and their direction is very much in that way. They're looking to provide distributed computing mechanisms across the board. Their support for middleware, components for middleware as well as for client side development is very very good across these tools. I expect to see them be a very large player in this area for quite some time. The use of these tools, along with methodologies, repository, and administrative mechanisms to help manage the complexity is something they've been focused on for quite some time.

Mark

Could you briefly mention how each of the VisualAge products compete in the marketplace, summarizing their greatest strengths and weaknesses?

Daryl

If you consider those tools' competitors in the marketplace, they are positioned differently depending on which language you're talking about.

VisualAge for Smalltalk is going to be positioned exceptionally well against the competition, as the other vendors of Smalltalk are beginning to fall by the wayside. If you're going to pick a Smalltalk, VisualAge for Smalltalk is becoming the defacto choice in the industry today. Its greatest strength is IBM pushing the infrastructure surrounding it and its place in the "vision". Its greatest weakness is that Smalltalk is a niche language in the industry today and not likely to expand further beyond that unless something changes. When you consider that, you've got the "best of the breed", but a breed that's not necessarily going to be the most important breed.

If you consider VisualAge for COBOL and VisualAge for BASIC, those products are not going to have the visibility in the market that you're going to find Microfocus COBOL or Microsoft Visual BASIC. Visual BASIC is the number one client-server development tool in the world, even though it's not really a client-server development tool, but it's got visibility and acceptability that VisualAge for BASIC will never have. Likewise, VisualAge for COBOL is in competion with Microfocus COBOL as well as a lot of legacy COBOL environments. Although it's got good acceptance in the marketplace, it's going to suffer from being sort of in the middle - not being a legacy COBOL, but not being the best COBOL in the world.

VisualAge for C++ - Microsoft C++ is very dominant in the marketplace today. VisualAge for C++ is going to have to compete with that, as the market for C++ had come down to Microsoft and Borland. IBM has an opportunity for VisualAge for C++ to fill some of the vacuum being left by the Borland products as they decline in the marketplace.

As I mentioned before, VisualAge for Java is one of the top three for evaluation. Its strengths being: its wiring technology and the use of components with IBM's commitment to 100% pure Java beans. Its challenges to come up with the kind of performance that is going to be necessary for Java applications to increase the existence of complex bean components in the world for building large applications, which really don't exist today.

Mark

Thanks Daryl. I appreciate your comments. I'm sure they'll be of value to our readers. Thanks again for your time.

Home Page