I gave a talk last week at the Flex and the City conference in London, England about the leading streaming technologies that are on the market to do "push" at scale and at low-latency on a high concurrency Flex project. I focused on the scale of the challenge, the requirements that you need to look for in a solution and the risk mitigation strategies that should be adopted to ensure you end up using a technology that best meets your requirements.
Most streaming solutions (such as Kaazing, Nirvana and Lightstreamer) focus on providing high performance duplex data communication to clients built in a range of different technologies such as Silverlight, AJAX, Java and C# but not much else. Adobe's LiveCycle Data Services on the other hand also provides higher-level abstractions such as managed collections designed to minimize the plumbing effort required to integrate Flex and Java. Unfortunately LCDS currently only supports Flex clients, doesn't support some of the channel types supported by other products and doesn't provide much support on the server for monitoring and managing active sessions. For that reason comparing the leading streaming products on the market is a bit like comparing apples with oranges. It would be great if we could take the best features of each of these products and combine them together.
In my talk I suggested Adobe should seriously consider collaborating with third parties such as My-Channels and Kaazing to provide support for those vendors' channel implementations (such as Kaazing's innovative Web Socket and Nirvana's nhps protocol) in the LCDS product. Imagine how cool it would be to be able to take advantage of Flex managed collections over a reliable (and more manageable) Nirvana channel!
I'd be interested to hear your experiences with these solutions on large-scale Flex projects or indeed any other full-duplex solutions you've used.
Monday, October 25, 2010
Sunday, August 29, 2010
Is Catalyst CS5 ready for prime time?
At Rule Financial we're still using the traditional tools and workflow to create static and dynamic wireframe mockups for customer projects (i.e. Photoshop, Illustrator and Flash Pro). Since Catalyst CS5 would appear to offer significant productivity improvements over the traditional workflow, I've been spending some time checking out whether it's ready for prime time.
These are some of the issues I found:-
When you add multiple instances of the same Custom Component to the stage:-
a) the "instance" name is automatically set by Catalyst as the same as the class name (MidLevelComponent in my example). This can be confusing since you can't easily tell the difference between a reference to the class and a reference to the instance in the rest of the UI.
b) because the class name is used all the automatically generated "instance" names are identical!!! This can be confusing when you come to add an interaction. For example, the "Choose State" dropdown shows an unhelpful list of instance names, all of which are identical, making it difficult to choose the correct instance. To confuse further the instance names all look like class names since the first letter is in upper case.
Neither of these issues is a problem in a trivial demo type application but in any serious application this will be confusing. The good news is that the code generation engine assign unique instance ids for each custom component instance. The bad news is that the engine appears to use a completely different set of rules for generating the ids. Worse still the generated ids don't follow ActionScript naming conventions either. Instead they're all lower case (e.g. id="customcomponent112", id="customcomponent113").
It would be better if the generated instance names of custom components were the same as the generated ids and if they used the camel case naming convention (i.e began with a lower case letter).
Since Catalyst's vision is to improve the designer-develop workflow, encouraging designers to use the same naming conventions as developers (instance names that begin with a lowercase letter and class names that begin with a uppercase letter) might be a good idea.
Vote for this feature to be included in the next release of Flash Catalyst: http://tinyurl.com/2fxcw7z
In the current build of Catalyst CS5 the only way to implement what would be called a "mask" in Flash Pro is to create a rectangular custom component and to turn on "clip to component bounds". Unfortunately this option is only enabled for components with a manually sized bounding box. It would be nice to have support for clipping to component bounds for components with autosized bounds (which is the default for new custom components).
These are some of the issues I found:-
When you add multiple instances of the same Custom Component to the stage:-
a) the "instance" name is automatically set by Catalyst as the same as the class name (MidLevelComponent in my example). This can be confusing since you can't easily tell the difference between a reference to the class and a reference to the instance in the rest of the UI.
b) because the class name is used all the automatically generated "instance" names are identical!!! This can be confusing when you come to add an interaction. For example, the "Choose State" dropdown shows an unhelpful list of instance names, all of which are identical, making it difficult to choose the correct instance. To confuse further the instance names all look like class names since the first letter is in upper case.
Neither of these issues is a problem in a trivial demo type application but in any serious application this will be confusing. The good news is that the code generation engine assign unique instance ids for each custom component instance. The bad news is that the engine appears to use a completely different set of rules for generating the ids. Worse still the generated ids don't follow ActionScript naming conventions either. Instead they're all lower case (e.g. id="customcomponent112", id="customcomponent113").
It would be better if the generated instance names of custom components were the same as the generated ids and if they used the camel case naming convention (i.e began with a lower case letter).
Since Catalyst's vision is to improve the designer-develop workflow, encouraging designers to use the same naming conventions as developers (instance names that begin with a lowercase letter and class names that begin with a uppercase letter) might be a good idea.
Vote for this feature to be included in the next release of Flash Catalyst: http://tinyurl.com/2fxcw7z
In the current build of Catalyst CS5 the only way to implement what would be called a "mask" in Flash Pro is to create a rectangular custom component and to turn on "clip to component bounds". Unfortunately this option is only enabled for components with a manually sized bounding box. It would be nice to have support for clipping to component bounds for components with autosized bounds (which is the default for new custom components).
Monday, April 12, 2010
Don't buy Flash Builder - it's now included in CS5!
Flex Builder has always felt a bit like like Adobe's "ugly duckling" product. I'm used to licensing Flex Builder and Creative Suite separately. Yesterday I tried to buy Flash Builder 4 but failed only 'cos Adobe's UK on-line store was down for maintenance. Wow that was lucky! Today I discover that Flash Builder 4's bundled in CS5 Web Premium now. So I can upgrade my Creative Suite license and I get Flash Builder for free!
Sunday, April 04, 2010
Configuring a default application-wide channel set in Spring BlazeDS
The Spring BlazeDS Integration project provides a very elegant framework for Flex-Java development. However the project documentation (as of 1.0.3) encourages the decoupling of the BlazeDS channel configuration in the client from the channel config in the server. While in many cases this is the right thing to do, in other cases developers may prefer to define the configuration in one place (in services-config.xml) and compile the client(s) against service-config. Developers using the joint Java-Flex project support in Flash Builder, for example, (provided under the hood by Eclipse WTP) will find this approach convenient, especially in the early stages as they are learning the framework.
Unfortunately neither the Spring BlazeDS Integration documentation (as of 1.0.3) nor Adobe's LCDS documentation (as of 3.0) provides an example of how to define an application-wide default channel set in services-config.xml.
You can define a default application-wide channel in service-config.xml as follows:-
With an application-wide default channel set in services-config you can define mx:RemoteObjects, mx:Producers and mc:Consumers in the client as follows without having to specify a channel configuration explicitly. (This assumes the client is compiled against service-config.xml which has been the default in Flex/Flash Builder for projects set up with BlazeDS support since WTP support was introduced in v2.0.1).
and also allows a simpler Spring config as follows:-
Additionally BlazeDS remoting endpoints annotated as Spring BlazeDS endpoints work too without having to specify a channel explicitly as follows:
While it may not always be the right thing to do, configuring an application-wide default channel set in service-config and compiling the client against services-config significantly reduces the complexity of the Spring BlazeDS config in the simple case.
Unfortunately neither the Spring BlazeDS Integration documentation (as of 1.0.3) nor Adobe's LCDS documentation (as of 3.0) provides an example of how to define an application-wide default channel set in services-config.xml.
You can define a default application-wide channel in service-config.xml as follows:-
With an application-wide default channel set in services-config you can define mx:RemoteObjects, mx:Producers and mc:Consumers in the client as follows without having to specify a channel configuration explicitly. (This assumes the client is compiled against service-config.xml which has been the default in Flex/Flash Builder for projects set up with BlazeDS support since WTP support was introduced in v2.0.1).
and also allows a simpler Spring config as follows:-
Additionally BlazeDS remoting endpoints annotated as Spring BlazeDS endpoints work too without having to specify a channel explicitly as follows:
While it may not always be the right thing to do, configuring an application-wide default channel set in service-config and compiling the client against services-config significantly reduces the complexity of the Spring BlazeDS config in the simple case.
Thursday, February 18, 2010
Can FlexUnit4 test Parsley applications?
One of the challenges you face when adopting a dependency injection framework for Flex development is how to test classes that use features of the DI framework. For example when you use the Parsley framework a Command class is typically implemented as follows:-
Here the command dispatches a CommandCompleteEvent message when the service returns a result using Parsley's MessageDispatcher. If you want to test this implementation you need to be able to write a test class that can handle Parsley's CommandCompleteEvent message. You'd probably write the test class like this:-
and you'd probably run it in the normal way as follows:-
Sadly since the test class is not in the Parsley context the [MessageDispatcher] and [MessageHandler] decorators are ignored, the test will never run the command and the test will always fail. Additionally you probably want to be able to [Inject] the test classes dependencies rather than instantiating them programatically in the setUp method. Clearly for this work the test class needs to be a "managed" object (i.e. an object in the Parsley context). It's easy to put the test class into the context but getting FlexUnit4 to use the managed object is easier said than done. What we really need is a Parsley-aware test "runner" (like Spring Java's context-based test runner) that you could use as follows:-
but unfortunately at the time of writing there's no such Parsley test runner.
If you declare the test class in a Parsley ApplicationContext.mxml and instantiate it using Parsley's FlexContextBuilder, the Parsley [MessageDispatcher], [MessageHandler] and [Inject] decorators will work but the challenge is to get FlexUnit4 to use the "managed" instance of the test class. Unfortunately the way FlexUnit4 works at the moment you specify the class names of the test classes to FlexUnit4 and FlexUnit4 goes off and creates its own instances of the test classes. Major disconnect.
If you take a look under the hood of FlexUnit4 you'll find that the parameters to FlexUnitCore's run method can be instances as well as classes. So you might expect the following to work:-
but don't try that at home because this undocumented feature of FlexUnit4 isn't fully implemented yet and it doesn't work. That's a shame since this would make FlexUnit4 much easier to use with dependency injection frameworks.
Time to give up? The good news is that Parsley 2.2 includes support for generic "short-lived" objects (originally included to support the command pattern) that we can leverage to insert the test class into the Parsley context programatically with createDynamicContext().addObject(this). The following works:-
I guess one day we might have test runner support in Parsley and Spring ActionScript. Until then I guess we have to make do with these workarounds.
Here the command dispatches a CommandCompleteEvent message when the service returns a result using Parsley's MessageDispatcher. If you want to test this implementation you need to be able to write a test class that can handle Parsley's CommandCompleteEvent message. You'd probably write the test class like this:-
and you'd probably run it in the normal way as follows:-
Sadly since the test class is not in the Parsley context the [MessageDispatcher] and [MessageHandler] decorators are ignored, the test will never run the command and the test will always fail. Additionally you probably want to be able to [Inject] the test classes dependencies rather than instantiating them programatically in the setUp method. Clearly for this work the test class needs to be a "managed" object (i.e. an object in the Parsley context). It's easy to put the test class into the context but getting FlexUnit4 to use the managed object is easier said than done. What we really need is a Parsley-aware test "runner" (like Spring Java's context-based test runner) that you could use as follows:-
but unfortunately at the time of writing there's no such Parsley test runner.
If you declare the test class in a Parsley ApplicationContext.mxml and instantiate it using Parsley's FlexContextBuilder, the Parsley [MessageDispatcher], [MessageHandler] and [Inject] decorators will work but the challenge is to get FlexUnit4 to use the "managed" instance of the test class. Unfortunately the way FlexUnit4 works at the moment you specify the class names of the test classes to FlexUnit4 and FlexUnit4 goes off and creates its own instances of the test classes. Major disconnect.
If you take a look under the hood of FlexUnit4 you'll find that the parameters to FlexUnitCore's run method can be instances as well as classes. So you might expect the following to work:-
but don't try that at home because this undocumented feature of FlexUnit4 isn't fully implemented yet and it doesn't work. That's a shame since this would make FlexUnit4 much easier to use with dependency injection frameworks.
Time to give up? The good news is that Parsley 2.2 includes support for generic "short-lived" objects (originally included to support the command pattern) that we can leverage to insert the test class into the Parsley context programatically with createDynamicContext().addObject(this). The following works:-
I guess one day we might have test runner support in Parsley and Spring ActionScript. Until then I guess we have to make do with these workarounds.
When is a Cairngorm command not a command?
Answer: When it's a Cairngorm 3 command
Cairngorm 2, notwithstanding the architectural weaknesses it inherited from EJB2, included an implementation of a pattern that's become widely used in Flex applications; the command pattern.
In this patten a command object is used to represent a request to perform a unit of work. Typically in a Flex application command instances represent calls to the service layer on the server where each command object stores the paramenters to perform its unit of work. Since Flex's I/O framework is fully asynchronous, several requests to the same operation on the service layer may be be underway at the same time. The command pattern with a separate instance for each request provides a elegant way to manage concurrency in a Flex application. In a Cairngorm 2-based Flex application, each time you dispatch a Cairngorm event, a fresh instance of the event's corresponding command object is created by the Cairngorm framework. If the same Cairngorm event is dispatched again while the first operation is still in progress you'll end up with another instance of the same command, each one representing a specific call, each with its own specific parameters.
As a conseqeunce of this design Cairngorm 2-based applications can safely assume that each command object is specific to each request and may store state in instance variables of the command object. That’s a safe assumption since that’s how the command pattern is defined.
One of the most remarkable features of the collection of libraries that Adobe have chosen to call “Cairngorm 3” is that it doesn't provide an implementation of the command pattern. In Cairngorm 3's "integration library" (implemented as a Parsley extension), commands are now singletons that are re-used by concurrent requests. While in many cases Flex applications will ensure the serialization of requests to the same operation, in general this means that applications written for Cairngorm 2 can't be easily migrated to Cairngorm 3. Cairngorm 3 simply doesn't provide an implementation of the command pattern that's compatible with previous versions of Cairngorm. In fact it doesn’t provide an implementation of the command pattern at all. Worse still the [Command] decorator is used in Cairngorm 3 to decorate these singletons implies that these decorated classes are implementations of the command pattern when they’re not.
Parsley appears to have replicated this mistake in its most recent release (2.2) which now also supports the [Command] decorator to decorate these singletons. This decorator would have been better named [Operation] or something else that doesn’t imply that the decorated class is an implementation of the command pattern. The good news is that the latest release of Parsley does provide an implmentation of the command pattern in what it calls “short-lived commands" and “dynamic commands”. These “dynamic commands", like in Cairngorm 2, are created each time a request event is handled. Unfortunately Cairngorm 3 doesn’t currently support Parsley’s implementation of the command pattern yet so if you’re thinking of upgrading an existing Cairngorm 2 application to Cairngorm 3 I’d think twice about using Cairngorm 3 in its current state.
If you’re keen to add presentation models to an existing Cairngorm 2 application while leveraging a dependency injection framework (to get rid of all the references to Model.getInstance() etc…), then Spring ActionScript is a great choice since (ironically) it includes much better support for Cairngorm 2’s command pattern (in its optional Cairngorm 2 support library) than Cairngorm 3.
Cairngorm 2, notwithstanding the architectural weaknesses it inherited from EJB2, included an implementation of a pattern that's become widely used in Flex applications; the command pattern.
In this patten a command object is used to represent a request to perform a unit of work. Typically in a Flex application command instances represent calls to the service layer on the server where each command object stores the paramenters to perform its unit of work. Since Flex's I/O framework is fully asynchronous, several requests to the same operation on the service layer may be be underway at the same time. The command pattern with a separate instance for each request provides a elegant way to manage concurrency in a Flex application. In a Cairngorm 2-based Flex application, each time you dispatch a Cairngorm event, a fresh instance of the event's corresponding command object is created by the Cairngorm framework. If the same Cairngorm event is dispatched again while the first operation is still in progress you'll end up with another instance of the same command, each one representing a specific call, each with its own specific parameters.
As a conseqeunce of this design Cairngorm 2-based applications can safely assume that each command object is specific to each request and may store state in instance variables of the command object. That’s a safe assumption since that’s how the command pattern is defined.
One of the most remarkable features of the collection of libraries that Adobe have chosen to call “Cairngorm 3” is that it doesn't provide an implementation of the command pattern. In Cairngorm 3's "integration library" (implemented as a Parsley extension), commands are now singletons that are re-used by concurrent requests. While in many cases Flex applications will ensure the serialization of requests to the same operation, in general this means that applications written for Cairngorm 2 can't be easily migrated to Cairngorm 3. Cairngorm 3 simply doesn't provide an implementation of the command pattern that's compatible with previous versions of Cairngorm. In fact it doesn’t provide an implementation of the command pattern at all. Worse still the [Command] decorator is used in Cairngorm 3 to decorate these singletons implies that these decorated classes are implementations of the command pattern when they’re not.
Parsley appears to have replicated this mistake in its most recent release (2.2) which now also supports the [Command] decorator to decorate these singletons. This decorator would have been better named [Operation] or something else that doesn’t imply that the decorated class is an implementation of the command pattern. The good news is that the latest release of Parsley does provide an implmentation of the command pattern in what it calls “short-lived commands" and “dynamic commands”. These “dynamic commands", like in Cairngorm 2, are created each time a request event is handled. Unfortunately Cairngorm 3 doesn’t currently support Parsley’s implementation of the command pattern yet so if you’re thinking of upgrading an existing Cairngorm 2 application to Cairngorm 3 I’d think twice about using Cairngorm 3 in its current state.
If you’re keen to add presentation models to an existing Cairngorm 2 application while leveraging a dependency injection framework (to get rid of all the references to Model.getInstance() etc…), then Spring ActionScript is a great choice since (ironically) it includes much better support for Cairngorm 2’s command pattern (in its optional Cairngorm 2 support library) than Cairngorm 3.
Friday, January 29, 2010
Why isn't it ActionScript10?
One of the things that's obvious when you start building applications with Flash Builder 4 is that there's a new component architecture. One of the other things that's obvious is that the ActionScript language and the Flash foundation class library have both been changed for version 10 of the Player. For example the new version of ActionScript includes a new strongly-typed Vector datatype and the Flash foundation class library includes support for 3D transforms etc.. That's progress I guess. However applications written in the "new version" of AS3 supported by Player 10 won't work in Player 9. It's always like that with new releases of the Player and it's no different from in Java and .NET with one key difference. When Sun releases a new version of the JRE which supports a new language features or additions to the Java foundation class library they increment the version of Java. JRE5 runs Java 5, JRE6 runs Java 6 and so on. It's obvious that code written in Java 6 won't run in the JRE5. That's software release management 101, right?
It seems Adobe doesn't want to play by the same rules. The reality is that the version of the ActionScript language is closely coupled to the version of the Player. Player 10 includes a Flash VM that runs applications written in "AS10" and "AS9" and a Flash interpreter that runs applications written in "AS8" and earlier versions of the language. So why doesn't Adobe come clean and call the new version of the language "ActionSctript 10". Better still, since ActionScript's not a "scripting" language and hasn't been one for a long time now, why not just call it "Flash 10"?
It seems Adobe doesn't want to play by the same rules. The reality is that the version of the ActionScript language is closely coupled to the version of the Player. Player 10 includes a Flash VM that runs applications written in "AS10" and "AS9" and a Flash interpreter that runs applications written in "AS8" and earlier versions of the language. So why doesn't Adobe come clean and call the new version of the language "ActionSctript 10". Better still, since ActionScript's not a "scripting" language and hasn't been one for a long time now, why not just call it "Flash 10"?
Wednesday, April 15, 2009
Will Flex be the engine of economic recovery?
I'm looking forward to next week's SeedCamp, a regular London-based forum where some of the UK's most promising web technology start-ups are invited to demonstrate their ideas to venture capitalists. I'll be with CityOdds, a innovative Flex-based financial services betting website. What's interesting is that CityOdds is not the only company with a Flex-based product in the top 20. Check them out for the next big idea. Will the Flash platform be the engine of global economic recovery I wonder?
Sunday, April 12, 2009
Implementing the Presentation Model in Flex using daisy-chained ArrayCollections
ArrayCollection is perhaps the most important data type in the Flex framework as it underpins all the data-driven components such as List and DataGrid. One of the things that I don't like about ArrayCollection is that it couples two quite separate concerns, namely data storage and data presentation (i.e. sorting an filtering). In a well architected Flex application storage should be the concern of the data model and presentation should be the concern of the view (or the view's presentation model). If you use ArrayCollection to both store data and to filter and sort the data you have to choose where to put it. The trouble is wherever you choose to put it, it's in the wrong place. Obviously in simple applications this isn't a big deal but in more complex applications getting the separation of concerns right pays big dividends in developer productivity.
Imagine an application that displays streaming market prices. Your user will probably want to be able to filter the prices by product or price (or whatever) and the user may want several different views of the same data in the same application, at the same time. So what do you do? Do you implement this as several ArrayCollections in the data model, one for each view and have your Cairngorm command keep them all up-to-date each time a new price arrives? Obviously there are problems with that approach. Firstly it's a lot of work and secondly every time you add a new view you have to change your command. What that should tell you is that your commands are coupled to you views which is bad news.
Ideally what you want to solve this problem is a single underlying collection in the client-side data model whose concern is data storage and nothing else and several collections in the application's views (or presentation models), whose job is to filter and sort the underlying collection. Using this approach you'd only need to keep one collection synchronized with it's equivalent in the server-side data model (either with polling or with the more elegant LCDS DataService) and the collections in the views (or presentation models) would be filtered and sorted versions of the same underlying collection. When a new price arrives the underlying collection is updated and what you want is that all the dependent collections in the views update accordingly.
This separation of concerns between view-agnostic data in the data model and view-specific versions of the underlying data in the presentation model is the fundamental idea that underpins Martin Fowler's presentation model pattern, a pattern that's already been made popular in the Flex community by Paul Williams, Borre Wessel and David Deraedt
The good news is that it's pretty trivial to implement this sort of separation of concerns in Flex using the ListCollectionView class. ListCollectionView provides the filtering and sorting functionality of an ArrayCollection and its list property allows you to define, what is effectively, a dataProvider allowing you to link them together like a daisy chain. (Had the list property been named dataProvider by Adobe it might be more obvious that this functionality exists but that's another story.)
Anyway here's a simple example that demonstrates how to daisy-chain ListCollectionViews with an ArrayCollection like this. Clearly in a real application the underlying view-agnostic data collection would be in the data model, the view-specific sorted/filtered collections would be in the relevant presentation model and there would be no ActionScript in the view but you get the idea.
Imagine an application that displays streaming market prices. Your user will probably want to be able to filter the prices by product or price (or whatever) and the user may want several different views of the same data in the same application, at the same time. So what do you do? Do you implement this as several ArrayCollections in the data model, one for each view and have your Cairngorm command keep them all up-to-date each time a new price arrives? Obviously there are problems with that approach. Firstly it's a lot of work and secondly every time you add a new view you have to change your command. What that should tell you is that your commands are coupled to you views which is bad news.
Ideally what you want to solve this problem is a single underlying collection in the client-side data model whose concern is data storage and nothing else and several collections in the application's views (or presentation models), whose job is to filter and sort the underlying collection. Using this approach you'd only need to keep one collection synchronized with it's equivalent in the server-side data model (either with polling or with the more elegant LCDS DataService) and the collections in the views (or presentation models) would be filtered and sorted versions of the same underlying collection. When a new price arrives the underlying collection is updated and what you want is that all the dependent collections in the views update accordingly.
This separation of concerns between view-agnostic data in the data model and view-specific versions of the underlying data in the presentation model is the fundamental idea that underpins Martin Fowler's presentation model pattern, a pattern that's already been made popular in the Flex community by Paul Williams, Borre Wessel and David Deraedt
The good news is that it's pretty trivial to implement this sort of separation of concerns in Flex using the ListCollectionView class. ListCollectionView provides the filtering and sorting functionality of an ArrayCollection and its list property allows you to define, what is effectively, a dataProvider allowing you to link them together like a daisy chain. (Had the list property been named dataProvider by Adobe it might be more obvious that this functionality exists but that's another story.)
Anyway here's a simple example that demonstrates how to daisy-chain ListCollectionViews with an ArrayCollection like this. Clearly in a real application the underlying view-agnostic data collection would be in the data model, the view-specific sorted/filtered collections would be in the relevant presentation model and there would be no ActionScript in the view but you get the idea.
Saturday, December 20, 2008
Should the financial services industry be using Flex?
For the last ten years software built by banks can be broadly divided into two very distinct categories. One type is software destined to be used internally by traders, sales people and the like. This software needs to be "connected", fast and is typically what I call "push-oriented". For example internal trading systems typically need to show streaming prices that a trader can "execute" (i.e not just indicative prices). The other type is software is designed to be used externally by the bank's customers and partners.
Today internal systems in banks are typically built using rich native desktop technologies such as Java Swing or Windows Forms.NET. On the other side of the fence software built for external use by the banks' customers is typically built using traditional web technologies such as JSP/Struts/Spring MVC or ASP.NET.
For a long time now business managers in banks have been under pressure to offer better services to their customers and partners. Hedge funds, for example, are typically staffed by the brightest and best former employees of the investments banks and represent very demanding customers. As a consequence IT managers in the banks are under pressure from the business to come up with software that provides as good an experience outside the firewall as is offered to the bank's traders inside the firewall. The last five years has seen the development of increasingly sophisticated web applications, still using traditional web technologies but with the addition of AJAX to the mix, that look more and more like the bank's internal systems.
In practice this means that most banks are developing and maintaining two software systems that increasingly offer overlapping functionality, one for internal use and one for external use. The push for more service-oriented architecture in banks is one of the responses this this duplication of effort. Clearly the parts that are common between systems that largely do the same thing can be "factored out" into common services to reduce the duplication.
Nonetheless building separate user interfaces, one for internal use and one for external use, has a significant cost implication. Given that even the smallest IT projects in the financial services industry cost in the order of tens of millions of dollars (many cost much more than this), if it's possible to build software that provides both the performance and connected-ness of traditional native desktop applications so that it can be used internally while at the same time providing the "reach" of a traditional web application so that the same software can be deployed externally, there's a huge potential cost saving for financial services institutions.
Clearly RIA technologies, such as the Adobe Flash Platform, allow banks to take advantage of this opportunity. RIA represents a huge bottom line opportunity for the financial services industry worth thousands of millions of dollars. What's surprising is that, even in the current financial climate, most IT managers in the financial services industry don't appear to have identified this opportunity yet.
Instead the visionaries in the financial services industry are the business managers. One great example of a visionary is Mike Chadney who gave up his position as head of derivatives trading at an a investment bank in London to build a business providing on-line options trading on the internet.
The company that Mike founded, CityOdds Ltd., has a traditional multi-threaded real-time pricing and quoting engine at the back-end and a front-end RIA built using Flex and Adobe LCDS.
It's been a non trivial exercise to build a system that can deliver tradable quotes, process cash trades and revalue positions in real-time to thousands of connected desktops concurrently. Nonetheless I'm convinced this is the shape of things to come in the financial services industry.
Buy ADBE and register to trade for free at www.cityodds.com!
Today internal systems in banks are typically built using rich native desktop technologies such as Java Swing or Windows Forms.NET. On the other side of the fence software built for external use by the banks' customers is typically built using traditional web technologies such as JSP/Struts/Spring MVC or ASP.NET.
For a long time now business managers in banks have been under pressure to offer better services to their customers and partners. Hedge funds, for example, are typically staffed by the brightest and best former employees of the investments banks and represent very demanding customers. As a consequence IT managers in the banks are under pressure from the business to come up with software that provides as good an experience outside the firewall as is offered to the bank's traders inside the firewall. The last five years has seen the development of increasingly sophisticated web applications, still using traditional web technologies but with the addition of AJAX to the mix, that look more and more like the bank's internal systems.
In practice this means that most banks are developing and maintaining two software systems that increasingly offer overlapping functionality, one for internal use and one for external use. The push for more service-oriented architecture in banks is one of the responses this this duplication of effort. Clearly the parts that are common between systems that largely do the same thing can be "factored out" into common services to reduce the duplication.
Nonetheless building separate user interfaces, one for internal use and one for external use, has a significant cost implication. Given that even the smallest IT projects in the financial services industry cost in the order of tens of millions of dollars (many cost much more than this), if it's possible to build software that provides both the performance and connected-ness of traditional native desktop applications so that it can be used internally while at the same time providing the "reach" of a traditional web application so that the same software can be deployed externally, there's a huge potential cost saving for financial services institutions.
Clearly RIA technologies, such as the Adobe Flash Platform, allow banks to take advantage of this opportunity. RIA represents a huge bottom line opportunity for the financial services industry worth thousands of millions of dollars. What's surprising is that, even in the current financial climate, most IT managers in the financial services industry don't appear to have identified this opportunity yet.
Instead the visionaries in the financial services industry are the business managers. One great example of a visionary is Mike Chadney who gave up his position as head of derivatives trading at an a investment bank in London to build a business providing on-line options trading on the internet.
The company that Mike founded, CityOdds Ltd., has a traditional multi-threaded real-time pricing and quoting engine at the back-end and a front-end RIA built using Flex and Adobe LCDS.
It's been a non trivial exercise to build a system that can deliver tradable quotes, process cash trades and revalue positions in real-time to thousands of connected desktops concurrently. Nonetheless I'm convinced this is the shape of things to come in the financial services industry.
Buy ADBE and register to trade for free at www.cityodds.com!
Subscribe to:
Posts (Atom)