Decision Support System

Definition:

For Little, a DSS is a "model-based set of procedures for processing data and judgments to assist a manager in his decision-making." Moore and Chang define DSS as extendible systems capable of supporting ad hoc data analysis and decision modeling, oriented toward future planning, and used at irregular, unplanned intervals. For Sprague and Carlson, DSS are "interactive computer-based systems that help decision makers utilize data and models to solve unstructured problems."

Decision support systems are a class of computer-based information systems including knowledge based systems that support decision making activities. Decision support systems are man – machine system for decision making purposes. Man part is more open & probabilistic while the machine part is more closed and deterministic. DSS must be closed system with feedback, external to the system. It uses the feedback to adjust output. Feedback is not internal like an elevator. The user provides judgmental inputs to the DSS.

According to the mode of assistance, DSS can be categorized into five different models:

• A model-driven DSS emphasizes access to and manipulation of a statistical, financial, optimization, or simulation model. Model-driven DSS use data and parameters provided by users to assist decision makers in analyzing a situation; they are not necessarily data intensive.
• A communication-driven DSS supports more than one person working on a shared task; examples include integrated tools like Microsoft's NetMeeting or Groove.
• A data-driven DSS or data-oriented DSS emphasizes access to and manipulation of a time series of internal company data and, sometimes, external data.
• A document-driven DSS manages, retrieves and manipulates unstructured information in a variety of electronic formats.
• A knowledge-driven DSS provides specialized problem solving expertise stored as facts, rules, procedures, or in similar structures; examples are Expert Systems.

Algorithms Developed For Implementing D.S.S.:

There are many algorithms such as Analytical Hierarchical Process (AHP), Analytical Network Process (ANP), The Simple Multi Attribute Rating Technique (SMART) and other AI and Expert system technique.
ANP is best used in the case when there is interdependence among the items and the alternatives. ANP does not require independence among elements, so it can be used as an effective tool in these cases. Thus, this dependency increases complexity in design and sometimes becomes overhead when there is no dependencies among the parameters. It is the more general form of AHP.AHP is the specific form of ANP used in multi-criteria decision analysis. Both the AHP and the ANP derive ratio scale priorities for elements and clusters of elements by making paired comparisons of elements on a common property or criterion.

Analytical Hierarchical Process:

The Analytic Hierarchy Process (AHP) is a structured technique for dealing with complex decisions. The AHP provides a comprehensive and rational framework for structuring a problem, for representing and quantifying its elements, for relating those elements to overall goals, and for evaluating alternative solutions.
In AHP, first the decision problem is decomposed into a hierarchy of more easily comprehended sub-problems, each of which can be analyzed easily.
Once the hierarchy is built, various elements are systematically evaluated comparing them to one another in pairs. In making the comparisons, judgments about the elements' relative meaning and importance can be provided. It is the essence of the AHP that human judgments, and not just the underlying information, can be used in performing the evaluations.
The AHP converts the judgments to numerical values that can be processed, evaluated and compared over the entire range of the problem. A numerical weight or priority is derived for each element of the hierarchy, allowing diverse and often incommensurable elements to be compared to one another in a rational and consistent way. This capability distinguishes the AHP from other decision making techniques.
Although AHP is used in wide range by lots of decision makers, we still can’t deny the fact that it has a flaw. Researchers have found that the flaws in AHP are significant and lead to various types of decision errors.
Some flaws of AHP are:

• The Use of Arbitrary Scales (1,3,5,7,9 or their reciprocal (1,1/3,1/5,1/7,1/9))
• Rank Reversal
• Inducement of Nonexistent Order

References:

http://en.wikipedia.org/wiki/Decision_support_system
http://en.wikipedia.org/wiki/Analytic_Hierarchy_Process
http://mat.gsia.cmu.edu/mstc/multiple/node4.html

Spring

What is Spring?
Spring is an open-source framework, created by Rod Johnson and described in his book Expert One-on-One: J2EE Design and Development.1 It was created to address the complexity of enterprise application development. Spring makes it possible to use plain-vanilla JavaBeans to achieve things that were previously only possible with EJBs. However, Spring’s usefulness isn’t limited to server-side development. Any Java application can benefit from Spring in terms of simplicity, testability, and loose coupling.
Put simply, Spring is a lightweight inversion of control and aspect-oriented container framework. Okay, that’s not so simple a description. But it does summarizewhat Spring does. To make more sense of Spring, let’s break this description down:

