Juan Pablo Crossley

Ranch Hand
+ Follow
since Oct 16, 2007
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Juan Pablo Crossley

woooot great job, I'm glad that my blog help you, thanks for reading it's highly appreciated.
Hi, I just want to share this post with the community, hope that somebody else had the same problem and saves them many hours of blog digging.


The main idea of this is to share how you could create a full dynamic JSF solution with dynamic properties. Hope you like it.
11 years ago

Prasanna Wamanacharya wrote:Hola Juan,

I totally agree with Antonio. Your web-pages are truly a guiding light for the SCEA preparation.

Would appreciate if you could add your thoughts and recommend some resources for the "Integration and Messaging" objectives.

Muchas Gracias!

Thanks Prasanna, I'll put that subject as soon as I can. I'll try to rewrite that blog in order to include this subject and all the comments received in order to improve it and serve as preparation guide for SCEA 5.

Antonio Fornie wrote:Thank you (Prasanna and Juan pablo) very much.

Juan Pablo, I had visited your page and it's really one of the best resources I found. It was a surprise to receive a message from you when I read and recognised your name. Tu página es realmente útil y la tengo en favoritos desde que me decidí a hacer el SCEA 5 ;) In fact you will see my comments and questions in your page soon.

Best regards from Madrid

I'm glad you liked it, just let me know if I can do anything to help you in your way to the SCEA. Soon I will take some time to create a new "guide" (it's not really a guide it's a summary of the test) to include all the comments from all the people, that discussions (on the comments section) are a good complement to the original post

Felicitaciones por tu decision de tomar el examen!

Erkin Kanlioglu wrote:
Basically, we are at the same point... BTW, Have you started using Scala on your project? Good to hear that somebody convince their manager to use Scala

Nope I didn't

Erkin Kanlioglu wrote:
If I didn't misinterpret your comment above, GenericDAO is same thing with AbstractFacade. There is even a nice example on google code.


Thanks again

Actually when I referred to "Abstract Facade" I was talking about a GenericDAO but as Abstract class, in order to implement the concretes and leave the door open to customize the facade if it's needed. Let me put in this way:

Suppose that you require a facade to "control" or persist 4 entities (Customer, Product, Payment, Purchase Order), you could create a single facade that serves all, using your GenericDAO, later somebody ask you to include a new logic in the Payment process, which includes the operation of the taxes every time a payment is generated, you cannot modify the GenericDAO simply because it's too generic, so you will need to create a new facade for your Payment Entity and change all its references to use the new facade (that will be a huge change if you consider it). So, what I proposed is a class like GenericDAO but marked as abstract and create 4 concrete classes extending the GenericDAO (without code) leaving the door open for some sort of customization, now, back in the payment problem, the only think that I will need to change will be the concrete facade of the payment entity and include the tax calculation, the clients of this facade will not need to change anything. (Actually is very very similar, the only difference is that I will put the GenericDAO as abstract to force the implementation of concrete classes in order to avoid the dependency from each client to this GenericDAO)

Prabu Senthyl Arumugam wrote:
2. Same with the Service locator pattern - EJB3 already has dependancy injection?

2. as far as not all the classes in your application will not be a SLSB you cannot use dependency injection in all cases, so it will be valid to use service locator... Websphere and OC4j still does not support full injection in all the classes :s, and jboss still have some problems with this too.

Prasanna Wamanacharya wrote:Are we expected to remember all the specific annotations, and details of what goes into a deployment descriptor for this exam? (e.g. which annotations can be used to secure web applications, what all can be configured in an EJB deployment descriptor)

nope, they're going to ask you about architecture things, not specific details like that.

Erkin Kanlioglu wrote:
3) TO (Transfer Object)
As far as I can see, most of us discarded using TO as entities are pojo and detached entity can be used in the view tier.
still not sure it is right approach to take as every change on entity might mean change on view as well... Keeping derivative fields on the entity or
putting some even very simple logic on the view to derive a field doesnt sound good.
Duke's Bank Example on JEE is still using TO pattern.
Note: I didnt like to see that Sun's reference implementation is using SFSB heavily even though it can ben solved with SLSB.

Ok, this one is "funny", when I started using EJB 3.0 as implementation I thought the same thing, POJOs=TO so... what the hell!, but the practice said something else, most of my entities (and I use a lot of them... as I mentioned before the application is HUGE and worldwide deployed, with a lot of customers on it) had relationships with other entities, because I don't want to load all the DB in a single call most of the relations are defined as lazy, when you pass the entity to the web level the deattached entity does not fill this relations if you never call them before, so the Deattached entity contain only the first level filled (and randomly some relations filled, I said "radomly" because in some cases the entity will need that relation and will be filled by the JPA) so the TO received will not suite well in most situations, on the other hand the logic behind the entity is larger than the one that the web should know, let me explain this in a simple sample:

Let's say that I have a Customer, Salary, and other relationships and I'm creating a list of customers with their salary, this means that the web should know how the customer and the salary are related to each other (and that could have different paths), so it's better to solve this in the Business layer instead of the web layer, and I will create a TO with something like:

CustomerSalaryTO {
name: String,
company: String,
income: double,

in this way the Web will not be attached to the logic of how the income is calculated, if I change the business layer in other to include new incomes, the web layer will be the same...

I hope this is what you were talking about, and I didn't misunderstood your point...

Erkin Kanlioglu wrote:Hi
2) I put question marks before Entity as I believe that it would be good to use some abstraction with generics --> Yes genericDAO )
Even though JPA is domain store implementation and easy to use, it is good to have a generic DAO for all basic operation and more specific DAO implementation for getting closer to domain.
For DDD friends, from my perspective

