CushionTheBlow (구 BluemoonSoft)

In software engineering, a Web application or webapp is an application that is accessed via Web browser over a network such as the Internet or an intranet. It is also a computer software application that is coded in a browser-supported language (such as HTML, ASP, PHP, Perl, Python etc.) and reliant on a common web browser to render the application executable.

Web applications are popular due to the ubiquity of a client, sometimes called a thin client. The ability to update and maintain Web applications without distributing and installing software on potentially thousands of client computers is a key reason for their popularity. Common Web applications include Webmail, online retail sales, online auctions, wikis, discussion boards, Weblogs, MMORPGs and many other functions.

Reference:
http://en.wikipedia.org/wiki/Web_application

Rich Internet applications (RIA) are web applications that have the features and functionality of traditional desktop applications. RIAs typically transfer the processing necessary for the user interface to the web client but keep the bulk of the data (i.e., maintaining the state of the program, the data, etc.) back on the application server.

RIAs typically:

- run in a web browser, or do not require software installation
- run locally in a secure environment called a sandbox

Reference:
http://en.wikipedia.org/wiki/Rich_internet_application

Model-view-controller (MVC) is an architectural pattern used in software engineering. Successful use of the pattern isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the application or the underlying business rules without affecting the other. In MVC, the Model represents the information (the data) of the application and the business rules used to manipulate the data, the View corresponds to elements of the user interface such as text, checkbox items, and so forth, and the Controller manages details involving the communication to the model of user actions such as keystrokes and mouse movements.

History
The pattern was first described in 1979 by Trygve Reenskaug, then working on Smalltalk at Xerox PARC. The original implementation is described in depth in the influential paper Applications Programming in Smalltalk-80: How to use Model-View-Controller.

Pattern description
It is common to split an application into separate layers: presentation (UI), domain logic, and data access. In MVC the presentation layer is further separated into view and controller. MVC encompasses more of the architecture of an application than is typical for a design pattern.

Model
The domain-specific representation of the information on which the application operates. Domain logic adds meaning to raw data (e.g., calculating if today is the user's birthday, or the totals, taxes, and shipping charges for shopping cart items).
Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model.

View
Renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes.

Controller
Processes and responds to events, typically user actions, and may invoke changes on the model.

MVC is often seen in web applications, where the view is the actual HTML page, and the controller is the code that gathers dynamic data and generates the content within the HTML. Finally, the model is represented by the actual content, usually stored in a database or XML files, and the business rules that transform that content based on user actions.

Though MVC comes in different flavors, control flow generally works as follows:

1. The user interacts with the user interface in some way (e.g. presses a button).
2. A controller handles the input event from the user interface, often via a registered handler or callback.
3. The controller notifies the model of the user action, possibly resulting in a change in the model's state. (e.g. controller updates user's Shopping cart).
4. A view uses the model (indirectly) to generate an appropriate user interface (e.g. the view produces a screen listing the shopping cart contents). The view gets its own data from the model. The model has no direct knowledge of the view.
5. The user interface waits for further user interactions, which begins the cycle anew.

By decoupling models and views, MVC helps to reduce the complexity in architectural design, and to increase flexibility and reuse.

Selected frameworks
GUI frameworks
Java: Java Swing
Java Swing is different from the other frameworks, in that it supports two MVC patterns:

Model
Frame level model-- Like other frameworks, the design of the real model is usually left to the developer.
Control level model-- Swing also supports models on the level of controls (elements of the graphical user interface). Unlike other frameworks, Swing exposes the internal storage of each control as a model.

View
The view is represented by a class that inherits from Component.

Controller
Java Swing doesn't necessarily use a single controller. Because its event model is based on interfaces, it is common to create an anonymous action class for each event. In fact, the real controller is in a separate thread (the Event dispatching thread). It catches and propagates the events to the view and model.

Combined frameworks
Java: Java Enterprise Edition (Java EE)
Unlike the other frameworks, Java EE defines a pattern for model objects.

Model
The model is commonly represented by entity beans, although the model can be created by a servlet using a business object framework such as Spring.

View
The view in a Java EE application may be represented by a Java Server Page, which may be currently implemented using JavaServer Faces Technology (JSF). Alternatively, the code to generate the view may be part of a servlet.

Controller
The controller in a Java EE application may be represented by a servlet, which may be currently implemented using JavaServer Faces (JSF).

Reference:
http://en.wikipedia.org/wiki/Model-view-controller

In software engineering, multi-tier architecture (often referred to as n-tier architecture) is a client-server architecture in which an application is executed by more than one distinct software agent. For example, an application that uses middleware to service data requests between a user and a database employs multi-tier architecture. The most widespread use of "multi-tier architecture" refers to three-tier architecture.

