Category Archives: messaging systems

Messaging Systems (like JMS, etc)

New Coherence Incubator Releases

Today is a big day.  After a few months of effort and following on from a lot of interaction with the global Coherence Community, we released the new series of updates to the Coherence Incubator, including; Coherence Common (Version 1.3), Coherence Command Pattern (Version 2.3.0), Coherence Functor Pattern (Version 1.1.0), Coherence Messaging Pattern (Version 2.3.0) and the Coherence Push Replication Pattern (Version 2.3.0).

So what’s new?  Here’s a brief breakdown…

Coherence Incubator Wide Changes

There have been several changes that are common to all projects.  These are;

1. The migration to use Apache Ivy as a dependency manager.

2. Simplification of the project Apache Ant build tasks and the ability to build (once Apache Ivy is installed) from the base of each project, simply by typing “ant”.

3. The inclusion of more examples and unit tests (based on TestNG) for most projects.

Coherence Common 1.3.0

Essentially this release of Coherence Common adds infrastructure for Coherence Messaging and the next generation of patterns (we’ll discuss this in a separate post). There are some generally useful things in here though that you might find interesting, including support for Tuples, different Ranges and more advanced (but simplified) Backing Map Listener implementations (like the DelegatingBackingMapListener).

Coherence Command Pattern 2.3.0

This release adds support for two often requested features;

1. The ability to cancel a submitted Command, and

2. The ability to submit “high priority” Commands – that will be executed in front of “regular” Commands.

Coherence Functor Pattern 1.1.0

The Functor Pattern has been updated to more closely follow the Java Concurrent Future interface and especially to support canceling submitted Functors through the use of the Future.cancel method.

Coherence Messaging Pattern 2.3.0

There have been many significant changes to the Coherence Messaging Pattern implementation.  In brief changes include;

1. Initial support for Queues (not just Topics)

2. The introduction of Subscribers (for both Queues and Topics)

3. Support for Durable and Non-Durable Subscribers (to Topics)

4. Support for Transactional Subscribers – the ability to rollback read messages (for both Queues and Topics).

Coherence Push Replication Pattern 2.3.0

Apart from upgrading to use the latest Coherence Messaging Pattern implementation, this release of the Coherence Push Replication Pattern adds support for “draining” pending updates for Publishers that have been off-line for a long period of time.  That is, instead of keeping all of the pending updates for a Publisher (ie: site) that you may be upgrading, taken down or taken offline, you can now “drain” those updates as to restart publishing from a point in time.  The “Drain” operation, together with the “Resume” and “Suspend” operations are available via the Publisher JMX MBean.

Acknowledgements

As with most Coherence Incubator releases there are a number of contributors that deserve special acknowledgement.  Of course there are some that equally deserve but be can’t publicly acknowledged (due to corporate confidentiality rules etc) and to those that fit in this category, we still say a “huge thanks” for your help.

Some people do deserve some special acknowledgement.  Those include;

a). The Coherence Incubator Team.  We’re really starting to rock guys.  Looking forward to the next release!

b). Simon Bisson.  Awesome work again mate. Thanks for your help reviewing everything.  Looking forward to the next set of releases.  They’ll certainly be the most exciting yet.

c). Sal Gambino.  Sal your thoughts, time and direction on the Messaging Pattern have been invaluable.  Looking forward to working with you on the next generation.

d). Nick Gregory.  As usual Nick, thanks for your direction on Push Replication and Hub-less Messaging.  I’m sure the next release will cover even more WAN-replication requirements.  We’re all looking forward to constructing the ultimate auto-configuring global data grid-based replication solution.

e). Andy Piper.  Thanks for your insight into both Messaging and the subtle changes to the Command Pattern.  I hope they are all that you envisioned.

Now to start on the next generation…

Cheers

— Brian

Advertisements

London Coherence SIG Winter Edition… Sold Out (almost)

If you haven’t reserved your free seat at the next London Coherence SIG on the 22nd of January (this week), you’d better do so fast.  We’re almost at capacity (again), and this time in a much bigger room.

Great to see the Coherence community continuing to grow. 😉

For more information, look here

London Coherence SIG: Winter Edition: January 22nd 2009

[Updated] We’ve finalized the next Coherence SIG in London.  It’s to occur on the 22nd of January, at the Oracle Offices, 1 South Place, 6th Floor, between 2:00pm and 6:00pm. 

Registration is available here.  To register, simply click on Book Event, log in and the rest is easy.  BTW: If you haven’t previously registered, it’s easy and free!

Here’s the agenda.

1. JRockit Real Time, Mission Control and Coherence.
This presentation will provide a technical overview of JRockit, the monitoring, management and diagnostic solution called Mission Control followed by a discussion concerning the impacts on application performance and scalability – especially around Coherence.  This is a must see for anyone that is interested in the latest JVM technologies and memory management, including deterministic garbage collection.

