Unsurprisingly these views have propagated around the Internet like wildfire. For a long while there have been claims and counter claims about HTML5 signalling the death of Flash, however this is the first time that someone in Jobs’ position has taken such a firm position.

Apple won’t support Flash on its mobile devices

Jobs’ post highlighted several of the shortcomings of Flash, most of which, if not all, have remarked on by others before. The crucial thing is the unequivocal statement that Apple won’t support Flash on its mobile devices because of these. This is interesting in its own right, however reading between the lines, where does this leave Apple with respect to the other main RIA, Microsoft’s Silverlight, since many of Jobs’ criticisms of Flash apply to it too?

Two workflows, one for Apple devices and one for others?

The response from Narayen is interesting too. However I was left wondering if he had misunderstood part of the message that I believe Jobs’ was delivering. Speaking to Alan Murray, Narayen had the following to say of Jobs’ post:

He says that Apple’s restrictiveness is just going to make it “cumbersome” for developers who are trying to make products that work on many devices. They’re going to have to have “two workflows” … one for Apple devices and one for others.

Mr. Narayen poses a question to Alan Murray, asking him if the Journal would “want to have stovepipes” — or separate development processes — when it is creating content. Mr. Murray says that certainly “it would be better if you could use one set” of development tools.

Both of these statements make it clear that Narayen is, unsurprisingly, considering that developers will only ever build their applications in Flash. Given that Apple have prevented Flash from running on its mobile devices, those applications will need to be rewritten. This is true if the developer wants to write the application in Flash, but also wants it to work on the iPhone. My interpretation of Jobs’ post was that if you want to write your multiple device application just once, there’s nothing stopping you; Apple devices all support HTML. That said, there is an obvious monetary incentive to write an iPhone application natively rather than as a webapp, and they get access to more of the phones features too.

As anyone who has worked with HTML knows there are differences between the browsers which can make it difficult to create an application that looks and works and exactly as intended across all of them. However I am optimistic about this. Over the last six months I have written two relatively complex webapps targeted at an iPhone (one of them demonstrating how we could run our Caplin Trader product on a mobile device), both of which appeared to work without any tweaks on an Android phone. The main problem with is adoption of HTML5 within browsers, especially on mobile devices. Fortunately Blackberry, which has been lagging behind with its browser, is introducing a new webkit based browser.

Where do we go from here?

This is certainly not the end of the HTML5 vs Flash debate, however the statement from Jobs’ is profound. Unless there is a major change of heart from Apple anyone looking to build applications that want to run across multiple devices will need to write them once in HTML, or at least twice in any other language.

The question is how will the web development community respond? A number of people have already nailed their colours to one of the particular masts, and the flame war will inevitably continue. Have you already chosen a side? Do you believe that there is still a place for HTML and Flash to exist in harmony? Or are you still sitting on the fence?

This part will focus on LiveCycle Collaboration Service, Flash Catalyst, LiveCycle DataServices, and the relatively new LiveCycle Mosaic. We also saw an example of what a Flex financial trading application could look like.

LiveCycle Collaboration Service

The LiveCycle Collaboration Service (LCCS) is designed to allow developers to add collaboration tools like whiteboarding and chat to their applications. In Flash Builder 4 we see these new tools in the component palette.

To give us a quick look at LCCS Christophe dragged a component called the Connect session container into the existing Twitter search application, and then dragged in a couple of the built in collaboration components – Webcam (designed for webconferencing) and SimpleChat. There is a bit of work to do in the MXML view, it is necessary to declare an AdobeAuthenticator object with a username (hard-coded for the purpose of the example rather than retrieved from a text input) and set it as the authenticator for the Connect session container. The Connect session container must also be configured with a “room” URL, essentially the context for the collaboration.

When we ran the application the container authenticated with the server and the webcam started up. Of course there was nobody to collaborate with, but we saw that if the application was loaded in multiple browser windows the instances were able to chat to each other.

Summary:

• LiveCycle Collaboration Services is an SDK that provides ready-made social and collaboration components.

Flash Catalyst

Catalyst is a tool for interaction design – it allows you to turn visual designs into working user interfaces. You generally start by importing assets from Photoshop or Illustrator, however I have been able to create an extremely attractive and professional UI using MS Paint:

When the design is initially imported into Catalyst it looks like the UI for a real application (not so much in my case) but at this point it is essentially just a drawing. You can then right click on the various parts of the design and use the right-click context menu to tell Catalyst what they are – this transforms them into components like buttons, scrollbars etc.

If you run the application from Catalyst you can actually interact with the design. The buttons will click and the scrollbar will actually work – not only will the “thumb” move up and down within the track when you click the up and down buttons but it will scroll the contents of the pane up and down as well. To complete the interaction design you can create states in much the same way as you would in the design view of Flash Builder and define transitions between the states. Transitions are defined by dropping effects on to a timeline, giving control over when and how the components disappear and reappear, slide around etc, and other components such as buttons can be set to trigger the transition.

Of course what this is doing in the background is creating MXML which will eventually be handed over to the developer. The developer can then import the MXML into Flash Builder and begin writing the code behind it. Interestingly Christophe mentioned that the full round trip is not guaranteed to work, in other words if the developer tweaks the MXML in Flash Builder and gives it back to the designer there is a chance that Catalyst won’t be able to open it. Apparently the round trip is being worked on at the moment.

My UI design doesn’t really do this justice, but I suggest watching the video from about 63:16 to see this in action.

Summary:

• Catalyst allows designers to turn static assets into MXML.
• The designer can also use Catalyst to define how the interaction with the application will work.

LiveCycle DataServices

When working with data services Flex 4 introduces the concept of model driven development, which is the idea of doing as much work as possible in the data model – defining relationships between entities, validation rules etc – so that you don’t have to do the work in code. To demonstrate this we created a simple UI with a data grid and used the “Connect to data service” wizard to connect to a remote LCDS database. The wizard uses data service introspection to find out which data services are defined in the application server – in this case a database of employee details.

Connecting to the data service brings up a new view in Flash Builder called the modeller view and an accompanying new perspective called the data model perspective. This view is able to understand the database schema and display the tables with lines connecting them representing the relationships.

The key point is that changes made in the model view affect the objects and methods available in code. By switching back to the Flash view we saw that there are now objects available representing each entity in the database and these objects are populated with appropriate methods. By dragging and dropping the getAll() method on to the data grid in the UI and running the application we saw that the table was automatically filled with employee data from the remote database.

When we tried to create a second data grid to show the employees relating to an account there was initially no getEmployees() method on the account object, that method only appeared after we switched to the data model view and made the relationship between the account table and employees table bi-directional.

Summary:

• There is a new view and perspective associated with data modelling in Flash Builder 4.
• The goal is to do most of the work in the data modelling view, not code.
• Database access is done using JPA under the hood, and Flex 4 ships with Hibernate as the default JPA implementation.

A trading application

Christophe says that applications for high-volume financial trading with streaming market data have recently been increasingly built in Flex. This is something we have also noticed at Caplin, leading to the development of our StreamLink for Flex API. To demonstrate the potential in this area we saw a basic trading application consisting of a grid which was basically a benchmark console to show how performance has improved in the latest version of LCDS. For the purpose of the benchmark the server feed was set up to send 1,000 updates per second and the grid was configured to request 1,000 symbols – in other words each symbol in the grid should update approximately once per second.

After running the benchmark for one minute we saw that the client received 59,633 updates with an average latency (calculated by adding a timestamp to the update on the server and calculating the delta between the timestamp and the current time on the client) of 12 milliseconds. The update rate was then increased to 5 updates per symbol per second, and the values in the grid began to change more rapidly as expected.

This was fairly interesting but obviously it was only a very quick overview and we would have to do a lot more analysis to see how well Flex is suited to high-volume trading. The numbers demonstrated in the benchmark are good for one client (in fact probably overkill) but a more realistic problem is scalability – for example Liberator has been tested with 10,000 concurrent users receiving 100 updates per second.

The grid size used in the example is also not particularly heavy duty for a trading application and I’d be interested to know what the limits of the Flex data grid are. We are well acquainted with the challenges in this area having spent a lot of time developing grids that can hold tens of thousands of fixed income symbols while remaining fast and responsive. It would be interesting to compare the performance of the Flex DataGrid control with the Silverlight DataGrid control, particularly since Silverlight 4 boasts a “200% performance improvement” as Mike noted in his blog last week.

Christophe didn’t attempt to scroll the grid while it was updating – does it remain useable, and what is the effect on CPU? And what is the mechanism for sending messages in the other direction if the client wants to trade on a particular price in the grid?

LiveCycle Mosaic

The final product on display was LiveCycle Mosaic, which seems to be best described as a sort of container framework or shell that allows you to aggregate multiple application modules into one view, with built in layout management and communication between modules.

Sticking with the Mosaic theme, the individual modules are called tiles. The idea of this product is to avoid creating monolithic applications and start creating modules that can easily be plugged in to the Mosaic shell. Although the tiles are independent they can communicate with each other because they share the same context, this works by modules setting attributes in the shell and registering as listeners for attributes they are interested in.