Three-tier architecture
'Three-tier' is a client-server architecture in which the user interface, functional process logic ("business rules"), computer data storage and data access are developed and maintained as independent modules, most often on separate platforms.

The three-tier model is considered to be a software architecture and a software design pattern.

Apart from the usual advantages of modular software with well defined interfaces, the three-tier architecture is intended to allow any of the three tiers to be upgraded or replaced independently as requirements or technology change. For example, a change of operating system from Microsoft Windows to Unix would only affect the user interface code.

Typically, the user interface runs on a desktop PC or workstation and uses a standard graphical user interface, functional process logic may consist of one or more separate modules running on a workstation or application server, and an RDBMS on a database server or mainframe contains the computer data storage logic. The middle tier may be multi-tiered itself (in which case the overall architecture is called an "n-tier architecture").

The 3-Tier architecture has the following three tiers:

Presentation Tier
This is the top most level of the application. The presentation tier displays information related to such services as browsing merchandise, purchasing, and shopping cart contents. It communicates with other tiers by outputting results to the browser/client tier and all other tiers in the network.

Application Tier (Business Logic/Logic Tier)
The logic tier is pulled out from the presentation tier and, as its own layer, it controls an application’s functionality by performing detailed processing.

Data Tier
This tier consists of Database Servers. Here information is stored and retrieved. This tier keeps data neutral and independent from application servers or business logic. Giving data its own tier also improves scalability and performance.

Comparison with the MVC architecture
At first glance the three tiers may seem similar to the Model-view-controller (MVC) concept, however topologically they are different. A fundamental rule in a three-tier architecture is the client tier never communicates directly with the data tier; in a three-tier model all communication must pass through the middleware tier. Conceptually the three-tier architecture is linear. However, the MVC architecture is triangular: the View sends updates to the Controller, the Controller updates the Model, and the View gets updated directly from the Model.

From a historical perspective the three-tier architecture concept emerged in the 1990's from observations of distributed systems (e.g., web applications) where the client, middleware and data tiers ran on physically separate platforms. Whereas MVC comes from the previous decade (by work at Xerox PARC in the late 1970's and early 1980's) and is based on observations of applications that ran on a single graphical workstation; MVC was applied to distributed applications much later in its history (see Model 2).

Web Development usage
In the Web development field, three-tier is often used to refer to Websites, commonly Electronic commerce websites, which are built using three tiers:

1. A front end Web server serving static content.
2. A middle dynamic content processing and generation level Application server, for example Java EE platform.
3. A back end Database, comprising both data sets and the Database management system or RDBMS software that manages and provides access to the data.

Other Considerations
The data transfer methods between the 3 tiers must also be considered. The data exchange may be file-based, client-server, event-based, etc. Protocols involved may include one or more of SNMP, CORBA, Java RMI, .NET Remoting, Sockets, UDP, or other proprietary combinations/permutations of the above types and others. Typically a single "middle-ware" implementation of a single protocol is chosen as the "standard" within a given system, such as J2EE (which is Java specific) or CORBA (which is language/OS neutral). Which protocol is chosen affects such issues as the ability to include legacy applications/libraries, performance, maintainability, etc. When choosing a "middle-ware protocol" (not to be confused with the "middle-of-the-three-tiers"), engineers should not be swayed by public opinion about a protocol's modernness, but should consider the technical benefits and suitability given the problem at hand. For example CGI is very old and "out of date" but is still quite useful and powerful, so is shell scripting, and UDP for that matter.

Ideally the high-level system abstract design is based on business rules and not on the front-end/back-end technologies. The tiers should be populated with functionality in such a way as to minimize dependencies, and isolate functionalities in a coherent manner - knowing that everything is likely to change, and changes should be made in the fewest number of places, and be testable.

Reference:
http://en.wikipedia.org/wiki/Multitier_architecture

Java Remote Method Invocation ("Java RMI") technology run over Internet Inter-Orb Protocol ("RMI-IIOP") delivers Common Object Request Broker Architecture (CORBA) distributed computing capabilities to the Java 2 platform. Java RMI over IIOP was developed by Sun and IBM. The joint work by Sun and IBM to implement Object Management Group (OMG) standards demonstrates the spirit of collaboration that continually moves the Java platform forward. Java RMI over IIOP combines the best features of Java RMI technology with the best features of CORBA technology.

RMI-IIOP (read RMI over IIOP) denotes the Java RMI interface over the CORBA system.

