Monthly Archives: April 2009

Oracle Open World Japan 2009: Done.

Well I’ve finally made it back to London (after 15hrs in a flying Air France can). It was certainly an interesting, enjoyable and busy trip to Tokyo.  The local teams and myself managed to pack a lot of meetings into just a few days!  As usual, all perfectly organized and synchronized – with multiple translators.  In all I gave over 7 hours of presentations about various Oracle Fusion Middleware and various Oracle Coherence concepts, everything from;

i). A keynote about Data Grid Design Patterns (was at the Japan Java Users Group. Had about 400 people in the talk I think),

ii). The concept of Application Grids – a new paradigm to help companies consolidate existing application servers (including open source) to make better use of existing hardware and proactively monitor / manage them. The whole point being that you may not need to make the “big bang” to Virtualized Infrastructure or Clouds if we all simply manage our existing architecture better.  For example; instead of provisioning applications individually (on dedicated or virtualized hardware), why not share the application on read hardware.  It turns out that doing this “first” before virtualizing (or thinking about cloud) may yield better benefits than attempting to move to virtualization / clouds immediately.  Some cost/benefit analysis is showing it’s cheaper and less risky to do so.

iii). An Introduction to Coherence – basically one of the standard Coherence introductions to developers and architects, and

iv). Optimizing existing SOA applications using the Application Grid and Data Grid concepts.

Of course there where a bunch of other talks about Oracle Coherence (like the new Toplink Grid JPA implementation and lab sessions), but it was hard to keep track.  It was great to see so many people talking about “Coherence”.

Here are a few photos of the event;  It’s so cool seeing everything translated.

The building in which Oracle Open World Japan was held was both massive and impressive. Perfectly quiet. Awesome acoustics.  The directions where easy… The conference was in the Glass Building.  The building was called “The Glass Building”.  Perfect for non-Japanese-speakers like myself!

Glass BUilding

Glass Building

This was the directions board for the Toplink Grid (ie: Coherence JPA implementation) presentation and hands-on-laboratory session.

Toplink Grid Session

Toplink Grid Session

 It was pretty cool to see Oracle Coherence stuff in Japanese.  Of course, I couldn’t understand a word of it.  Perhaps next time ;)

Oracle Coherence (in Japanese)

Oracle Coherence (in Japanese)

I managed to find the Oracle Coherence Demo Booth (during the quiet period while talks where on… actually in the last hour of the last day) 

Oracle Coherence Demo Booth

Oracle Coherence Demo Booth

And lastly, a photo of “Wendy Wendy” (no I don’t have a typing problem!).  From what I can tell, she’s the Oracle Japan “mascot”. She drew a big crowd.

Wendy Wendy

Wendy Wendy

London Coherence SIG – Spring Edition: Thursday May 14th.

[It's nothing to really do with the "Spring Framework", it's about the season]

Here’s the current agenda for the next London Coherence SIG event, to occur on the 14th of May, from 2pm to 6pm at the Oracle London Office.

[Updated] You can now register using the UKOUG Coherence SIG site  here

1. Integration: Oracle Coherence and Platform Symphony (by Platform Computing)
In this talk Platform Computing outline the use, deployment and management of Oracle Coherence on the Platform Symphony Grid Product. Included in the presentation is a demonstration of static and dynamic Coherence Server management, together with a dynamic integration with Microsoft Excel (via the Coherence .NET client)

2. Portable Objects: Best Practices for Seamless Java, .NET and C++ Interoperability (by Aleksandar Seovic – Coherence.NET Engineer)
Portable Object Format (POF) is an important technology used within Oracle Coherence. It’s central to the optimal Binary represent of objects and the seamless integration between Java, .NET and C++ clients. While it’s been available for some time, those using the Java version of Coherence don’t often use it.

In this session you will learn best practices on how to use POF within your cross-platform applications, as well as why you should use POF as a
serialization format even in pure Java applications. We will also cover new POF-related features introduced in Coherence 3.5, such as POF extractor and
POF updater, and show you how you can leverage them in order to a). improve the performance of your applications, b). reduce the amount of network traffic and b). reduce your memory footprint within the grid.

About the speaker: Aleksander was one of the core engineers that developed the initial version of Coherence .NET and the first Portable Object implementations. He’s a very talented and experienced .NET developer. He was also one of the founding engineers of Spring.NET, the .NET implementation of the Spring Framework. (ok… The Spring Framework may be mentioned)

If you have any Coherence .NET, .NET, Spring.NET or POF interests, he’s a must see speaker. He’ll be traveling from the United States for this talk.