• Lightweight—Spring is lightweight in terms of both size and overhead. The entire Spring framework can be distributed in a single JAR file that weighs in at just over 1 MB. And the processing overhead required by Spring is negligible. What’s more, Spring is nonintrusive: objects in a Spring-enabled application typically have no dependencies on Springspecific classes.
• Inversion of control—Spring promotes loose coupling through a technique known as inversion of control (IoC). When IoC is applied, objects are passively given their dependencies instead of creating or looking for dependent objects for themselves. You can think of IoC as JNDI in reverse—instead of an object looking up dependencies from a container, the container gives the dependencies to the object at instantiation without waiting to be asked.
• Aspect-oriented—Spring comes with rich support for aspect-oriented programming that enables cohesive development by separating application business logic from system services (such as auditing and transaction management). Application objects do what they’re supposed to do—perform business logic—and nothing more. They are not responsible for (or even aware of) other system concerns, such as logging or transactional support.
  
• Container—Spring is a container in the sense that it contains and manages the life cycle and configuration of application objects. You can configure how your each of your beans should be created—either create one single instance of your bean or produce a new instance every time one is needed based on a configurable prototype—and how they should be associated with each other. Spring should not, however, be confused with traditionally heavyweight EJB containers, which are often large and cumbersome
  to work with.
  
• Framework—Spring makes it possible to configure and compose complex applications from simpler components. In Spring, application objects are composed declaratively, typically in an XML file. Spring also provides much infrastructure functionality (transaction management, persistence framework integration, etc.), leaving the development of application logic to you.
  

All of these attributes of Spring enable you to write code that is cleaner, more manageable, and easier to test. They also set the stage for a variety of subframeworks within the greater Spring framework.

Spring modules:
The Spring framework is made up of seven well-defined modules. When taken as a whole, these modules give you everything you need to develop enterprise-ready applications. But you do not have to base your application fully on the Spring framework. You are free to pick and choose the modules that suit your application and ignore the rest.
All of Spring’s modules are built on top of the core container. The container defines how beans are created, configured, and managed—more of the nuts-and-bolts of Spring. You will implicitly use these classes when you configure your application. But as a developer, you will most likely be interested in the other modules that leverage the services provided by the container. These
modules will provide the frameworks with which you will build your application’s services, such as AOP and persistence.

1. The core container
Spring’s core container provides the fundamental functionality of the Spring framework. In this module you’ll find Spring’s BeanFactory, the heart of any Spring-based application. A BeanFactory is an implementation of the factory pattern that applies IoC to separate your application’s configuration and dependency specifications from the actual application code.

2. Application context module
The core module’s BeanFactory makes Spring a container, but the context module is what makes it a framework. This module extends the concept of Bean- Factory, adding support for internationalization (I18N) messages, application lifecycle events, and validation.
In addition, this module supplies many enterprise services such as e-mail, JNDI access, EJB integration, remoting, and scheduling. Also included is support for integration with templating frameworks such as Velocity and FreeMarker.

3. Spring’s AOP module
Spring provides rich support for aspect-oriented programming in its AOP module. This module serves as the basis for developing your own aspects for your Spring-enabled application. To ensure interoperability between Spring and other AOP frameworks, much of Spring’s AOP support is based on the API defined by the AOP Alliance. The AOP Alliance is an open-source project whose goal is to promote adoption of AOP and interoperability among different AOP implementations by defining a common set of interfaces and components. You can find out more about the AOP Alliance by visiting their website at http://aopalliance.sourceforge.net.
The Spring AOP module also introduces metadata programming to Spring. Using Spring’s metadata support, you are able to add annotations to your source code that instruct Spring on where and how to apply aspects.

4. JDBC abstraction and the DAO module
Working with JDBC often results in a lot of boilerplate code that gets a connection, creates a statement, processes a result set, and then closes the connection. Spring’s JDBC and Data Access Objects (DAO) module abstracts away the boilerplate code so that you can keep your database code clean and simple, and prevents problems that result from a failure to close database resources. This module also builds a layer of meaningful exceptions on top of the error messages given by several database servers. No more trying to decipher cryptic and proprietary SQL
error messages!
In addition, this module uses Spring’s AOP module to provide transaction
management services for objects in a Spring application.

