Search our
entire site
Enter your search
terms below, or visit
our search page

Distributed Computing over the Internet: A Primer

The 10 biggest problems with distributed computing for a large organization

Let's see if we can rank the 10 biggest problems an organization faces when starting to port its distributed apps to the internet.

1 - Lack of know-how and experience within the organization and in the market place

2 - Lack of clear objectives within the organization and a lack of the ability to establish them by the major consulting firms, and technology suppliers

3 - Lack of a clear perception of benefits within the organization, within technology suppliers and within the major consultancy firms. This is worsened by too much hype. The pricipal suppliers are overselling they possibilities and banking on their prestige and credibility to sucker customers, this leads to false expections and that is generally the ruin of any project

4 - Lack of commitment on the part of the management, with many projects being carried out for the personal prestige of the management, alias COOL FACTOR is the main motivator

5 - Lack of resources, this is a result of the previous associated with project teams and mainly managers who figure out that they might as well accept a stupid and impossible assignement without any chances of sucess because, either they can politically wriggle through it, or nobody else was going to do any better and they might as well use the reference for the next job - since prestige projects always provide good refs

6 - Security. this is actually only a problem because of a lack of understanding of the issues, and because most people who work with security in the computer field are security illiterate, but pass themselves off as gurus. Most security problems are not related to the lack of technology since most security breaches are childish, but because security is in the hands of amateurs, and nobody wants to pay an expert to go in and tell them the truth. Even when security is compromised, and detected most companies will just go out and buy another boxed product and install it without understanding what the issues really are, and they are mostly organizational. Most systems whose security has been compromised have not detected the intrusions...

7 - The limited resources of an exploding Internet. My sugestion is focus first on developing systems and applications for your own internal network.

8 - Some applications do not lend themselves well to the kind of model that exists on the internet

9 - Internet uptime is not the same as mainframe uptime/reliability... doesn't cost the same either.

10 - Managing and running a system over a network of millions of unknown users and computers, is a lot more complicated then running an application on your PC or on a nice comfy mainframe enviroment.

What is the right language for distributed computing?

Java is the language of choice for disributed computing simply because Java's characteristics are ideally suited for developing robust, modular software and provide a powerful object oriented cross platform paradigm and environment. Furthermore, Java is also a runtime environment that can be run almost on anything.

Java has automatic garbage collection. The need in C++ to manage memory explicitly is one of the major causes of hard to track bugs. Many C++ constructs, for example a structure, are not OO. In Java a structure is simply a class with only attributes - fields in Java parlance, and no methods. Java has a cleaner more readable syntax and structure. For example you can declare variables where you use them, while in C++ you must declare them in the head of your classes and methods. C++ libraries are just encapsulations of C libraries... look at the Windows API for a good example. While Java libraries are collections of classes. Java has stronger type checking.

All the above points are important to developers. But what really matters to users is that, Java is also a runtime environment. Like Prolog, it has a vitual machine, meaning that wherever that virtual nmachine has been ported to then you can run your Java applications... and there are Java Virtual Machines for pratically anything. That means that the exact same application will run without changes on any of those I believe around 40 different platforms - last time I counted. This is very important in a distributed system unless you think you can tell everybody that you want participating in it that they should the same platform. That is really unrealistic now days.

Another major adavantage of Java is that it is supported by all the major browsers. This allows you to develop applications as applets, and which are executed within the memory space of it's container, the browser. The implications of this is you can develop and application, install it on your web server, and it's automatically available to the world. No need to distribute it, no need to pre-install it, no problems with user who can't figure out installing and configuring it, total guarantee that everyone wherever they are is using the exact same version, data is located centrally, so it is guaranteed to be consistent at all times and always up to date - everybody has the same view at any moment in time, processing is distributed. Last but not least, because your browser already has all the Java class libraries, downloading an applet is only a matter a downloading the little bit of custom specific stuff need to implenent the business logic of the application. Furthermore Java incorporates a strong security concept... not encryption and authentication, but access control to system resources. This is very importnat because when you download and application over the network you have no way of knowing beforehand if it is malicious and will read all the data on your system and forwared it to someone else or even worse mash up your hard disk. Notice that however control of application previligies for accesing system recources does use encryption and authentication technology.

