 |
|
||
|
|
An Identity crises. Bob? Bob is that you? |
Each Corba ORB is responsible for uniquely identifying an object within the ORB's address space, the identification number is a series of bytes, how many bytes and what it contains is up to the vendor. For example a particular C++ vendor I dealt with used the TCP/IP address, name of their product, a copyright statement, and the memory address of the object. The SmalltalkBroker implementation took a simplistic, but incorrect route, and started incrementing object identifiers from one. This caused problems. For example if an image was restarted the state might not be the same as it was in the past, and you don't know who the users were. These remote users have an object reference to you. So at any later time they can talk to you using a now bogus object reference. Problem was that usually the first few objects you created always had the same object reference number due to the heuristics of startup, but of course your state was wrong. Better yet if the numbers did change, remember you are reusing number that might have been used for other types of objects in the past.
For example, say you always order the same chicken club sandwich from the local deli, in fact you phone them up everyday and talk to Bob. By now you have a known state with Bob and just phoning him up triggers the creation and delivery of the sandwich. But one day you phone and find Bob's gone, and Brenda there. Now it's the same phone number, but no-one knows who you are or what you expect. Thus you need to explain your needs again. But just to confuse you what if Bob Daily left and Bob Morgan took over, asking for Bob would really confusing for both parties!
This little problem was hard to understand at first since it displayed itself as bizarre behavior on part of two application, like message send failures because the target object now no longer understands the sent message, but once we realized what was happening we fixed it by seeding the object reference number with a timestamp plus fudge factor. In theory object identity numbers were no longer being reused between invocations.
Recovery Code.
This lead to another consideration about how recovery worked. Our recovery code dictated if you got a bad object reference then you should invoke handshake logic to restore a known state between you and the remote object. We had a choice.
1) You run stateless, much like NFS so from call to call you and the remote object have no state. Thus little if any recovery, just ask the other fellow or something else? for a valid object reference, and retry your call.
2) You had state, but if the other fellow restarted then he, or you needed to restore the state once you/he realized the state was forgotten. In this case you needed to make some other type of call and pass in state information and get a valid object reference, then retry your original call. If you restarted, then you could ask the other fellow what your state was, or be responsible for recovering it.
So back to my example with Bob, you could tell the new fellow at the Deli what you wanted, or perhaps they had access to a card file showing your past history. Or it didn't matter, but of course for this example it does.
Chicken and the Egg?
Ok just take that Object reference. Er.. where does it come from. Oh well you ask that application. Er how? Ok a problem how do you get the object reference for a service?
One way of course was to startup the service, and have it serialize the object reference of interest and place it in a storage area, say a data file. Other people could then read the data file, reconstruct the reference and talk to you. This works, but is clumsy. Ok, send it by email? Well maybe. To solve this problem two theories are presented. OMG has the first thought.
Naming Service.
The Corba naming service allows you to store a directory of descriptive information and keys which are the object references. When the service starts up you registers its newly created object reference of interest with the naming service. Users of the service go to the naming service and get the object reference they need based on an agreed upon key string.
Now if our Corba call got a bad object reference exception, or communication failure or other unknown and fatal condition we would go to the naming service, get the object reference of the service and do the agreed upon handshaking, then redo the original call.. On failure, we would repeat this forever, with a delay of course.
Problem is the naming service is dumb, and could be dead. Let alone be fooled with Trojan Horses and the like. Also trash it, or lose it and we all fall down. Alas I'm not going to think about security yet.
The Trader
One step more beyond is the Trader. Somehow a set of distributed applications works as the Trader so it's never dead, part of it could be dead, but not all. (Ha!) When you ask for a service the Trader then decides based on some criteria, who, what where, and when, then returns which service you should talk to out of a pool of one or many viable candidates. Think Load Balancing. Today we see some of that implemented on the web where a reference to a site might invisibly invoke Akami to service up pages from one of their 1200 servers based on load, and location heuristics. A true Trader service.