5. Object/relational mapping integration module
For those who prefer using an object/relational mapping (ORM) tool over straight JDBC, Spring provides the ORM module. Spring doesn’t attempt to implement its own ORM solution, but does provide hooks into several popular ORM frameworks, including Hibernate, JDO, and iBATIS SQL Maps. Spring’s transaction management supports each of these ORM frameworks as well as JDBC.

6. Spring’s web module
The web context module builds on the application context module, providing a context that is appropriate for web-based applications. In addition, this module contains support for several web-oriented tasks such as transparently handling multipart requests for file uploads and programmatic binding of request parameters to your business objects. It also cotains integration support with Jakarta Struts.

7. The Spring MVC framework
Spring comes with a full-featured Model/View/Controller (MVC) framework for building web applications. Although Spring can easily be integrated with other MVC frameworks, such as Struts, Spring’s MVC framework uses IoC to provide for a clean separation of controller logic from business objects. It also allows you to declaratively bind request parameters to your business objects, What’s more, Spring’s MVC framework can take advantage of any of Spring’s other services, such as I18N messaging and validation.


References:
Spring In Action - Craig Walls, Ryan Breidenbach - Manning

GlassFish

Overview:
In June 2005, Sun launched the GlassFish project -- an action that opened to the Java community the development of an application server that will be compliant with Java Platform, Enterprise Edition (Java EE) 5. Since then a large and growing community of developers has actively participated in the project.

Community:
The GlassFish community currently includes over 1100 members participating in the GlassFish project, with the objective of developing an open source application server that implements Java EE 5. In addition, the community is working to develop various web services technologies apart from the application server development effort. The community includes independent contributors as well as contributors from various organizations and companies. Members of the GlassFish community don't necessarily have to take an active role in developing code for the application server. By simply using the application server, they can file and track bugs and exchange information with other community members.

Projects:
The GlassFish project is a structured environment for developing the open source application server. The establishment of the GlassFish project is part of a larger effort by Sun to release major portions of its code into open source for use and improvement by the community. The GlassFish project is one of a variety of community-based projects hosted on java.net.

An open source application server:
GlassFish community is building an open source application server within the GlassFish project. The open source application server is based on the source code for Sun Java System Application Server Platform Edition 9, donated by Sun Microsystems, and on source code for TopLink, a Java object-to-relational persistence architecture, donated by Oracle. The GlassFish community makes periodic builds of the open source application server available for download.

About GlassFish Project:
GlassFish puts a free, open source, commercial-grade implementation of Java EE 5 in the hands of the community -- and puts it there early. Think about what benefits this might have for you. If you develop enterprise Java applications, being a GlassFish community member gives you an early opportunity to develop those applications and test them for conformance to Java EE 5. Note that conformance to Java EE 5 cannot be assured until the Java EE 5 specifications are final.
If you maintain enterprise Java applications, you can get an early start in migrating to Java EE 5. You can also get an early look at some of the new features in Java EE 5, such as the new Java Persistence API, the enhanced mapping capabilities in Java Architecture for XML Binding (JAXB) 2.0, the simplified interface for web services development in the Java API for XML Web Services (JAX-WS ) 2.0, as well as the ease-of-development improvements in Enterprise JavaBeans 3.0 technology. You can try out some of the new features in applications that you deploy to the GlassFish application server.
Another significant way in which community members contribute is by exchanging information. Whether it's through postings on the GlassFish discussion forum, broadcasts to mailing lists, or blog entries, members of the community maintain a continuing dialog about many aspects of the project, such as personal insights about GlassFish features, project-development issues, and answers to technical questions. Additionally, The Aquarium, a group blog, collects news related to the GlassFish community from a variety of sources. These communication channels provide a free-flowing information pipeline between members of the GlassFish community, including Sun and Oracle engineers.
GlassFish also gives community members the opportunity to improve the application server code. Developers have told Sun that they want the ability to contribute fixes and new features to Sun's code. The GlassFish project gives community members the context to do just that. As a member, you can identify bugs in the GlassFish code, contribute fixes, and even add new features.



References:
http://java.sun.com/developer/technicalArticles/glassfish/GFBasics.html

Two Development Models

Overview:

