Alberto Dell'Era

Originally posted by Alexander Yanuar Koentjara:
Hmm... I just stated the equality of interface (in java) and Bridge. And, I'm still thinking that the design pattern used in "java language's interface" is Bridge..

The Java Interface can be used in almost any pattern, e.g. as the return type of a factory method, as the Adapter supertype of the Adapter DP ... as I said previously, there's no relation between the Java Interface and the word "Interface" in DP terminology.
You may *use* a java interface as en *element* of DP realization in Java, but perhaps you can use an abstract class instead, or a non-abstract class.
There are a lot of different resources that explain what the concept of a DP is. My favourite is the "Design Patterns Explained" book I quoted above.

Yup, you're taking from different book.. I got the references in PDF file: Design Pattern (Java Companion) by James W. Cooper. He uses the term "interface" instead

I was quoting from the Gang Of Four book, which is the "father of all books about DPs", and from "Design Patterns Explained". ;-)
I own the book you mention, but it's one of the few books I dislike (I'm not the only one, see the reviews on Amazon).

Correct me if I am wrong, in JDBC the root interface is the Driver and the hierarcy you mentioned are Resultset, Connection, Statement, etc. Now I get a clearer picture. Thanks very much!
But then, if there is currently only one possible implementations for the root interface and the hierarchy, that become a Facade design pattern!!

