June 27th, 2011 by caucho
You have no doubt heard of Java EE Web Profile. In the words of Rod Johnson, founder of the spring framework project, “Java EE 6 Gets it Right”.
Java EE Web Profile is the standard for servers that are more focused on web development using the pieces of the traditional Java EE stack that matter the most. You could say it is all of the stuff with none of the fluff. It allows vendors to create a slim focused application server. In our opinion, it allows vendors to provide an application server that fits the most common case of Java EE development. It has allowed Caucho to focus on what Resin does best, Java EE web development without the distraction of features that our clients don’t use.
Read the rest of this entry »
June 27th, 2011 by Reza Rahman
I just came back from a trip to the Raleigh, NC area to record a JavaLobby Tech Chat on Resin 4 (last year Emil did a Tech Chat that you might have seen). The Tech Chat went great. Mitch Pronschinske, the Editor-in-Chief of JavaLobby/DZone drove the Chat. Not to give away too much right now but we talked about:
- Past/present/future of Resin
- Defining characteristics of Resin - lightweight, standard and feature-complete
- Resin 4 Java EE 6 Web Profile certification
- Java EE Web Profile leadership
- How it stacks up against Tomcat/JBoss/GlassFish/WebLogic/WebSphere
- Small, dedicated, agile World class engineering team
- CDISource - a vendor-neutral space for all things CDI
- The CDISource Spring/CDI bridge
- Possibilities for Java EE 7/Java EE 8 (open for participation from you!)
- Early Resin WebSocket support
- Resin support for private clouds
Keep your eye on JavaLobby - the Tech Chat should be out there soon!
I chose to drive to NC to avoid the hassle of flying and because NC is quite drivable from my home office in Philly. On the way back, I did CDI demos at both the Research Triangle JUG and the NoVA/Washington, D.C. JUG. Both talks were very well attended. The interest/participation levels were fantastic. The DZone folks gave me a few nice printed copies of the CDI RefCard. Every single copy was taken and people were asking for more! They also asked me for the slide deck and code examples. I’ll send them to the JUG leads to post on the JUG websites. You can also take a look at the slide deck and code examples if you want and send me any follow-up questions. I also wanted to talk at the Maryland and Richmond JUGs but things didn’t quite work out schedule-wise this time around. Both JUGs are working on scheduling me to speak in the Fall instead.
May 31st, 2011 by caucho
What makes a good cloud offering for a Java EE server? What do developers and architects expect from a Java EE vendor to be cloud ready?
I suspect they expect the following:
- Cloud ready
- Elastic ready
- Ability to manage the nodes in the cloud
- Ability to manage versions in the cloud
The advantage we get from deploying applications to the cloud is the ability to scale up processing nodes (Java EE servers) rapidly if needed. And the ability to re-purpose processing nodes (spin down, re-purpose and spin back up) when needed as well. This can be in a public cloud setting like Amazon EC2 or in a private cloud (VMWare vCloud) or some combination thereof.
To be elastic, is to be flexible. The ability to bring up a new node without any configuration.
Ability to manage nodes in the cloud
Once you have nodes deployed in the cloud, how do you manage them? How do you check the health of so many nodes? How do you keep your eye on them all?
Ability to manage versions in the cloud
A common problem with cloud computing and Java EE servers is application archive versioning, war files, and ear files. How do you version a new war file? More importantly, how do you deploy one war file to the entire cloud? Can you deploy a version in a graceful manner without bringing down the entire cloud of nodes?
Resin Java EE 6 application server
Caucho’s Resin server is an elastic cloud ready, Java EE 6 Web Profile server. It has the ability to bring up new instances in an elastic cloud environment. The triad is the brain of the pod. A pod is a collection of nodes that serves some common set of applications. New instances, called dynamic servers, join the pod, talk to the triad and get the current versions of the applications to run. Then they start running the applications.
Cloud aware, load aware, intelligent load balancer
The pod load balancer is smart enough to allow the new dynamic server some time to warm up and install its applications from the triad before it starts sending it requests. The pod load balancer can truly balance the load based on the true load on each node, not just random round robin load balancing. The load balancer can also act as an http proxy cache to increase throughput by caching images, css files and other web resources.
Cloud failover that is cloud deployment version aware
Membership has its privileges, once up, the new dynamic server joins the pod services. It gets reliable, failover sessions. It gets reliable, failover caching. It gets reliable, failover messaging. Everything you would expect from a cloud computing platform like Caucho Resin server.
Now what if for some reason a node in the pod goes down. And then let’s say you deploy new versions of the applications. Then later, we bring that node back up. Does it start serving an old version of the application? No. Of course not. It talks to the triad and gets the current version of the applications.
Our deployment mechanism is truly cloud aware. It versions the deployments. You can even rollback an entire pod to a previous version. You can also gradually deploy a new version of the application. New sessions in the pod will use the new version of the application while existing sessions will use the older version of the application. Eventually all of the older session timeout and only sessions using the new application are active.
Also with Resin you can manage entire pods from load balancer to http proxy cache to triad to individual dynamic servers with a single admin tool. This admin tools allows you to profile, analyze GC, Heap, PermGen, OS memory, monitor threads, inspect memory usage at the class level, and other Java VM graphs and OS graphs from one console for every node in the pod. The support the admin tool provides rivals that of some dedicated profiling tools but does it for your entire pod. Now you can really see what is going on in the cloud.
Health Watches to auto-manage your cloud
You can also setup up health watches so you know when some critical situation has been released and then take some action to monitor, diagnose and control your cloud.
Resin is a Java EE, cloud computing ready server
Resin goes beyond just being a processing node in an elastic cloud. It is truly an intelligent elastic cloud coordinator bringing the promise of cloud computing into the hands of Java EE developers.
May 26th, 2011 by Paul Cowan
Based on a few recent support queries, some clarification of Resin’s directory structure should be beneficial for everyone and new users in particular. Â This is all spelled out in the documentation, just in different words.
Read the rest of this entry »
May 12th, 2011 by ferg
Resin 4.0.18 is now available at http://caucho.com/download. Release notes are at http://caucho.com/resin-4.0/changes/resin-4.0.18.xtp.
Resin 4.0.18 is primarily a quality and bug-fix release. For the next several months we’ll be focusing on quality and bug fixes with limited new features. So now is a good time to test it out and to report any bugs at http://bugs.caucho.com.
April 22nd, 2011 by Paul Cowan
Now that Resin is passing all the required TCKs and is ready for Java EE 6 Web Profile certification, we plan to shift focus to quality and stability for the next few months. Â Updates to the HealthCheck system, which are already underway, are an important part of that effort.
Resin 4.0.16 and later includes “health.xml”, a new configuration file dedicated to health checks, action, and meters. Â This is a big step forward from Resin’s <ping> or <resin:PingThread> that some users may be familiar with. Â While external application monitoring is important to your overall system architecture, the real power of Resin’s health monitoring is the ability to easily trigger things like restarts and thread dumps that would otherwise require custom external hooks.
Read the rest of this entry »
April 7th, 2011 by ferg
As WebSockets gets closer to a final draft, the real question becomes: how should applications use it? While JSON is an obvious payload format, sending plain JSON payloads just doesn’t have enough structure for any non-demo application. I’m putting together a JSMP (JSON Message Protocol) rough draft, as a suggested JSON pattern for WebSockets.
JMTP is based on our experience with clustering in Resin for the last two years. While we use Hessian instead of JSON for the payload, the architecture and issues are the same.
- typed messages: basically object-oriented messages. Any significant application will have several message types, and using an object-oriented
type is a clean way to dispatch.
- unidirectional messages and rpc queries: both styles are needed, and queries require a bit of protocol effort and definition to get right.
- addressing: larger applications should be decomposed into smaller services. With addressing, that architecture is trivial.
March 21st, 2011 by Reza Rahman
TSSJS 2011 went extremely well for us. Our talks/events went very well and the booth attendance was great. I think the TSSJS 2011 agenda, quality of content/speakers and buzz was the best in years. The new TSS editor Cameron McKenzie did an admirable job at putting everything together.Â Some of the notable speakers included James Gosling, Steve Harris (SVP Oracle), Adam Messinger (VP Oracle), Patrick Curran (JCP chair), Rod Johnson, Bill Burke, Adam Bien and Kirk Pepperdine.
I started the conference with a 5-minute lightning round presentation on Resin 4, the Java EE 6 Web Profile, our vision, history, thought leadership, values, global footprint and growing customer base. The presentation seemed to go over well with a number of existing customers and developers reaching out to us afterwards.
The first session on the first day of the conference I did was my enterprise caching talk titled â€œEffective Caching Across Enterprise Application Tiersâ€. The talk covers the different flavors of caching in the web (HTTP), presentation, application, domain, infrastructure (persistence) and resource (database) tiers using mechanisms like proxy caching (especially as supported by Resin), JSF/CDI @ApplicationScoped, @SessionScoped, @ConversationScoped, @ViewScoped, @RequestScoped scopes, passivation, EJB pooling, EJB thread-safe singletons, extended persistence contexts, JPA first (transactional) and second (shared) level caching, database connection pools, prepared statement caching, JCache as well as distributed caching APIs like Coherence, Terracotta, GigaSpaces, Infinispan, EHCache, JCS, SwarmCache and OSCache. The talk was very well attended, the Q&A was good and I got great feedback afterwards. In the evening, I participated in the “Meet the Authors” event. TSSJS gave away two copies of EJB 3 in Action (I am currently working on the second edition) and I signed both copies for the winners. I had a few engaging conversations on topics like EJB/Spring, authoring and the JCP during the course of the evening.
I started the second and busiest day of the conference with a panel titled “The Java Community Process: What’s Broken and How to Fix It”. This was a panel with Patrick Curran, James Gosling and me, moderated by Cameron McKenzie. We discussed the need for reforming the JCP, greater transparency, the Apache Harmony licensing issues, more non-Oracle spec leadership and more participation from non-vendor affiliated independents. We all agreed that many ills in the JCP can be cured through greater interest and participation from the developer community. The panel generated a great deal of interest, attendance, participation and feedback. After lunch, I gave my “A Quick Tour of the CDI Landscape” talk. The talk is a broad overview of the vibrant CDI landscape composed of implementations, supported runtimes, portable extensions and tools. I discussed Weld, CanDI, OpenWebBeans, GlassFish, JBoss AS, Resin, Geronimo, WebLogic, WebSphere, Tomcat, OpenEJB, TomEE, JOnAS, Seam 3, Apache MyFaces CODI, the ZK Framework, Arquillian, Forge, JBoss Tools, Eclipse, NetBeans and IntelliJ. The audience was great and I had some lively discussions afterwards. Later in the afternoon, I did my Java EE testing talk titled â€œTesting Java EE 6 Applications: Tools and Techniquesâ€. The talk covers end-to-end testing along the entire Java EE stack including Servlet 3, JSF 2, EJB 3.1, JPA 2, JAX-WS and JAX-RS using existing and emerging tools like JUnit, HttpUnit, HtmlUnit, Cactus, Selenium, JSFUnit, embedded containers, embedded databases, Arquillian/ShrinkWrap, Resin JUnit integration support and soapUI. The talk was well attended and I got excellent feedback for the talk. It was only somewhat surprising that folks donâ€™t realize how robust Java EE testing is with the latest release and tools like Arquillian. In the evening, I participated in the “Ask the Experts” session which also went very well.
A number of folks asked for the slides and demo code, so the materials for the talks is posted here.
A good number of folks stopped by at the Caucho booth to talk to us. We had an excellent location this year for the booth and people saw us last (almost). I think we had the best booth traffic of any conference so far. The guitar giveaway seemed to go over very well too. We can only hope that next year is just as successful!
January 12th, 2011 by alex
While part of our team was busy getting Resin to pass the needed for Web Profile compliance TCKs I had dedicated some time to updating Resin Eclipse Plugin. There were few things done for this release:
- removed dependency on Resin libraries
- changed hot deploy mechanism to using new Resin CLI interface
- added download and license request option to the Server Configuration Dialog
Read the rest of this entry »
December 21st, 2010 by alex
As I was working on the Resin’s NetBeans plug-in I started to realize that we needed to change the model we use for plugins. Previously, we packaged Resin’s classes with the plugins. That presented us with number of challenges ranging from keeping the plugins in sync with the Resin’s code to having to release the plugins every time we release a new version of Resin.
The solution was in introducing a level of indirection that came in the form an updated Resin CLI interface. Initially, the interface is extended with the commands required for the plugin to work. That included the deployment commands and web-application administration commands.
Read the rest of this entry »