When Sun introduced JSP technology, it provided a development road map for working with it and defined two models for building JSP-based Web applications. The two models are known as Model 1 and Model 2 and they prescribe different approaches to designing JSP-based Web applications. Model 1, the simpler of the two, was the primary solution implemented when JSPs were first introduced. However, over time, Model 2 has been accepted as the best way for building JSP-based Web applications and, as you'll see, is the inspiration for MVC-based Web frameworks like Struts. Following is an overview of both architectures.

Model 1 Architecture Overview :

The Model 1 architecture is very simple. A request is made to a JSP or servlet and then that JSP or servlet handles all responsibilities for the request, including processing the request, validating data, handling the business logic, and generating a response. Although conceptually simple, this architecture is not conducive to large-scale application development because, inevitably, a great deal of functionality is duplicated in each JSP. Also, the Model 1 architecture unnecessarily ties together the business logic and presentation logic of the application. Combining business logic with presentation logic makes it hard to introduce a new "view" or access point in an application. For example, in addition to an HTML interface, you might want to include a Wireless Markup Language (WML) interface for wireless access. In this case, using Model 1 will unnecessarily require the duplication of the business logic with each instance of the presentation code.

Model 2 Architecture Overview:
Model 2, or as it is most commonly referred to today, Model-View-Controller (MVC), solves many of the inherent problems with the original Model 1 design by providing a clear separation of application responsibilities. In the MVC architecture, a central servlet, known as the Controller, receives all requests for the application. The Controller then processes the request and works with the Model to prepare any data needed by the View (which is usually a JSP) and forwards the data to a JSP. The JSP then uses the data prepared by the Controller to generate a response to the browser. In this architecture, the business and presentation logic are separated from each other. Having the separation of business and presentation code accommodates multiple interfaces to the application, be they Web, wireless, or GUI (Swing). Additionally, this separation provides excellent reuse of code.

Model View Controller (MVC) Architecture

Overview:

Model-View-Controller architecture is all about dividing application components into three different categories Model, View and the Controller. Components of the MVC architecture have unique responsibility and each component is independent of the other component. Changes in one component will have no or less impact on other component.

Model Components:
In the MVC architecture, model components provide an interface to the data and/or services used by an application. This way, controller components don't unnecessarily embed code for manipulating an application's data. Instead, they communicate with the model components that perform the data access and manipulation. Thus, the model component provides the business logic. Model components come in many different forms and can be as simple as a basic Java bean or as intricate as Enterprise JavaBeans (EJBs) or Web services.

View Components:
View components are used in the MVC architecture to generate the response to the browser. Thus, a view component provides what the user sees. Oftentimes the view components are simple JSPs or HTML pages. However, you can just as easily use WML, a templating engine such as Velocity or FreeMarker, XML with XSLT, or another view technology altogether for this part of the architecture. This is one of the main design advantages of MVC. You can use any view technology that you'd like without impacting the Model (or business) layer of your application.

Controller Components:
At the core of the MVC architecture are the controller components. The Controller is typically a servlet that receives requests for the application and manages the flow of data between the Model layer and the View layer. Thus, it controls the way that the Model and View layers interact. The Controller often uses helper classes for delegating control over specific requests or processes.

Struts

Overview:

Although the Model-View-Controller architecture is a powerful means of organizing code, developing such code can be a painstaking process. This is where Struts comes in. Struts is a Web application framework that streamlines the building of Web applications based on the MVC design principles. But what does that mean? Is Struts an MVC Web application that you just add on to or extend? Is Struts just some libraries? Actually, Struts is a little bit of both. Struts provides the foundation, or framework, for building an MVC-oriented application along with libraries and utilities for making MVC development faster and easier.
You could create a new Controller servlet every time you wanted to use the MVC design pattern in your Web application. Additionally, you'd need to create the management/flow logic for getting data to and from the Model and then routing requests to the View. You'd also need to define interfaces for interacting with your Model objects and all the utility code that goes along with using the MVC design pattern. However, instead of going through this process each time you create a new application, you can use Struts. Struts provides the basic structure and outline for building that application, freeing you to concentrate on building the business logic in the application and not the "plumbing."
To better understand the benefits of Struts, consider the following analogy. If you were to create a GUI application in Java, you wouldn't write a text field widget and a drop-down widget yourself. You would use Java's Swing API that already has standardized, fully functional code that provides these controls. Not only are the Swing controls ready-to-use, but they are also understood by all Java programmers. Struts provides the same type of advantages: Struts supplies a standard way of implementing an MVC application, the Struts code is tried and true, and the techniques required to use Struts are well known and documented.
In addition to providing the foundation for MVC applications, Struts provides rich extension points so that your application can be customized as you see fit. This extensibility has led to several third-party extensions being made available for Struts, such as libraries for handling application workflow, libraries for working with view technologies other than JSP, and so on.