The demo application was a financial research screen with tiles containing grids, charts, videos and so on. Some of the tiles featured products and enhancements that we had seen earlier in the presentation, such as LiveCycle DataServices to display data and LiveCycle Collaboration Service to chat with traders. We also saw some rich interaction – dragging a tile containing company details onto a tile containing a chart caused a new line to appear on the chart representing the company stock price.

The Mosaic shell also provides some other nice features out of the box such as the ability to load and save layouts and an iTunes cover flow style alt-tab navigator for switching between tiles.

Conclusion

I hope this recap has been useful and that it took less time to read than the 90 minutes it would take to just watch the video! We’ve been keeping an eye on Flex for a while at Caplin and it seems to be making some good strides forward, such that we now provide a fully featured Flex version of our StreamLink library for building client applications. If you’re thinking of using Flex for your front end then let us know.

Flash Builder 4: Improved interaction with data services

Christophe began by building a Twitter search application in order to showcase the improved way to communicate with data services in Flash Builder 4. Throughout the talk he did almost everything in the design view rather than writing any code, so to create the UI he just dragged in a control bar with a text area called key and search button, and a data grid to display results. It looked something like this:

To perform a search we would use the Twitter API, for example http://search.twitter.com/search.atom?q=flex4 to search for “flex4″. The problem is that in Flex Builder 3 interacting with an HTTP service like this is very dynamic – you can create a WebService object but it cannot give you any code completion options and it will not fail to compile if you try to invoke an operation that doesn’t exist.

Flash Builder 4 includes a “Connect to data service” wizard that allows various types of data service to be configured, including HTTP and LiveCycle Data Services. In the HTTP wizard it was possible to paste in the base URL and then define a list of operations – in this case just search.atom – and a list of parameters for each operation, in this case q. This generates a service proxy object that you can give a custom name, for example TwitterService, and the proxy object is populated with methods for each of the operations you defined. Our proxy object included the method TwitterService.search(String q).

The wizard also allows you to customise the return type using data service introspection. What this does is execute the operation and show you the returned XML as a tree. Christophe pointed out that the XML typically contains some boilerplate information at the top which is not important, the relevant part of a twitter search is the list of <entry> elements which represent tweets:

  <entry>
    <id>tag:search.twitter.com,2005:12256129876</id>
    <published>2010-04-16T01:23:52Z</published>
    <title>getting #vs2010 iso takes a while. Oh, well, I'll play
with #Flex4 while I wait for .net and #SL4 downloads. It's good
to have options</title>
    <updated>2010-04-16T01:23:52Z</updated>
    <twitter:lang>en</twitter:lang>
    <author>
      <name>TarasNovak (TarasNovak)</name>
      <uri>http://twitter.com/TarasNovak</uri>
    </author>
  </entry>

You can select this list of <entry> elements in the XML tree and mark it as the return type of the search operation, filtering out all the other stuff. To add even more semantic meaning, you can rename “entry” to “Tweet” – the search method on our proxy object now returns an array of Tweet objects. If you want to access properties of the Tweet in your ActionScript (including nested elements) you use the normal dot notation:

var myTweet:Tweet;

// returns "2010-04-16T01:23:52Z"
var publishedDate:String = myTweet.published;

// returns "TarasNovak (TarasNovak)"
var authorName:String = myTweet.author.name;

Hooking everything up didn’t require any code to be written. You can now right click on a button and choose “generate service call” from the context menu, then select the TwitterService.search operation and bind q to {key.text}. Using the context menus you can also bind the data grid to the return value of the TwitterService.search operation – the data grid is automatically populated with a column for each of the attributes on a Tweet.

Summary:

• You can now define data services more easily using the new wizards.
• By giving Flash Builder more information about what your data service does you can interact with it in a strongly typed way.
• It is possible to build a working Twitter search app in about 10 minutes without writing any code.

Flex 4: Improved state syntax

The next example used a similar application, only this time it displayed employee information from an LCDS data service. It was possible to automatically generate a form from the data grid of employees using the context menu. The application looked a bit like this:

The goal was to make the “full screen” button remove the data grid so that the form fills all the available space. To do this, Christophe created a new state in the design view called fullScreen, deleted the data grid and adjusted the width of the form to 100%. He then switched to the generated MXML, which now has these states:

  <mx:states>
    <mx:State name="state1" />
    <mx:State name="fullScreen" />
  </mx:states>

The key point is that states used to be unreadable because they contained so much information about how to transition into that state from the base state. Now the states themselves are kept simple and the differences are added to individual components in a “cleverer” way.

