|
August 2006
August 29, 2006
Real Time Java
Real time or just "real fast?" WebLogic introduces a new Java VM and application server built on it.
The Real Time Specification for Java (RTSJ) was the very first Java Specification Request (JSR) worked through the Java Community Process (JCP). Sun, working with the community, implemented the specification and created the Java Real-Time System (Java RTS).
The actual definition of real time is often misconstrued. Many people confuse real time with "real fast," yet real time is really all about predictability in terms of latency and response. In order to achieve real-time performance in a software system, you need to control latency, therefore speed is a factor, but still it’s not the only one. The most important factor in real-time Java is guaranteeing predictability, and ensuring that garbage collector activity will not interfere with an application’s ability to respond to real-time events (such as an elevator passing a sensor). See Wikipedia for a good definition of real time.
At JavaOne this year, Sun had many Java RTS demos, but the one that interested me most was the real-time application server. In a nutshell, Sun took their Java EE application server and opened up two ports to requests. In one port they ran the normal Java VM, but in the other port they ran the real-time VM. The results were astonishing, as all requests made to the real-time Java VM were handled within a predictable, consistent, and very short time frame. As load was increased on the server, the real-time VM still responded predictably, yet the normal VM showed great latency.
WebLogic Real Time
But Sun is not the only vendor offering real-time Java; BEA recently announced WebLogic Real Time™. BEA’s real-time Java implementation offers latency in the 30 millisecond range. This is pretty good, but Sun’s real-time Java offers latency in the 10 microsecond range, which is an order of magnitude better, and leads to a much more predictable system.
One factor in the difference in latency may be the underlying operating system requirements imposed by the two vendors. Sun requires a real-time OS environment such as Solaris or, soon to come, carrier-grade Linux. WebLogic Real Time, however, works on Windows or Linux. With Windows and most Linux distributions not being real-time operating systems, this may account for the higher latency in the WebLogic VM.
Regardless, the introduction of new real-time Java VM implementations shows that Java is heading towards new territory. Applications for financial institutions, manufacturing, aircraft control, telecommunications, and the military--once the domain of C/C++--can now be built with Java.
What requirements do you have for real-time Java? Are you willing to accept greater latency for more flexability in OS choice? Let me know by entering your comments in the section below, or email me at eric@ericbruno.com.
-EJB
Posted by Eric Bruno at 09:19 AM Permalink
|
August 23, 2006
NetBeans Mobility Pack Released under CDDL
Sun just announced that it's releasing the mobility pack under the CDDL open-source license.
Today, Sun Microsystems announced the availability of source code for NetBeans Mobility Pack and NetBeans Mobility Pack for CDC (Connected Device Configuration), which will be released under the OSI-compliant Common Development and Distribution License (CDDL).
Perhaps this is a hint as to the license choice that will be used for the rest of Java ME and SE? One can only speculate.
You can read the entire press release at http://biz.yahoo.com/prnews/060823/sfw073.html?.v=66.
Posted by Eric Bruno at 02:52 PM Permalink
|
Open Access. Open Federation
OpenSSO helps you to build authentication, authorization, and session management for Java and web applications and web services.
Project OpenSSO was released on August 17. OpenSSO helps you to build authentication, authorization, and session management for Java and web applications and web services. The Open Web SSO project (OpenSSO) provides core identity services to simplify the implementation of transparent single sign-on (SSO) as a security component in a network infrastructure. This project is based on Sun JavaTM System Access Manager, a core identity infrastructure product offered by Sun Microsystems.
At the OpenSSO site, you can be part of the development community and provide code reviews, submit bug fixes, make suggestions for future functionality, and deploy the WAR file for your own projects.
Flux 7.2 Released
Today, Flux Corporation announced the release of Flux version 7.2. Flux is a Java job scheduling, file transfer, workflow, and business process management (BPM) engine. Beyond the new visual tools, Flux 7.2 includes support for Service Level Agreements (SLAs), file transfers using FTP over SSL (FTPS), a repository for storing pre-defined workflows, and skipping failed tasks within a workflow.
Apache Project Listing
Apache recently launched a site that intends to provide an overview of all the available Apache projects. You can review the projects and determine which ones fill your development needs. Not all projects are listed yet, but the list is growing and needs your feedback to make it complete.
Posted by Eric Bruno at 09:48 AM Permalink
|
August 17, 2006
The Age of Integration
I disagree with Jonathan Schwartz, regarding the age of participation.
In my opinion, the age of participation is better marked by the invention of the printing press, and then renewed by the invention of the telephone. Those technologies enabled many generations of people to participate in worldly activities (and become educated in matters of the world) unlike any generation that came before.
Instead, I think it’s the "Age of Integration." The web, more than anything else, has caused a huge amount of integration to occur between computers, networks, databases, applications, and so on.
Furthermore, the amount of integration is seemingly increasing, as seen by the growing popularity of web services and related technologies. Server technology; frameworks; web service technology; the enterprise service bus; XML; these technologies are all about integrating disparate computer systems and their related data.
If anyone is going to get credit for the modern age of participation, it may better go to AOL as it enabled people to chat with one another in chat rooms, in very large numbers, back in the mid-90’s. Instant messenger technology was quickly born from that, with ICQ, AOL, Yahoo!, and Microsoft offering IM networks soon after.
Java and Integration
Java, with its write once, run anywhere promise, along with the fact that it’s still the most popular Web application technology, is the king of integration in my opinion. Java EE 5, for instance, contains more tools and support for Java-based web services, such as NetBeans 5.5 and JAX-WS 2.0, than any version of enterprise Java that came before.
Sun recently released an article on how to build high-performance web services with JAX-WS and Java EE 5. The article compares JAX-WS with its predecessor, JAX-RPC, and discusses its new features such as support for asynchronous messaging, HTTP and non-HTTP transports, and improved performance, especially for large message payloads.
BEA, Oracle, and Open-source
Sun is not the only company with server technology to support Java-based web services. Both BEA, with its AquaLogic product, and Oracle, with its Fusion middleware, are two excellent examples of products that aim to make it easier to build Java SOA solutions.
As for open-source solutions, there’s Apache Axis (which makes it very easy to build both SOAP-based servers and clients and technology), along with over a dozen other Apache open-source frameworks and tools. To integrate those services and aggregate them into new applications and business processes, there is open-source enterprise service bus (ESB) software you can use, such as ServiceMix from LogicBlaze –- now an Apache Incubator project –- and Mule from CodeHaus.
What’s your opinion on the age of integration? What percentage of your applications and projects are related to integrating other applications, and/or their data? Further, what role has Java played in your integration work? Let me know by replying to this blog below.
-EJB
Posted by Eric Bruno at 02:08 AM Permalink
|
August 03, 2006
What Do Java, a Grizzly, and Comet Have In Common?
Explore advanced Ajax programming in Java.
Comet programming is the name given to the pattern commonly used in Ajax web applications, where data is streamed asynchronously to the browser from a web server. It also describes the ability of the web server to continue to send data to the browser, even without a new request from the browser. This requires the web server to maintain client connections for very long periods of time. Doing this for many browsers is a resource-intense operation that does not scale well.
There are techniques you can use to help with scalability, but there are other issues, such as message reliability, that may otherwise require you to use an enterprise messaging system, such as a JMS provider. So much for lightweight web applications!
Fortunately, there are other solutions. For instance, Sun created an HTTP listener that uses Java NIO in a package called Grizzly. Grizzly was designed to work on top of the Apache Tomcat Coyote HTTP Connector, and has since been integrated into GlassFish and the Sun Java Application Server 8.1, Platform Edition. The blog I referenced above, by Jean-Francois Arcand, describes Grizzly, its design, and how it helps a Comet-based applications scale well.
Comet API
Recently, Jean-Francois Arcand blogged about the Comet API that has been created for Grizzly (and hence GlassFish), and works with any web server that supports asynchronous request processing (ARP). This includes Apache Jetty, Tomcat, and of course GlassFish. However, Comet support is fairly new and available only starting in GlassFish 9.1 ea-b10.
If you’re building Ajax-based applications, and you’re experiencing (or concerned you will experience) issues around scalability, you should check out Comet and Grizzly. The techniques used within, namely the use of Java NIO as opposed to individual threads per request, achieve the same asynchronous, event-based, behavior needed for Ajax, except without all of the overhead.
To further simplify your life of Ajax-induced JavaScript coding, check out jMaki, which enables you to use JavaScript in your Java-based applications as either a JSP tag library or a JSF component.
Posted by Eric Bruno at 09:25 AM Permalink
|
|