Recent articles:
Popular archives:
Java: A platform for platforms
Sun's reorg may seem promising to shareholders but it's also a scramble for position. The question now is whether Sun can,
or wants to, maintain its hold on Java technology. Especially with enterprise leaders like SpringSource and RedHat investing
heavily in Java's future as a platform for platforms
Also see:
Discuss: Java: A platform for platforms?
Developing a log service that suits common needs often provokes debate. Numerous homegrown log frameworks are available in addition to many professional and open source products. Products such as log4j and J2SE 1.4 logging are worth mentioning. Many frameworks were developed before the advent of JMS (Java Message Service), and thus, without the benefits of asynchronous messaging. Frameworks designed after JMS's initiation benefited from asynchronous messaging.
In a traditional synchronous log model, the caller cannot execute further unless the log service returns successfully. All calls are blocked until the record is persisted or acknowledged by the log service. That clearly results in an overhead, especially if an application is designed to code numerous log messages. Imagine a source file consisting of a large number (sometimes hundreds) of log statements. Each statement should be logged before the following statement is processed—clearly a time-consuming process. In a distributed-computing environment, obviously, clients operate concurrently. The alternative is to build a concurrent client architecture using the traditional log service, although performance may remain an issue. Distributed computing architectures may also have deployments spread across many servers (geographically similar or dissimilar locations), in which case, logging to a central database synchronously is cumbersome, if not impossible.
This article will help you develop a simple log service. The service creates some log messages, sends them across the network to a JMS provider, and persists them in the database. For this purpose, we use JMS for its asynchronous benefits and Hibernate for its simple yet powerful persistence features. You can persist data in many ways, such as through standalone JDBC (Java Database Connectivity) connections, EJB (Enterprise JavaBeans), and stored procedures. I vote for tools that create domain entities from plain-old Java objects. In this article, I move away from constructing the domain model using EJB entities by using Hibernate.
Before developing the log service, let's look at some important concepts vital for developing this application.
J2EE continues to mature with respect to distributed computing environments. We can leverage many of its features, such as JMS, to develop asynchronous services. JMS is a specification from Sun Microsystems and its partners that covers inter-application messaging standards. See Resources to download the specification. Third-party vendors implement the specification defined by Sun. JMS is designed to handle different message types without the messages having knowledge of each other.
Remote procedure call (RPC) models such as RMI (remote method invocation), SOAP (Simple Object Access Protocol), and ORB (object request broker) are interface-centric, meaning the publisher expects a return value. In the case of JMS, the sender has no knowledge of the receiver. The applications that send and receive messages do not communicate via a standard communication channel. In fact they delegate the responsibility of delivering the messages to the JMS provider. The applications' jobs are completed when they post a message to the destination.
| Subject |
|
|
|
( 1 2 all )
|
|
|
|
|
great articleBy Anonymous on November 19, 2008, 11:45 amvery useful (not often used) demonstration. thanks
Reply | Read entire comment
View all comments