Managing a Coherence Data Grid

One of the challenges with Coherence has been the limited management tools.  There is a built support for cluster wide JMX, but this only provides a limited management capability and requires a JMX console, see documentation for more details.  Using a JMX console is fine but it isolates the management of the cluster from other management tools, such as database and web servers.  Last month Oracle released a new Enterprise Manager pack, the Oracle Management Pack for Oracle Coherence.  This pack enables you to manage and monitor Coherence from within Enterprise Manager.  If you are running Coherence as part of WebLogic Suite or WebLogic Application Grid then the management pack is included in those suites.  If you are running a standalone Coherence (standard, enterprise or grid edition) then the management pack is available separately.  So go and give it a try by downloading Enterprise Manager 10.2.0.5.

How to Build and Manage a Product Suite

I was in Redwood Shores this week with a customer and we were lucky enough to have Thomas Kurian speak to us for an hour in a Q&A session.  One of the customers I was accompanying, Michael, asked a really useful question, well actually he asked several but I am only blogging about one of them.  Michael is in charge of his company’s largest software development that will redefine the types of service that can be offered by his company.  Quite naturally he is feeling a little pressured so his question to Thomas was not related to technical issues but to the philosophy of integrating different products into a consistent product stack.  Obviously Thomas has a great track record on this, WebLogic Suite combines products from Oracle, BEA and Tangosol in a single product stack; SOA Suite combines products from Oracle, BEA and Oblix into a single product stack etc.

Thomas identified the following steps that can be applied when integrating products into a consistent product set:

• Group similar functionality together into Suites.
  This enables a focus on related pieces of functionality and avoids being overwhelmed by the sheer size of the product stack.  it also simplifies the messaging that has to be communicated to the market.
• Get the pieces to work together.
  Within a suite the emphasis is on making the components work well together, eliminating duplication of function.
• Pick up dependencies in a single way.
  Everyone should access the functionality in the same way.  This takes advantage of common abstractions and makes it easier for clients of the suite to take up new functionality in a seamless fashion.
• Suite pricing encourages big picture thinking
  Customers generally want several related pieces of technology.  Bundling them together into suites at a combined price focuses the development teams not just on their small piece of the puzzle but on the wider suite, giving them an incentive to make sure it all works together.
• Mandate
  In addition to the carrots mentioned above, force people to pick up functionality in a single way and to be consistent across components in the suite.

In conclusion Thomas identified three principles that guide the above steps

• Unify – using suites
• Simplify – everyone accesses functionality in the same way
• Mandate – force everyone in your organization to play by the rules

Thomas was adamant that Fusion Middleware would be more than a simple branding.  Over the last 5 years Thomas has moved the Fusion Middleware towards tighter and tighter integration.  The latest demonstration of this will come later this year with the release of SOA Suite 11g.

Michael wasn’t looking for a silver bullet, but I think he did appreciate Thomas’ thoughts on this one.

 Oracle SOA Executive Roundtable Webcast: Top Five Insights for Maximizing Returns with SOA

Oracle are having an executive round table web cast at 8AM PDT Thursday 23rd 2009 chaired by Amlan Debnath, Senior Vice President Integration Products at Oracle.  Other attendees include

• Job Simon, Senior Director, NetApp
  Dan Goerdt, Director, Schneider National Inc.
  Jennifer Briscoe, CTO and VP, Collect America

Check out the registration page here.

Oracle SOA Suite Developer’s Guide

My friend Matt Wright just pointed out to me that I hadn’t mentioned that our book was now available.  Thanks to the guys at Packt Publishing for guiding us through the process and publishing the book.  Our focus when writing the book was to provide a practitioners guide to implementing SOA using the Oracle SOA Suite.  As such we have set each component of the SOA Suite within the context in which might be used.  This seems to be the area that a lot of companies starting down a SOA path struggle with.  They are unsure what bits of technology to use for what.

Dave Shaffer, Oracle VP for SOA, kindly wrote a foreword for us.

Writing the book has been a huge undertaking for both Matt and myself.  During the writing of the book the 11g release was seriously delayed so we switched versions from 11 to 10.1.3 (the current production release).  Matt decided that he was sick of 365 days of rain and moved his family from England to Australia.  Finally Oracle purchased BEA and caused a re-evaluation of the Service Bus technologies.

