One of the biggest advantages, besides the support for the Red Hat JBoss Enterprise Middleware are the access to continuous updates and bug fixes. In previous versions, minor patches could not be applied automatically, also updates or bug fixes had to be installed manually, by changing individual configuration files and replacing Java Archives.
Since version 6.2 the Command Line Interface of the JBoss Enterprise Application Platform (EAP) contains a command to apply minor updates and patches without changing individual files manually.
The Java EE platform provides a component-based architecture, which supports modular concepts to develop applications and reuse components in different applications and environments. Dependencies to the application server specific environment can be defined in deployment descriptors, such as ejb-jar.xml for EJB components.
In the last post we used a demo application to discuss the development of maintainable Rich Web Applications with AngularJS. We introduced the most important concepts: The Model View Controller pattern and its application, the extension of HTML using directives and the routing concept to define the navigation between views.
This post explains how to integrate AngularJS into a build process based on Maven and shows how to develop automated unit tests and end-to-end tests for AngularJS applications.
The JBoss EAP6 and AS7 supports different approaches to mange server configurations. One approach is the command line interface (CLI). It is based on the De-Typed Management API and allows the execution of management operations. The CLI has support for CLI scripts with management and configuration operations that can be executed in a non-interactive mode.
In this post we want to introduce two ways of using CLI scripts to manage server configurations.
Compared to Thin Web Applications, Rich Web Applications imply a higher grade of client-side functionality and complexity as opposed to the server-side. The user interface of a typical Thin Client architecture is server-generated (per page), while rich clients are complete applications running in a web browser. This allows for user interfaces that are more user-friendly, more performant and offline-enabled. Such characteristics, offline capability in particular, are especially important for mobile applications.
As announced this is the last post of our series about clustering of the Redhat EAP 6 and JBoss AS 7. The other posts of this series were
This post will dig deeper into the clustering mechanisms of the EAP 6 and JBoss AS 7. We will show different solutions to multicast problems you will get in most cloud networks as well as some other networks. Infinispan uses JGroups to do its cluster communication. Cluster communication here means multiple things: finding other cluster nodes, providing a reliable transfer, implementing multicast communication even if there is no IP multicast available, identifying dead cluster nodes and a little bit more. In fact JGroups is able to do a lot more but Infinispan does not need all of the opportunities JGroups offers. The upcoming HornetQ version 2.3 which will be included in the EAP 6.1 will use JGroups for server discovery too. This post will explain the basic principles of JGroups and how to configure it in different network setups, especially most cloud networks.
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:
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 a software development process, there are usually multiple environments, such as development, test and production, etc. The development team usually provides the QA users a test version before acceptance and production, as illustrated below.
If, however, the application contains assumptions about the environment, this chain is broken. Therefore it is good practice, for the deployment to make no assumptions about the target environment. A good way to achieve this is that the application servers provide the environment specific configurations of the application, such as datasource configuration or integration of other Enterprise Information Systems (EIS). But this is often not so easy.
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.