SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Jacada Ltd (JCDA)

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Sam Nizam who wrote (95)10/31/1999 4:26:00 AM
From: 2MAR$   of 401
 
Face to face with Nimrod Gil-Ad, Co-Founder and CTO of Jacada Ltd...

java.sun.com

Recently, we wrote about companies that provide Graphical User Interface (GUI) technologies in extending legacy systems. With ecommerce transforming our economy, many companies are being challenged to make their legacy systems Web-ready. Here, Jacada co-founder and CTO Nimrod Gil-Ad talks about the uses of JavaTM technology in making the transition.

How did Jacada first decide to use Java technology?

There's an interesting twist here. When Jacada first started developing, we formulated what we needed our technology to do -- and what we needed was, in effect, Java technology. But it was 1991, and Java technology didn't exist. Back then, no other technology was as widely available, as robust, and as flexible as Java technology is today. So, we had to write in-house software that resembled the Java platform. We didn't have Sun's development and marketing muscle, nor the full support from the industry. So, it never came out as a marketable technology.

When Java technology came out, we opened our eyes and said, "Whoa! This is a godsend! Now, we don't have to continue developing our platform anymore. Here's a ready-made platform that's available today on many operating systems. It's going to be more powerful, more robust, and speedier." Furthermore, it was also very closely tied to the Internet and to TCP/IP and networking, whereas our technology wasn't yet capable in these areas. So Java technology gave us a leap forward into the Internet era.

Jacada Ltd.
Since its inception in 1990, Jacada Ltd. has provided solutions that enable corporations and software providers to more effectively compete in the global market. Jacada's products allow businesses to leverage their extensive investments in existing applications to provide ecommerce technologies. Jacada delivers JavaTM technology-based graphical interfaces, re-engineered HTML web access, and integrated business systems with electronic storefronts.

So you started using Java technology from the very beginning?

Almost the very beginning. We were cautious and wanted to absorb what was going on, to make sure that we were not just hopping on the bandwagon. While we are technologically advanced, we're also a company attuned to our customer base, and our market. We don't do things just because they're the right thing to do technology-wise, or because they would be more productive, if our customers aren't ready. We're trying, first and foremost, to understand the business needs of our customers and find the best solution for them. We're careful, and we wanted to be sure there was substance behind the hype. We needed to see that Java technology had a future. Once we were certain, we moved.

Did you port your own code to the Java platform?

Yes, we've moved large parts of our code from our own internally developed platform to the Java platform. We still provide both, but Java technology is more advanced -- our future product features are, first and foremost, based on Java technology.

Related Stories

Jacada Customer Agencyworks
Talks About Java Technology: Case Study

The Great Migration to Java Technology


How has Java technology changed since you started using it?

It's certainly become more mature, robust, and faster -- absolutely. It has become more available on other platforms. We now have Java technology on the mainframe and on the AS/400. The porting out of the AS/400 was a breeze. And I'm talking about the first implementation of Java technology on the AS/400. The AS/400 is a unique box. To a programmer it doesn't look anything like a UNIX® box, or a PC, or anything else. It has its own idiosyncrasies.

What other platforms does it port to?

Java technology ports not only to the SolarisTM or Windows NT operating environments, but it's a natural port to all the UNIX-based machines, and the modern, UNIX-like operating systems, all the way from Linux to QNX, and even to a Macintosh or to a mainframe.

Tell us more about porting Java technology to the AS/400.

Porting Java technology to the AS/400 at first sight might seem a little bit surprising. There's UNIX on the mainframe, but not on the AS/400. OS/390, the leading OS on mainframes, includes a full UNIX implementation, running everything from NFS, through the Java platform, and all the way to Emacs.

But if you actually know the AS/400, you understand that it is already a virtual machine that is object-based. So it was also a natural environment to run Java technology on. Java technology on the AS/400 was not as natural as Java technology on Linux. Yet the actual code that we were developing on Windows NT executed flawlessly on the AS/400 at first shot. Naturally, we later had to fine-tune memory requirements, etc. There was no porting to do when we were moved to the AS/400. So, that was a very, very pleasant surprise for us.

How would you characterize Java technology today?

Right now, Java technology is available on practically every platform. It's also becoming available on lightweight desktops or palmtops, so to speak, on the Palm Pilot or the cellular phone, and mobile computers. I see a very interesting future for Java technology on these machines as clients for the systems that we provide. It's become more powerful with much richer APIs and a better GUI tool kit. Every aspect of naming and directory and cryptography and security is now available. We now have Enterprise JavaBeansTM (EJB) technology and the Java 2 Platform, Enterprise Edition.

The Java APIs cover the whole gamut -- from the desktop to the enterprise, and that is very comforting, because we know that we can expand our solutions based on Java technology, and get where we need to go. We don't have to go back and redesign features into the system. We can reuse the interfaces and link directly to all these features that Java technology provides.

How is Java technology integrating with systems like CORBA?

Java technology is integrated with non-Java technology-based systems like CORBA. The new CORBA specification, CORBA 3, is bringing CORBA into much closer ties with the EJB (Enterprise JavaBeansTM) specification. Customers invested in CORBA-based solutions will be able to more easily integrate with Java technology-based solutions.