Furthermore there are simple tricks... such as iInstall performs that allow you to actually install an application, and then download whatever parts of the applcation are changed on the distribution server, only when they are changed. This trick means that you can go to the installer web page, with a few clicks allow it to install an application on your system, which you can then run as a self contained application that does not need a browser and that only needs to download something when and if it has been updated on the distribution server. This is better then the applet approach because applets always gets loaded everytime, and for security reasons it's much more limited what an applet can do, while applications are assumed to be trusted and free from the security constraints of applets, which are actually browser imposed.

Last but not least on this point, Java can be executed in hardware and is very compact, allowing it to be fitted in very small footprints as the virtual machine is not needed. Naturally it doesn't compare to assembler but then assembler is the least protable language there is and you have to re-write your software everytime the processor for which it was written is tweaked. Even if you use the virtual machine it's still very compact.

The only real downside of it is that a because its bianries are not machine binaries they have to be translated by the JVM and that slows it down. Once again as with Prolog which you know well, various techniques exist, among which run-time compilation as opposed to the more traditional execution time translation.

The whole point of distributed applications is to distribute processing in an optimal way. Ensure consistency by maintaining code and data centrally and provide power by distributing execution. Java fits very well this scenario.

Are there any suites that solve all the problems of distributed computing?

IONA is the only company in the world with a consistent, integrated and well though out architecture. All the other players have little pieces of the puzzle. Some, like IBM, have lots of pieces, but they are just loose pieces and do not fit or work together as well.

IONA provides a completely object oriented architecture, that is not only platform independent but is also language independent. You can write ORBS in COBOL, C/C++, Smalltalk, and Java. Extending that is mostly a matter of defining the appropriate language mapping. In other words... you can get the COBOL guys to write a piece of the application, the C guys to write another piece and and the SmallTalk gusy to maybe write another, and finally you could deliver it as an applet written in Java.

Since you control the server it would actually not be a stupid idea to write the server side of the application in C which is the most efficient and then write the client side as a Java applet.

CORBA provides all the mechanisms for making object location transparent. Therefore it is a distributed object architecture, and because of it's object based architecture you can just keep building on top of whatever you have. The OMG is now for example defining vertical services which sit on top of the connectivity framework to provide vertical functionality. You can then obtain the vertical services you need from those components, and the CORBA does it's magic and gets you what you want transparently wherever it happens to be. The particularly interesting aspect of CORBA is its ability to pass object references across the network and to invike object also across the network. In other words your application sees whatever is on the server as if it where local, as a matter of fact it sees all the servers as if they were local, your environment is the network. Where within that adress space the exact code that you want to execute is, is as trasparent as which function of your application you want execute in the memory space of your local system in the traditional world.

IONA is the leading implementor of the CORBA specifications, has a lot of experience is the market leader, and they are doing a very, very, very good job of it.

What is special about IONA is that they are light years ahead of everybody else, but I expect they will face competition from Visigenic if they survive Borland, and Object Space, both of which have good technology even though they lack all the neat stuff.

The only one that I think fails anywhere is Oracle's because it's oriented to it's database. All CORBA architectures mentioned are the best there is, several other comapnies like Sun and IBM I haven't mentioned because I don't think they will be able to compete effectively with the ones mentioned, hwoever with all of them if any flaws exist its an implementation issue, which they can resolve if they put themseves to it. Oracle actually supports CORBA but it's a half hearted thing tied also to its database.

Our opinion is that they will become the single most influential company in distributed computing in the 21st century...

Motorola's IRIDIUM project is all based on IONA technology.

A company called Object Space is also doing a decent job, as well as Visigenic (but they may get destroyed by the Borland takeover).

What will be the application building process in the next century?

There are no doubts it will be like building toys with Legos. We already see component models on the market that allow developers to build applications by mixing components. More and more architectures will enable ISVs and corporate IS departments to build applications from reusable software components. The Internet constitutes the ideal workbench for component-based development, since literally thousands of components are spread around the Internet servers of the world.