3. Product Update: Coherence 3.5 (by Gene Gleyzer – Head of Coherence Engineering)
With the release of Coherence 3.5 just around the corner, come along to here Gene dive into some of the cool new features.

About the speaker: Gene was a founding engineer of Coherence. He probably knows more about Coherence than anyone else, and how to build massively scalable high-performance systems. He’s a must see speaker if you have any detailed questions about Coherence. He’ll be traveling from the Coherence Engineering team in the United States for this talk.

4. Community Update: Coherence Incubator
As usual, we’re going to be doing a Coherence Incubator update. We’ll be covering some of the changes together with a new pattern. Be there to find out.

Cheers

– Brian (from Tokyo)

Raw Power… summary of Coherence NYSIG

If you haven’t read it already, Craig has written an interesting summary of the Coherence NYSIG.

While I wasn’t able to attend, I did hear that the talks where well received, especially Patrick’s on Coherence Portable Object Format, or POF as we call it.  Basically this presentation was an extension to the one we delivered at the London and NY SIGs a while back, but with a lot more details about evolving objects and new stuff in Coherence 3.5 (we’ll be covering the new stuff at the next London SIG).  It was great to cover the new ground, especially how to design backward and forward compatible applications that don’t require a cluster restart.  Awesome work Patrick on the new slides and design guidelines.

What I didn’t know however, and what I think is completely hilarious, is that a few “competitors” tried to “sneak” people into the SIG.  What gives?  I mean, when some (not all) competitors seemingly spend so much time “rubbishing” Coherence, yet they then try to attend the SIGs, I really wonder what’s agenda? Oh… and the best tactic is when they send “partners” along to attend.  We certainly never saw that one coming.

I guess they do have a special interest in Coherence :P, so perhaps they should attend? Personally I think Craig’s comment about this is spot on; [this should be fine but you must be fine with this] “we are happy to come to meet your customers at your next event”… the most important thing here being “next event”.  Err…. please let us know when the next non-sales event is occurring so we can send the “Oracle Bus” (ie: collection of multi-domain experts) around to take notes.

Coherence in Japan

Well I’ve finally made it back to Japan (and managed to wake up after some back-to-back jetlag fun; New York, Boston, London and Tokyo in 10 days has been an interesting experiment in sleep management).  Unlike last visit, which was primarly about training and Coherence workshops, this time I’m here for a series of conference presentations and new customer visits.  Like Coherence in other parts of the world, adoption is really rocking here.

As far as my schedule goes, tomorrow (Tuesday) I’m talking at the Japan Java Users Group (in Tokyo) about Data Grid Patterns with Coherence. It’s a similar to the presentation that I gave in QCon early this year, but with more diagrams.  On Wednesday and Thursday I’ll be talking at Oracle Open World Japan (also in Tokyo), not only about Coherence but also about Scaling SOA (without having to rebuild everything).

The most exciting task for the week however is to start organizing the Coherence SIG for Japan, well Tokyo at least.  When Simon Bisson and I thought up and delivered the first Coherence SIG nearly two years ago, we certainly didn’t conceive that we’d be running them globally!

Speaking of Coherence SIGs, the next London one will be on the 14th of May – the two year anniversary.  I’ll be releasing the agenda and registration details in the coming days.

Coherence Push Replication

Coherence itself has always had the capability to “run across a WAN” in some fashion or another (*Extend or custom CacheStores being the pre-dominate solution).  While solutions in the past have usually required some level of customization, mainly at the application level because every application is completely different in terms of replication strategy, with the introduction of the Push Replication Pattern example on the Coherence Incubator, essentially an open-framework for solving distributed Data Grid replication, things are a lot easier.

To be honest, over the past few years I’ve heard a lot of non-sense about the use of Push Replication Pattern as a strategy for keeping sites in sync (using push rather than a pull model), especially around it’s applicability as a solution for large scale distributed replication challenges. While the comments have seemingly originated from competitors of Coherence in the Data Grid space (feedback is that they don’t have these features) or from people that have never really solved these types of problems (what would we do without critics huh? :P), it’s pretty clear why…. simply understanding the possible combinations of technologies coupled with the replication semantics and business rules makes globally distributed replication a very challenging problem.  (Note: I was told this stuff even before I joined Tangosol when I was investigating Data Grids).

For example:  Often every name space (say cache) in a system will have completely different semantic requirements for replication.  Some may require an active passive strategy, some may require active + active, some may hub-and-spoke, and so on.  When you have a system with twenty of these different requirements it’s clear why “one single hard coded solution” or “one button in the tin” is not flexible enough for architects.  It’s not about “things being too complex”, it’s about supporting business models that are “complex”.  Ultimately what you can do in a single JVM, or the strategies that work between a few servers in a single data center are nothing compared to keeping things running in real-time across the globe. Actually, usually the rules are completely orthogonal.

