where's the "sharpen your pencil" answer?

[Andres Gonzalez]

I'm refering to the one in page 80. I can't find the answer for it...

[Kathy Sierra]

Howdy! I am about 30 minutes away from posting PDFs of all the sharpen answers that aren't in the book (we leave them out of the book for the sake of instructors).
I'll give the link here when I'm done posting them...
But for now, let's think about the sharpen on page 80.
For everyone who has no idea what that is... I'll pose it as a question, here and let you play with it a while. It's actually an RMI question, not EJB... but it applies to EJB.
Imagine this scenario:
1) You have a client on one machine, and a Remote service on the other machine (the server).
2) The Remote service is called "DogTrainer" (the name of the interface).
3) An instance of type Dog is passed from the client to the Remote service
Given that scenario, and this list of classes, decide WHERE those classes must be at runtime and compile time. On the client? On the server? Both?
Here are the classes, and you decide if they go on client or server or both. And by the way, this is one of the most common mistakes made by new EJB (and RMI) developers, so if you're brand new to this, you might want to play around with it...
* Client class (OK, that's a freebie )
* Dog class
* DogTrainer stub class
* DogTrainer Remote interface
* DogTrainerImpl class
OK, there you go. Which belong on the server and which belong on the client? And how do they GET to the client? (there's no one right answer to that last question)
Cheers,
Kathy

[Andres Gonzalez]

here's my first guess..
client:
DogTrainerStub
Client class
Dog *
DogTrainer Interface *
Server:
DogTrainerImpl
Dog *
DogTrainer Interface *
I have doubts in Dog and DogTrainer Interface. I put Dog in both because the book mentioned somewhere that the class file must be available in the other side (server).
And the DogTrainer interface in both because the remote object and the stub (in client) implement the same interface.
am I completely lost?

[Kathy Sierra]

Originally posted by Andres Gonzalez:
here's my first guess..
I have doubts in Dog and DogTrainer Interface. I put Dog in both because the book mentioned somewhere that the class file must be available in the other side (server).
And the DogTrainer interface in both because the remote object and the stub (in client) implement the same interface.
am I completely lost?

No, you're not
You're thinking on the Dog and DogTrainer are correct, and you put the DogTrainerImpl on the server only, which is right. The *only* tricky one is the stub class... the DogTrainerStub class still needs to be on the server, at least for plain old RMI. With EJB, it might not be true, depending on the specifics of your Container. So, with the basic pre-generated stub distributed mechanism, the stub *class* is nearly always on the server as well (always for RMI, "it depends" with EJB).
The key point is that this stub class MUST be on the client side for sure, somehow, at runtime. Now, some servers generate stubs dynamically, in which case you don't have to worry about the stub class in advance, but we'll consider that a special case -- an implementation detail that some Containers use.
So, you get an A.
cheers,
Kathy

[Kanth Kris]

But there is already a 'skeleton' on the server side. Do you mean there would be a stub class on the server side besides the skeleton or are you calling this 'skeleton' as the 'stub on the server side'?

[Kathy Sierra]

Howdy -- we don't really know or care about the "skeleton" class, because even though we *know* that we need skeleton 'behavior', a skeleton *class* is optional with RMI. But as for the stub class, with RMI, the stub class has to be on the server, because the stub object is placed in the RMI registry (unless you aren't using RMI registry, as would be the case with something like Jini), and any time the Remote object passes a *reference* to itself, remember, it is actually passing the stub.
With EJB, if the Container makes RMI (including CORBA/IIOP) stubs, the stub classes are generated at deployment time and are on the server. At runtime, the stub object itself might be in a JNDI service on a *different* server, but in virtually all cases, the stub class is still going to be on the server where the beans are.
Think about what happens when someone calls a create() or find() on a Remote home
interface... that interface *always* returns a Remote reference, which means... a stub.
Now, we're not talking about the case where the stubs are generated as dynamic proxies, which some servers use. But if the stubs are NOT dynamic, then the stub class will be on both the server *and* the client. And in fact this will be true for not just EJB object references, but anything that is a Remote object that might be passed as part of a method call.
I suppose there could be a scenario in which the application is distributed on different nodes on the network, and the Home is one place, and has access to the stub for a Remote interface that lives on a different server, but even in that case, the stub class is still almost certain to be on the server, even if it's moved to other locations as well when the app itself becomes distributed.
So, the answer is -- although not 1000% true in every case, you can assume that if there IS a stub class, it will be on both the server and client, because it is the server that gives OUT the stub objects, and in order to do that, it must have the stub class. (Again, there could be strange scenarios where perhaps the stub is never unmarshalled until it reaches the clients, etc... but the stub had to be there at ONE time... and we won't go there )
The exam won't get into the issue of skeletons (since they're optional -- even though SOMETHING has to perform the skeleton *job* on the server (unmarshalling, etc.)), but you *are* expected to know that the client needs the stub class *somehow* -- but there are multiple ways in which that can happen, depending on the Container... from dynamic *code* downloading to dynamic proxy generation to plain old "you have to give the client the stub* (one of the biggest mistakes made by EJB newcomers is to not have the stubs in the client's classpath).
cheers,
kathy

[Bob Walker Jr]

I don't get it. Why is the stub skeleton issue so important?? They are transparent to the application programmer. In fact, the client only needs classes/interface that it uses (references in the code). Everything else is managed by the RMI infrastructure. When I package my EJBs for clients, I DO NOT put stubs in there. All I put is the home and remote interface classes (and other value object classes). That's it. Stubs classes are marshalled to the client by the RMI framework as needed. That's the job of PortableRemoteObject.narrow().
Is it not so??

[Ed Tse]

My guess to why stub are so important is because even though the programmer is only dealing with an interface, however, the remote object will still serialized and transfer over the network. Without the stub, client side has no way of knowing how the remote object should look like.

[Bob Walker Jr]

Originally posted by Edward Tse:
My guess to why stub are so important is because even though the programmer is only dealing with an interface, however, the remote object will still serialized and transfer over the network. Without the stub, client side has no way of knowing how the remote object should look like.

The client does not have to know how the remote object looks like. All it cares about is the interface. It doesn't need the stub for that. Saying that a client program needs a stub is, imho, same as saying that a client program needs socket classes.

[Bharat Ruparel]

Hello Kathy,
You wrote:

Howdy! I am about 30 minutes away from posting PDFs of all the sharpen answers that aren't in the book (we leave them out of the book for the sake of instructors).
I'll give the link here when I'm done posting them...

I am not sure where to find these links. Please let me know.
Thanks and Regards.
Bharat

[Kathy Sierra]

Originally posted by Bob Walker Jr:
I don't get it. Why is the stub skeleton issue so important?? They are transparent to the application programmer. In fact, the client only needs classes/interface that it uses (references in the code). Everything else is managed by the RMI infrastructure. When I package my EJBs for clients, I DO NOT put stubs in there. All I put is the home and remote interface classes (and other value object classes). That's it. Stubs classes are marshalled to the client by the RMI framework as needed. That's the job of PortableRemoteObject.narrow().
Is it not so??

Howdy -- no, this isn't always the case. The stub class is often *not* delivered to the client automatically. RMI will *only* deliver the class if dynamic class downloading is used, and that is often NOT supported by a particular EJB server PLUS it involves additional security policy settings on the client. The stub *object* is marshalled, but not the stub *class*. The stub *class* (again, assuming that there is one, and often there IS) has to be on the client, somehow, and in many cases, that stub class has to be hand-delivered. Otherwise, the stub object, won't be able to be deserialized, because Java can't load the class. So, dynamic class downloading is not a guarantee when RMI stubs are used, and even it is, it can still fail on the client because of the security manager, so in many cases (depending on your own configurations, of course), the client just has to have the stub *class* in his classpath before the client runs.
If you are not required to give your clients the stub classes, then your server is probably using dynamic proxy generation. But I agree that the skeletons are a non-issue. It's only the client-side that we're concerned about. So a lot of times, someone will write a client and simply not have the stub classes available, and nothing works. And again, it's not just the stubs to the component and home interfaces that we're talking about... we also have to make sure that the client has stub classes for any Remote objects that might be passed into or out of a Remote method call (again, unless dynamic code/class downloading is being used and working on both sides).
Personally, I think that RMI dynamic class downloading (which is not the same as dynamic proxy generation) is one of the most powerful (and cool) parts of Java (and makes it possible to have fabulous things like Jini), but it simply isn't guaranateed to be supported by the vendors, and although I haven't checked lately, in the past many of them did not. Which meant that if your Container does not use dynamix proxies, it was up to you to find out where the Container put the generated stub classes and then somehow deliver those stub classes to the client.
Forgive me if I'm just making this more confusing... it's just that I've seen so many people pull their hair out over ClassNotFoundException when running their clients...
cheers,
Kathy

[Kathy Sierra]

Originally posted by Bharat Ruparel:
Hello Kathy,
You wrote:

I am not sure where to find these links. Please let me know.
Thanks and Regards.
Bharat

Oops -- still working on getting them up there. I really will post the link later today!!
cheers,
Kathy

[Kathy Sierra]

Update... I'm having a few technical difficulties getting my PDFs posted. I'll try again tomorrow morning, so I'll post again then! (I'm going to sleep now, but I'll be here in the morning, and with luck -- I'll have the link to the sharpens.) Sorry for the delay!
Remember, you can also always post your exercise here, with what you *think* the answers could be, and let others have a look at it as well.
cheers,
Kathy