However, developers will have to be cautious which component model they choose, because these will literally be parallel universes, unable to communicate and forever trapped in their own spacetime. For example, Sun has announced its Enterprise Java Beans (EJB) specification, while Microsoft has refocused its Microsoft Transaction Server (MTS) for the Internet. They both aim at making it easier to create server-side components. MTS has been on the market for six years, but that also means that its design predates the Internet age. On the other hand, EJB has not even reached the specification stage, but it was designed with Java in mind, and therefore with all the (very important) issues of portability, scalability and distribution in mind. MTS users are likely to be trapped in the Microsoft world far more than EJB users will be in the SUN world. Also, life on the Internet is likely to be much harder for MTS users than for EJB users.

The importance of TCP/IP and HTTP

TCP/IP has beaten every other protocol dead, including NetBIOS - sponsored by IBM and Microsoft, XNS by Novell and X.25 by most standards bodies, and my opinion is that LU 6.2 is only surviving because as the native protocol of IBM SNA it has a very costly legacy base installed.

CORBA/IIOP is TCP/IP based.

You want tools that support TCP/IP via the Berkeley Socket interface (the other was TLI from AT&T, which is basically dead) and CORBA/IIOP. The reason for this duplication of effort is that CORBA/IIOP is hardly a lightweight thing.

HTTP is based on a TCP/IP protocol called UDP, alias UNIX Datagram Protocol. This is a broadcasting protocol which is used by e-mail systems, since it does not require a connection between the parties involved.

Therefore HTTP is a stateless protocol. It is good for when you need to ask another system for a document/file. The other side eventually gets the request and sends back the document. There is no connection between the two parts or guarantee of delivery in part or in whole of whatever is being sent back and forth. That also means that each request is completly disconnected from any others.

Basically HTTP is a one shot request for data which might or might not be serviced partly or completly. Pretty efficient for what it is designed to do. This is not a good protocol for applications. It is generally used by programs that request documents and then render them.

If the program requesting data, receives an incomplete or corrupt data set it has no way of knowing about it. The server doesn't know either, and therefore you can't use HTTP for any kind of business apps since they're all transactional and must maintain state information even across lost connections.

What tools are available to develop client/server applications over the Internet?

You have no reason to be happy about what is available today on the market.

Forte and Dynasty are probably the most popular tools for developing client/server applications. Forte supports Sun Solaris, Windows NT, HP9000, IBM RS/6000, Digital Alpha NT, Digital Alpha OSF and Digital Alpha VMS. Dynasty supports Windows NT, etc. What is the problem with these platforms? That they have to list them! Why? Because they have been developed in C or C++ and are tied to the architecture. These are not tools that will port smoothly to the Internet, and they were not meant to run on the Internet.

They all work by integrating a hodge-podge of technologies and products.

They deliver either static web pages or real applications that require distributing and installing by every single user.

What you want for the Internet is a tool that delivers real live applications whether standalone or as applets. You want to see only one technology, one delivery, one approach. You want a tool that builds applications which are easy and cheap to distribute and maintain, because they distribute and update themselves transparently.

There are a few dozen products which more or less claim to be the best and the first. Anyway their ability to exploit the Internet is based two fundamental approaches:
1. They can generate HTML and then they provide a back-end server or extension to somebody else's server that can receive an HTML form and run requested function against a local database of some kind and return the result formatted in HTML. This is the most common and is basically a way of dynamically generating documents instead of having them statically sitting on the hard disk. Cool but pretty limited.
2. They provide an application server and an API that allows you to write an application in, for example, C++ (for a specific platform, of course) and connect to the server and ask it to do something. The more advanced tools provide a development environment which will generate and take care of most of the code for talking to the server. This approach also means that you have to package you application, distribute it, install it and then look after all the users. All these vendors support TCP/IP... so of course you can run the apps over the Internet.

The really creative vendors allow you to develop your apps as Java applets, a method that gets around the distribution model problems of the previous point, and that is pretty good, but still leaves them with all the other problems. Among which: the servers being platform dependent, and the fact that those who don't require you to code your own services only support Database connectivity. The vendors who do the best job here are Borland and Symantec. However their servers are all NT.