Java technology is more than just a technology. It is the glue that links everything together, because it touches every aspect of computing, and it interfaces with every system that exists. You don't have to invest in many different technologies. You can just pick one, Java technology, and expand to wherever Java technology expands to.

Do you want to say anything about Enterprise JavaBeans component architecture? What's the level of interest? What are the big challenges for this technology?

The level of interest is quite high. The challenge right now is to have proper EJB containers -- EJB technology-based application servers -- widely available in order to bootstrap the whole marketplace, because right now, the technology's there on paper with the reference implementations. And there are even a few products. But it's not yet widely available. It's not as if you could write an Enterprise JavaBeans architecture-based component (enterprise bean), and expect that wherever you go, you can just plug it into an EJB technology-based server, an EJB container, and it will play along with everything, because it's just not there yet. So, I believe that's the biggest challenge. It goes hand-in-hand with the other challenge, to adapt the model of development into the EJB model.

But no one's going to adapt the development paradigm into the EJB model unless they know they have someone to deploy the enterprise beans. No one is going to deploy the EJB container unless they know they have enterprise beans, the actual beans to plug into these containers. So, it's a little bit of the chicken and egg problem. But it's getting there, and the fact that the specification is more mature and already has a reference implementation and even a few products helps a lot.

Jacada is an important player in the unshackling space. What are the biggest misconceptions that you encounter about the unshackling process from legacy enterprises using Java technology?

Probably the biggest misconceptions result from the hype that accompanied Java technology in its early days. People want Java technology. Everyone tells them it's the great product, the great technology, the great solution. So they say, "Okay, now I need to have Java technology in my solution, but I don't exactly know how." These tend to be customers who are not acquainted nor comfortable with the technology. We try to calm them down, and understand their business needs. Jacada is a company that deals with Java technology from the ground up. We have it in our development tools and on our servers and clients. And we can also interface with Java technology on mainframes. We do Java technology everywhere. In many cases, customers come to us to help them chart their way into the future, into Java technology and the Internet.

How would you describe your customers?

Our customer base is fairly specific. We're dealing with either software vendors or large companies who deal with IBM mainframes and IBM AS/400-based mid-range computers. Software vendors need Java technology in order to sell their software server. Our more direct customers need business solutions in which Java technology plays a large role. We try to identify their exact business needs so that we can understand where they need Java technology. If it's on the mainframe, for example, then how do they interface with the users?

And if they need Java technology on the desktop?

If they require it on the desktop, because they need to Web- enable their applications, then we need to take care of the user interfaces and the middleware of the infrastructure to communicate with the legacy applications on the mainframe. If they're a more advanced customer who's already talking about deploying an Enterprise JavaBeans-based application server, then we actually tie all the loose ends together, because an EJB- based application server in that scenario will have to have back- end links to the legacy applications based on the middleware we provide. We'll have to have front-end links to the desktop, and we also provide the user-interface technology based also on Java technology. The challenge is to identify how competent, technology-wise, the customer is, and whether they're actually looking for Java technology per se, or for Java technology as a viable solution to their business problem.

What do you see as big markets for Java technology in unshackling, or elsewhere, that have not been tapped?

On the mainframes and the AS/400s, the trend is toward Java technology-based computing on the server, on the actual back-end system. There's huge potential in that space. Mobile computing also has great potential. People may reach a point where they don't really care about which mobile platform they're on, because if it can run Java technology, it can run whatever they need.

Java technology is the glue and the ubiquitous enabling technology. First, it was on the server, and now it's on the back- end, the mainframe, the AS/400s, and the database servers.

Tell us more about the mobile computing space.

The area of mobile computers is big -- there are palmtops, Webtops, set-top boxes, etc. The next step forward is Java technology in your toaster, in your microwave, and in other appliances. But that is looking out into the future.

Where does the network computer fit in to the scheme of things?

In Java technology's early days, when the network computer (NC) was being promoted, people looked to it as a solution to lower operating costs. The NC was supposed to compete with the high-priced PC, but then look what happened. Today, for $500 you can get a PC that you couldn't get two years ago for ten times that price. But looking closer, you see that the basic price of the PC system was only a very small part of the equation. You have to figure in the cost of support, and the cost of installing every piece of software on every desktop, as opposed to the great savings and ease of use a central source NC offers.

Yet the NC backers have had a difficult time convincing the marketplace to invest in NCs instead of PCs. But once again, things have been stood on their head because now, instead of pushing from the desktop, we're pushing from the servers. The movement toward application service providers and everything surrounding Sun's recent acquisition of StarOfficeTM suite is exactly about this shift. It's about getting back to the NC model, not from the desktop, but from the back-end, from the servers, from the actual application hosting.

What will the acceptance of network-based computing bring?

Network-based computing will provide significant savings in terms of the total cost of operation. And most of that is enabled by Java technology, because Java technology is particularly suitable for this kind of enterprise computing based on back-end servers where you don't really care about the desktops, and the desktops are really just NCs. Officially they're PCs, but they're used as NCs. And the new intranets, which are based on low- cost PCs, use them as NCs in front of Java-based applications hosted on application hosts. The enterprise computing model is the one that will bring the most savings in terms of operation costs, so its future looks bright.
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext