London Coherence SIG: Winter Edition: 26th February 2010

The registration page for the UKOUG London Coherence SIG are now up.  Details are here.  Space is limited, so register early!

Here’s an overview of what’s happening.  See you there!

Session 1: TopLink Grid: Scaling JPA applications with Coherence (Shaun Smith – Principle Product Manager – Oracle)
JPA, the Java Persistence API, is the Java standard for relational database access. But as is the case for many technologies, scaling JPA applications into large clusters is a challenge. In this session we’ll introduce Oracle TopLink’s new “TopLink Grid” feature which supports scaling JPA applications through Coherence integration. We’ll also introduce the new TopLink Grid enabled “JPA on the Grid” application architecture in which the underlying relational database is replaced by Coherence and all standard database operations, including JPQL query execution, are handled by Coherence. In this session we’ll demo how easy it is to leverage Coherence from JPA using TopLink Grid and how to build standards compliant Java EE applications that scale.

If you’ve used Top Link/Hibernate/JPA and thought it would be great if you could do it without a database (on Coherence), this is the talk for you.

About the speaker:  Shaun Smith is a Principal Product Manager for Oracle TopLink and an active member of the Eclipse community. He’s Ecosystem Development Lead for the Eclipse Persistence Services Project (EclipseLink) and a committer on the Eclipse EMF Teneo, Dali Java Persistence Tools, and Eclipse Examples projects. He’s currently involved with the development of persistence services for OSGi and Oracle TopLink Grid, which integrates Oracle Coherence with Oracle TopLink to provide “JPA on the Grid”.

Session 2: Coherence Security: Securing your Coherence cluster members, Extend and JMX connections using Active Directory / Kerberos authentication.  (Jonathan Knight - Coherence Expert)
Coherence Security is not something people often play when using Coherence.  Typically it’s simply used out-of-the-box. In this presentation Jonathan traverses the depths of Coherence Security options and in doing so provides a demonstration of .NET *Extend Client single sign-on for accessing a secure cluster.

If you’ve ever wanted to know about securing a Coherence Cluster, this is an essential introduction.

About the speaker: Jonathan Knight is a Coherence and security expert.  Having used and extended Coherence for over four years in multiple globally recognised companies, he’s a trusted source of information, innovation and adviser to the Coherence Engineering team on the subjects of security integration, configuration, deployment and push replication in the wild.

Session 3: Extensible Coherence Configuration, Namespaces and Event Processing (Brian Oliver – Solutions Architect – Oracle)
In this talk we examine how you may extend traditional Coherence Configuration files to include and embed your own services, resources and beans with in a Coherence process.  Using the latest Incubator releases, we demonstrate how to independently develop simple namespace extensions to allow things like; declarative specification of indexes, automatic pre-loading/cache warming and cluster wide task schedulers, without needing to sub-class Coherence or create custom applications.

If you’ve even wished you could easily create and embed processing in a Coherence cluster member that has the resilience of Coherence itself, this talk will show you how.

About the speaker: Brian Oliver is a Solutions Architect at Oracle, working within the Coherence Engineering team.  Primarily customer facing, Brian leads the development and innovation within the Coherence Incubator and is the founder of the Coherence SIG.

Session 4: Open Discussion: Coherence Quorums and the Guardian (Gene Gleyzer – Coherence Architect – Oracle)
In this session Gene discusses some of the upcoming features in Coherence 3.6, including the notion of cluster Quorums and how to control the Guardian.

If you’ve ever wanted to know more about how Coherence works, this session from one of the architects of Coherence will fill that need.

About the speaker: Gene Gleyzer is one of the founders of Tangosol and architect of Coherence.  His insights into Distributed Computing and Data Grids are second to none.

Ridiculous class and interface names, fear of change and the new operator

One of the important tasks when designing software (or probably anything for that matter) is creating appropriate/correct/reasonable names for things, whether it be for classes, interfaces, methods or variables.  Why?  Simple… When someone reads your code they should ideally require little additional documentation, third party contact or alternative education/context to work out what something means, or determine it’s purpose.  Perhaps it’s not always the case, but it’s a good goal.

