Enterprise JavaBean

JavaBeans are simple classes that follow a particular coding style (setter and getter methods). Enterprise JavaBeans (EJBs), must operate within the context of a container, are server-side components built to deal with the complexities of distribution. The EJB framework (container and server) allows user to focus on writing business logic code within the EJBs. The EJB server holds containers and provides generic EJB server services required by all containers, including transaction monitoring services, generic security services and administration service. Although the precise demarcation of responsibilities between the server and its containers is not defined by the EJB specification, the container to EJB interface is part of the specification. There are four basic elements that make up an EJB component:

1. Business logic interface (also known as the object interface)
2. Life cycle interface (also known as the home interface)
3. EJB component class
4. XML deployment descriptor

(since EJB 2.0, local life cycle interface and local business logic interface were introduced).

For every EJB component you must implement certain methods. These are called callback or life cycle methods. For example, a method is called just after a component instance is created, or just before it is destroyed, or just prior to its passivation (a form of serialization) or reactivation.

Although users are responsible for writing the life cycle and business logic, their implementation classes are generated automatically prior to deployment by container tools. XML files are written to describe the required distribution properties for EJBs. With an appropriate XML deployment descriptor editor, we are able to display and alter the deployment properties. Container tools read these XML deployment descriptor files and generate distribution code. Among the various properties there are some worth to mention:
Security - logical security role names are used. Allows user to say who is allowed to invoke which methods.

Transaction scope, persistence requirements, composition, and the type of EJB - e.g. indicate to the container the kind of EJB you have developed and chain of methods used in a transaction. If a persistent EJB, the parts of the EJB that should be synchronized with a table in an underlying RDBMS.

There are three kinds of EJBs:
Session EJBs - used to encapsulate business logic. Stateful session and stateless session EJBs are two variants of session beans. Their data is not synchronized automatically with an underlying persistent store by the container.

Entity EJBs - used to encapsulate business logic. Unlike the session EJBs, their data is synchronized. This synchronization can either be at the control of the container entirely (container-managed persistence), or can be partially the responsibility of the EJB code (bean-managed persistence).

Message driven EJBs - this is new to EJB 2.0. While session and entity EJBs support synchronous communication, message driven EJBs support asynchronous communication. It read message objects off an associated destination (a queue or topic).

Spring

The front-ends built using WebWork or Struts (Struts²) can be integrated with a Spring-based middle-tier. By using Spring's declarative transaction management features the web application is fully transactional, just as it would be when using container managed transactions as provided by Enterprise JavaBeans. The only thing you need to do is wire up your business logic using an ApplicationContext and integrate your web layer using a WebApplicationContext.

Model-View-Controller

The Struts framework was created by Craig R. McClanahan and donated to Apache Software Foundation (ASF) in 2000. A framework provides generic, cooperative components that your application extends to deliver a particular set of functions. So it is also referred as an "upside-down" library. The Struts framework provides three key components for the implementation of the MVC structure.

• A "request" handler provided by the application developer that is mapped to a standard URI.
• A "response" handler that transfers control to another resource which completes the response.
• A tag library that helps developers create interactive form-based applications with server pages.

Others
Cocoon project founded by Stefano Mazzocchi in January 1999 is an open source project the ASF. Cocoon leverages XML, XSLT, and Simple API for XML (SAX) to help create, deploy, and maintain XML server applications.

Velocity is a Jakarta project like Struts. It is a Java-based template engine that can generate SQL, PostScript, and XML form templates.

JavaServer Faces (JSF) project is to provide a standard set of JSP Tags and classes to aid in the management of complicated HTML forms, event handling, and presentation state.

Jakarta Turbine is a servlet-based framework. A large set of components is included with the framework, including those for using relational databases, security, and scheduling, etc.

WebWork is a web application framework that uses the Pull Hierarchical Model View Controller (HMVC) design. With a standard MVC design, changes made to the model are pushed to the view. In the case of WebWork, the views pull the data when they need it.

Spring is a J2EE application framework developed by Rod Johnson. Spring is not just a web framework. It can integrated with other disparate components.

