# Being as Developer we have had implemented all this but, due to unavailability of words we are unable to expose all this stuff .
# When we are designing application architecture, we can have multiple layer in our application, such kind of application called N-Tier Application.
# Here I am going escape pattern of Web tier, JAVA Design pattern & Well known patterns like Intercepting Filter, Front Controller etc.
# The advantages of any design pattern are: solutions to the problems like decoupling, reusability, improved performance, increased maintainability, etc.
In such case J2EE can propose following Layers:-
1. Presentation Layer
2. Controller Layer
3. Business Layer
4. Integration Layer
5. Persistence layer
6. EIS (Enterprise Information Layer)
7. Client layer (Users)
Presentation Layer & Controller layer
Following design pattern comes under this Layer
1. Intercepting Filter
2. Front Controller
3. Context Object
4. Application Controller
5. View Helper
6. Composite View
7. Dispatcher View
Business Layer
Following design pattern comes under this Layer
1. Business Delegate
2. Service Locator
3. Session Façade
4. Transfer Object
5. Application service
6. Business Object
7. Transfer Object Assembler
8. Value List Handler
Integration Layer
Following design pattern comes under this Layer
1. DAO (Data Access Object)
2. Service Activator
3. Web Service Broker
We will discuss here most used pattern, like DAO, BD,SL
************** DAO *******************
Problem: - I want to encapsulate data encapsulation and data manipulation in separate layer.
Explanation: - In real world application POJO or Entity Bean are used as Persistent Object. This persistent object deals with RDBMS. Sometimes enterprise data may reside in other type of repository such as flat file, mainframe, LDAP or could be a Legacy Systems. Apart from this in B2B application enterprise data can reside on external systems eg: in Credit Card Information
I mean to say it could be anything based on your requirement.
For these repositories Access Management, Supported API & features will be changed from data store to data store.
When you try to access these repositories directly from your business component, you may get maintenance problem if the data store is migrated.
Because of doing this, Persistence logic will mingle with business logic which creates direct dependency between business component & Persistent Component.
Because of direct dependency Components must be modified with respect migrate in data store.
Solution:-
(i) Use DAO to abstract & encapsulate all access to the persistence store
(ii) DAO is implemented as Stateless i.e. it doesn’t catch any result of query, exception or any data that client might need at later point. This makes DAO light weight Object and avoids the potential threading and concurrency Issues.
******************* Service Activator (Message Facade) *******************
Problems :- I want to invoke business service asynchronously.
Explanation:- In Enterprise application, Most of the business process happens synchronously manner. It means client should wait until business process have to complete that has been invoked by.
Business process can take more considerable amount of time, as it might span to multiple applications inside and outside the enterprise.
So, For this long-lived business process, it is not good looking for application client to wait until the business process complete.
Hey what are you talking about? I don’t want to wait, let that task to be completed, I want to go forward, please provide me solution
Solution: - Use Service Activator to receive asynchronous request and invoke one or more business services. Say for this, you can use Message Driven Bean (MDB) to receive an asynchronous request. Also Service Activator will be located as JMS Listener.
******************* Web Service Broker :- *******************
Problems: - I want to provide access to one or more business services using XML and Web Protocol.
Explanations: - Session Façade or Message Façade can be used to expose your business functionality for an Enterprise Application.
When other application is trying to access exposed business functionality, this could be a problem. Surprised? Let me clarify, you are right, might be you haven’t face any problem, because of that both applicati3on has been implemented in same platform.
Now let me make you know, you will face problem when you (J2EE) are going access exposed functionality implemented in other domain like .NET.
Solution: - In such case use Web Service Broker to expose the business functionality as a Web Services.
******************* Business Delegate: *******************
Problems:- I want to hide remote client from complexity of remote communication with remote business service component.
Explanations:- When I am going to access remote business service component directly following problem can occurs
1. I f you are calling business component directly. This means when code changes on business side client code might need to change. This increase Amount of Maintenance and decreases System Flexibility.
2. I f you are calling business component directly. Single action in client can require many complex interactions with business services, because of doing multiple remote calls on network, Network Traffic will be increased and Performance will be decreased.
3. When client interacts so closely with business component, Clients code needs infrastructure code to interact with the business component, this infrastructure code deals with Naming Services such as JNDI, Retry Logic, Network Failure………
Solutions:-
Use Business Delegate (BD) to hide the infrastructure implementation details of business service, to increase the Performance and to decrease the maintenance.
BD hides details of business services, because of this client become transparent to Naming & Lookup Services.
BD also handles the Exception, i.e. BD translates System Level Exception to Application level Exception.
BD can also transparently perform any recovery & retry task operation required in crack of service failure with exposing to the client unless it is confirm that problem is not resolved.
BD can catch results to the remote business services, for this BD uses Service Locator catching can significantly improve performance because it reduces remote call over network.
BD is used with Session Façade, in this scenario there should be One-to-One mapping between BD & Session Facade.
******************* Service Locator *******************
Problems: - I want to locate business component transparently in a uniform manner.
Explanations: - When BD from Controller layer try to contact with Session façade in business layer, BD needs to lookup JNDI registry, similarly when JMS client tries to deliver the message to message Server, it must lookup the JNDI registry for JMS connection factory and JMS destination.
When you implement lookup mechanism in your client code, you may get several problems related to Complexity, Code Duplication, Performance Degradation and Vender Dependency
Solutions: - Use Service locator to hide implementation details of lookup mechanism and reduce the vendor dependency.
Service Locator is implemented typically as Singleton.
******************* Session Façade *******************
Problems: - I want to expose business component and Services to remote client.
Explanations: - POJO or Entity Bean is being used as server side component. Allowing remote client to directly access will be problems like
1. Tight coupling between client and business component leads to direct dependency. So when business code changes it effects client.
2. When client has the direct access to business component, client needs to complex logic to do JNDI lookups, to demarcate transaction, manage Security and to do business services. This increases complexity and responsibility to client.
3. Think when two different types of client direct access to business component. J
4. One more thing if client needs to direct access. They should access multiple components again & again, So Network traffic will be increased.
Solutions:- Use Session Façade to expose your business functionality, instead of allowing remote client to directly access of business component. It can be implemented as SLSB (Stateless Session Bean) & SFSB (Stateful Session Bean).
******************* Transfer Object (TO) *******************
Problem: - I want to transfer multiple data element over the network or layer.
Explanation: - J2EE application implements to expose business methods as Session Façade, so to fetch data from Session Façade if it returns, we can have multiple set/get methods. This can cause efficiency problems because every method will call to enterprise bean is remote.
Solutions:- TO is designed to optimize data transfer over the network. It must be serialized.
******************* Application Services *******************
Problems: - I want to centralize business logic across several business tier component.
Explanation: - In some scenario you will come across that you need to reuse some methods (reusable methods), If you are going to implement this in multiple Session Façade , than it won’t be reusable as well as it code duplication doesn’t contain any business logic. So place your code in separate component and can be called from multiple Session Facade.
Solution: - Use application service to centralize your business logic.
_________________________________________________________________
# Definatelly we will vists in the sight of JAVA & Web Tiers Pattern