In the MXML view we saw that the data grid element now had an attribute includeIn=”state1″ because Flash Builder had worked out that it only appears in that state. The form element had an attribute left.fullScreen=”0″, indicating that when the application is in the fullScreen state it should take up the whole area. This attribute.state=value syntax is new in Flex 4.

Summary:

• After adjusting the application in design view, the generated MXML is much cleaner.
• There is a new syntax for defining how components behave in different states.

Flex 4: Improved transition syntax

In order to make the change between normal and full screen states a little more attractive we added transitions to the MXML. Note that the snippet below is pseudo-code based on my scribbled notes and the syntax may not be 100% accurate.

  <mx:transitions>
    <mx:Transition toState="fullScreen">
       <Parallel>
          <Fade target="{dataGrid}" duration="1000" />
          <Resize target="{myForm}" duration="500" startDelay="1000" />
       </Parallel>
    </mx:Transition>
 </mx:transitions>

This created a nice effect where data grid fades away and when it is fully removed the form smoothly expands to fill the gap. The startDelay attribute, which ensures that the form doesn’t start expanding until the data grid has finished fading away, is new in Flex 4.

Flex 4: Skinning

If you take a look at the code for an old “Halo” style component such as Button (which you can do, because as Christophe pointed out they are open source) you can see that the Button class defines both the behaviour and the look-and-feel of the control. This is a bad thing, because in order to change something like the graphics or layout of the control you would need to subclass the Button and edit the ActionScript. This style of control also does not work with Catalyst, which we covered later.

Flex 4 introduces a new component model called Spark which splits the behaviour away from the look and feel. Spark controls consist of an ActionScript behaviour class and an MXML skin file. According to Christophe we should be comfortable creating skins for our custom controls because we already know how to lay out a UI in MXML, and skins are no different. Ideally the skins will be created by a UX Designer in Catalyst and the code will be written in Flash Builder by a developer. Skins for a control can then be seamlessly swapped in and out by changing the new skinClass attribute for the control.

To demonstrate this we were shown a Webcam class that enabled the user to take a photo and replace the existing photo in the employee application. Initially the webcam just appeared as a box above the existing photo, but by changing the skinClass to a different skin and refreshing the page the webcam box slid out from behind the existing photo and included a shutter sound effect when the new photo was taken, which is defined in the skin.

Summary:

• Splitting the behaviour away from the UI makes sense, and supports the idea of dividing work between the developer and designer – this is really just the same concept we see in Silverlight where developers use Visual Studio and designers use Expression Blend.
• You can now change the look of the application without touching any code or affecting how it behaves.

Conclusion

We covered a lot more in the talk including improvements to LCDS, LiveCycle Collaboration Services, Catalyst and Mosaic. There was also a demo of a high-update low-latency financial trading application, which I was interested in for obvious reasons! All of this is covered in part two.

Yet the capital markets want more than a Microsoft version of Flash, and fulfilling their additional business requirements is where Silverlight 4 looks to shine.

When banks build single-dealer portals they need an application framework that leverages existing skills so that client offerings can be created quickly, deployed easily, and rolled out to clients en masse. The integration and functional requirements on application frameworks across pre-trade, deal-capture and post-trade are varied and not usually completely solved by any single vendor implementation or framework.

The ability though to empower enterprise application developers with a familiar language, good IDE and tools for rapid collaborative implementation is paramount for success. Non-functional requirements on the underlying application platform such as stability, maturity, security and performance are essential, yet often difficult to measure.

Where does Silverlight 4 fit in? The release notes may not immediately instil delight into e-commerce managers around the world as the business benefits aren’t entirely obvious. The presence of features such as right-click support for context menus may be welcomed, but it also gives the impression that other important pieces of functionality might be missing and won’t be around until Silverlight 5 or 6.  Luckily that doesn’t seem to be the case and the business credentials of the Silverlight 4 beta have generally been well received. There’s a plethora of features in the new release and not enough blog space here to cover them all, so here’s a brief description of the key business benefits for financial markets.

Pre-trade

Data aggregation

There are several Silverlight 4 enhancements for pre-trade and analytics, the first being the ability to add external HTML content into your Silverlight application. Silverlight 4’s WebBrowser control allows client-side aggregation of external web content such as market data, calendars, news and technical analysis. AJAX and Adobe Flex content such as charting applications can be easily lifted into a Silverlight app.  Interestingly, duplex interoperability between guest web pages and Silverlight is feasible, as Silverlight can invoke JavaScript methods and receive notification back from the page. A potential (yet unproven) benefit of this feature is to aid the transition period from your legacy RIA application into Silverlight, as an intermediate/hybrid approach is facilitated.

