Java / J2EE Application Development |
|
Ebosys has invested in training resources and developing framework combining best design practices for J2EE Application Development based on Java , this enables a developer to jump-start into development right away, without worrying about the intricacies behind database connectivity, File I/O, error handling, session and application management.
The framework is created to help speed up development time and build web applications with fewer complexities. Using these frameworks, majority of the efforts is focused on the business logic or functionality implementation.
Most J2EE web-based enterprise applications are split into three logical tiers, Presentation Tier, Business Logic Tier, and Enterprise Information System Tier.
The presentation tier, which aims at presenting the business information to the user, is implemented using Servlets, JSPs and HTML/WML.
The business tier, where core business mechanisms are implemented, is usually encapsulated in EJBs (Enterprise Java Beans).
The enterprise information system tier, which represents different kinds of legacy systems, database servers, etc is usually accessed through the JDBC API and other standard interfaces provided by the J2EE Connector Architecture.
|
| JAVA / J2EE Key Features implemented
|
Experience Ebosys
Ebosys has successfully developed Enterprise Solutions, E-Commerce Portals (B2B), using J2EE Specification. Ebosys’s experience as a company with J2EE Development architecture has already crossed 12.5 years working on different projects.
|
| |
| Presentation
Layer |
Applet,Servlet,JSP,HTML |
| Validation(Client
Side) |
Java Script |
| Database |
Postgre, MySql,
Oracle |
| Middle Tier |
Pramati, Tomcat,
Oracle 9iAs |
|
| |
| Following is technical detail about Design Patterns that we commonly use |
| |
| The
communication between the presentation layer and
business layer in distributed business
applications often leads to tight coupling
between clients and the business tier. The
interaction could get so complex that
maintaining the system becomes difficult. The
solution to this problem is to provide a simper
interface that reduces the number of business
objects exposed to the client over the network
and encapsulates the complexity of this
interaction. |
In J2EE
Applications, the client needs to exchange data
with the business tier. For instance, the
business components, implemented by session
beans and entity beans, often need to return
data to the client by invoking multiple get
methods. Every method invocation is a remote
call and is associated with network overhead. So
the increase of these methods can significantly
degrade application performance.
The
solution to this problem is to use a Value
Object to encapsulate the business data
transferred between the client and the business
components. Instead of invoking multiple getters
and setters for every field, a single method
call is used to send and retrieve the needed
data. |
| By using the
Session Façade pattern, we did not rule out all
the design problems involving the interaction
between the client and the business layer. We do
have a centralized access to the business logic
but still the session bean itself is exposed to
the client. Enterprise beans are reusable
components and should be easily deployable in
different environments. Changes in the business
services API should not affect in principle the
implementation of the beans. To achieve loose
coupling between clients at the presentation
tier and the services implemented in the
enterprise beans, Business Delegate Pattern is
used. This hides the complexities of the
services and acts as a simpler uniform interface
to the business methods. |
| In J2EE
applications, clients need to locate and
interact with the business components consisting
of session and entity beans. The lookup and the
creation of a bean is a resource intensive
operation. In order to reduce the overhead
associated with establishing the communication
between clients and enterprise beans (clients
can be other enterprise beans), the Service
Locator Pattern is used. This pattern abstracts
the complexity of the lookups and act as a
uniform lookup to all the
clients. |
Enterprise Java Beans are reusable components and should be deployable in different environments with lesser effort. Implementing a so-called bean-managed persistence entity bean means that the programmer should provide all the persistent code (JDBC code). However, the API to different databases is not always identical so the bean programmer should consider different persistence code for different data sources.
Depending on the data source, one specific implementation is used. To make the enterprise components transparent to the actual persistent store, the Data Access Object pattern should be used. |
| View navigation is a key issue in web-based enterprise applications. Because views usually share common logic, a centralized access point for view navigation can be introduced in order to remove code duplication and improve view manageability. This pattern controls and coordinates the processing code across multiple requests. It centralizes the decision with respect how to retrieve and process the requests. A common strategy to implement this pattern is to use command pattern. |
Requests and responses need sometimes to be processed before being passed to handlers and other clients.
An example of request processing is form validation, user authentication, or data compression. The solution is to create pluggable filters to process common logic without requiring changes to core request processing which improves code reusability and decouples request handlers.Servlet specification version 2.3 comes with a standard Filter approach that can be used to apply this kind of processing. |
| The system
needs to control the flow of execution and the
navigation between views. In particular, the
system needs to know to which view to dispatch
next based on the request. It is vital to
separate the logic on deciding which view comes
next from the view components themselves. The
pattern does not perform heavy processing on the
request but can be seen as a simple forwarding
facility. |
| In J2EE
applications a view is used for content
presentation, which may require the processing
of dynamic business data. Business and system
logic should not be placed within views.
Encapsulating business logic in a helper instead
of a view makes the application more modular and
promotes code reuse. View Helper Pattern
enforces the use of only presentation format
inside the view and not the processing required
to get the presentation content. |
|
| |
|
| |
|
|
