 Distributed Programming Boot Camp by Michael Ernest
Five words on distributed programming; done right, it ain't easy. And by "done right" I do not mean program code that compiles and runs; rather, that the programmer understands what their code does, and can apply their understanding to reading exception dumps correctly and fixing problems and, more importantly, knowing when there's nothing to fix. So let's first talk about what is not, in the fullest sense of the word, a distributed program. The term we often use for examples like the one below is network programming. You'll see why very soon. Applets are a good example of what we do not mean by distributed programming. Applets download from an HTTP server to a browser. The browser runs a local JVM to 'execute' the applet. On one hand, there are context-sensitive hooks an applet can use to point to the web server (getDocumentRoot()) and the enclosing browser (getParameter()). On the other hand, none of these hooks point to an active process, just files/directory locations or environment variables. In a "true" distributed program, two or more processes interact; they share data (and possibly code) in such a way as to "distribute" the work that needs to be done. In this sense, applications that follow the client-server model don't "truly" qualify, although the semantics are often the same. If you really want to get snooty about it, you would even say that web servers and browsers aren't "true" client-server roles, but rather a "request-response" model -- in short, "network" programming. Imagine instead a program running on your machine that takes on a large job that can be broken down into chunks; it's primary purpose is to determine how long it will take to process the job, based on how many compute servers are available at the time. It then submits the chunks to each server, one at a time, requests updates on the chunk (or just waits on the result), and provides regularly updated estimates of completion time to the user. That's distributed work -- several computers working together on a common task. Or imagine a program that tracks company purchase requests. Many such requests have to be checked against inventory, an approved vendor list, purchase amount, and finally management approval. An application that expedites such a request, known as a workflow application, must also reduce the overall metadata for purchases down to a view that each party (store manager, contract manager, purchase officer, division vice-president) cares about. It must also ensure the request doesn't fall through the cracks or sit in an indefinite holding pattern. That's also distributed work, in that the overall product (an approved request) relies on the individual work of several other processes. You may surmise that neither of these examples needs a distributed architecture. The job chunker could be written as a batch program, for example, and email often suffices for workflow for tasks with many responsible parties. Both of these are better understood and simpler than a distributed solution, but need people to serve as the knowledge base or "glue" between pieces. It's the need for better efficiency and consistency that drives people to for a distributed approach -- business people, anyway. You geeks probably just think it would be "cool." Seriously, though, for some companies only this kind of architecture allows them to manage complex work acceptable and stay competitive. What distributed programs benefit from is the asynchronous nature of complex, interrelated work. Many related but separate activities run at their own pace. To link them together, you need a rendezvous scheme that doesn't force one activity to halt progress while waiting for another activity to finish. The notion of de-coupling, a benefit of good object-oriented design, is critical to distributed systems. What distributed systems suffer from is the unreliability of networks. By this term, we do *not* mean that networks fail anytime, all the time. Of course they can fail, as can anything else. Unreliability in this context is relative, in this case relative to the likelihood that a CPU instruction will fail. The system I'm on now, a SPARC Ultra 1 running at 167 MHz, runs a potential 167 million cycles (instructions) per second, or about 600 billion possible instructions per day. How many of those fail, affecting program operation? Don't know -- it's been quite a while since I've had that happen. Compared to that, networks fail a lot, to such a greater degree that we can't write distributed programs with the same level of comfort that we write local, single-process programs. So how does this manifest itself in the form of working code? In the simplest terms, make a method in one program call a method in another program. "But wait a minute," you OS-savvy types will say, "isn't that kinda sorta what any process does when it talks to the kernel of our operating system? Isn't our program a process that is communicating with another process, the kernel?" Well, yeah, but kernels only emulate asynchronous contact with user programs. And, if they were unreliable, we wouldn't use them for any reason (in the Unix world, anyway. You may feel differently, depending on your current Service Pack). To work effectively together, two programs have to
a) be able to find each other and connect Of course, you don't have to go through Uncle Mike's boring old lecture on the Way All Things Are Done Right if you haven't got the time, patience, or respect for an old man in his last few years of good health. You can, if you like, dive right in with RMI tutorials, only they won't tell you why you want distributed programs to plague you for the rest of your life; they'll only show you how to invoke the plague. Talk back to the Newsletter editor; if you'd like to hear more about the foundations of distributed programs, I'll say more. If not, I'll go back to flirting with Map all day long. Your call, readers! If you're willing to listen but still want to do something, check out this "live tutorial" that we started building in the Distributed Forum some times ago. It's in need of more stuff, but I'm in need of more read input to write. Let's help each other out, ok? Here's the link: http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=4&t=000596 Thanks for reading!
Return to Top |
||||||||||||||||||||||||||||||
|
Segment 2: When relatives move in Or - Surviving your sub-classes Kids these days!! I tell you , they are spoiled rotten. Look around and you will see what I mean. You would think that those sub-classes would be happy that they have their very OWN classfile at last, where they can express themselves as they see fit. But NO. That is not enough for them. When they go out to build their Classfile Castle, not a one of them can get along without an umbilical cord back to their Dad. Well, OK - it is more like a tunnel back to Dad's Classfile Castle "just in case" they have to lean on Dad. And boy do they use that tunnel.
Check it out. When Junior goes to build his Classfile Castle, he makes sure that he builds in storage for all the Elite Static Variables that he wants, but then if someone asks Junior about one of Dad's Static Variables, Junior just runs down that tunnel and gets the value from Dad's Classfile Castle and presents it as though it were his own. Heck he will even update the value of Dad's static variable - mind you - the one that is sitting in Dad's Classfile Castle, just as though it were his own. So then when Dad goes to use his very own Static Variable, well . . . you KNOW there is going to be trouble. Of course, every so often Junior gets gutsy and builds a Static Variable in his Castle with the same name as one of Dad's Static Variables. Since he never confessed that he was getting the value from Dad, as far as all his friends know, Junior's Static Variable is the only one there. He just hides the fact that Dad has one with the same name. Heck - he often isn't so respectful as to even use the same TYPE for his Static Variable. Anyway - you have to be on to his tricks and know to use the magic words (that would be to say "super dot" ) before you request a Static Variable from Junior, to insure that you are getting at Dad's Static Variables for sure. Then again, you could do what the rest of the world does, and just request Dad's Static Variables directly from Dad by using his Classfile name in front of the variable, like "Dad.var" or whatever.
When Junior is being especially difficult he will intentionally pull rank with his Static Variables. So if Dad has blueprints for his subjects object houses on the heap that call for a variable closet with a particular name, Junior may just decide that he has to use that EXACT name for his Static Variable. Well, that means that every single one of Junior's objects that might have inherited a small closet from his Dad, well, it gets its meager closet hidden, just so some Royal Variable can use that name. It is bad enough when his Castle Variables go around hiding Dad's Castle Variables, but to hide the variables of the poor of his kingdom,
Same thing for his behavior. If Junior's Classfile just does not know how to do something, even after he has looked through ALL of his Royal Static decrees, he just runs down that super tunnel and finds the Royal Static decree that his Dad is keeping in Dad's method area, and follows those instructions.
Yes, he often hides Dad's Static behaviors that he should have learned with his own childish Royal Static behaviors. Royally rotten, that's what he can be. At least he can't use his Royal Static behavior methods to hide any of the behaviors that his objects might learn from his Dad (from his Dad's regular method decrees), like he can with variable closets. If he tries that the Justice Department would come down on him big time at compile time
Of course the reverse is true also. Junior's regular methods are way too feeble to override or hide one of Dad's Royal Static Methods. It can be good to have the Justice Department working for YOU.
Building bigger and better
So even though Dad has laid out some very good regular method decrees, and even though left alone, the masses would benefit from inheriting this knowledge of how to behave, and even though Junior can not hide those methods with his own Royal Static methods, he CAN invent his own regular method decrees and give them the same method names. AND since Junior is the last one to talk to the objects of his kingdom, yep - you got it, they always decide to override good common sense - with Junior's version of how they should behave in case that method is called. You know - Junior is shaping up to be a heck of a politician.
Moving in on Dad
You know about TYPEs don't you? You know how all variable closets are stamped with a type which directs them at the Classfile to get directions from?
That is great if all of the variables with Dad's Variable types are holding objects that are subjects of Dad. You know:
Well, when that variable is asked for the value of any other variable that is in it's object, FIRST the variable has to run to the Classfile for his type, and get the OK to give out that information. Since Dad's Classfile knows all the variables in his objects, Dad hands out the OK to get a "Dad::var" from the object and all is good. It even seems a bit of a waste to have to go get that OK from Dad. The same thing for Junior. Junior hands out OKs for "Junior::var" information.
As long as everyone sticks to variables that are stamped with their own type, there is no confusion.
But, if Junior's subjects have a hidden Dad:X and also have a Junior::X they will give out whichever one that they get the OK for. If a Junior type is asking, then that type will go to Junior's Classfile and get the OK for a Junior::X. But when Junior butts in like:
Too bad it doesn't work that way with behavior. But like I already said, behavior is not built into the object houses, it is decided on at the last minute. If a Junior object is sitting in a Junior type and a method is requested, the type runs to the Classfile and finds the behavior for the method in Junior's Method area. If it can't find it there, it sneaks down that tunnel and gets the behavior from Dad's method area.
If the Junior object is sitting in a Dad type and a method is requested, the type goes to Dad's Classfile to get the OK for the method. If Dad HAS that method, he will give out the OK, and THEN Junior will convince the subject to use HIS version instead. Unless of course you use the magic words "super dot" when calling the method.
Well, at least if one of Junior's subjects can not GET the OK for a method from Dad's Classfile, Junior can't use his own methods, even if he has them, until he gets his butt into his own darn variable type.
Did I mention that that tunnel is one way. Too bad Dad can't sneak down and swipe whatever behaviors he wants to learn from Junior.
Dare to discipline
Do NOT let them get at your private Stuff! Your privates are your own business and that is that!
You must be Firm and INSIST that they use the return type that you have used if they insist on overriding your methods. It really is not so bad if their behavior strays from the path, as long as they return correctly.
NO WAY that they should be able to throw extra exceptions in their methods after they have overridden Dad's, and expect Dad to pick up the tab! Just say NO.
If you just be sure to add these elements of discipline to your relationship with the kids, and try to understand them - well, you will just LOVE them - in spite of their wayward ways.
Next month - "Stereotyping and pidgeon -holing" - or "When is an Interface too tight" |
||||||||||||||||||||||||||||||
|
It's where you come to learn Java, and just like the cattle drivers of the old west, you're expected to pull your weight along the way. The Cattle
Drive forum is where the drivers get together to complain, uh rather,
discuss their assignments and encourage each other. Thanks to the enthusiastic
initiative of Johannes
de Jong, you can keep track of your progress on the drive with the Assignment Log. If you're tough enough to get through the nitpicking,
you'll see your name on the Graduation Log. And a shiny spur goes to... Back from being out on the range...
Saddle sore... Nitpicking is hard work too... Tips for the Trail…...
Written by Jason Adam and Pauline McNamara Return to Top |
||||||||||||||||||||||||||||||
Return to Top |
||||||||||||||||||||||||||||||
For more information on JavaRanch's Giveaways see Book Promotion Page.
|
||||||||||||||||||||||||||||||
|
JavaRanch to remain JavaRanch! Sun will be "...structuring a free licensing agreement with the site..." for "...managing the brand/trademark in a way that is positive and open - in the spirit of the technology itself...." I for one salute Sun's actions on this topic. This truly shows the dedication and spirit that I have come to expect from the Javatm community and from the Sun itself! Thank You Sun!!!! JavaRanch has added a new forum to better assist people in their hunt for information. As always JavaRanch is dedicated to providing you with the best source of information on Java Programming and Engineering.
by Carl Trusiak Return to Top |
||||||||||||||||||||||||||||||
