Software for the Financial Industry
The epitome of technological advancements could not be more evident that in the Financial industry. Those of us who have spent time consulting and/or migrating/modernizing legacy systems have seen the good and the bad. However, whether you’re writing software that moves Struts to Spring, Cairngorm to Parsley or even Oracle to Netezza and vice-versa one thing is for sure; You need patience and the ability to dig into your bag of tricks to get the job done.
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:
- Make sure you have or introduce a structure such as a services, manager, delegate, dao, etc, etc..
- Keep your services layer thin and exposable (is that a word?)
- Let the MANAGER handle the construction of objects and the delegation of responsibilities (such as calling other Managers, calling Formatters, DAO’s etc)
- The DAO layer (of course only for data manipulation) –DO NOT MANAGE from here.
- and ultimately, only pass objects upstream to the SERVICES layer fully populated, configured and ready to roll.
So, going back to our example:
- Create a PortfolioHedge service with its corresponding interface and its implementation class in the /service folder
- Create a PortfolioHedgeManager in the /manager folder
- Create a PortfolioHedgeDAO in the /dao folder
- Move all the Value Objects to the /vo folder
- Break down the method getPortfolioInstrumentsForHedging into three different methods.
- 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
- Configure Spring BLAZEDS with Spring
- Discuss the application’s FLEX components that will display the objects and allow the user to act upon them
- Asynchronous and/or AJAX functions for real-time processing
- To paginate or not to paginate.
- What should we consider for these applications?
Leave a Comment