SCA, OGSi and Spring from an IT management perspective

March starts next week and the middleware blogging bees are busy collecting OSGi-nectar, Spring-nectar, SCA-nectar, bringing it all back to the hive and seeing what kind of honey they can make from it.

Like James Governor, I had to train myself to stop associating OSGi with OGSI (which was the framework created by GGF, now OGF, to implement OGSA, and was – not very successfully – replaced with OASIS’s WSRF, want more acronyms?). Having established that OSGi does not relate to OGSI, how does it relate to SCA and Spring? What with the Sprint-OSGi integration and this call to integrate OSGi and SCA (something Paremus says they already do)? The third leg of the triangle (SCA-Spring integration) is included in the base SCA framework. Call this a disclosure or a plug as you prefer, I’ll note that many of my Oracle colleagues on the middleware side of the house are instrumental in these efforts (Hal, Greg, Khanderao, Dave…).

There is also a white paper (getting a little dated but still very much worth reading) that describes the potential integrations in this triangle in very clear and concrete terms (a rare achievement for this kind of exercise). It ends with “simplicity, flexibility, manageability, testability, reusability. A key combination for enterprise developers”. I am happy to grant the “flexibility” (thanks OSGi), “testability” (thanks Spring) and “reusability” (thanks SCA) claims. Not so for simplicity at this point unless you are one of the handful of people involved in all three efforts. As for the “manageability”, let’s call it “manageability potential” and remain friends.

That last part, manageability, is of course what interests me the most in this area. I mentioned this before in the context of SCA alone but the conjunction of SCA with Spring and/or OSGi only increases the potential. What happened with BPEL adoption provides a good illustration of this:

There are lots of JEE management tools and technologies out there, with different levels of impact on application performance (ideally low enough that they are suitable for production systems). The extent to which enterprise Java has been instrumented, probed and analyzed is unprecedented. These tools are often focused on the performance more than the configuration/dependency aspects of the application, partly because that’s easier to measure. And while they are very useful, they struggle with the task of relating what they measure to a business view of the application, especially in the case of composite applications with many shared components. Enter BPEL. Like SCA, BPEL wasn’t designed for manageability. It was meant for increased productivity, portability and flexibility. It was designed to support the SOA vision of service re-use and to allow more tasks to be moved from Java coding to infrastructure configuration. All this it helps with indeed. But at the same time, it also provides very useful metadata for application management. Both in terms of highlighting the application flow (through activities) and in terms of clarifying the dependencies and associated policies (through partner links). This allowed a new breed of application management tools to emerge that hungrily consumer BPEL process definitions and use them to better relate application management to the user-visible aspects of the application.

But the visibility provided by BPEL only goes so far, and soon the application management tools are back in bytecode instrumentation, heap analysis, transaction tracing, etc. Using a mix of standard mechanisms and “top secret”, “patent pending” tricks. In addition to all of their well-known benefits, SCA, OGSi and Spring also help fill that gap. They provide extra application metadata that can be used by application management tools to provide more application context to management tasks. A simple example is that SCA’s service/reference mechanism extends BPEL partner links to components not implemented with BPEL (and provides a more complete policy framework). Of course, all this metadata doesn’t just magically organize itself in an application management framework and there is a lot of work to harness its value (thus the “potential” qualifier I added to “manageability”). But SCA, OSGi and Spring can improve application management in ways similar to what BPEL does.

Here I am again, taking exciting middleware technologies and squeezing them to extract boring management value. But if you can, like me, get excited about these management aspects then you want to follow the efforts around the conjunction of these three technologies. I understand SCA, but I need to spend more time on OGSi and Spring. Maybe this post is my way of motivating myself to do it (I wish my mental processes were instrumented with better metadata so I could answer this question with more certainty – oh please shoot me now).

And while this is all exciting, part of me also wonders whether it’s not too early to risk connecting these specifications too tightly. I have seen too many “standards framework” kind of powerpoint slides that show how a bunch of under-development specifications would precisely work together to meet all the needs of the world. I may have even written one myself. If one thing is certain in that space, it’s that the failure rate is high and over-eager re-use and linkage between specifications kills. That was one of the errors of WSDM. For a contemporary version, look at this “Leveraging CMDBf” plan at Eclipse. I am very supportive of the effort to create an open-source implementation of the CMDBf specification, but mixing a bunch of other unproven and evolving specifications (in addition to CMDBf, I see WS-ResourceCatalog, SML and a “TBD” WS API which I can’t imagine will be anything other than WS-ResourceTransfer) is very risky. And of course IBM’s good old CBE. Was this HTML page auto-generated from an IBM “standards strategy” powerpoint document? But I digress…

Bonus question: what’s the best acronym to refer to OGSi+SCA+Spring. OSS? Taken (twice). SOS? Taken (and too desperate-sounding). SSO? Taken (twice). OS2? Taken. S2O? Available, as far as I can tell, but who wants a name so easily confused with the stinky and acid-rain causing sulfur dioxide (SO2)? Any suggestion? Did I hear J3EE in the back of the room?


Filed under Everything, IT Systems Mgmt, OSGi, SCA, Specs, Spring, Standards