Unfortunately restrictions almost cripple this approach; the browser stack security model prevents cross-domain calls, so the WebBrowser control is limited to Out-Of-the-Browser (OOB) Silverlight deployments. If you attempt to place the control in a browser-based Silverlight instance you get a not-very-useful big blank white box. Just to navigate to a web site, the Silverlight package (XAP) must be signed by a certificate authority (XAPs with elevated trust is a new feature) otherwise the client is subject to the cross-domain policy files of the respective sites.

Persistence

Local disk access within Silverlight 4 opens up a few possibilities for providing client access to saved documents or for saving data generated within Silverlight to your client’s local hard disk.  Disk access may be employed for any persistence of application settings or for your clients to save/load business logic such as client generated structures or derivatives. Similar restrictions also apply here, only IsolatedStorage (sandboxed space) is accessible in browser-based apps. Microsoft also felt the need to restrict signed OOB apps by writing only to the “My Documents”, “My Pictures”, and “My Music” directories. In general, this feature will probably not infringe on the traditional app-server / hibernate/ database deployments for persistence, but there is potential in this new feature for client log storage or large file manipulation.

Low latency rendering

Finally, pre-trade often involves streaming indicative prices from the banks pricing engine to the client’s browser instance. Although we are never likely to see real-time topic based pub/sub messaging capabilities within Silverlight’s default controls, GUI performance plays a critical role in ensuring low latency price consummation and rendering. Exploratory testing of streaming prices across the web to the client and rendering them within the DataGrid control indicates similar performance between Silverlight 3 and 4, however judgement should be postponed until the release version. I suspect Microsoft’s claim of ‘a 200% performance improvement’ is probably centred on Storyboard animations, procedural animations and perspective 3D transforms. Nevertheless, performance has been satisfactory for foreign exchange one click trading since Silverlight 2.

Deal-Capture

Trade ticket stability

To correctly capture RFQ trades, Silverlight must efficiently render quotes and validate form-based data submitted by clients. It is critical for ticket-based workflows that trade tickets operate in a deterministic, stable fashion. One of the most interesting additions to Silverlight 4 is the ‘commanding support’ enhancement, which makes it much easier to unit test applications with complex GUI interactions, resulting in a more stable application.

Without getting too bogged down with the technical details, ‘commanding support’ helps promote implementations using the Model-View-ViewModel (M-V-VM) pattern. M-V-VM extends the standard Model-View-Presenter pattern by featuring a ViewModel, an abstraction of the View which contains the View’s state and behaviour. The idea is that a View is just a rendering of a ViewModel, and Microsoft makes it very easy to keep a View in sync with a ViewModel via ‘Data Bindings’.

So what’s so good about adding this extra layer of abstraction? ViewModel classes are easy to unit test. First hook up your unit-testing framework to the ViewModel in place of the View, then change the Model. Your ViewModel consumer can test the outcome. There’s no need to add any extra binding as ViewModels update all ViewModel consumers, and no XAML needs to be parsed or initialised for your tests. The new ‘commanding support’ comes in for the other direction; your unit-testing framework issues a command emulating something like a button click, and your framework then tests that the input is fed correctly back into the Model.

Although the M-V-VM pattern probably suits WPF better than any other language – and having some code between the XAML View and the Model seems like a good idea – it’s good to see Microsoft promoting test friendly features for enterprise apps, especially when you consider the difficulties in MVC testing in alternative RIAs.

Batch trading

Often deal capture involves assigning pre-trading allocations and importing baskets and lists from external applications such as Excel. Often clients or sales traders open a spreadsheet, tweak the sizes, allocations or portfolio constituents, and then paste the batch directly into the deal capture UI. Silverlight 4 now includes true multi-platform clipboard support, replacing Silverlight 3’s IE-only approach that didn’t work OOB. Developers can customise how Silverlight parses and copies to the clipboard content using the GetText() and SetText() methods. If running Silverlight within a browser, a new prompt warns the user the first time the clipboard is read or set. In Silverlight 4 beta it is not possible for the user to disable these prompts for more than a single session.

Field formatting

Formatting RFQ trade ticket fields such as prices, sizes and settlement dates in real-time is an everyday requirement. Silverlight 4 adds the ability to specify standard or custom string formatting via XAML. Consider a trade ticket displaying the settlement date:

<TextBox Text=”{Binding Path=SettlementDate, Mode=TwoWay, StringFormat=’MM-dd-yyyy’}”/>


