Java Theory and Practice: Let EE out of the container

In most cases, a Java application is either an EE application or a J2SE application, and it is entirely separate from this point. The Java EE application requires the services of the Java container, and the container implements a long list of Java-EE APIs, including Enterprise JavaBean (EJB), JTA, JNDI, JMS, JCA, and JMX. Java EE API Design for collaborative work; After all, the Java EE design is a public demand extracted from the experience of hundreds of of people developing enterprise applications over the years. Like all frameworks, the main purpose of the Java EE API is to "not reinvent the wheel."

Some APIs are part of the Java EE specification, but can be easily used in J2SE applications such as JDBC, JSP, and servlet, but for most Java EE api,j2ee is either or not a proposition-most Java APIs require full function of the Java container. However, there are often good reasons why some server applications are developed as J2SE applications rather than Java-EE applications. Why do developers of these applications have to reinvent the wheel? Is there some content in Java EE that can easily be borrowed by J2SE applications to provide the same benefits? What components can be used at the same time for Java EE and J2SE application components?

Loosely coupled

One of the main design principles of Java EE is that Java-EE applications can be loosely coupled-assembled with components, not defining or altering the components ' interconnectedness when assembling or deploying an application, or at the time of component development. The Java EE component uses JNDI to find and find resources, such as JDBC and JMS connections, to each other. Technologies such as JMS encourage loose coupling, allowing for flexible workflow modeling, easy allocation of processing tasks, scalability, and fault tolerance. Many J2SE server applications can also benefit from these technologies and principles.

APIs such as JDBC, JMS, and JNDI are basically "middleware"--they serve as a unifying interface between applications and different service providers. Almost every database server has a JDBC driver, a large number of free database servers, so almost every Java application that wants to take advantage of a database can easily do this. However, this is not the case for JMS. Message Queuing servers are far less common than databases, especially in small stores. But there are a number of applications that can benefit enormously by using Message Queuing.

Somnifugi JMS

Message Queuing is a powerful paradigm for building robust, flexible, loosely coupled, scalable applications. There are some commercial Message Queuing products, such as WebSphere MQ, Sonic, Fiorano, JBOSSMQ, and Spiritwave. Like JDBC for databases, JMS is the middleware of messages-it enables applications to access different Message Queuing products through a unified interface that provides abstractions such as Connection, Topic, and messages.

Many J2SE applications use some form of Message Queuing, but instead of using jms--, they use thread pools, work queues, task managers, and so on. The AWT and Swing frameworks use messages (events) to communicate between the model and the view layer, and the JavaBean component uses listeners to support a theme-based message. Message Queuing provides a number of structural advantages-its inherent loose coupling facilitates flexible, component-based approaches and provides a natural abstraction boundary that helps simplify design and reduce interconnection. An incidental benefit is that the MQ paradigm makes distributed, scalable, and fault-tolerant designs easier because messaging producers and consumers do not necessarily run in the same JVM, and the nature of most producer/user tasks is to allow concurrent processing.

Developers of J2SE server applications often develop their own message tiers, either from scratch or built on a library such as Util.concurrent. The usual reasons for doing this are:

MQ servers are expensive and heavyweight, and because we don't need more heavyweight features like persistence, distributed, transactional, and validation, it's easier to build the message layer in our own memory.

While this is generally true, application requirements tend to increase over time, and some of the message features that you don't need at first may become more important in the future.

Developers of message-oriented applications have to make choices early in the development process--Select a commercial messaging product, or build their own cheaper, lighter-weight solutions. The Somnifugi JMS package combines these two approaches-a non-persistent in-memory Message Queuing service based on High-performance Util.concurrent libraries, and an interface that conforms to the JMS API. Compared to traditional JMS providers, Somnifugi is fairly lightweight, functional or performance. It is limited to use in a single JVM (although it can be removed) and lacks persistence, transaction, and validation capabilities. On the other hand, it's particularly fast-it's much faster than a traditional JMS implementation, so that it can be used where messages may not be available for performance reasons. To show how lightweight Somnifugi is, the distribution includes several examples of replacing the Swing/javabean event framework with a JMS theme.

Increased flexibility

Somnifugi also provides another important benefit: you can now develop components that use the JMS interface, and then decide whether to use a faster, in-memory Somnifugi provider or a more heavyweight, but more reliable provider, such as WebSphere MQ, when you deploy your application. The benefits of postponing this choice to deployment are enormous-especially since the requirements may change during the development of the project-and provide the opportunity for code reuse, which is unlikely to be possible for the development of the message layer.