While it may seem easy experience shows that creating reasonable names often requires a lot of thought.  In the Coherence team we invest a lot of time in finding names and defining the language of concepts, not only for ourselves, but also for external groups that depend on our code (like customers). Likewise in the Coherence Incubator team, we critically review the names we’re proposing for things, because we know that customers (and competitors) will read our code.  Many a “warm argument” has occurred due to the naming of things, and to me it’s both one of the toughest and most enjoyable things to do.  It’s a critical part of our design process.  There’s nothing like finding a good name to describe something elegantly.  So much so, we often invest time searching dictionaries and thesauruses just to find inspiration.  To me… a name is worth a thousand words.  Unfortunately we don’t always get it right, but we do try, and we try very hard.

When I look at a problem, design or have to reflect on an existing architecture, I start with the names of things.  If I find a name I’m uncomfortable with, or something that requires a lot of explanation, I start to challenge that design is possibly wrong.  ie: It’s overly complex or overly generic and with more thought it could be radically simplified.  Why?  I think this steams from my strong belief that the purpose of writing (commercial) software is to deliver a solution, and with that, there needs to be simplicity (such that we can deliver on time and provide value).   This doesn’t mean a lack of features. It simply means delivering something that is easy to use and is suited for purpose.  It’s about keeping customers happy.  Like Coherence.  Small, remarkably simple yet powerful without a massive API.

SIDE NOTE 1: Sometimes thing’s just can’t be simple… but it’s a good goal to ruthlessly attempt to achieve.

Personally I believe one of the biggest challenges when naming something is the fear of change and the apparent need for developers to “allow for the future”.  Delivering software is a tough enough job as it is, but having to design in solutions involving predictions about the future,with an uncontrollable urge to make things extensible only makes things much harder and more complicated. When I look at a system I intentionally try to limit the amount of “framework building” (accept when asked to develop a framework that is), and instead focus on providing a solution as soon as possible.  I strongly believe that the future is for another version.  ie: Don’t attempt to build 2.0, 3.0, 4.0 etc into 1.0.   Ruthlessly protect and deliver version 1.0, because that may be your last version.

So how does this related to names?  Let me give you a simple example.

Say I need a class to represent a Person.  It has a few attributes, say, First Name, Last Name and Address. You know, it’s nothing to complicated.  That’s all I really need for version 1.0.  While it sounds simple, here’s often what I see happening;

1. Developer decides to model this as a simple Person class.  Great.  Satisfies version 1.0 requirements.

2. Then out of fear for the future, change, the pain change can inflict and the remote posibility that they may need alternative implementations, they change their mind and instead introduce the Person interface (in .NET land they’d create IPerson) to represent the Person as an abstract concept.

interface Person {
   public String getName();
   //etc
}

Not a big change, so seems reasonable.

3. In Java they’d declare the setters/getters in the Person interface, then create a concrete class for Person, calling in something like PersonImpl.  (In the Coherence Engineering group we’d call it something like DefaultPerson or SimplePerson).

4. Now that they have an interface, the question arrises “how should you create an instance of a Person?”. That is, although we have the PersonImpl class, “we should not expose that to the core of the application, so we need a way of hiding creating instances”.  (Unfortunately most languages don’t allow overriding the behavior of “new” like this “new <interface>”. It would be great if you could tell the compiler, hey if you see “new Person” I actually mean “new PersonImpl”).  Anyway, to solve this problem and keep the code “pluggable”, they decide it’s time to use the “Factory Pattern” or potentially the “Builder Pattern” to create Person instances.  Hence the PersonFactory is born.

5. But… what if we need to replace the Factory?  Ok… easy… “just introduce a PersonFactory interface, and then introduce a PersonImplFactoryImpl class to create the Person instances as we need them”

Can you see how the names are starting to sound strange/ridiculous?  What once was a simple problem to solve, has now blossomed into the Person framework.  The names are starting to look ridiculous and to me, this gives the first indication of over-genericizing.

SIDE NOTE 1 (revisited): It’s very possible that something like this may actually be needed, but more often than not, it’s pretty rare.  Sometimes you just can’t simplify something that is intangibly complex.

SIDE NOTE 2: This is not over-engineering.  Over-engineering occurs when you make a product unnecessarily stronger or more durable.  The above does not increase strength (performance, availability, reliability or scalability).  It increases flexibility for the future and often a requirement that no one demands up front.

But we’re not finished yet.

6. The last and often ugliest of all steps is to consider how to create instances of the PersonFactory interface.  And you guessed it… it’s time for another factory, the PersonFactoryFactory interface.

Of course this sounds even more ridiculous, so it often becomes the PersonFactoryService

So what went from a simple Person class and using the new operator to create instances, we now have a completely generic pluggable Person framework requiring the Person, PersonFactory and PersonFactoryFactory interfaces (an SPI if you like), together with the PersonImpl, PersonImplFactoryImpl and PersonImplFactoryImplFactoryImpl classes (to be completely correct)… just to say person.getName() and person.setName(…).

SIDE NOTE 3: I’m guessing you could simplify the factory names to PersonImplFactory and PersonImplFactoryFactory, but it’s not much better.

With this simple example it’s easy to see why inversion of control (IoC) has taken off.  In any system with 5 or 10 artefacts like this the complexity of wiring together an application is so great that it’s hard to know where to start…. and why?  All essentially so we can get back to saying something like “new Person”, but without being committed the Person implementation. No wonder we have the term “plain old java objects” (POJO), just to tell people “you can use the new operator on this class”.

Are we crazy to continue to build systems like this?  Isn’t OSGi (et al) making this any easier?  Spring has tried to, but even it’s download and dependencies are getting massive.

Perhaps the world is no longer as simple as it use to be, wants to be or needs to be.

There is help though… If you’re stuck for a class/interface name, you should check out http://www.classnamer.com

—

PASSING NOTE: The Java Beans specification and thus the introduction of the term Bean (essentially to mean a Object with getters and setters) often makes naming things even more ridiculous.  While I really like the Bean spec, it can be brutal on class names.

Person -> PersonBean
PersonFactory -> PersonBeanFactory (or PersonBeanFactoryBean)
PersonFactoryFactory -> PersonBeanFactory (or PersonBeanFactoryBeanFactoryBean)

London Coherence SIG: Winter Edition: 26th February 2010

Save this date:  26th of February 2010 (Friday)

This is when the next London Coherence SIG will be on, in London, at the usual place, the Oracle City Office.

More details to come next week… including the place the register.

PS: Look forward to some very cool Toplink Grid (think Toplink JPA running purely on Coherence – all those nice Object Queries on a Grid), a huge number of Incubator updates and perhaps a few surprises.

Leopard to Snow Leopard Upgrade (almost no problems)

So I’ve finally managed to get a few seconds to upgrade my 13″ Mac Book Pro and Mac Pro to Snow Leopard.  For the most part the upgrade was a very simple process.  For the Mac Book Pro, I simply inserted the DVD (while running Leopard), clicked on Install and let it do it’s thing.  About an 40 minutes later everything was good.

The Mac Pro was a little more challenging.  I think this was mainly due to the fact that I’m running RAID 1 disks as my boot drive.  After inserting the DVD, I expected pretty much the same response as my Mac Book Pro.  Alas, it was different.  Instead of asking me if it was ok to install Snow Leopard onto my RAID array, it couldn’t find any hard drives at all (and gave no message to indicate what was happening or what to do).  The bundled instructions were unfortunately useless.

The simple solution however was to boot from the DVD  That is, restart the machine and hold down the “Option” key while it was booting, select the Snow Leopard DVD as the start up disk and let it do it’s work.  After this everything proceeded as per my first installation on the Mac Book Pro.

I have two general warnings about making this upgrade though;

1. If you’re a developer and use Java 1.5, don’t do this upgrade.  Java 1.5 (as far as I can tell) is not supported on Snow Leopard.  Your existing Java installation will become Java 1.6 – great if you can use that (which I can).

2. If you have some 32-bit applications (like Growl) that make use of the System Preferences (application), then you’ll be annoyed by the constant need to change into “32-bit mode” to use the applets for the said 32-bit applications.  I don’t expect it will be long before Growl is 64-bit happy, but in the mean time, be prepared for a little bit of restarting the System Preferences application.

Apart from that, Snow Leopard is sweet.

This never gets old…

Has the process of developing and delivering software really changed?

(click the image for full size version)

New Coherence Incubator Releases

As announced at the London Coherence SIG last week, we’ve released a new set of updates to the Coherence Incubator, the major highlights being;

• Introduction of the new Examples Project: This contains a set of Coherence Incubator Examples.  Once easy download that includes all of the patterns, including multiple push-replication deployments.
• A significant update to the previously released Processing Pattern, including new types of dispatchers and executors.

While a lot has been achieved in this set of updates, if I had to pick my favorite thing for the release, it would be our improved documentation examples.  In particular, the multi-site Auction example really rocks.  In the past few weeks we’ve demonstrated this around the world, including Oracle Open World and the London Coherence SIG, with fantastic feedback.  I can’t wait for the next release… and to demonstrate it on multiple clouds at QCon San Francisco in a few weeks.

Sun Microsystems and Coherence

So cool.  Just saw the latest Sun Microsystems home page.

Sun have just released their first in depth Oracle Coherence blue-print (white paper) documenting the architecture, performance and scalability impacts seen in a large application.  As a comparison, the document outlines the performance and scalability of an application both with and without using Oracle Coherence.  Apart from the performance numbers (which are obviously good), their independent tests demonstrate near perfect linear scalability to over 80 servers and a 40% resource reduction on the database.  The numbers are very consistent.

The lesson here:  Predictable Performance and Predictable Scalability beats plain old scalability, every time.

Oracle Open World 2009: Application Grids

It’s hard to believe but another year has passed and it’s time again for Oracle Open World in San Francisco. Like last year, it’s going to be big.  Apparently San Francisco is bracing itself for an influx of 85,000 or so delegates, not all talking about Coherence obviously, but there will be a lot more than last year. A lot more!

In terms of agenda the Coherence presentations, panels, tutorials and hands-on-labs all appear as part of the Application Grid theme – think of Application Grids as fully managed and flexible infrastructure for running applications, everything from the operating system to the top of the application stack (including open source stacks).  Perhaps “private cloud” might be a way of thinking about it (typically how our customers are talking about it).

There are over 80 sessions on the topic of Application Grids, covering everything from WebLogic, Tuxedo, JRockit, Enterprise Management, Virtualization and Coherence.  There are over a dozen customer presentations.  Nearly half of these sessions are focusing on Coherence.

Like last year everything is being “demoed” in the DEMOgrounds, the Fusion Middleware Pavillion and the Oracle Technology Network lounge.  All of the areas are staffed by the actual engineers, product managers and/or executives from the product divisions.

So if you’re in San Francisco, be sure to drop by the Coherence booth (and others) to say hi.  We’ve got some really cool demos cooking. We can’t wait to show them off!

A quick guide to Application Grid sessions is available at http://www.oracle.com/goto/appgridopenworld, or if you like as a PDF.

Hope to see you there.

Next London Coherence SIG: Autumn Edition (29th October)

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

[Updated] Registration is now open at http://www.ukoug.org/calendar/show_event.jsp?id=4563

1. Coherence and Incubator Update
Noah Arliss: Coherence Engineering, United States

In this talk we’ll look at some of the new features in Coherence 3.5.2 and changes since 3.4 and 3.5.  We’ll also outline some of the feature themes for the next set of releases.

2. Simplifying (Server Side) Event Driven Architectures
Brian Oliver: Coherence Engineering, United Kingdom