Defining the formatting rule within the XAML view removes Silverlight 3’s dependency on boilerplate IValueConverter interface implementations.

Input validation

Validation of user submitted data is another key requirement, and this too is facilitated using the M-V-VM pattern without writing anything into the code-behind. Two interfaces, ‘INotifyDataErrorInfo’ and ‘IDataErrorInfo’ expose validation results into the user interface for both server-side [asynchronous] and custom client-side validation logic.

<TextBox Text="{Binding SettlementDate, Mode=TwoWay, NotifyOnValidationError=True}" ... />


Here the View Model receives client settlement date instructions and can validate them against an internal or external calendar model. On validation failure, the UI is updated with a list of errors.

Post-Trade

Straight Through Processing (STP)

In order to achieve Straight Through Processing, end-to-end automation is required from all processes in the trading cycle between the buy- and sell-side institutions. Automated deal capture, order entry in the buy-side Order Management System (OMS), and settlement and reporting integration systems eliminates human error and speeds up the clearing and settling process. A very important but little emphasised change in Silverlight 4, is the addition of the WCF net.tcp protocol. The addition markedly boosts the client-side integration potential within the buy-side, allowing the client to establish duplex asynchronous TCP/IP communication with a local server.

Across RIA technologies, HTTP communication with the buy-side OMS is hampered by cross-domain policy issues and the necessity for a web facing application server stack. TCP communication offers superior throughput and no web infrastructure is required.  

Source:“WCF net.tcp protocol in Silverlight 4″ – Tomek on Software.

The potential for TCP communication of settlement and clearing information with buy-side internal systems is promising, yet again subject to rather crippling restrictions. Most ports such as (443 or 80) are blocked unless the application is signed, so clients may need to open firewall ports for the 4502-4534 range. It’s also not possible to write a FIX implementation (e.g. OpenFix .Net) directly into your Silverlight app, as Microsoft (being Microsoft) has bound all traffic to the WCF protocol and the Microsoft WCF server-stack (e.g. IIS). Another obvious omission is the lack of transport security (e.g. SSL), which is a big deal even just for internal traffic.

Further pre- and post-trade integration capabilities are provided by Silverlight 4’s newfound access to native Component Object Model (COM) components through COM Automation classes. This means Silverlight 4 OOB applications can interoperate with local Microsoft Office application instances in the same way as Visual Basic for Applications. Examples of use include integration of Spreadsheet pricing structures with the deal capture system, feeding spreadsheet pricing models with real-time data, illustrating payment schedules using Excel graphs and spreadsheets, exporting historical trade blotters into Excel, or auto-generating emails in Outlook. Automation also provides speech support to business applications should it be required for accessibility.

Trade Confirmation Printing

For single-dealer platforms where STP is employed, buy-side clients often require hard copies of trade confirmation. Silverlight hasn’t previously included printing support, and Silverlight 4 duly adds printing capabilities for XAML trees (either the full UI view or specific controls). The Silverlight implementation is rather rudimentary, sending the printer a single paged-sized bitmap. This approach incurs rather high memory usage and slow printing. Flex is still ahead of the game here with better quality vector printing, together with the ability to override the default printing behaviour of individual UI components.

Building Applications with Silverlight 4

Brushing all functional requirements to one side, banks need to build Single Dealer Platforms cheaply and fast. The ability of a development team to consistently deliver good quality business logic is the game played out across platforms like Barx and REDIPlus, and competition is stiff.

Skills

Leveraging existing skills to deliver Single Dealer Platforms means less training, hiring of RIA experts, ramp up periods and better quality releases at project inception. But Silverlight can’t tick this box just by sharing C# with the rest of .Net; alignment between WPF and Silverlight is paramount for Silverlight to be accessible to accessible to an average .Net / WPF developer. In the past it seems Microsoft has tried to deliberately diverge WPF (or ‘XBAP’ which is WPF running in a browser) and Silverlight. Some Silverlight 3 features, such as Deep Zoom, are not in WPF, and the XAML syntax differs between the two platforms.

Silverlight 4 begins to makes some small but important changes in the right direction. Enhancements such as DependencyObject binding and WPF XAML syntax convergence helps bridge the gap:

<Button Content="Launch RFQ"/>
Silverlight (all versions)

<Button>Launch RFQ</Button>.
WPF & Silverlight 4

As a distinct subset of WPF, Silverlight will never offer the capabilities of its parent, but it always leaves you wanting more. For example, imagine a client visualisation component representing an orderbook; a WPF solution might employ the SortedDictionary Class to sort depth rows by price. Silverlight however omits this class, forcing you to writing your own efficient implementation which is time intensive and bloats the XAP.