Repository implementations sounds/smells like DAO.
Functional approach is better than object oriented approach to follow to get some information from domain.

Note: I agree that DAO should NOT be accessed/injected as SLSB. Factory which takes EntityManager as a parameter is better solution if you are not using Spring.

Ok, here I go again.

I'm not really getting exactly what you meant with a GenericDAO, if you're saying an Class with generics as definition to control all the different entities in your application, I'm not sure if you could handle all the different situations with this approach,

I think the Facade pattern fits better in this problem, and will be able to do some modifications (complementary work) just before saving the entity into the persistence layer (JPA), if you don't change anything in your entities you could think some sort of abstraction using an AbstractFacade with the default methods create, edit, delete, findAll, etc in it. and you could implement some SLSB overriding the abstract (with no methods, because the main ones are defined in the abstract class) that will leave the door open if you need some sort of customization in the future. The abstract facade will have a reference to the EntityManager. That's it... simple, manageable, scalable, maintainability, etc.

Erkin Kanlioglu wrote:Hi

1-) Separation of web tier from application tier is inevitable but it doesn't have to reflect on deployment.

In reality, we deploy web tier and application tier on the same jvm instance and we try to use local executions/calls instead of remote executions. So annotations are there to use and for fast development.
(Clustering between jvm instances which serve web+application)

If we ignore from the beginning these realities, so what is the point investing on these new ideas?

Note: Yes, Ideal solution could be
a) to have different jvm instances for web and application tiers
b) to use remote call between them
c) ssing different physical nodes (even more ideal) and arranging DMZ.
d) then writing Business Delegate, Service Locator

My suggestion would be...
JSP Page --> FacesServlet --> Managed Beans(Facade) --> Stateless Session Beans --> ??? --> Entity

Hi Erkin, I like the points you are trying to discuss, and because I have thoughts on each point I will put them separately.

You're right most of the applications are deployed on a single jvm, but the experience showed me that you must take special care of the exceptions, I work to a company as an architect of a solution that is deployed in almost 100 clients around the world, and every single client has different "ideas" (to put it in a word...) in 5% of them they required us to separate the static part (html, gifs, css, etc) in a web application (apache), must of the clients does this and it's a good practice, and those clients demands that the jsps and servlets must be in a different web container (tomcat or other) arguing security and other things, and the rest (EJBs, etc) will be deployed in other server with clustering capabilities and so on. So, if I don't take care of what will be this 5% of the non-functional requirements I will be in a nightmare with those clients, because of that I must try to cover all the possible scenarios in the real life...

I must say that EJB 3 solved a lot of this things, just put the interface, and use the deployment descriptor, Service Locators, to solve the remote/local deployment problem. (business-local business-remote in the deployment descriptor it's a very good way to solve this without changing the code, but.... your design should be aware of this or you will have serious problems in the performance).


(I'm not an english speaker, so if something is not clear, please let me know and I could discuss it)

Volker Abel wrote:
How many classes does your class diagram consist of?

Hehe, nice and tricky question, cauz I'm not violating the agreement answering this, I only used 20 classes, including facades, entities, factories, and MVC classes.

P Das wrote:Passed the part I of the exam; there was some hitch with my name having been mis-spelt; cooling my heels over the assignment after having submitted the 'Quotation' for part 2. Sun does not respond.

Going through some of my own architectures that I had done for clients. Can some experienced people give advice on the following?
1) What exactly I need to do in respect of part 2? Only give a few UML diagrams (Class, Component, Package, Sequence)? It appears so from one post around 2003. However, things might have changed now.

2) What is the level of detail required in part 2?

3) How to expedite Sun's sending me links (or some other instrumentality) to register for part 2, pay required fees, and download assignment?

En passant: the questions were quite easy: not lengthy and only thing needed was to keep cool and time for revision.

Cache: The drag and drop questions suck: you cannot place the pieces quickly. I had wasted a lot of time on them and there I lost marks, presumably.

Great job P Das, the important thing about the second part it's to put the level required to explain the solution of the problem, if you put too much detail the solution will be hard to understand, don't forget to include patterns references and things like that, that will clean your designs and will let the examiner to understand what you are explaining,

Just ask yourself, am I going into too much detail? is this really helping the design or is distracting from the main solution? as somebody else said... practice the KISS method.

Antonio Fornie wrote:Hello everybody!

I've got a question I'm sure it must be answered before but I've looking for it and I don't find it. So I have to ask it: Is there any url to look for the contents of the SCEA part 1? I've been looking in Sun's page but it's such a sort description I don't know for sure wich contents I must study and how in depth. For example, I don't know if I must study applets, don't know what can I be asked about JSF (or wich version of JSF) and so on!

Thank you very much! bye


Hi Antonio, I did a summary of what you should prepare for this test, take a look for it at http://javaxcross.blogspot.com/2008/03/how-to-pass-scea-5.html hope this will solve all your questions about it, if not please let me know... also take a look of the comments, there're a lot with questions and answers about this test.
Hi, EJB 3.0 born a long time ago, and I realized that only some vendors implemented and certified their application servers as JEE 5 compliant. http://java.sun.com/javaee/overview/compatibility.jsp

What will be the future of JEE in the market if the big players are having problems to implement a good AppServers?

Glassfish --> Good for production environmet but nobody wants it.
WebSphere CE --> is not clear if the geronimo project will keep going.
Oracle 11g --> It's in its first beta preview
etc etc. etc.

I'm a little bit worried about this because seems that we have a very good specification but there's no servers to rely on.

(Sorry about my english )
12 years ago