Have you ever tried to expose a JAX-WS web service via https in JBoss FUSE? Well I tried to do that recently and ran into issues. I hope this post may help you on that task.
In general, every software solution requires a roadmap, as the basis for targeted further development and so it can be adapted to users’ needs in the coming years. No matter which niche the software serves, it always represents a form of reliable standard for its users. As a result, features are rarely removed, since this is perceived as a loss and impacts user acceptance.
Normally, the product manager is responsible for planning and marketing software. This person is the product-market expert for his or her specific area. The product manager develops a product strategy, known as the roadmap. Software releases are generally implemented in the form of a project, with the help of a project manager. Project and product managers provide each other with significant support by sharing their experiences.
In the recent posts of this series we talked about many different aspects of clustering for the JBoss AS 7 and its quality assured version EAP 6, such as:
- the basic concepts,
- managing cluster nodes in domain mode,
- scalable HA cluster topologies and
- load-balancing and failover of remote EJB clients.
Until now, there is one important thing we have not covered yet: clustering of the messaging subsystem. The EAP 6 as well as the AS 7 uses HornetQ as default messaging provider. In this post we want to give an overview about the clustering abilities of HornetQ and explain how to use the various clustering features in combination with the EAP 6 or respectively the JBoss AS 7. We implemented a simple JMS client application to demonstrate the HornetQ clustering abilities.
In the recent posts of this series about the clustering capabilities of the JBoss EAP6 and the AS7, we covered the basic concepts, managing cluster nodes in domain mode and scalable HA cluster topologies. This post will be about clustering capabilities for remote EJB clients. We will explain how to cluster EJB components and invoke them from a standalone remote client with client-side failover and load balancing.
In a recent blog-post Clustering in JBoss AS7/EAP 6 we showed how basic clustering in the new EAP 6 and JBoss AS 7 can be used. The EAP 6 is basically an AS 7 with official RedHat-support. Our cluster we described in that post was small and simple. This post will cover much more complex cluster structures, how to build them and how we can utilize the new domain-mode for our clusters. There are multiple ways to build and manage bigger JBoss cluster environments. We will describe two ways to do so: One using separating techniques also applicable to older JBoss versions and the other way using an Infinispan feature called distribution.
Scalability vs. Availability
The main challenge when building a cluster is to make it both highly available and scalable.
Availability for a cluster means: If one node fails, all the sessions on that node will be seamlessly served by another node. This can be achieved through session-replication. Session-replication is preconfigured and enabled in the
ha profile in the
domain.xml. Flat replication means that all sessions are copied to all other nodes: If you have got four nodes with 1GB memory for each of them, your cluster can only use 1GB of memory because basically all nodes store copies from each other. I. e. your cluster will not have 4*1GB=4GB memory. If you would add more nodes to this cluster you would not get more memory, you will even lose some memory due to overhead for replication. But you will get more availability and more important more network traffic due to replication overhead (all changes need to be redistributed to all other nodes). Let us call this cluster topology full-replication.
Since the first final release of jBPM5 at the beginning of 2011 a little more than one year has passed. Despite of being a final release there have been a couple of bugs and the documentation was having many deficiencies. During the last year, however, jBPM5 was quickly moving forward and many bugs were fixed and the documentation has significantly improved.
Notwithstanding the improvements there are still some points which are not covered by the documentation of which the most important one for us is the integration of jBPM5 into a Java EE6 application. In the past we had multiple Java EE 5 projects where jBPM3 could be easily integrated. This is something we want for the current amazing Java EE 6 stack. Unfortunately there is no documentation on how to achieve this goal – maybe because no one succeeded in implementing it? Therefore, we took on this challenge and found a solution which meets our requirements. In this blog post we will describe this solution. Before we start to describe our solution we want to briefly lay out the requirements of the integration of jBPM5 into a Java EE 6 application.