2. Coherence 3.5: A Sneak Preview
The Coherence 3.5 release is only a matter of months away.  In this presentation we’ll dive into some of the core improvements and new features. 

3. Coherence Incubator Update
A lot has happened in the Coherence Incubator since it release.  In this presentation we’ll dive into some of the improvements and discuss the roadmap.  If you want to influence the roadmap, this is a great time to provide feedback.

4. Coherence Push Replication: WAN Patterns Revisited
In this presentation we’ll review the Push Replication Pattern, what’s new and the 10 common WAN application architectures.  A must for anyone wanting to know “how to do WAN”.

This time we have the “larger room”, but given last SIG attendence, register early so we don’t turn anyone away!

BTW: If you have colleagues in New York, perhaps they’d be interested in attending the New York Coherence SIG.

Coherence across a WAN? Push Replication rocks!

We’ve done a lot of work in the past six months to simplify how to use and deploy Coherence Data Grids around the globe.  It’s always been possible to do these things – Coherence provides some great infrastructure like *Extend to do this – but we’ve lacked a concrete framework.  The Push Replication Pattern is making some serious in-roads to solve some of the challenges faced when designing a globally distributed Data Grid.

There are some great advantages of this pattern;

  1. We’ve provided the complete source code for it.  You can embed, change, enhance it as you like.  No restrictions.
  2. It provides support for completely asynchronous, but guaranteed in-order updates (with batching) between multiple-sites (Data Grids).
  3. It provides a completely pluggable infrastructure layer to programmatically resolve data conflicts between sites.
  4. It avoids the classic problems of other approaches, like explicitly setting up dedicated and single point of failures with Mirror Services, Gateways or routers.  The solution simply embeds in your application.
  5. It’s completely monitorable via JMX.
  6. It supports almost every type of WAN replication/synchronization scenario, including; one-to-one (uni-directional), one-to-one (multi-directional), many-to-one (uni-directional “centralized”), one-to-many (uni-directional “hub”), many-to-many (multi-directional “mesh”) architectures – with all of the above mentioned guarantees.
  7. It’s not just a theoretical pattern – it’s in production in several large projects.
  8. We’re constantly enhancing it based on customer demand and feedback.

I’ll leave you with this quote:

“The [push replication] tools are working very well.  This is very good news for us, as it allows us populate and re-populate caches across the globe in a safe and consistent way.  Thanks…”

QCon: In Finance Exchange (free event)

Ok… I’m a little late in blogging this, but on Wednesday next week (8th of October) I’ll be speaking at QCon: In Finance eXchange on the topic of Patterns for managing order books and reference data on a global basis.  Over the past few years I’ve been involved in numerous commercial projects (predominantly with tier-1 investment banks) that face the challenge of “how to manage and keep multiple globally distributed clusters containing fragmented order books and reference data (interconnected by potentially unreliable wide-area-networks) in sync (close to real time)”. Or similarly, how to keep your Disaster Recovery site(s) in sync and potentially in active+active configuration at all times.

While most of these challenges have been solved in the past using a combination of technologies (including messaging platforms, enterprise service buses, database log shipping and Oracle Coherence), several recent implementations have solely been based on Oracle Coherence, providing a simple, elegant, high-capacity and close-to-real-time solution without the need for additional servers or infrastructure.  In the talk, I’ll cover some of these new patterns.

Even if you’re not interested in this talk, there are two things I think you’ll really like about this event; a). it’s FREE and b). the speakers are well known (perhaps not me… it’s a privilege to be invited to talk!)… but people like Rod Johnson (of Spring Source) and Eric Evans (Domain Driven Design guru) and many others will be there to share some of their insights.  

If you’re in London, work in Financial Services (I hope you’re doing ok!) and have some time free, drop by.

Next London Oracle Coherence SIG – The Autumn Edition

The agenda for the next London Oracle Coherence SIG event – The Autumn Edition – on the 15th of October has now been finalized. The theme for the event is “Data Grid Patterns” and will cover some of the more advanced architectural patterns commonly seen in applications and systems using Oracle Coherence in the field.

Registration for the event is here.  Please note:  If you’re not a member of the UK OUG, you may register as a “visitor”.

Three technical talks will be presented.  The first talk will be an introduction to the Data Grid “Command Pattern” – an extension and implementation of the standard Command Pattern but applied to Oracle Coherence.  This is an extremely useful pattern that I’ve seen adopted in many projects around the world, especially in trading and workflow-based systems.  Specialized implementations of this pattern have been used to implement some very large, globally recognized and complex trading systems – so it’s not ‘research’.   It’s very fast, highly scalable (I’ll give figures at the talk), and very resilient.  In the past 18 months I’ve personally used this pattern to help several customers migrate from competitor-pushed architectures where they’ve ended requiring massive hardware spend to avoid poor performance and scalability.  For less than 100k of Java, this pattern could save you a lot of time and money.

