Today CME Group released an official statement about their use of Virgo. This is posted under the "Virgo Powered" section of the Virgo home page, but the full text is also reproduced below.
I'm delighted both that CME Group are using Virgo and that such a large player in the finance area was happy to go public.
CME Group, formerly known as
Chicago Mercantile Exchange Holdings Inc., was founded in 1898 and
operates the CME, CBOT, NYMEX, and COMEX regulatory exchanges
worldwide. It is the world’s leading derivatives marketplace with 2570
full time employees and a market capitalisation of over $15B.
CME Group kindly released the following information in January 2012.
At CME Group, the goals for our project were to use and create a platform
that would be easy to maintain, expand and reuse. Our applications are of
various sizes and complexities, but there are certain aspects that are
common, which was the reason to find a very modular solution. In
particular, our current efforts are in Surveillance tools which allow
monitoring the state of the exchange and the market.
We started using Virgo 2.0.1 during a “proof of concept” in November of
2010 and spent 2011 working closely with them to build the application.
Today we use version 3.0.1. with 48 service bundles and 20 web bundles.
These services range from simple DAO type services, through authorization
and authentication, web services, and even distributed caching. All web
bundles use snaps and customized apache tiles views.
What Virgo and OSGi provides for us is complete modularity and
plug-and-play capability. This enables us to work more intelligently with
other teams who need to build bundles independently of us where the strong
isolation of services and APIs allows for a clear separation of control.
We have created a core set of services that will be a platform for future
projects across CME Group and are already actively building two projects
on top of that platform. Having Virgo bundled with Apache’s Tomcat also
helped in deciding which container to use as our projects are mostly web
applications.
Thursday, January 19, 2012
Thursday, January 05, 2012
Virgo Nano Technology
The first milestone of Virgo 3.5.0 is available. It introduces two significant new features: p2 support (covered previously) and a new Virgo distribution known as nano. (Apologies for the pun in the blog title - it was too hard to resist.)
Nano is essentially a cut-down version of Virgo which starts up really fast and has a single (kernel) region. It is intended for simpler scenarios where you don't need to isolate applications from each other or from the kernel.
The current nano distribution includes Gemini Web and so is a fully-functional OSGi web server which starts in about 3 seconds (compared to Virgo Tomcat/Jetty Server which take about 9-10 seconds). However, we plan to factor out Gemini Web so that nano becomes a small/fast subset of the Virgo kernel. We will then provide a separate distribution which adds Gemini Web to nano, as in the first milestone.
As well as introducing nano, the milestone re-bases the kernel and the Tomcat/Jetty servers on nano. Initial provisioning via p2, with full instructions in the user guide, is provided for all distributions in addition to the familiar ZIP file installs (the ZIP contents are now constructed using p2 at build time). All distributions use a regular Equinox directory layout and launcher which will simplify third party tooling integration (e.g. Pax Exam). A short-term downside is that we need to update the Virgo IDE tooling to work with Virgo 3.5.0.
The current nano distribution can also dynamically provision content via p2 which is particularly useful for automated or cloud deployments. (We tried to implement this for the multi-region kernel and Tomcat/Jetty servers, but that was beyond the scope of the current p2 design, so we've put it on hold.)
There is also a nice engineering side-effect of the introduction of nano: we are starting to refactor the kernel — by far the most complex Virgo component — and move the more general, region-agnostic features down into nano.
The following picture summarises the distributions we anticipate in Virgo 3.5.0:
As well as being the fruit of several months of effort, this first milestone kicks off Virgo development in 2012 in a very exciting way.
Nano is essentially a cut-down version of Virgo which starts up really fast and has a single (kernel) region. It is intended for simpler scenarios where you don't need to isolate applications from each other or from the kernel.
The current nano distribution includes Gemini Web and so is a fully-functional OSGi web server which starts in about 3 seconds (compared to Virgo Tomcat/Jetty Server which take about 9-10 seconds). However, we plan to factor out Gemini Web so that nano becomes a small/fast subset of the Virgo kernel. We will then provide a separate distribution which adds Gemini Web to nano, as in the first milestone.
As well as introducing nano, the milestone re-bases the kernel and the Tomcat/Jetty servers on nano. Initial provisioning via p2, with full instructions in the user guide, is provided for all distributions in addition to the familiar ZIP file installs (the ZIP contents are now constructed using p2 at build time). All distributions use a regular Equinox directory layout and launcher which will simplify third party tooling integration (e.g. Pax Exam). A short-term downside is that we need to update the Virgo IDE tooling to work with Virgo 3.5.0.
The current nano distribution can also dynamically provision content via p2 which is particularly useful for automated or cloud deployments. (We tried to implement this for the multi-region kernel and Tomcat/Jetty servers, but that was beyond the scope of the current p2 design, so we've put it on hold.)
There is also a nice engineering side-effect of the introduction of nano: we are starting to refactor the kernel — by far the most complex Virgo component — and move the more general, region-agnostic features down into nano.
The following picture summarises the distributions we anticipate in Virgo 3.5.0:
