RIA (Rich Internet Applications)

Let’s assume you’ve got all your services identified, configured, etc and your endpoints defined.  No? –Before we begin to start talking about our RIA layer, let’s discuss the approach in which you’ll expose your endpoints and services that Flex will call (via AMF).

Identify business logic and the ‘heart’ of the application

The goal here is to isolate the functionality that will be exposed to other consumers.  This is a very critical step since your application will become as valuable as those services you’re exposing and the data/functionality you’re providing to the clients.

Refactoring your source code

You may need to refactor your business objects.  If the implementation isn’t based on best-practices (ie, interfaces vs concrete implementation, inheritance vs object composition, encapsulation, etc) you’re in for a long day/night.

We will be exposing our services based on our interfaces, so this is a MUST.

One of the suggestions I give to all my clients is to not just look at the trees in the forest but step back and look at the tree.

If we’re going through the pain-staking process of code refactoring (and in some instances re-designing the application) assume we’re exposing our application as services and not just for consumption of Flex or any other RIA.

Take for example the following:

• getPortfoliosInstrumentsForHedging() : List<BusinessObject>();

This method could potentially have the following responsibilities:

• getAllInstrumentIdsBySegregation(ApplicationConstants.ELECTRICITY_EXPOSURE) : HashMap<Integer, Instrument>();
• getPortfoliosByInstrumentId(Integer instrumentId) : List<Portfolios>();
• isPortfolioCandidateForFurtherHedging(Portfolio portfolio) : Boolean;

and on and on and on…

All the functionality that is contained in this method getPortfoliosInstrumentsForHedging(..) is a sure candidate for segregation according to responsibilities.  Not only that, some of these method calls NEED TO BE delegated to an intermediary manager or another layer (to further decouple) the responsibilities.

What to do:

1. Make sure you have or introduce a structure such as a services, manager, delegate, dao, etc, etc..
2. Keep your services layer thin and exposable (is that a word?)
3. Let the MANAGER handle the construction of objects and the delegation of responsibilities (such as calling other Managers, calling Formatters, DAO’s etc)
4. The DAO layer (of course only for data manipulation) –DO NOT MANAGE from here.
5. and ultimately, only pass objects upstream to the SERVICES layer fully populated, configured and ready to roll.

So, going back to our example:

1. Create a PortfolioHedge service with its corresponding interface and its implementation class in the /service folder
2. Create a PortfolioHedgeManager in the /manager folder
3. Create a PortfolioHedgeDAO in the /dao folder
4. Move all the Value Objects to the /vo folder
5. Break down the method getPortfolioInstrumentsForHedging into three different methods.
6. Create your tests, either by running Spring Mock Objects, running JUnit (only boolean results blah) or creating a simple void main method for them.

Now we’ve got a service that has gone from monolithic to actually being a topic of discussion at a bar (to impress the ladies).

NEXT

1. Configure Spring BLAZEDS with Spring
2. Discuss the application’s FLEX components that will display the objects and allow the user to act upon them
3. Asynchronous and/or AJAX functions for real-time processing
4. To paginate or not to paginate.
5. What should we consider for these applications?

Never compromise integrity

What we do and how we do it depends on what we know and who we are. What this means is simple; If you’re used to hacking and writing code ‘just’ to get the job done, chances are your team dynamic lacks substance and you’re not cut out for the long haul. However, if you’re someone who works with best practices and good discipline in mind, your work is your calling card, and your phone rings often.

No one knows it all. Whoever says he/she does, is full of shit and someone you need to stay away from. I’ve been privileged to work with some great technical people who are as humble as the day is long. These folks love what they do and in turn their bosses, peers and clients love them back.

How much Java/Flex/Oracle.. do you know?

Anyone who asks this question doesn’t know what they’re asking… Do yourself a favor and move on.

-Josh

If you want the gory details, here’s the link to Adobe. There! Now, on with the code.

Let’s start out with something simple.  Very simple.

What is an event? How do they happen?

An event is purely and simple something that happens; A click of a button, the refreshing of a page, the focus on a text field, etc, etc.

First, by listening to what’s happening.  For every action there’s a reaction.  If you want to throw a ball, you want someone to catch it.  You (the event dispatcher), the catcher (the event listener).

We can get very detailed about the event flow and how it propagates itself on the DOM of Flash/Flex.  Suffice it to say that it all starts at the Parent Node (the Application/MXML) and travels all the way down to the object (broadcasting/sending) the event.

Adding an Event

An event can be triggered in 2 ways:

1. MXML

<mx:button ... click="callFunctionOnClickEvent(event);"/>

CLICK = Event Handler

2. ACTIONSCRIPT 3

myButton.addEventHandler(MouseEvent.CLICK, myFuctionToBeCalledOnClick);

This is pure code, so we’re responsible for creating a button, giving it its properties (look and feel) and ultimately telling it what to do in case someone presses on it. As you can see, we attach the Event Listener to the button itself.

REMEMBER: In real-life scenarios, applications with multiple layers will dispatch and listen for events at different levels.  It is very important to understand the ‘bubbling‘ of said events.  We’ll get into that later…

Here’s what it looks like all put together:

Some source code for that azz!