The second talk will be an introduction to an implementation of Store and Forward Messaging on Coherence.  ie: a JMS-like implementation (about 30k of Java) that completely avoids the need for individual messaging-servers (ie: hub-based architectures) but provides all of the usual messaging requirements like ordering and guaranteed delivery.  As Nicholas Gregory says,  “it’s hub-less messaging” with the ease, scalability and high-availability of Coherence.  The talk will go into some depth about the implementation (based on the Command Pattern) and how it may be easily extended to perform all kinds of in-process, in-order, guaranteed message (or financial order) processing.  The implementation is based on my earlier ideas about modeling Messaging systems as Financial Exchanges.

The last talk will be an introduction to a new pattern for global cluster replication called the “Push Replication Publishing Pattern”.  As a simple extension to the Store and Forward Messaging Pattern, the talk will cover in detail how to configure, embed and further extend the implementation to solve a range of WAN-based replication requirements. As with the previous pattern talks, we’ll discuss about how Push Replication is being used in the field (for global reference data management and synchronization).

For each of the talks, complete source code and documentation will be made available.

Look forward to seeing you at the event.

Messaging Systems as Financial Exchanges?

Over the past few 10 months I’ve been involved in a number of challenging enterprise projects that have, to put it simply, had to replace standard asynchronous messaging architectures (like JMS) and Space-based implementations in order to stay in business (meet SLAs etc). One project in particular, where the team had invested over 11 months of their lives with a Space-based implementation, only to find that the vendor supplied architecture did not scale, lost transactions, failed to meet SLAs and ultimately did not make it into production (but that’s another story) lead me to believe that the way we understand, implement and teach scalable system design is, well…. broken (or heavily dependent on the concept of a Transaction – which aren’t as scalable as people seem to assume).

Rather than talking about “what went wrong”, which I’ll be doing over time on this blog (and at Javapolis in December 2007), I thought it might be interesting to reflect on the fundamental challenges of messaging systems, message-based architectures and how they are implemented.

Given my five or so years engineering experience with trading exchanges and automated trading systems (by no means an expert, by no means a pup, but I’ve implemented a couple) I can safely make the following observations.

  1. Most trading systems seem to scale better, have better performance and availability profiles than most implementations of JMS and Javaspaces (well the one’s I’ve worked on seem to anyway).
  2. Almost all successful trading systems seem only to make use of JMS (and Javaspaces if adopted) for system integration ie: exchange -> front office -> middle office -> back office. They are not integral to the exchange / matching processing as they tend to have very high-latencies (seconds not milliseconds). Let me make this very clear – such systems don’t use these technologies in core business logic. Personal experience suggests that even modern messaging/space-based systems have 10x to 1000x higher latencies than that typically required.
  3. Trading systems get their performance and scalability by using different architectural approaches – eg: Avoiding JEE, multi-phase transactions / multi-pass hand-shake protocols / going to disk etc and rely more on Recoverable Computing.

Why should I care? Why does this matter?

It’s pure personal frustration I guess. There’s nothing wrong is JMS, Javaspaces etc. They have a purpose and that purpose is typically integration or ordering of events.

I guess I’m routinely starting to see that the fundamental premises of stateless-ness and bus-based architectures is failing us as we demand scalability etc.

Every week I work with different projects, companies, architectures and architects, all of which face the challenge of delivering predictably scalable systems (10x to 1000x), with mandatory requirements such as high-availability (sub 1, 2 or 3 second recovery) and high-performance (1 to 2 millisecond response time)… to be delivered tomorrow – or in some cases, that afternoon!

In most circumstances I see that the aforementioned design approaches, inter-connected systems via message-buses (put “enterprise” in front of that if you like) or in some very rare cases, a space-based approach, where by messages/entries are placed in a queue/space/topic, written to disk, read out and delivered to a consumer (within a transaction) is practically ensuring all of the requirements mentioned above, simply can’t be met.

So here’s my challenge. If we are so reliant on messaging, why don’t we have implementations that operate in the same manner that we build financial exchanges? Why don’t we learn from lessons of engineering financial trading systems? On one side you have “sellers” – ie: Producers / Publishers / Writers and on the other side you have “buyers” – Consumers / Takers etc. We then simply “cross” (match) the “buyers” and “sellers”. Simple really. In fact the conditions for message delivery are much simpler than those of financial exchanges / automated trading / matching systems, but achieve the same result. Buyers buy, Sellers sell, Publishers publish and Consumers consume.

Perhaps the next JMS / Spaces implementation will be like this… but grid enabled.