Java EJB 3.0
EJB 3.0 is a "sea of changes from the previous versions of EJB technology in that the programming and the deployment is very different."(Mastering EJB 3.0 4th Edition). The ability to use POJO(plain old Java object)) style entities with enterprise beans is a much sought after feature. A powerful concept introduced is the ability for any enterprise information system effectively sending any type of messages to a message-driven bean endpoint via EE connector architecture-based resource adapters. Because JAX-RPC does not support asynchronous messaging, connector architecture-based message providers/resource adapters can be extremly handy.
Java 2 Enterprise Edition Applications
J2EE is used to build extensible, scalable, reliable, timeliness systems for enterprise applications. Using the Model-View-Controller pattern provides an
overall structure for web applications in J2EE. While the idea of using JavaBeans as a Model, Servlets, and JSP for the View for the controller is not a requirement, it is a good rule of thumb. It's far more important to understand how the seperation between Model, View, and the Controller makes an application extensible and maintainable. Most web application frameworks implement at the MVC pattern, and many even claim to be "pattern-based". In general, frameworks force applications written to them to conform to certain patterns. Recognizing these patterns can be a big help in designing applications that work well in a given framework.
Jakarta Struts is probably the best-known web application framework(a part of the Apachie Project). It is based on what they call a "Model 2" approach, an implementation of MVC in which you write the model and view componenets, and Struts provides the controller. The struts controller is based on the Service to Worker pattern, featuring a front controller, a dispatcher configured via XML files, and a s2w code framework for embedding application logic into actions. Struts also includes a number of utility classes and tag libaries, including Tiles, an implementation of the Composite View pattern
- Reliability
Corporate software projects are subject to specific quality requirements, and reliability is usually first among these. Most large software teams have one or more people in a Quality Assurence role, or they make use of services of a dedicated QA team or department. Large projects, particularly in regulated industries such as health care, are subject to validation processes and audits. A software audit can include every aspect of the development cycle, from initial requirements gathering through design, up to final testing and release procedures.
- Design Patterns
Design patterns play a major role in ensuring reliability and can be validated at a high level and incorporated early on in the design process. This
type of planning makes the validation process simpler, and generally produces code that is easier to audit in the first place.
- UML
UML supports all aspects of the software design development cycle, from requirements gathering to design to deployment. In particular, The UML can be extremely important(helpful) in documenting the object structure underlying an application, known as the domain model; but UML models can represent use cases, class structures, program interactions, process flows, physical deployments, packages, and more.
Often simply creating UML diagrams uncovers subtle flaws in system design.
UML also provides an excellent way to describe design patterns, both in terms of class structures and program processes. UML is complex. The specification itself is dense, and as a result much of the available literature must address the complexities in detail.
Most teams find a comfortable middle ground in which modeling, via UML, or other methods, serves the teams underlying goals rather then becoming a end in itself.
- Class Diagrams
Class diagrams show the relationships between classes in system. Since object oriented design blurs the line between data objects and executable application logic, a UML class diagram documents both. UML actually supports both class diagrams and object diagrams.
The distinction between a class and an object:A class is a framework containing methods and data that can be instantiated into one or more objects, which contain actual data items. UML class diagrams show the relationship between the frameworks, and object diagrams show the state of a system with actual objects, containg actual values.
Class diagrams can be used to build conceptual pictures of an application's domain model, which can then be used to develop more specific system designs that eventually map to code.
In real life a client class could include persistence methods, cryptographic algorythms, message transports, or anything that might need to be done consistently in more then one way.
|
Design patterns can also be misapplied, making simple problems more complex then necessary, or encourging code-first design later developemnt cycles as developers assume that the presence of patterns(with their promise of easy extensibility and maintenence.) allow requirements to be dealt with as they come up.
To be useful, design patterns need to be expressed. While there are a varity of ways to do this, a UML diagram is a part of most of them. The diagram can make broad concepts and implemention details clear in a langauge-independent way that doesn't require working through large chunks of sample code. There are relatively few programming patterns that don't lend themselves to some sort of UML representation.
Coupling modeling with design patterns has a number of advantages. The model provides context for choosing the right design patterns, although the presence of
effective design patterns will also, perhaps somewhat recursively, influence the developement of the model. In most circumstances, the result is a simpler smaller, more manageble software.
Software validation efforts can be time-consuming and require clear documentation at the design and implementation levels--and in some cases proveable correctiveness.
Scalability
Scalability and performance are closely intimate but are not the same thing. Scalability can broadly be defined as the ability of an application to maintain performance as the number of requests increase. The best possible scenerio is a constant response time, where the time it takes to process a request stays the same regardless of the load on the server.
- Linear Scalability
Linear Scalalibility is when the time it takes to process n requests is equal to ntimes the time to process one request. So if one user gets a reponse in 1 second, 10 simultaneous users will have to wait 10 seconds, as each second of processing time is divided 10 ways.
Extensibility
The one constant in software development is that requirements always change. In general, the extensibility of software determines how easily changes can be accommodated. While objects must interact with each other in order for a program to do anything, the number of dependencies should be limited. Using clear interfaces separates an objects implementation from its interactions. This makes the specific implementation independent of the rest of the application, allowing implementations to be fixed, changed, or replaced at will. In an extensible program interfaces are kept as tight as possible to make sure they interact in well known ways.
- Model-View-Controller Pattern
Click View Code Tutorial
Using the Model-View-Controller pattern provides an overall structure for web applications in J2EE. Providing an architecture for the entire presentation tier that cleanly seperates state, presentation, and behavior.
MVC breaks the interface into three distinct pieces: model, view, and controller. The model stores the application state. A view interpets data in the model and presents it to the user. The controller processes user input, and either updates the model or displays a new view.
A controller is the first point of contact for a request. An application may have multiple controllers, each responsible for a certain area of an application. The model stores application state. Application state is data stored anywhere: databases, JavaBeans, files, network services or just in memory. The models job is to manage access to this state, providing the controller and view with a uniformed interface. The model does not simply copy the information. It is an abstraction of the data, and may implement and enforce rules on how the data may be accessed or combine muiltiple fields of data into a single logical field. The view reads from the model and uses the data to generate a response. The view itself is a stateless component that simply transforms values from the model into a format that clients will find useful.
Building a Center Controller, the first point of contact for a request. Is the place where we have the most programming and design freedom. Unlike the model, which is shaped by the underlying data, the controller is designed from start to finish as a part of the presentation tier. And unlike the view , which is stateless and generally focused on presentation, we are free to perform as much complicated logic as we like.
- Front Controller Pattern
Pattern's combined allow us to dynamically add functionality to the front controller, creating an extensible presentation tier. .................
|
The Model-View-Controller Pattern gives an architecture for enterprise applications that separates the application into functional pieces with a clear interfaces. The Front Controller Pattern extends this architecture, describing a central controller that performs common functions on each request. Finally the Decorator Pattern shows how to dynamically add functionality to the front controller. Used together ,
these patterns create an extensible presentation tier.
While decorators represent a fairly simple way to extending an object's functionality, aspect-oriented programming (AOP) is a programming methodolgy
centered around dynamically extending objects. An aspect in AOP represents a common concept that cuts across multiple classes, like the ideal of logging. An aspect encapsulates the code to perform an action (like logging) as well targets it applies to(the front controller) and the conditions for which it should apply (whenever a get request is recieved), all in one construct. Whenever its conditions are met the code in an aspect is exicuted.
|
|