[Bharat Ruparel]

Hello Kathy,
I will keep reminding you until you post those PDFs.
Thanks.
Bharat

[Nehul NN]

me too.. but Thanksgiving week so I can wait little longer..
SCJP 1.4
SCWCD

[Joe McIntyre]

I too am anxiously awaiting the sharpen links! And I could be persuaded to give y'all a good review on the O'Reilly site...

[Kathy Sierra]

OK OK!! Phase 1 is done... (thanks Bharat; I have to admit your notes made me work on it more quickly )
And Wally... you know you DID say...
I put them on our anonymous ftp site. I will add some kind of a web page link for those who can't retrieve from ftp, but hopefully this will help most of you.
From your terminal:
ftp ftp.wickedlysmart.com
[name: anonymous]
[password: your email address]
binary
cd pub
ls
-rw-r--r-- 1 clover wickedlysmartgrp 823083 Nov 24 23:11 EJBSharpenA.pdf
-rw-r--r-- 1 clover wickedlysmartgrp 648312 Nov 24 23:12 EJBSharpenB.pdf
-rw-r--r-- 1 clover wickedlysmartgrp 643295 Nov 24 23:12 EJBSharpenC.pdf

get EJBSharpenA.pdf
getEJBSharpenB.pdf
getEJBSharpenC.pdf

