Weblog for the AMIS Technology corner
Java, JEE, OAS and WebLogic Server
ADF 11g : Fancy Master Detail or how to Highlight Related Detail Records
Feb 6th
Last week I a had a rather interesting question: Is it possible to highlight related data that is in different af:table components ? Sure you can, so I decided to write a simple example application, and share the knowledge in this post Read the rest of this entry »
Create simple Java application to post JSON message to CometD Bayeux Channel using Apache HttpClient and Maven style NetBeans project
Jan 20th
The objective discussed in this article is to post messages to a CometD Bayeux Channel with a standalone Java Class – without dependencies on CometD. For example to control from Java the Slideshow introduced in the synchronized Slideshow demo application created using CometD (see previous articles Push based synchronized Slideshow demo application implemented using CometD and jQuery running on Tomcat and Publishing to CometD Bayeux Channel from inside the Oracle Database – PL/SQL based push to CometD Web Client ).
This article describes the creation of a simple Java Class leveraging Apache HttpClient to post HTTP requests (JSON messages) to a CometD Bayeux Channel. The main point is to show working code with the lest dependencies, not an optimal program (it is far from optimal). The article demonstrates how NetBeans and Maven conspire here to make the task as simple as possible. The Maven support in NetBeans allows me to simply create a new Maven style project of (arche)type Java Application.
Sharing session state between JEE web applications through WebLogic session descriptor of sharing-enabled
Jan 18th
Session state in Java Web application is associated with a single (user) browser session on the one hand and typically with a specific web application on the other (server side) hand. Session state is created and maintained in the context of a usually a single web application. However…
We ran into a situation where our web application was assuming gigantic proportions. To complex to quickly deploy or even easily build, compile and test. On closer inspection, it was quickly revealed that the application really consisted of a number of relatively independent modules – say one for each of the options in the main menu and one for the entry point – main menu, login, manage user preferences etc. From a functional point of view, the big web app monster was by and large a collection of almost individual web applications. Almost because a substantial number of navigations took place between pages in these modules. And some context data – including credentials – should be passed on these navigations. The application was developed with such information stored in the session scope – as all modules always have access to a (shared) session scope, it was thought.
We got to the point where for many reasons we would like the big fat web application to be split in one web application per module. This would allow much easier development, administration, release management etc. However, we could not resolve this issue of shared session state that should be maintained across the web applications-per-module.
We contemplated moving this shared session state to a memory grid – but the impact on the existing application would be quite substantial (although an interesting challenge: introduce a new scope for managed beans (superapplication, cross-application or application-cluster) and create an EL resolver that knows where to find beans referred to with expressions like #{super-application.bean.property}; find a way for all applications in the applicationcluster to identify a user session in the same way to ensure the bean instance associated with the current session in the current application is retrieved).
An easier solution presented itself – after briefly conferring with Mike Lehmann of Oracle’s Application Server team – in the form of WebLogic Server’s session sharing capabilities.
Using custom functions in EL expressions in JSF 1.x
Jan 17th
EL expressions are one of the main driving forces for JavaServer Faces. Most dynamic characteristics of pages and widgets are governed by EL expressions. In JSF 1.x, there are some limitations for EL expressions that can at times be a little frustrating. One of the limitations is the fact that no custom functions or operators can be used in EL expressions. Quite some time ago, I wrote this article – http://technology.amis.nl/blog/622/how-to-call-methods-from-el-expressions-pre-jsp-20-trick-for-jsps-with-jstl – to demonstrate a trick for using a Map interface implementation to access custom functionality from EL expression after all.
However, things can even be better. Rather than jumping through the somewhat elaborate hoops of implementing the Map and consructing complex EL expressions, there are two other approaches. One is to create a custom EL Resolver can configure it in the faces-config.xml. Another is discussed in this article. It involves registering custom Java methods as eligible for use in EL expressions. And that really makes life a lot easier. It allows us to create EL expressions such as:
#{cel:concat (cel:upper( bean.property), cel:max(bean2.property, bean3.property), cel:avg(bean4.list))}
or
#{cel:substr(bean.property, 1, 5)}
Implementing a Java Server Side component for jWebSocket Server for WebSocket interaction with Web Clients
Jan 14th
In a previous post – http://technology.amis.nl/blog/14949/push-based-synchronized-slideshow-web-application-implemented-using-websockets-and-jwebsocket-server-the-open-source-java-websocket-server – I discussed the implementation of the synchronized slideshow application using Web (HTML/JavaScript) clients and jWebSocket as websocket server. In an earlier article, I described the same for the Kaazing WebSocket server – http://technology.amis.nl/blog/14777/push-based-synchronized-slideshow-web-application-implemented-using-websockets-and-kaazing-websocket-gateway – and both stories are (fortunately) fairly similar. In the Kaazing article I also described a Java based Server Side ‘client’ or ‘WebSocket interaction partner’. In the jWebSocket article, that part was missing and in this article I will rectify that.
This article will describe how a Java application can integrate with jWebSocket server – in fact: start the server from within the Java code -and subsequently register listeners that intercept WebSocket communication from other interaction partners such as Web clients. The Java application can also send messages to specific clients or broadcast to all clients. This article will merely scratch the service by describing how a simple Java application interacting in this way with jWebSocket server can be created in NetBeans 7.
Finding the information to achieve this was not very easy by the way. And finding out how a stand alone Java application can connect to a stand alone (separately running) jWebSocket server is still slightly beyond my reach.
Introduction of BPEL 2.0 forEach activity – valuable loop and standard based successor to FlowN
Jan 10th
BPEL 2.0 introduced the forEach activity – similar to for [-loop] found in many programming languages. Oracle SOA Suite 11g adopted BPEL 2.0, first in run time (PS2) and later in Design Time (JDeveloper) as well (PS3 an beyond). For BPEL processes created using BPEL 2.0, forEach is a looping mechanism – similar to repeatUntil and while – and also the successor to the proprietary Oracle extension to BPEL 1.x called FlowN. In that latter capacity, forEach is the activity that enables parallelism in BPEL processes to a dynamic degree.
The well known Flow activity also supports parallelism – but only for a static number of branches, known at design time. FlowN (1.x) and forEach (2.0) add the ability to execute a scope a dynamic number of times, determined at run time. 
For example when an operation needs to be performed on multiple elements in a collection, such as all order lines in an order or all persons in a travel booking, forEach is valuable – especially when it makes sense to perform the operation on multiple elements at the same time.
Note however that parallelism in BPEL is a relative concept: a single BPEL process instance is never operated on in more than one JVM thread, so there is no real parallel execution at CPU level.
However – when asynchronous activities are ‘waiting other activities can be performed ‘in the mean time’. Examples of asynchronous activities are Wait, Receive (for a reply to the invoke of an asynchronous service, Pick (onMessage and/or onAlarm).
When the forEach scope contains such asynchronous actions, it can provide parallel execution by executing the scope for the next element in the for-loop while the previous element’s iteration is waiting for an activity to continue or complete.
Push based synchronized Slideshow demo application implemented using CometD and jQuery running on Tomcat
Jan 9th
In a string of recent articles, I have discussed downloading, installing and running demos for a number of different tools, frameworks and libraries that support push-style (web) applications in one way or another. I have looked into ‘classic’ comet with Grizzly, Atmosphere and CometD as well as ADF Active Data Service and WebLogic Pub/Sub (Bayeux) Channels. I have also looked to WebSockets with jWebSocket, again Atmosphere and CometD and also with Kaazing. I am now working on a series of articles in which I use each of these frameworks and push infrastructures to implement the same simple push-style application – to see how that goes and to compare the various implementations. The functionality I will be implementing is simple:
- through the web client (HTML 5/javaScript), a user can select an image from a list of ’slides’
- the selection of the image is communicated to the server (background WebSocket based or alternatively regular AJAX)Comet (Bayeux)/Long Poll style)
- the server informs all connected clients about the selected image through a pushed message (background WebSocket based or alternatively Comet (Bayeux)/Long Poll style); these clients all synchronize that slide selection
- a Java (server side) component can also connect to the server and listen in to image selection events as well as publish image selection messages of its own
The first article discussed the implementation using WebSockets and Kaazing Gateway (http://technology.amis.nl/blog/14777/push-based-synchronized-slideshow-web-application-implemented-using-websockets-and-kaazing-websocket-gateway). In this article, I will present an implementation using the CometD framework.
Get going with Kaazing WebSocket Gateway – HTML5 Edition – installing locally and running demos
Jan 8th
My last few articles on this blog site have all dealt with push architecture and technology in some way. This is an area that I have been investigating into quite bit recently. Part of these investigations had to be of course Kaazing, a specialized commercial offering, specifcally around WebSockets and its application in new HTML 5 application architectures.
Kaazing suggests a new way of implementing multi-tier (web) applications.
Communication between client and back end services happens over WebSockets. The Kaazing Gateway handles all WebSockets communication, turning messages from various back end services based on technologies such RSS, XMPP, JMS into WebSocket events.
Kaazing supports a variety of clients – though HTML 5 (JavaScript) web clients (including those running on mobile devices) are probably the most prominent ones.
Push-based synchronized slideshow web application – implemented using WebSockets and Kaazing WebSocket Gateway
Jan 7th
In the last few articles, I have discussed downloading, installing and running demos for a number of different tools, frameworks and libraries that support push-style (web) applications in one way or another. I have looked into ‘classic’ comet with Grizzly, Atmosphere and CometD as well as ADF Active Data Service and WebLogic Pub/Sub (Bayeux) Channels. I have also looked to WebSockets with jWebSocket, again Atmosphere and CometD and also with Kaazing. I intend to now take a closer look at some of these frameworks, by taking a simple push-style application and implementing it using each of these frameworks. The functionality I will be implementing is simple:
-
through the web client (HTML 5/javaScript), a user can select an image from a list of ’slides’
-
the selection of the image is communicated to the server (background WebSocket based or alternatively regular AJAX)Comet (Bayeux)/Long Poll style)
-
the server informs all connected clients about the selected image through a pushed message (background WebSocket based or alternatively Comet (Bayeux)/Long Poll style); these clients all synchronize that slide selection
-
a Java (server side) component can also connect to the server and listen in to image selection events as well as publish image selection messages of its own
-
bonus: it may also broadcast ‘new image available’ events to allow the web clients to update the list of images presented to the user
In this article, I will present an implementation using the Kaazing WebSocket Gateway. The application parts that I created or configured are a static HTML page with some JavaScript elements, the Kaazing gateway-config.xml file and a single Java Class. Maybe 50 lines of code in total, to get a fully operaional push style WebSocket application. Not a bad start for this series. Note: I would like to thank Matthias Wessendorf from Kaazing for his help.
