Raghubir Bose

The reliable one is whizlabs....

I used it and was benifitted by it and the 288 questions.Search the old posts and you will get links to it.

Hey Daniel,
Interestingly knowing a design patterns well does not establish one as an architect.Knowing EJB3.0 or hibernate well also does not establish somebody as an architect.He may at best be called someone uptodated.Architecting is more than knowing design patterns and EJB3.0.I feel that it is the way to think things properly.For example common architectures,DP, Legacy connectivity, Messaging,i18n,UML is something that will always be around with some variation.

We do certification to get ourselves recognised in the job market, getting some dollars/Rupees more per hour.Of all the standard architect level certification SCEA still has value, since it touches the basic tenets of architecting.Pls remember technology is a part of architecture not the whole of it.

The other ones to compare are of-course from IBM and Microsoft, which are also very good.But you cannot conclude that since only SCEA has EJB1.1 it is backdated . It would be a misconception of the basic principles of architecting.

I do agree new things needs to be brought in like ESBs and AOPs and stuffs like that, but this is also fine.

To take the exam or not is your own personal decision, but pls do not be biased with technology, see how much of architecting you can learn by doing a certification.

Depends on the depth you want to go !!! If you are working in the capacity of an architect you would possibly not asking this question ...

you might want to try with Mark Cade !! .. HFDP(Head First Design Patterns) and EJB by Ed Roman ...

1.Classes loaded from a jar file on a remote source can sometimes be trusted even if the jar file is unsigned - False

2.Classes loaded from a signed jar file are trusted if the public key associated with jar file's signature is marked as trusted in the keystore. - True.

This is again a whizlabs question it seems but this question can also be found else where.I could have ended here itself but somehow felt that some explanation to this is necessary.

Java security guidelines say that

"Currently, all JDK system code invokes SecurityManager methods to check the policy currently in effect and perform access control checks. There is typically a security manager (SecurityManager implementation) installed whenever an applet is running; the appletviewer and most browsers, including those from Netscape and Microsoft, install a security manager.

A security manager is not automatically installed when an application is
running. To apply the same security policy to an application found on the local file system as to downloaded applets, either the user running the application must invoke the Java virtual machine with the new

�-Djava.security.manager�

command-line argument (which sets the value of the java.security.manager
property), as in

java -Djava.security.manager SomeApp

or the application itself must call the setSecurityManager method in the
java.lang.System class to install a security manager."

Now If no security manager is specified, the built-in default security manager is utilized (unless the application installs a different security manager)

Upto this point I hope it is clear that always a secutrity manager is in place.

Now the Second part.This one says that we need a policy file to restrict access.

"JDK v. 1.2 security allows one to restrict read and write access to a subset of signers or locations. The runtime system organizes code into individual domains, each of which encloses a set of classes whose instances are granted the same set of permissions. Permissions are granted by an entry in a policy file. " - This policy file can be edited by policytool.

Now the third part.This is regarding digital signatures.

The basic idea in the use of digital signatures is as follows: -

1. You "sign" the document or code using one of your private keys, which you can generate by using keytool or security API methods. That is, you generate a digital signature for the document or code, using the jarsigner tool or API methods.

2. You send to the other person, the "receiver," the document or code and the signature.

3. You also supply the receiver with the public key corresponding to the private key used to generate the signature, if the receiver doesn't already have it.

4. The receiver uses the public key to verify the authenticity of the signature and the integrity of the document/code.

5. A receiver needs to ensure that the public key itself is authentic before reliably using it to check the signature's authenticity. Therefore it is more typical to supply a certificate containing the public key rather than just the public key itself.

Now the Last Part.This part discusses about keystore.

Private keys and their associated public key certificates are stored in password-protected databases called keystores. A keystore can contain two types of entries:
1.the trusted certificate entries
2.key/certificate entries

Each of this contains a private key and the corresponding public key certificate. Each entry in a keystore is identified by an alias.

A keystore owner can have multiple keys in the keystore, accessed via different aliases. An alias is typically named after a particular role in which the keystore owner uses the associated key. An alias may also identify the purpose of the key. For example, the alias signPersonalEmail might be used to identify a keystore entry whose private key is used for signing personal e-mail, and the alias signJarFiles might be used to identify an entry whose private key is used for signing JAR files.


I think Part 1 thru' 4 can be easily related to understand that why Question 2 is true.

There is a very interesting conversation in this link

http://www.codecomments.com/archive245-2005-8-577419.html

One might want to go thru' it for more understaning.


Regarding Question 1.- I leave it to you to decide , the rationale..

NJoy ....!

I dont know if this is a Whizlabs question or not but, two things needs to be considered over here.

1. Whether any workflow operations are involved or not.
2. The number of users using the application.

If there are workflow operations (like shopping cart) and the number of users are high go for SFSB , else go for servlet.

In this questions none of these factors are mentioned..so I think that servlet should be the answer.

So what I get from you is that

1 If we have a defined family of objects to build(meaning the object compostion is known at design time), go for Abstract Factoty Pattern

2.If we do not know the object composition meaning that the object compostion has to be dynamically determined , then go for a builder pattern.

Is that correct ?
If yes then

If no then

sure thing ...we can even pass an html control reference to the function, check the type of the control and make that control enabled/disabled.

I was thinking the intent of the Mediator Pattern is "encapsulate how a set of objects interact together by promoting loose coupling by keeping the objects from directly referring or even contact each other"

Html script consitsts of html controls.So whether the interaction between the HTML controls can be encapsulated by using javascript mediation was my question.

I was thinking whether I can pass HTML event to a javascript mediator, which I think I cannot.What I think I can do is put independent javascript processing functions on HTML events.These javascript functions can do the mediation.

I would rather put it this way.
Reliability is defined as "The probability of failure-free software operation for a specified period of time in a specified environment".

With vertical scaling, meaning with the addition of CPU, the performance increases , but the probability of failure does not change(neither increases or decreases).