In this talk we look at the results of the “Seismic” research project – a new way to develop server-side event-driven system with Coherence, without using Backing Maps and other custom extensions to Coherence.

3. Processing Pattern Revisited
Noah Arliss: Coherence Engineering, United States

We’ve done a lot of work since the first release of the Processing Pattern.  In this talk we’ll look at some of the changes and new features to enable “compute-grid” style development with Coherence.

4. Rapid Talk: Building GUIs with Coherence, SWT and JFaces
Brian Oliver: Coherence Engineering, United Kingdom

In this rapid talk (no slides) we’ll look at techniques for simplifying the construction of GUI’s for Coherence when using SWT/JFaces.

5. Rapid Talk: How to use the Command Line utility
Brian Oliver: Coherence Engineering, United Kingdom

In this rapid talk (again, no slides) we’ll look at how to use the Command Line utility, how to perform queries, extract values, define filters and repeat commands.

Hope to see you there!

– Brian

New Coherence Incubator Releases!

We finally managed to get the new Coherence Incubator releases out at the end of last week.  Unfortunately I’ve been on the road/in the air so I didn’t get much of a chance to blog about them.  As usual each project page contains a high-level overview of the new stuff/updates and changes. For those that want more even more detail, there’s always the history.txt files in the source. However for those that want to know more about the factors/motivations for the changes, here’s a brief commentary.

Cross-Project Changes

With increasing adoption of the Incubator Projects in the community we found that some adopters were running into name-clash problems with the cache names we’ve been using.  ie: we use a cache called “messages” and so it seems do other people!  So one of the major changes in the release was to introduce name-spaces for all of the Incubator cache names.  Hence forth all Incubator cache names are prefixed with “coherence.<incubator-project>.<cachename>”.

In addition to this we refactored more of the commonly used code and pushed it down into Coherence Commons.  But more about that next.

Coherence Common 1.4.0

Within Coherence Common we made two significant changes.  The first involved moving the sequence generation code from the Coherence Command Pattern into Common making it more generally available without needing to depend on Coherence Common.  The second  change involved “hardening” the Ranges implementation.  While the previous Ranges implementation was sufficient for the uses within the Coherence Incubator, after code review we found several things needed to be changed, improved and fixed.

Coherence Command Pattern 2.4.0

Within the Command Pattern we also made two significant changes.  The first was an internal refactoring to remove the use of the Invocation Service and instead use EntryProcessors.  The motivation for this was mainly to support the use of *Extend clients to submit Commands (and example Extend Cache Configuration is included in the source).  The main impact of this change was the internal separation of Commands that are managed as “co-located” v’s those that are “distributed”.  That is, there are two caches now to hold Commands, depending on the “management strategy” chosen for the contexts.  There are where no changes to the APIs.  The second change introduced the notion of a “batch command”.  This allows a batch of commands to be submitted atomically.  For some use cases this allows for significant performance and throughput improvements.

Coherence Functor Pattern 1.2.0

Apart from the introduction of name-spaces for the Functor Pattern caches, we simply upgraded the project to use the new Command Pattern and Commons releases.

Coherence Messaging Pattern 2.4.0

Apart from the introduction of name-spaces for the Messaging Pattern and the upgrade to use the new Command Pattern/Common projects, the only changes involved resolving two defects and hardening subscription time-outs.

Coherence Push Replication Pattern 2.4.0

Within the Push Replication Pattern we made several enhancements.  These included;

a). The ability to support cache-side asynchronous batching of replication to the push replication engine (will provide at least 2x performance improvements)

b). Introduced the FilteringBatchPublisherAdapter that provides the ability to filter out entries before they are pushed to a site (publisher)

c). Introduced the CoalescingBatchPublisherAdapter that provides the ability to coalesce entry operations (ie: coalesce multiple entry updates into a single operation) prior to being pushed to a site (publisher).

d). Fixing the spelling mistake in the DefaultPushReplicationManager class name! (oops).

Having just finished the planning for the next round of releases (and new patterns), I’m really looking forward to what’s next. We should get the roadmap for everyone to see in the next week.