Such analysis is perhaps fastidious; given the availability of skills in ActionScript, Silverlight offers a distinct advantage over other RIA technologies.

Development environment

A good IDE assists UI implementation, runs pre-compile checks, links to documentation and examples, profiles, debugs, and helps test the client application. In the past Single Dealer Platform development has had mixed results with WYSIWYG HTML editors or tools like Adobe FlexBuilder – most machine generated code suffers from poor readability, performance or flexibility. Silverlight 4 is paired with Visual Studio 2010, older versions of which are generally received as the best IDE for RIA development.

Visual Studio 2010 includes a major reworking for Silverlight – the design surface is fully interactive, allowing controls to be dragged and dropped into place. The properties window configures controls without you touching the XAML or writing code. Importantly, XAML generated by the design surface is readable and flexible – controls are easily manipulated by editing the composite controls, and control templates are easily created out of other controls. The generated XAML lends itself to the M-V-VM architecture, and Data Binding between a XAML View and your ViewModel can be completed automatically using the Data Source Configuration wizard or drag-and-drop data binding.

The upgrade sees a good deal of enhancements to the XAML parser – XAML mistakes are more often detected pre-compile rather than run-time, and complete Intellisense is now provided making it faster to lookup UI control properties and classes (although this was a little slow in VS2010 beta).

The debugging capabilities of Visual Studio have long been class leading, but they have improved with the upgrade – debugging of Silverlight applications’ worker threads is simpler and easier, and Microsoft have added a historical debugger called ‘Intellitrace’. Profiling support is enhanced but was not assessed at the time of writing.

Developing large Enterprise Applications

Considerable effort is expended in designing Single Dealer Platforms in a modular manner. Modular development allows better collaboration of multiple development groups and helps reduce the scope of end-to-end testing.  If the client application is designed with a ‘plug-in’ architecture, modules can be downloaded on demand. Typical business use cases involve functionality packs such as ‘Fixed Income trading’ or ‘Foreign Exchange Options’ built on top of the underlying client framework.

A major addition in Silverlight 4 is the Managed Extensibility Framework (MEF). Instead of building your own dynamic classloader, and framework for building and testing modules separately, Silverlight 4 solves the problem out-of-the-box. Your Silverlight application does not need any plumbing code; to design a pluggable widget you simply declare what attributes each class imports or exports. Using MEF, you can split a monolithic XAP into multiple XAPs that reduce the general startup time of the application, allowing on demand loading only when a MEF package is required. An added benefit is that third-parties can take your MEF packages and extend them themselves.

Deployment

Most Single Dealer Portals now need to target IE6, IE7 and Firefox, and some less regulated end-users are using IE8, Safari or Chrome. Having to target multiple platforms reduces the ability to roll out new features to your client base and platform-specific testing adds a test burden.

Silverlight 4 provides support for IE, Firefox, Safari, Chrome and out-of-browser instances. At present there are few identified platform-specific issues with Silverlight 4. The most significant differences occur with Mac drag-and-drop file handling (e.g. when dragging a Mac desktop icon onto the Silverlight window).

Client onboarding of out-of-browser applications is aided by the Silverlight 4 silent installation tool, and installation of the Silverlight plugin can be invoked by group policy administration or by Windows update. The process of deploying or running a signed Silverlight application running with elevated trust is similar to running a standard application, with no client-side certificate required. Note that AJAX will always offer a distinct advantage with its zero-footprint deployment model; proliferation of the Silverlight plug-in is often cited as an impediment to client onboarding, and the recent succession of Silverlight runtime releases will not help.

Internationalisation is a key requirement for single-dealer platforms owned by the tier 1 banks and Silverlight 4 adds support for right-to-left languages such as Arabic and Hebrew. Other languages such as Bengali, Tamil and Devanagari are now officially supported.

Finally, deployment of Single Dealer Portals onto Smartphones such as the iPhone, Android and Blackberry often arise as business requirements.  Silverlight is now the application development platform for the Windows Phone 7 series, which means no code changes need to be made to get your Silverlight application working on a Windows Phone. Silverlight will power built-in and custom applications, and Visual Studio 2010 now includes an excellent phone development environment, complete with a Windows Phone emulator. Again the new design surface allows you to drag-and-drop controls onto the phone, resizing them and rapidly design compelling UIs.

Windows Phone running Silverlight within Visual Studio 2010

The Crunch

