General Design Choice for SCEA or any new Enterprise App

[Erkin Kanlioglu]

Hi

I'm repeating this message under this topic as I don't want to hijack another topic....

Hi

As I think it is good to discuss everything, I would like to share my ideas.

There are couple of points (that I think) contradicts with reality as we are developing the application in the assignment from scratch and I think it is important to think about rapid development, initial simple requirements.

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

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.

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.


please let me know your thoughts ....

[Juan Pablo Crossley]

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).

IMHO.

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

[Juan Pablo Crossley]

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.

[Juan Pablo Crossley]

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,
etc...
}

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...

[Prabu S Arumugam]

1. Is Transfer Object even considered a unique design pattern with the POJO based EJB3?
2. Same with the Service locator pattern - EJB3 already has dependancy injection?

[Juan Pablo Crossley]

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.

[Prabu S Arumugam]

hey. Thanks.

I have a question on the Sequence diagram.
I have completed the class and the component diagrams.

For the sequence diagram, in the life line..and inside the boxes.. should it have the "class names" or the component names like "UI or EJB"
??

[Erkin Kanlioglu]

Juan Pablo Crossley wrote:

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).

IMHO.

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

In case of customer requirements, definitely I agree
1-) to have/write Proxy/Business Delegate EJB ,which implements same Remote Interface from original EJB,
2) to associate Business Delegate EJB with Service Locator
3) Changing original EJB to Proxy/Business Delegate EJB in deployment descriptor.

Thanks for comment on this.

[Erkin Kanlioglu]

Juan Pablo Crossley wrote:

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.

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

GenericDAO

Thanks again

[Erkin Kanlioglu]

Juan Pablo Crossley wrote:

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,
etc...
}

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...

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

[Juan Pablo Crossley]

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.

GenericDAO

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)

[Juan Pablo Crossley]

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