EJB 3.1 and TimerService challenges Quartz Framework

A significant number of enterprise applications have some sort of time-driven requirements. For a long time the spec has ignored such needs, forcing developers to find non-standard solutions like Quartz or Flux. EJB 2.1 introduced the Timer Service, consisting of a service provided by the container that allows EJBs to have timer callbacks being invoked at specified times. Moreover, such invocations can be done in a transactional context.

Even though the Timer Service was able to bridge some of the necessities, there were considerable limitations, like for example:

• All timers have to be created programatically.
• Lack of flexibility in the scheduling of timers.
• Missing support for the use of timers in environments with multiple JVMs like clustering.

With EJB 3.1 there are two ways to create timers:

• Programatically, using the already existing TimerService interfaces. This interface has been greatly enhanced in order to provide more flexibility while creating timers.
• Declaratively, using annotations or the deployment descriptor. This way a timer can be statically defined so it is automatically created during application startup.

A method can be annotated with more than one timer, like shown below, where two timers are defined for the method mealTime, one which will expire every day at 1pm and another expiring at 8pm.

@Stateless
public class MealEJB { 

    @Schedules(
    {    @Schedule(hour="13"),
         @Schedule(hour="20")
    }
    public void mealTime(Timer timer) { (...) }

}

In terms of timer scheduling there were major improvements. The callback schedule can be expressed using a calendar-based syntax modeled after the UNIX cron. There are eight attributes which can be used in such expressions:

Attribute	Allowable Values	Example
second	[0, 59]	second = “10″
minute	[0, 59]	minute = “30″
hour	[0, 23]	hour = “10″
dayOfMonth	- [1, 31] – day of the month  - Last – last day of the month - -[1, 7] – number of days before end of month - {“1st”, “2nd”, “3rd”, “4th”, “5th”, …, “Last”} {“Sun”, “Mon”, “Tue”, “Wed”, “Thu”, “Fri”, “Sat”}- identifies a single occurrence of a day of the month	dayOfMonth = “3″  dayOfMonth = “Last” dayOfMonth = “-5″ dayOfMonth = “1st Tue”
month	- [1, 12] – month of the year  - {“Jan”, “Feb”, “Mar”, “Apr”, “May”, “Jun”, “Jul”, “Aug”, “Sep”, “Oct”, “Nov”, “Dec”}- month name	month = “7″  month = “Jan”
dayOfWeek	- [0, 7]- day of the week where both 0 and 7 refer to Sunday  - {“Sun”, “Mon”, “Tue”, “Wed”, “Thu”, “Fri”, “Sat”}- day’s name	dayOfWeek = “5″  dayOfWeek = “Wed”
year	Four digit calendar year	year = “1978″
timezone	Id of the related timezone	timezone = “America/New_York”

The values provided for each attribute can be expressed in different forms
Note any of the attributes support the cron-style “*” wildcard to represent all values, a comma separated list (such as “Jan, Feb, Mar” for the month attribute) or a dash-separated range (such as “Mon-Fri” for the day of week attribute).

There are two different types of @Schedule:

1. Persistent – specified by persistent=true in @Schedule annotation
   This is the default type of any @Schedule.
2. Non-persistent – specified by persistene=false in @Schedule annotation

Both persistent and non-persistent timers can exist simultaneously, and the persistent and non-persistent configurations are not mutually exclusive. Your application might use both persistent and non-persistent timers.

Use persistent timers when the timer must persist through server shutdowns and restarts. Otherwise, use non-persistent timers when a server shutdown must cancel the timer.

When a persistent timer does not fire because the server is unavailable, then the missed attempt is recovered when the server restarts. When a non-persistent timer does not fire because the server is unavailable, the missed attempt is not recovered, because the server shutdown cancels the non-persistent timer.

Rerferences:

O'Reilly Enterprise JavaBeans 3.1

Flex 4: Asynchronous Token

Flex is all about Event Driven Development

Consider an enterprise application in which a user can place purchase orders for some

parts and request price quotes from various suppliers. In this case, the user may click

several buttons, resulting in server-side calls to one or more destinations. On each click

event of the button, a RemoteObject sends a new request to the server.

Here’s the million-dollar question: how can the application code map arriving result

objects back to the initial requesters if they can come back to the client in an arbitrary

order?.

Ans: Asynchronous Token Pattern

The goal of the Asynchronous Token pattern is to properly route the processing on the

client in response to the data arriving asynchronously from the server.

OK, How do i design using it:

Flash 4 Builder can generate CallResponders for your service calls and what you all have

to do is write your business logic.

<fx:Script>

<![CDATA[

import mx.controls.Alert;

import mx.rpc.events.ResultEvent;

protected function getHelloString():void

{

getHelloStringResult.token = excelDbService.getHelloString();

}

protected function getHelloStringResult_resultHandler(event:ResultEvent):void

{

Alert.show( getHelloStringResult.lastResult);

}

]]>

</fx:Script>

<fx:Declarations>

<s:CallResponder id=”getHelloStringResult” result=”getHelloStringResult_resultHandler(event)”/>

<services:ExcelDbService id=”excelDbService” fault=”Alert.show(event.fault.faultString + ‘\n’ + event.fault.faultDetail)” showBusyCursor=”true”/>

</fx:Declarations>

reference: Enterprise Development with Flex and Flash 4 tutorials

Java Code findings DashBoard using Flex on AppEngine

Experience the Java Architectural/Code findings at glance.
This Application uses simple Flex XML features and Flex Charts
Feel the Experience at: demo

Export Excel data into Google’s BigTable using JPA, Flex

This is a Simple Flex Application that manages your Excel data and exports into Google’s BigTable on Google’s App Engine.

Presentation Layer: Flex 4

Communication Layer: AMF Blazeds 4

Integration Layer: Spring 3

Persistence Layer: JPA

Infrastructure:  Google’s App Engine

Click here to experience the demo

Flex 4

Familiar with Flex? Make the most of what’s new in Flash Builder 4 and Flex 4.

A Flex 4 application is just a Flash movie (SWF), which lives inside a web

page loaded by a web browser that has Flash 10 installed.

Flex 4 applications typically use three XML namespaces, since Flex

4 is introducing an entirely new set of components (the Spark components).

The old school Halo components are what were used in Flex 1-3.

They have the mx prefix by convention, since that’s what was used in

Flex 1 through 3. The namespace for the Halo components is

library://ns.adobe.com/flex/halo. You still need to use the Halo components

where there are no Spark equivalents yet, such as DataGrid.

The new Spark components use, by convention, an s prefix for the

new namespace of library://ns.adobe.com/flex/spark. These components

have “Design in Mind,” which will allow designers and developers

to work together in a more harmonious way.

The fx prefix is for the core Flex namespace (http://ns.adobe.com/

mxml/2009). This is for things like declarations, metadata, and script

blocks—basically, for nonvisual language elements.

Flash Builder 4

Data-centric development with Flash Builder 4

Flash Builder 4 beta has built-in support for services created with ColdFusion, PHP, and Java. Other kinds of services can be used as SOAP web services or HTTP services.

In Flash Builder 4 beta, the new Data/Services panel is the central location for managing and interacting with all of the servers and services used in your application.

Select a DataGrid (grouped under Data Controls in the Components panel) and drag it out onto the page. You’ll notice that the grid isn’t bound to any data; if you run the application now it will just be an empty grid                         with three columns. To have the grid display data that comes back from one of your service operations, simply drag the operation from the Data/Services panel and drop it on the grid.

Flex 4

• Differences between Flex 3 SDK and Flex 4 SDK
• Introducing skinning in Flex 4 beta
• Spark layouts with Flex 4 beta

References: flexblog.com, adobe, Hello! Flex 4.

A Flex 4 application is just a Flash movie (SWF), which lives inside a webpage loaded by a web browser that has Flash 10 installed.

Grails and Flex nothing simple than this for Rich Web App on GAE

Most of us know by now just how easy it is to write Flex applications backed by Java and Java using GraniteDS. Adobe have done a lot of work to ensure that integration with ColdFusion is seamless. It’s very impressive.

Browsing through the Grails site, I noticed they have a plugin for Flex so I figured I’d try it out.

Following the instructions, I installed the plugin (grails install-plugin gdsflex) which took a fair while to fetch the plugin from the codehaus.org site and build it and install it into my project. Then I created a service class – a regular Groovy class – with just this one additional line:

static expose = [ 'flex-remoting' ]

It had a method, hello(), that returned a string.

Then I put my main.mxml file in the web-app directory of my Grails project with these lines inside the mx:Application tag:

<mx:RemoteObject id=“ro” destination=“homeService”/>

<mx:Button label=“get Address!” click=“ro.homeAddress()”/>
<mx:TextInput text=“{ro.homeAddress.lastResult}”/>

You don’t need to build the project. You don’t need to set any paths in FlexBuilder. Just create the MXML file.

Then I hit the MXML file in my Grails app:

what i had to code is:

package app

class HomeService {

static expose = ['flex-remoting']

boolean transactional = true

def hello() {

return “Hello World!!!”

}

def getHomeAddress() {

return “3924 Hillstead ln”

}

def getHomePhone(){

return 3344433

}

}

what i had to type :

>grails create-app home

>grails install-plugin gdsflex

>grails create-service app.Home

>grails run-app

>grails install-plugin app-engine

>grails app-engine package

>%APPENGINE_HOME%/bin/appcfg.cmd update ./target/war

>grails app-engine deploy

reference: corfield.org, http://grails.org/Flex+Plugin

Ride your RIA Vehicle using Google App Engine in a Cloud

Know your Engine:

GAE is running Java 6. However, there are  number of limitations that have been imposed to constrain Java to fit the GAE model. GAE Java is based on the Java 2.4 Servlet API:

• Once a request is sent to the client no further processing can be done. This includes data streaming.
• A request will be terminated if it has taken around 30 seconds without completing. At this point an exception is thrown. If not caught a 500 error is returned to the user.

Moving up the stack are several sandbox restrictions:

• Applications can not write to the file system and must use the App Engine datastore instead.
• Applications may not open sockets
• Applications can not create their own threads or use related utilities such as timer.

java.lang.System has been restricted as follows:

• exit(), gc(), runFinalization(), and runFinalizersOnExit() do nothing.
• JNI access is not allowed.

Choose your RIA Vehicle(FLEX/BLAZEDS/JAVA):

• Eclipse – http://www.eclipse.org/galileo/ (FREE)
• Google App Engine Developer Account – http://appengine.google.com/ (FREE)
• Install the Google App Engine Java plug-in for Eclipse – http://code.google.com/appengine/docs/java/tools/eclipse.html (FREE)
• Flex Builder plug-in for Eclipse – http://www.adobe.com/products/flex/features/flex_builder/ ($$$)
• The BlazeDS Binary Distribution- http://opensource.adobe.com/wiki/display/blazeds/Release+Builds (FREE)

Aravind Kopparthi.