Having been personally responsible for these types of solutions in the past (prior to joining Tangosol and Oracle over four years ago), the Coherence-based Push Replication Pattern example seems to demonstrate most of these challenges can be solved, especially in the Data Grid space.  

In a nutshell here’s what the Oracle solution is designed to deliver;

1. Completely Asynchronous Replication (no blocking between sites – especially those distributed around the world!)
2. Many deployment models; from one to one, one to many, many to one and many to many sites (not just single servers)
3. Simultaneous replication in multiple directions (those active + passive and hub + spoke are also supported)
4. Guaranteed ordering of updates
5. Completely monitorable (from any point using JMX) (and now also has third party monitoring tool integration)
6. Pluggable (business rules based) Conflict Resolution (on a per-cache and site basis)
7. Native Java (but supports portable objects from .NET and C++)
8. Provided with complete source code.
9. You can continue to use the Coherence APIs as they are… no changes in either the product (either statically or dynamically with byte-code manipulation) or your application code. 

Ok… enough of the background and marketing crapolla… Here’s a very common deployment scenario.

Consider the requirement where a company has three different regional operating centers.  Say for example the deployment model that exists in virtually every investment bank (before most of them recently turned into “savings banks”).  Each typically has an East Coast operation (in the United States), one operation in Europe, and lonely centre somewhere in the far reaches of the Asia Pacific :P, each being “active” and each with their own local business continuity (disaster recovery site).  So a total of six sites.  

ASIDE: As I’ve always said, and recently talked about at the NY and London Coherence SIGs, once you have an architecture that is globally distributed, you effectively have to double the number of sites you need to keep in sync (to allow for regional disaster recovery), regardless of whether everything is hot or not.   Why?  Because everyone wants everything as hot as possible (and 24 x 7) as their requirement/dream is “anyone should be able to trade from anywhere at anytime”.  Even for the smallish firms I’ve worked for in the past eight years, this was exactly the requirement  - trading everywhere.

Doing this with a bunch of servers, even say just deploying six around the world, would be a significant challenge for most technologies.  The big challenge however is coping with capacity requirements, especially when those servers don’t have enough.  In the extreme cases, shipping log files around, or using a messaging bus, simply doesn’t cut it, and this is where a Coherence-based solution can provide the capacity, low-latency and high-resilience typically required.

So what do the Coherence-based deployments look like?  Well instead of six servers, there are usually somewhere between say twenty and several hundred Coherence servers at each site, most mainly configured to be part of a regional Compute Grid, usually for a risk management/trade position keeping/reference data solution.  Thus in terms of replication the challenge is to keep not six, but somewhere between 6 x 20 = 120 and 6 x (say) 100 = 600 Coherence servers in sync.  

While these numbers are just examples, I’ve recently have been involved with implementations and discussions concerning Push Replication that range from three sites to over five thousands sites (sounds a bit extreme but in some industries – non financial – this type of capacity is “normal”), with anything from three servers per-site to hundreds per-site.  In reality, almost all investment banks operate the same way; three or four major centers with a few hundred servers per site (typically per application).

Just to be clear and not to sound like I’m taking ownership of these patterns, while the Coherence implementation of Push Replication is relatively new, the concepts are not.  Just solving this on a large scale with a flexible example framework is.  The fact is, WAN-based solutions are becoming more prevalent and solutions for implementing them more commonly known as the requirements for operating on a global basis in real-time is dramatically increasing.

In some ways it’s what you “don’t have to do” that makes the Coherence solution unique.

1. When you want to scale (even more), you simply add more servers at run-time. There’s no need to shut an entire site down (or the system globally) to reconfigure, use a console or anything else, you just start more servers.  

2. You also don’t need to setup up “gateways” (single points of failure) to do the work between the sites.  Each cache uses a set of “publishers between sites” and these are managed as an integral “part of the grid(s)”.  Basically this means there is no need to separately configure them (from the rest of the infrastructure). Also, if they die (say because they are killed off to be then upgraded), everything just fails over and continues where it left off.  This is usually sub-second.

The great thing about the Coherence Push Replication implementation is that it’s been customer driven.  Like all of the features in Coherence itself, the features and semantics for the Coherence Push Replication example implementation have come from a variety of firms, some small and some large, each kind enough to invest some of their time in providing guidance around their unique challenges.  It’s been great working with these firms, each themselves distributed around the world, and I’m sure they are looking forward to the next generation of the Push Replication Pattern implementation, including adding support for cache-based and directional filtering of updates between sites, together with coalescing of updates for even greater network through-put.  (it already supports compression)