10 Responses to SCA, OGSi and Spring from an IT management perspective

  1. Oh no not more talking up of Spring over standards such as Java EE and then to actually claim a still in beta product that uses call stack as a ideally suitable for production over byte code instrumentation based approaches that can accurately relate work to a transaction context and database operations. I am really shocked and disappointed. When I read the BCI FUD in the Oracle white paper I assumed it was just some Oracle marketing person misinterpreting or overstating a benefit of one particular narrow approach (note: one approach is never sufficient in the enterprise context) to performance management.

    Now I would dearly love to show everyone how far off this one is but unfortunately the license of the software restricts any benchmark publication. All I can say is that obviously someone has never considered the typical call depth (>200) of Java EE/Spring applications (hint: deeper -> higher overhead) and tested this with an application having a sufficiently high number of active threads. Not to mention that it is impossible to determine maximum times so important for performance engineers focusing on user experience with such a simple approach.

    For your information one does not have to trace every event and instrument every method. Trace instrumentation techniques including proxying and BCI (AOP) can easily out-perform thread call stack sampling whilst providing accurate measurement and diagnostic data (argument, target object state) you just need to think outside of the box – metering strategies.

    Probe Metering Strategies

    If you are up for a public benchmark (shoot-off) of performance management tools and techniques then please accept my participation.


  2. vbp

    Hi William L.

    Is it the parenthesis in which I point to AD4J that set you off? I am trying to make sense of your comment in the context of what I wrote in the article. The article is not about comparing the different approaches to java perf management. And I don’t see any BCI FUD in there.

    The point I make is that many techniques have been developed for java management (especially in the performance management area) that together provide an unprecedented level of visibility into performance aspects. But that new opportunities are created (not just in the perf mgmt side) by the metadata made available through the use of such techniques as Spring, SCA and OSGi.

    They don’t in any way replace the existing perf mgmt techniques, but they allow these techniques to be used in a more contextualized way. And again, it’s not just perf mgmt. The value is even more immediate for cross-process instance monitoring, SLA, dependencies, root cause, etc.

  3. One of the reasons we have a large amount of tooling for performance analysis of Java EE applications is because there was finally a standard component architecture and set of supporting service specifications used by developers that had a sufficiently coarse grain interface suitable for instrumentation. It was relatively easy to create a management solution around a few standard component interfaces (EJBHome, EJBObject). Unfortunately not everyone understood the difference between a component and class and hence the overhead for teams both during development and at runtime. Spring approached this problem by recognizing that most people will never be able to make the distinction clear enough and delivered ** some ** similar services but at a smaller cost. Unfortunately this has resulted in an excess of service interfaces with some CMS solutions requiring 500 Spring POJO’s to be created on start-up just to access a simple PDF document. How does one now provide a performance management solution for such architectures as the granularity of the interfaces various so much (much more than EJB). Is is now very hard to offer a bog standard out of the box experience (low overhead) without a large amount of tuning of instrumentation levels (exclusions!).

  4. By the way I am all for meta-data. JXInsight was the first contextual execution trace solution for Java offering more than a code level view.


    FUD 1: “Many Java diagnostics tools in the market are based on Byte Code instrumentation (BCI) technique that requires application instrumentation. It requires in-depth understanding of the application to know which Java components to instrument. In addition to the application knowledge, it also requires specialized skills to use the tools to instrument the application. BCI based tools have high configuration overhead and also add significant performance overhead…. ”

    Configuration overhead? With JXInsight you only have to drop an instrumentation extension pack library into the class path of your server. Runtime overhead? With metering strategies we can deliver the lowest level of overhead whilst providing accurate data which is not the case for sampling.

    Note: Most experts in the performance field (especially those familiar with SPE) know that performance problems cannot be resolved without ** first understanding the application **. That is why performance engineering starts early in the application life cycle recording trace execution paths which are then used as reference when viewing higher level and lower overhead performance data (probes) within a production environment. I would hate to be the operations person tasked with looking at data generated solely from call stack samples with runtime context and a reference application behavioral model.

    FUD 2: “[BCI Tools] They also do not provide visibility for transactions across the Java and DB tiers. All these reasons make the BCI based tools unsuitable for diagnosing application problems in production environment.”

    JXInsight’s Transact (JDBInsight) is the ** only ** solution on the market that relates database transaction patterns (sequence of SQL operations within a XA/Non-XA transactional context). All other tools simply relate an database operation to an entry and exit point (http request) we actually have a transaction manager within our runtime mimicking the operation of a real transaction manager. We can point out multiple resources transactions within a single business transaction (entry-exit) and we can do this across all databases and not just Oracle.

    You know some of us in the industry do care about how we have tackled and solved such problems.

  6. Correction: “I would hate to be the operations person tasked with looking at data generated solely from call stack samples WITHOUT runtime context and a reference application behavioral model.”

  7. Speaking of meta-data (and previously CMDB) what are your thoughts on JCR. I see that JBoss DNA is going to use it as the standard for its information management system. This was something I pushed hard at OpenView in 2004 when they started talking (and talking) about building a federated CMDB solution.

    The implementations of the JCR specification leave a lot to be desired but I do like the specification and programming model with some minor exceptions that I hope will be fixed in 2.0.

  8. How about SEE? S(OA) Enterprise Edition,


  9. Liverath A.

    do we really need a name for the combination of osgi, sca and spring? whenn you put the toaster on the top of he refrigerator to save space in the kitchen you don’t start calling them different, do you?

  10. You must be very tall, Liverath.