I am pleased with the way the book has turned out, and Matt and I learnt a huge amount as we prepared the book, both of us had to delve into area with we weren’t totally familiar.  Matt became a master of the Rules engine and I discovered the marvelous new deployment capabilities added to the 10.1.3.4 release.

We have made every effort to match the book to the current production 10.1.3.4 release so get yourself a copy and give us some feedback.

Tuxedo Connections or the On Ramp to Tux

Tuxedo can be considered as the original and purest service oriented architecture.  The key abstraction in Tuxedo is the service and everything is made to fit into the service mould.  It seems strange then that people think of Tuxedo as a legacy application.  Tuxedo is highly regarded by the senior management team in Oracle who view it as a key tool to support extreme transaction processing.  The question is then, how does this relate to the rest of the SOA world which does not subscribe to the Tuxedo technologies such ATMI, C++ or COBOL.

The diagram below shows the different interfaces into and out of the Tuxedo world.  Lets look at them briefly and how they relate to the rest of the SOA world which is focussed on XML, SOAP and HTTP.

Native Client Interfaces

The native client interfaces to Tuxedo are the C, C++, .Net or COBOL client interfaces using ATMI (Application to Transaction Monitor Interface).  There is also a version of ATMI for Java, called Jolt.  These interfaces allow clients to invoke Tuxedo services and get responses.  They do not allow Tuxedo to invoke services in these clients except by listening on Tuxedo message queues, these interfaces are asymmetric.

Legacy Client and Server Interfaces

A Tuxedo domain can interface to other Tuxedo domains, treating their services as though they were its own services.  This capability is extended to other systems such as mainframe systems.  The external systems see Tuxedo services as native services and invoke them as they would any other service, similarly Tuxedo sees these external systems as native Tuxedo services and invokes them as it would any other service.  This provides relatively seamless integration between legacy environments and Tuxedo and allows either side to operate as a server to the other, in other words these interfaces are symmetric.

Open System Interfaces

In addition to treating legacy mainframe interfaces and other Tuxedo domains in the same way as local services Tuxedo can also do this for such open system standards as CORBA and java code running in WebLogic Server.  CORBA applications can invoke Tux services through the CORBA API and Tuxedo services can invoke CORBA objects.  The WebLogic Tuxedo Connector (WTC) extends the capabilities of Jolt to become fully symmetric in that EJBs in WebLogic can be invoked as services from Tuxedo.

A Transactional Note

Note that all the interfaces we have spoken about so far are transactional, as in they are part of the Tuxedo transaction infrastructure, invoking a remote mainframe transaction may cause an XA transaction to be started within Tuxedo.  When calling an EJB in WebLogic this also is part of the overall Tuxedo XA transaction infrastructure.

Web Service Access to Tuxedo

There are two alternative ways to get Web Services to access Tuxedo.  The most obvious is to use SALT (Service Architecture Leveraging Tuxedo) which exposes Tuxedo services as web services, and allows Tuxedo to invoke Web Services as though they were Tuxedo services.  This is a symmetric interface and takes care of all the XML to Tuxedo translations but it is not transactional.  The web service call is not part of the transaction.  A web service request to Tuxedo may cause a Tux transaction to be initiated, but webs services don’t currently provide a transactional context.  Similarly when Tux makes a call to a web service, that call is not part of any Tuxedo transaction.

So what if you want transactionality and access to web services.  This is where the service bus comes in.  The Oracle Service Bus (OSB) takes advantage of the WebLogic Tuxedo Connector to provide a fast efficient and transactional interface to and from the Tuxedo world.  This allows a pipeline to make two seperate calls to Tuxedo as part of the same transaction.  Note that there are a couple fo wrinkles to making this happen and I will deal with those in a later post.

Summary – Long Live Tux, King of Services

Not only is Tuxedo the original service oriented architecture but despite being more than 20 years old, through SALT and WebLogic Tuxedo Connector it still speaks the modern lingo of service buses, Java, XML, SOAP and HTTP.  So if you have a Tuxedo investment don’t write it off, but look at how you can more easily make your Tux services available to the new fangled XML based web service world.