K-Soft Information Technologies Inc.

Overview :
K-Soft 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:

J2EE Design and development guidelines
N-tier architecture
Enterprise JavaBeans (EJB) 2.0
JavaServer Pages (JSP) 1.1 /Servlets 2.3
Java Database Connectivity (JDBC) 2.0
Java Naming and Directory Interface (JNDI) 1.2
Java Transaction Service and API (JTS, JTA) 1.0
Java Message Service (JMS) 1.0.2
JavaMail 1.1
Java Activation Framework (JAF) 1.0

Experience K-Soft
K-Soft has successfully developed Enterprise Solutions, E-Commerce Portals (B2B), using J2EE Specification. K-Soft’s experience as a company with J2EE development architecture has already crossed 12,000 man hours (@5 man years) working on different projects.

J2EE Expertise
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 are commonly used

Business-Tier Patterns

Session Façade

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.

Value Object

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.

Business Delegate

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.

Service Locator

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

Data Access Object

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

Front Controller

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.

Intercepting Filter

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.

Dispatcher View

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.

View Helper

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.