:roll: Ehm ... no. The hierarchies in Bridge are both "is-a" hierarchies, and definitely a Statement is NOT a Connection (you may say that a Connection has-a statement instead). And, amazingly, confusing the Bridge and the Facade pattern is a so-common mistake that is reported in the Design Patterns Explained book! Of course that's because the Authors are both OOP instructors ...
Of course, I get a dollar for every DPE copy sold
[ June 06, 2002: Message edited by: Alberto Dell'Era ]

I *completely* agree with everything you have said, I could say I agree to 110%.
I have had the same experience as you, especially regarding the self-confidence that the knowledge obtained to get the certifications (and not the certifications by themselves) has given to me. I really feel to be a better professional than before.
I may just add that the certifications are also valuable because they set an immediate goal (to be certified) and so you complete your knowledge because you have a time frame and a set of topics to know. I.e., perhaps you know Design Patterns are important but you have never had the time to study them - than you decide to certify and you are (self-)forced to study, thus completing your knowledge to the advantage of your next project...

Originally posted by faiza athar:
by the way can u coach me? only if u have time? so i can write u wht i studied today and if and only if u have time u answer, asking me any question???

Of course - write me using the e-mail set in my account (I don't always follow javaranch forums).
I would anyway suggest to try to answer your question by yourself first thing, because that builds up in a better learning experience; I have myself used that strategy to excellent results. Sometimes, just letting the mind rest for a while it's enough to make the subconscious work out the problem ... I'm saying this because it seems to me (i may be wrong) that you are anxious about the whole thing of certification, which is good to a certain level (concentration matters) but may be counterproductive above
Also, by using the search engines (on javaranch, or groups.google.com) you can normally find out that your question has been already asked and answered previously, perhaps by real gurus (which I'm not), and so you can get it "in real time". I use google on a daily basis for my work and study, to the point that I normally don't even consult the products documentation. It's my "secret weapon" ...
And then, posting on javaranch (or google) is always a great thing to do - after having checked that your question is new or not already answered clearly enough, of course -.
Anyway, feel free to write to me (that counts for anyone else, of course). I will do my best to answer as much as I can, as I have always done in the past. Helping is the reason while I started this post.

Originally posted by faiza athar:
i guess its mor of dedication...thanx for the replies, and i have to set some target too...i read the 2nd chap of oreilly and it went over my head...ejb's are really hard???

At first they are hard, but the mess get clear after a while (like any difficult subject - ever studied Oracle ?) as new informations clarify the early one. Yes, dedication is the answer - you must be motivated and put in the effort required (like any difficult subject).
Anyway please note that what's really hard is the problem that EJBs solve - having a scalable, secure, extensible, maintainable and TRANSACTIONAL system.
Given a complex problem, the solution is normally complex as well - you're lucky if it's not *overly* complex. Driving a Ferrari is difficult because it's difficult to win the F1 championship, not the other way around.

whats the secret of learning fast?

No secret. As your experience increase you get better in learning, but there's not such thing as a Secret Fast Lane - "genius is 10% inspiration and 90% perspiration" (Albert Einstein, perhaps?)
[ June 05, 2002: Message edited by: Alberto Dell'Era ]
[ June 05, 2002: Message edited by: Alberto Dell'Era ]

Originally posted by Alexander Yanuar Koentjara:
From design pattern book, I found that Bridge's goal is to separate the interface of class with its implementations (which may do different business logic).
The question is: what is the different between Bridge and interface in java?

By "Interface" they don't mean the Java interface, since DPs are language-agnostic and they don't care if you use Java, C++, Eiffel ...
Being confused is totally appropriate, since this is one of the most difficult patterns to grasp (but also the most useful).
In the Bridge DP they don't use the term "Interface " but "Abstraction" instead:
"The Bridge Pattern separates the Abstraction from the Implementation ..."
The Abstraction of Bridge is actually a hierarchy of classes (not a single class) and the Implementation is another hierarchy of classes; the two are connected through a reference from the root class of Interface to the root class of Implementation. When you draw it on paper it resembles a bridge (hence the name, even if other interpretation is possible, of course).
(Please note that this is just one of a number of possible "prototypycal" arrangement of classes).
There's a wonderful dissertation about the Bridge DP on "Design Patterns Explained" by Alan Shalloway, a wonderful book, not only on DP but on OOA/OOP in general.
[ June 05, 2002: Message edited by: Alberto Dell'Era ]

Originally posted by Chris Mathews:
Hey Alberto, you beat me to the punchline.

Next time we should synchronize the starting time ...

Originally posted by andy armstrong:
Just to confirm there have been a lot of places
in the notes where people have said you must
implement these functions for your primary key.
This is not the case!! You in fact should but it is not a must. You must have a no-arg constructor..
As well you should not even use the equals method
to determine equality but the isIdentical method.
Any comments..

Quoting from the EJB Specification 2.0:
"10.6.13 Entity bean?s primary key class
The Bean Provider must specify a primary key class in the deployment descriptor.
The primary key type must be a legal Value Type in RMI-IIOP.
The class must provide suitable implementation of the hashCode() and equals(Object
other) methods to simplify the management of the primary keys by the Container."
So definitely you have to provide the implementation of the equals (Object) and hashCode() for your Primary Key class. Of course, if you use e.g. java.lang.String for your PK, that two methods are already implemented in a suitable way.
That is not surprisingly, since the default implementation of the equals(Object) method (inherithed from java.lang.Object) is to compare the "this" references of the two objects, so two PK objects with identical values would be always different (!) ...
Try this:
public class CustomerName { public String z; public static void main (String [] args) { CustomerName h1 = new CustomerName(); CustomerName h2 = new CustomerName(); h1.z = h2.z = "James Gosling"; System.out.println (h1.equals(h2)); // prints "false" (!!!) } } ~
So you won't find your PK in an array even if it's there, even if you use the straighforward method of looping on the array comparing each element to your PK with the equals method - a thing that any client, not to mention the container, would definitely think it's safe to do.
This is much better:
public class CustomerName { public String z; public boolean equals(java.lang.Object rhs) { if (rhs instanceof CustomerName == false) return false; return this.z == ((CustomerName) rhs).z; }; public static void main (String [] args) { CustomerName h1 = new CustomerName(); CustomerName h2 = new CustomerName(); h1.z = h2.z = "James Gosling"; System.out.println (h1.equals(h2)); // prints "true" } }
Similar considerations apply for hashCode(); if you don't implement it correctly, you will have surprising results (such as adding your PK to a Collection and not finding it in the Collection immediately afterwards - even if it's there ...).
A *GREAT* dissertation on the subject is contained in "Effective Java" by Joshua Bloch, the best book on robust Java Programming that I've ever read.

Originally posted by faiza athar:
how many hours did u put each day and did u do code practice too while reading?

Since I 'm employed,I have studied mostly on week-ends, and probably it took me about 3-4 weekends to complete each book. Probably 3*8= 24 hours on average.
I didn't actually code, coding is not required for an Architect and since I was able to understand just by reading the code samples, I avoided it. Of course I would have been better to code (you understand amd memorize things much better if you get your hands dirty), but after 6+ years of experience in OOP design/programming for n-tier systems, probably the added value would have been minimal (probably).
Definitely, the time spent experimenting with applet jar signing and thing alike was a good investment, since that were things fairly new to me.

Originally posted by faiza athar:
[QB]
The toughest part for me is the ejb understanding...any shortcut... oreilly book first or the ejb specs...any suggesstions and tips?
/QB]

The o'reilly book (Monson-Haefel) has a lot of nice Java examples and is more like a tutorial, while the EJB specification are much more condensed.
Why not reading them side-by-side, e.g. read the chapter about stateless session bean from O'Reilly's, and then the same chepter in the EJB specs ? It is probably the best approach IMHO.
By the way the Ed Roman book is roughly equivalent to the O'Reilly 's and downloadable from www.theserverside.com; I would try it. I've read both and I've liked both of them.

Hi folks,
I passed part I on Friday with an unexepected for (i'm a pessimist in nature ...) 100% mark.
Since I have got a lot from the javaranch community, here I am to share my experience with you, in the best tradition of this nice web place. I've just celebrated with a pint of beer and English is not my native language, so forgive any grammatical mistake and Italianism ;-)
First of all, I've noticed a lot of questions (perhaps 30% of the total) which were of the 'scenario' type, hence my first suggestion: don't study to just pass the certification, study to become an Architect, i.e. try to understand and not simply memorize things; scenario questions are easy (and fun) if you have deeply understood the matter, but they are a nightmare if you know things superficially.
Then, experiment as much as you can. This applies especially to applet/jar signing; I've noticed that that kind of stuff is remembered only if you 'put your hands on', otherwise it remains just a bunch of fuzzy concepts. In the Java Tutorial there's a section in which they guide you through an example of security; I recommend it:
http://java.sun.com/docs/books/tutorial/security1.2/toolsign/index.html
(A similar example is available in 'just java 2, by Van Der Linden').
There was at least one scenario-based question about applets.
Installing and running the j2ee sdk is another great move IMHO. It comes with a standalone db (cloudscape) which saves the hassle of installing a 'real' one, and the examples are really good.
Another suggestion: read the EJB Specifications (I read the 2.0 version) available on Sun's site.
Unlike other Specifications which are written in forensic language, the EJB specifications are clearly written, full of examples and rationales for almost everything, and explain things from the point of view of the Bean Provider, then from the point of view of the Client, then from the point of view of the Container ... a bit repetitive, but at the end the understanding is the best possible. Perhaps read them after the Monson Haefel's or the Ed Roman's book (I've read both two times) to get a more discorsive introduction, but definitely read them.
There are a bunch of pdf files available on the yahoo group scea_j2ee (the Author is a misterious
guy or girl named PJC) named 'SCEA in a nutshell' which are worth their weight in gold.
http://groups.yahoo.com/group/scea_j2ee/files/SCEA-Nutshell/
They are, as the name implies, a distilled and schematic view of our beloved certification topics,
but are invaluable as a refresher/introduction. They are written by an actual architect, and so
they add practical wisdom to everything.
Design Patterns. A lot of questions, my advice is to read the 'Design Patterns Explained by Shalloway' book which speaks about only some of them but which explains what Design Patterns are in the clearest possible way (the Authors are OOD instructors) and using Java language for examples.
Do you know that that book is considered the best book on DP along with the Gang of Four's ?
After having mastered the DP explained (pun intended) in the book, understanding the others is a breeze IMHO.
Then think about java technology examples: e.g. the Remote and Home object references are proxies,
the JDBC ResultSet is an Iterator, the Swing/AWT Listeners are Observers, the Home Interface is an Abstract Factory, the Session Beans are (may be considered) Facades, the AWT/Swing Containers are Composites, the java.io stream chained classes are Decorators, and so on. I can't tell you the exact questions of course, but as I expected, there were some questions that required that sort of knowledge.
Perhaps reading 'core j2ee patterns' may help, even if that's not a fundamental book for this certification (but interesting onetheless). Know what an ADO is anyway ...
About security, know all about applets/applications permissions, what they are not allowed to do (the PDF files are great about that) if signed or not, and before that, know by heart how public key cryptography works (what are the public and private key), what is a digest (aka hash) of a file, what is a signature (i.e. it is the hash of the message encrypted using the private key of the signer).
Online tests. The best IMHO is Ian's one:
http://www.ianswebpage.com/cert/
Which has a lot of thought-provoking questions that cover the majority of the exam topics. A 100% on this tests is a must for passing.
HTH

[ June 03, 2002: Message edited by: Alberto Dell'era ]
[ June 03, 2002: Message edited by: Alberto Dell'era ]

Originally posted by shai koren:

just wondering about the practicalllity and benefit of deffering the pk class untill deployment. how usefull is it?

Perhaps you are writing an application that manages people and one of your customer wants to have the Social Security Number as the PK, another the Employee Code, and another the combination of First Name, Family Name, Date of Birth ... you just write one application and then, at deployment time, at the customer's site, decide which column to use.
[ May 07, 2002: Message edited by: Alberto Dell'era ]

Originally posted by Ian B Anderson:
Hello,
Just to let anyone who's interested know I've added some UML questions.

Great Work!
Just a note: I think "composite aggregation" (i.e. the relation with a solid black diamond) is also called "composition". Perhaps it woul be a nice idea to annotate the question with the synonym.

As far as I have understood, a screen scraper is a (commercial) program that emulates a dumb terminal and connect to the legacy system pretending to be one of them. Then a Java program can connect to the SS and see an objectified view of the interface provided by the legacy system. It's an "object-to-terminal" adapter.
What's good for ? If you don't have access to the legacy code, this is the only way to integrate the two systems. Inelegant and weak (a single cosmetic change on the legacy interface breaks everything), but it works. And perhaps simple from the point of view of the legacy system engineer: it sees just another terminal, not e.g. a strange "java-to-cobol" mapping process that sits on his/her system and has to be maintained managed and so on ...

Originally posted by Greg Fox:
It is more likely that the technology will move forward and you will want to get certified in a version that includes the newer features. For example, businesses may want to use Message Beans which are covered with the current exam. I don't think they invalidate the certifications that you already have.

I agree. IMHO the SCEA certification is focused on Object Oriented Analysis and Design (UML, Design Patterns, etc.); personally I think that Part II is the most important (and difficult) part of it. I think that OOAD will remain the same for many, many years ;-), so there's no need to invalidate the previous certification just because of the introduction of (e.g.) Message Beans, local interfaces and relations in the latest specification: it takes two days to learn those new features, while it takes months to understant OOAD.
Of course the exam will stay aligned with the latest J2EE specifications, but, in my opinion, that will not invalidate the "certified" status of previous people. Of course it's just my opinion.

Originally posted by J Ash:
I agree with Robin, but I feel all a, c & d are mandatory in SSL handshaking. b can be avoided if server doesn't ask for a client authentication.
I found this on a google search - SSL Handshake - MSN
So whats correct the answer? Can some one help please?

Ian is correct IMHO. If you open the Netscape SSL doc (check http://www.javaranch.com/scealinks.jsp), you can see (chapter "Cipher Suites with RSA Key Exchange")that a possible algorithm selected in the handshake may be "No encryption, MD5 message authentication only". No key is generated in this case, since no encryption is necessary; perhaps MD5 needs a key exchange (i don't know about that), but that is not for encryption ... MD5 means "Message Digest 5th version", a sort of hash function computed on the message to avoid tampering or substitution (i.e. loss of Integrity); a sort of "signature".
The doc on Microsoft Network just summarizes the usual steps performed in the 99% of the cases, not in all cases.
Anyway this question is very interesting because it remainds us of a truth about SSL, that is, that the encryption algorithm selected in the SSL handshake may be absolutely not sure (the weakest ones can be decoded relatively easily).
When I knew about that, I jumped to Amazon to verify the encryption algorithm they use. Fortunately, this is a strong 128-bit code, so no cracker can order books from my account ...
[ April 15, 2002: Message edited by: Alberto Dell'era ]