Apache Struts 2 was originally known as WebWork 2. After working independently for several years, the WebWork and Struts communities joined forces to create Struts².

Controller - MVC
The controller portion of the web tier MVC design generally is a Java Servlet. The Front Controller pattern, which is part of the J2EE Design Patterns, describes how a web tier controller should be implemented. Code that would normally need to put in every JSP page can be put in the controller servlet, which processes all the request.

In the Struts framework, the controller responsibilities are implemented by several different components, one of which is an instance of the org.apache.struts.action.ActionServlet class. The ActionServlet extends the javax.servlet.http.HttpServlet class and its responsible for packaging and routing HTTP traffic to the appropriate handler in the framework.

An org.apache.struts.action.Action class in the Struts framework is an extension of the controller component. It decouples the client request from the business model. This allows for more than a one-to-one mapping between the user request and an Action. The Action class can perform other functions, such as authorization, logging, and session validation, before invoking the business operation.
Note: In Struts ², POJO Actions - use any class as an Action class - even the interface is optional. We can inject dependencies into Actions using Spring without glue code or red tap.

Model - MVC
In an enterprise application, the model portion of MVC pattern will be Enterprise JavaBeans. The Struts framework does not have a great deal of support in the way of model components. This is better left for EJB, CORBA, or some other type of component framework.

The EJB 2.0 made performance improvements through the use of local interfaces. However, due to the overhead of making remote calls, there still can be a significant performance impact if the web tier attempt to use entity beans directly as the model portion of the application. Therefore, JavaBeans are returned from session beans and used within the web tier. These JavaBeans are referred to as data transfer object (DTO) and are used within the views to build the dynamic contents. In a distributed application, usage of DTOs reduces the network bandwidth and improve response.

In Struts, application data is encapsulated in Java objects. User input is used to populate an action form upon form submission, business methods accept transfer objects as arguments, and custom tags are designed to manipulate JavaBeans. You can keep business logic out of the Action classes to protect against change. The Action is free to put the object in the request or session and then forward it to a JSP, where the data can be extracted and presented to the user.

View - MVC
The views within the web tier MVC pattern typically consist of HTML and JSP pages. The view components employed in a Struts application are:

• HTML
• DTO
• Struts ActionForms
• JSP
• Custom tags
• Java resource bundles

The Struts framework (ActionForm objects) automatically collects the input from the request and passes the data to an Action using a form bean. To keep the presentation layer decoupled from the business layer, DTO was created by using the data from the ActionForm.
Note: In Struts ², no more ActionForms. POJO forms - use any JavaBean to capture form input or put properties directly on an Action class. Use both binary and String properties!

JSP pages make up the majority of what has to be built for the Struts view components. Combined with custom tag libraries and HTML, JSP makes it easy to provide a set of views for an application.

The Struts framework provides six core tag libraries. We may extend the Struts tags or create our own custom tags. The custom tag libraries that are included with the framework are: HTML, Bean, Logic, Template, Nested, and Tiles tag libraries.

Note: The Struts ² adds interactivity and flexibility with AJAX tags that look and feel just like standard Struts tags.

Strike Pegger

There is a Wall Street axiom that says "90% of all the options that are bought and held to expiration will expire worthless". The Strike Pegger computes the stock price where the sum of the amount to be paid by all call and put writers is the smallest. This computed price changes as the ratio of open interest for calls and puts changes.

The Max Pain effect is the tendency for a stock’s price to gravitate towards this number as we approach the expiration date. Options officially expire the day after the third Friday of the month. Apple (AAPL) July 2008 options expired on July 18 after the closing bell. The calculated Max Pain value for AAPL is 160.



Update: AAPL closed at 165.15 on July 18.

Note: The strike pegger is more accurate for most major indexes and stocks which have large option volume, relatively low float, and have not experienced a significant and abrupt price move. The Volatility Skew, the Put/Call Ratio, and the Strike Peg should all be evaluated. Correct interpretation of the Volatility Skew is most valuable, since it effects the accuracy of the Put/Call Ratio and the Strike Peg.

Ref: http://www.optionistics.com/i/strike_pegger