The Evolution of Struts:

Struts was originally created by Craig R. McClanahan and then donated to the Jakarta project of the Apache Software Foundation (ASF) in May 2000. In June 2001, Struts 1.0 was released. Since then, many people have contributed both source code and documentation to the project and Struts has become the de facto standard for building Web applications in Java and has been embraced throughout the Java community. Struts 1.1 was released in June 2003 and included a substantial amount of new functionality, including the addition of Tiles, Validator, declarative exception handling, and much more. Later, in December 2004, Struts 1.2 was released with several minor updates to the framework. Struts 1.3, released in 2006, introduced the largest change to the framework since the 1.1 release: the move to a chain of responsibility (COR)-based request processing engine.
Today, Struts is continuing to evolve. There are now two distinct major versions of Struts: Struts 1 and Struts 2. Struts 1 is the mature, widely adopted, documented, and supported version of Struts. It is the version of Struts in use now. Struts 2 is a completely new version of Struts based on the merger of Struts and WebWork, another popular open source Java Web application framework. At the time of this writing, Struts 2 is under development and does not have a specific release date. Going forward, Struts 1 and Struts 2 will both be actively developed and maintained as separate subprojects of the Struts project.
Another event has punctuated Struts' evolution: its graduation to a top-level Apache project. Struts is no longer a subproject of the Jakarta Project. This is an important change because it affords Struts more autonomy and gives it the ability to have its own subprojects.

Java Server Faces

Overview:
JavaServer Faces is a holistic solution to several longstanding problems facing software developers and the customers who consume the software. For the end user, JavaServer Faces holds the promise of an easier, more intuitive usage experience for Web-based applications. For software developers, JavaServer Faces provides a standard, object-oriented, easy-to-use application programming interface (API) that takes much of the pain out of bringing a great user experience to the world of Web applications. JavaServer Faces gives users the power, flexibility, and performance that have previously been addressed only in a piecemeal fashion. JavaServer Faces was developed by a community of Web application experts assembled by the Java Community Process. These experts are the people behind Jakarta Struts, Oracle Application Server, Sun Java Studio, IBM WebSphere Studio, ATG, and many other programs in the Web application development space. Their collective wisdom was brought to bear on the problem
of how to take the best patterns from the existing technologies that solve the same problems and combine them into a cohesive whole, as well as filling in the gaps not filled anywhere to date. JavaServer Faces combines the ubiquity of JSP and servlets, the simplicity of JavaBeans, the power of J2EE, and the common-sense chutzpah of frameworks like Jakarta Struts to bring you the best-of-breed way to develop the user interface for a Web application.

Introduction:
JavaServer Faces (JSF) is an exciting new technology that will change the way we build user interfaces for Java 2 Enterprise Edition applications. With the introduction of JSF, we can finally create user interfaces simply with a set of reusable components. And with a component-based framework, Web applications are finally on a more level playing field with client-based User Interface (UI) frameworks such as Swing. Web developers will be able to use and reuse components off the shelf in their applications so we will see tool support and components implemented for JSF.

Why JSF?

• MVC for web applications
• Clean separation of roles
• Easy to use
• Extensible Component and Rendering architecture
• Support for client device independence
• Standard
• Huge vendor and industry support
• Offers finer-grained separation of behavior
  and presentation than JSP
• UI-component and Web-tier concepts
  without limiting a particular scripting
  technology or markup language

Comparing JSF & Struts:

• Struts (I am not saying you should not use Struts)
  
  
  • No built-in UI component model
  • No built-in event model for UI components
  • No built-in state management for UI components
  • No built-in support of multiple renderers (Struts is more or less tied up with HTML)
  • Not a standard (despite its popularity)
• Struts and JSF can be used together

References
JSF in Action - Kito D. Mann