|
|
| |
 |
|
|
 |
| |
| ISquare has invested in
training resources and developing framework
combining best design practices for developing
applications based on J2EE, 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.
|
| |
| Key features implemented |
| |
| J2EE specification implemented: |
| |
|
Co_,Ltd.files/bullet_org.jpg) |
J2EE Design and development guidelines. |
Co_,Ltd.files/bullet_org.jpg) |
N-tier architecture. |
Co_,Ltd.files/bullet_org.jpg) |
Enterprise JavaBeans (EJB) 2.0 |
Co_,Ltd.files/bullet_org.jpg) |
JavaServer Pages (JSP) 1.1 /Servlets
2.3 |
Co_,Ltd.files/bullet_org.jpg) |
Java Database Connectivity (JDBC)
2.0 |
Co_,Ltd.files/bullet_org.jpg) |
Java Naming and Directory Interface (JNDI) 1.2 |
Co_,Ltd.files/bullet_org.jpg) |
Java Transaction Service and API (JTS, JTA)
1.0 |
Co_,Ltd.files/bullet_org.jpg) |
Java Message Service (JMS) 1.0.2 |
Co_,Ltd.files/bullet_org.jpg) |
JavaMail 1.1 |
Co_,Ltd.files/bullet_org.jpg) |
Java Activation Framework (JAF) 1.0 |
| |
| ISquare has successfully developed
Enterprise Solutions, E-Commerce Portals (B2B),
using J2EE Specification. ISquare¡¯s experience
as a company with J2EE development architecture
has already crossed 12,000 man hours (@5 man 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. |
| |
| Integration-Tier
Patterns |
| |
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. |
| |
| Presentation-Tier
Patterns |
| |
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. |
|
|
|
|