Microsoft has delivered a surprisingly complete release, adding some new out-of-browser functionality and filling the gaps in Silverlight 3. Enhancements seem focused at the business application developer, and features like the Managed Extensibility Framework are rather nice for the capital markets. Visual Studio 2010 makes it easier than ever to design a compelling client offering; it even builds things for phones that haven’t been invented yet.

From a business point of view the conversation gets interesting when Kevin Bourne asks “do you not want to see a point where people want 100% of the choice but all out of the can with a library of applications that they can then tailor much more specifically to what they want to deliver to their clients?”

You can see the other highlight videos on the Caplin Systems You Tube Channel.

You can also download a full transcript of the event:
Buyers Market – Single Dealer Portals and Courting the Online Client

We found this interesting as we as a company have entered the world of Flex. Our product is a Flex library API, which is part of our Caplin Xaqua offering, whereas the session discussed creating a Flex GUI application. It was good to see that there are a number of powerful Flex application frameworks and that they could easily be leveraged to use our library. The talk covered frameworks, modularisation techniques and tools that have been used by Lab49 in the various Flex projects they have been involved in.

Borre Wessell of Lab49, who gave the talk, also covered their agile development process, which sounds fairly similar to ours even though they do more consultancy and we do a mix of consultancy and product work.

It was also interesting that Borre recommended using Flash Builder 4 beta as we also found that was better with its integrated unit testing and other productivity enhancements. Tool support does seem a bit lacking in some areas for Flex – whilst there is a memory profiler as part of Flash Builder 4 the performance testing seems to be very much a manual process. We prefer to have performance tests as part of our automated processes so you can catch any regressions as early as possible.

Next week I will post my followup to my previous post about streaming technologies, which will touch on the LCDS approach compared to Caplin’s methods.

There has been a big push from Adobe towards using Flex (and to a lesser extent LiveCycle Data Services – their messaging product) for trading portals and you can certainly build a flashy offering, as can be seen in the recent launch of Morgan Stanley’s Matrix.

But questions still remain over the ease of development and deployment of such a large-scale enterprise application, and though the Flex Builder seems to make this easier, digging beneath the surface can make for a frustrating experience, as Alex Vandeberg’s excellent analysis recently described.

Could Silverlight be an answer to this?

Caplin Trader is Caplin’s toolkit and platform for building trading portals, in production at a number of banks. The client-side framework is built in Ajax (the browser’s native presentation technology), though we allow and encourage the embedding of content in any RIA techology – be that HTML, Ajax, Flash/Flex, Silverlight (and even Java Applets if you are still that way inclined!). I believe that this approach encourages building a best-of-breed portal: You use Caplin’s APIs and the browser’s native language for the container and most pricing and trading components, but where appropriate (for example rich media, 3D, vector graphics) you have the freedom to seamlessly embed a more suitable technology such as Flex or Silverlight. In addition you can leverage existing web content with minimal effort. The alternative approach of using one of these proprietary plugins for the container makes it very hard to embed anything else within the container.

Caplin Trader is built on top of the Caplin Platform – a generic financial client-connectivity, web messaging and trading layer. Caplin have always provided client APIs for a variety of languages (Java, .Net, Ajax, C++ currently) to allow people to either integrate with existing applications or build their own from scratch (usually where Caplin Trader isn’t suitable or desired).

What is interesting is the growing demand for Silverlight as a client-side target for Caplin’s technology. I know of at least 3 large investment banks that are kicking off projects targetted at Silverlight. Whilst not yet cross-asset single dealer portals on the same scale as Matrix (or most of the Caplin Trader projects), it’s interesting that they’ve bitten the bullet despite lingering doubts over adoption rates and install base (<30% as of today at riastats.com), though Microsoft would like you to think otherwise!

If it can gain momentum, Silverlight will quickly eclipse (no pun intended) Flex as a developers’ platform of choice, at least in terms of true software engineering tools and developer productivity. Whilst we’ve done a lot of work to build developer tools and structure our APIs to ‘tame’ Ajax and JavaScript, neither Ajax or Flex/ActionScript will catch up with C# any time soon when it comes to more advanced activities such as IDEs with truly integrated build/test/debug/profile tools and refactoring, not to mention the number of existing C# developers that could transition to Silverlight easily.

You can already use the Caplin Platform and Caplin Trader with Silverlight by creating a bridge to our JavaScript StreamLink for Browsers library. We’ve recently built a prototype native Silverlight library, with an identical API to our existing C#/.Net offering, and we expect to be able to release a full version in July. On top of our Caplin Trader subsystems this could be used as a powerful front-end for those who choose to build single dealer portals with it and it will certainly be interesting to see who jumps first…