This standard was created to simplify the development of CORBA applications, while preserving all major benefits. RMI-IIOP is largely based on the Object by Value concept that serves as a container or direct replacement for CORBA structures, unions, sequences, arrays and strings. The IDL is not used. Instead, the data structure definitions "supposed" automatically, collecting the necessary data via reflection mechanisms. When CORBA needs supplementary generated classes for each non trivial data structure being transferred, RMI-IIOP only uses the generated code for remote objects. Less generated code results in the smaller footprint.

Both CORBA and RMI-IIOP use the same GIOP communication standard. If required, it is possible to generate the IDL definitions for the involved RMI-IIOP data structures and use these definitions to arrange the interoperability between the RMI-IIOP and plain CORBA applications.

The recent versions of RMI-IIOP derive their servants from the standard Servant (CORBA) class. Hence it is possible to connect them to the CORBA ORB manually, involving, if necessary, the Portable Object Adapter, Portable Interceptors, CORBA naming service and all other standard CORBA features.

Reference:
http://en.wikipedia.org/wiki/RMI-IIOP

In CORBA, a Servant is the invocation target, containing methods for handling the remote method invocations. In the newer CORBA versions, the remote object on the server side is split into the Object (that is exposed to remote invocations) and Servant (where the former part delegates the method calls). It can be one Servant per remote Object, or the same servant can support several (possibly all) objects, associated with the given Portable Object Adapter. The Servant for each Object can be set or found "once and forever" (servant activation) or dynamically chosen each time when the method on that object is invoked (servant location). Both servant locator and servant activator can forward the calls to another server. In total, this system provides a very powerful means to balance the load, distributing requests between several machines.

In the object oriented languages, both remote Object and its Servant are objects from the viewpoint of the object oriented programming.

Reference:
http://en.wikipedia.org/wiki/Servant_%28CORBA%29

In distributed computing, General Inter-ORB Protocol (GIOP) is the abstract protocol by which object request brokers (ORBs) communicate. Standards associated with the protocol are maintained by the Object Management Group (OMG).

IIOP (Internet Inter-Orb Protocol) is the implementation of GIOP for TCP/IP. It is a concrete realization of the abstract GIOP definitions.

Reference:
http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol

Enterprise Java Beans (EJB) is a managed, server-side component architecture for modular construction of enterprise applications.

The EJB specification is one of the several Java APIs in the Java Platform, Enterprise Edition. EJB is a server-side component that encapsulates the business logic of an application. The EJB specification was originally developed in 1997 by IBM and later adopted by Sun Microsystems (EJB 1.0 and 1.1) and enhanced under the Java Community Process as JSR 19 (EJB 2.0), JSR 153 (EJB 2.1) and JSR 220 (EJB 3.0).

The EJB specification intends to provide a standard way to implement the back-end 'business' code typically found in enterprise applications (as opposed to 'front-end' user-interface code). Such code was frequently found to reproduce the same types of problems, and it was found that solutions to these problems are often repeatedly re-implemented by programmers. Enterprise Java Beans were intended to handle such common concerns as persistence, transactional integrity, and security in a standard way, leaving programmers free to concentrate on the particular problem at hand.

Accordingly, the EJB specification details how an application server provides:

- Persistence
- Transaction processing
- Concurrency control
- Events using Java Message Service
- Naming and directory services (JNDI)
- Security ( Java Cryptography Extension (JCE) and JAAS )
- Deployment of software components in an application server
- Remote procedure calls using RMI-IIOP.
- Exposing business methods as Web Services.

Additionally, the Enterprise JavaBean specification defines the roles played by the EJB container and the EJBs as well as how to deploy the EJBs in a container.

Reference:
http://en.wikipedia.org/wiki/Enterprise_JavaBean

iBATIS is a persistence framework which enables mapping SQL queries to POJOs (Plain Old Java Objects). The SQL queries are decoupled from an application by putting the queries in XML files. Mapping of the retrieved objects is automatic or semi-automatic.

The basic idea behind the iBATIS introduction was to significantly reduce the amount of Java code that a Java developer normally needs to access a relational database with the use of XML files containing SQL queries.

For example there may exist a database table PRODUCT (PRD_ID: INTEGER, PRD_DESCRIPTION: VARCHAR) and a Java object com.example.Product (id: int, description: String). To populate the contents of a particular PRODUCT of a specified PRD_ID into the Product POJO we would insert the following into an XML SQL map:

The Java code which sets up a parameter object and populates the result object is as follows:

Note the #id# comes from the parameter object.

The framework is currently available in Java, .NET, and Ruby (RBatis) versions.

Reference:
http://en.wikipedia.org/wiki/IBATIS