==================
cheers and have fun!
Oh yeah, these are not necessarily the One True Right Answer (for some of them for which there isn't a right answer). And, NOBODY has reviewed these yet, so if you find questions, issues, or problems with what I've written, PLEASE say something here. (Somehow, I don't feel like I have to push too hard to get you to post problems here... )
-Kathy

[Joe McIntyre]

Thank you very much. And now for your review... oh, uh... first just one little bitty question - how come Bharat's a ranch hand, you're a sherriff, and I'm only a greenhorn?

[Andres Gonzalez]

Originally posted by Wally Flint:
Thank you very much. And now for your review... oh, uh... first just one little bitty question - how come Bharat's a ranch hand, you're a sherriff, and I'm only a greenhorn?

because of the number of posts you have.
https://coderanch.com/t/2139/Ranch-Office/Whats-process-Promotion

[Nehul NN]

Thank you Kathy.

[Rajkumar Saboo]

I am not able to access PDF's by using ftp. So can you please send PDF's to my email :: [e-mail] . Or somebody upload on some URL ..That will be better option for everybody. Thanks in advance !!

[Srinivasan Mani]

try typing the following url in ur browser
ftp://ftp.wickedlysmart.com/pub/

[Bharat Ruparel]

Hello Kathy,
Got it. Thanks.
Those who are having problems downloading. Try typing in:
ftp://ftp.wickedlysmart.com/pub/
as Srinivasan suggests above.
On a Windows machine, since Kathy has enabled the anomymous login for FTP process, you should be able to see the PDFs in the explorer view. Simply select, copy, and paste in your local drive's folder. Works.
Regards.
Bharat

[Keith Rosenfield]

I picked up a copy of Head First EJB the other day and I'm having a blast reading it. I downloaded the solutions to the Sharpen Your Pencil exercises and I have a question on one of the solutions. The exercise on the botton of page 19 indicates that AdviceHome is from the javax.ejb package. Is this really the case? Doesn't it come from the headfirst package. I'm aware that it inherits from EJBHome which is from the javax.ejb package but that's not what's being asked for.
I this an appropriate place to submit errata or should I submit it to the O'Reilly web site?

[Kathy Sierra]

Howdy Keith,
You're the proud winner of the "first person to find an error in a sharpen exercise". (You're absolutely right on that one.) I'm replacing the file right now, so you don't need to submit an errata for the electronic solutions, other than to tell *me* about them and I'll just change them.
If you have errata for the printed book, the quickest way to help is to write to me directly:
[e-mail]. If you aren't sure or you want to discuss it with people, then posting here is also good. I will take care of posting them to O'Reilly, so if you write to me, we'll handle it. If we're on vacation or something and you don't hear from us, then posting on O'Reilly would at least get something happening.
Thanks SO much Keith!
cheers,
Kathy

[Keith Rosenfield]

Kathy,
You're very welcome.
Keith

[Prasad Kuppa]

hi Kathy, you missed the answer for page 187.. sharpen your pencil.. yes, I know.. it is very very easy one.. still thought of making you aware..
Prasad