November 18th, 2009

IBM feels cozy on sidelines as Oracle-Sun deal languishes in anti-trust purgatory

Posted by Dana Gardner @ 3:44 am

Categories: Apache, BI, Cloud computing, Eclipse, Enterprise Java, HP, Hardware Infrastructure, IBM, Intellectual Property, Java, Microsoft, Open Source, Oracle, SAP, SOA, Silicon Valley, Software Development, Software Infrastructure, Sybase, System Z, Wall Street, business intelligence, database, datacenters, mainframe

Tags: Oracle Corp., Antitrust, Sun Microsystems Inc., Steve Mills, IBM Corp., Programming Languages, Open Source, Java, Databases, Software Development

You have to know when to hold them, and when to fold them. That’s the not just slightly smug assessment by IBM executives as they reflect — with twinkles in their eyes — on the months-stalled Oracle acquisition of Sun Microsystems, a deal that IBM initially sought but then declined earlier this year.

Chatting over drinks at the end of day one of the Software Analyst Connect 2009 conference in Stamford, Conn., IBM Senior Vice President and IBM Software Group Executive Steve Mills told me last night he thinks the Oracle-Sun deal will go through, but it won’t necessarily be worth $9.50 a share to Oracle when it does.

“He (Oracle Chairman Larry Ellison) didn’t understand the hardware business. It’s a very different business from software,” said Mills.

Mills seemed very much at ease with IBM’s late-date jilt of Sun (Sun was apparently playing hard to get in order to get more than $9.40/share from Big Blue’s coffers). IBM’s stock price these days is homing in on $130, quite a nice turn of events given the global economy.

Sun is trading at $8.70, a significant discount to Oracle’s $9.50 bid, reflecting investor worries about the fate of the deal now under scrutiny by European regulators, Mill’s views notwithstanding.

IBM Software Group Vice President of Emerging Technology Rod Smith noted the irony — perhaps ancient Greek tragedy-caliber irony — that a low market share open source product is holding up the biggest commercial transaction of Sun’s history. “That open source stuff is tricky on who actually makes money and how much,” Smith chorused.

Should Mills’s prediction that Oracle successfully maintains its bid for Sun prove incorrect, it could mean bankruptcy for Sun. And that may mean many of Sun’s considerable intellectual property assets would go at fire-sale prices to … perhaps a few piecemeal bidders, including IBM. Smith just smiled, easily shrugging off the chill (socks in tact) from the towering “IBM” logo ice sculpture a few steps away.

And wouldn’t this hold up go away if Sun and/or Oracle jettisoned MySQL? Is it pride or hubris that makes a deal sour for one mere grape? Was the deal (and $7.4 billion) all about MySQL? Hardly.

Many observers think that Sun’s Java technology — and not its MySQL open source database franchise — should be of primary concern to European (and U.S.) anti-trust mandarins. I have to agree. But Mills isn’t too concerned with Oracle’s probable iron-grip on Java …, err licensing. IBM has a long-term license on the technology, the renewal of which is many years out. “We have plenty of time,” said Mills.

Yes, plenty of time to make Apache Harmony a Java doppelganger — not to mention the Java market-soothing effects of OSGi and Eclipse RCP. [Hey, IBM invented Java for the server for Sun, it can re-invent it for something else ... SAP?]

Unlike some software titans, Mills is clearly not living in a “reality distortion field” when it comes to Oracle’s situation.

“We’re in this for the long haul,” said Mills, noting that he and IBM have have been competing with Oracle since August 1993 when IBM launched its distributed DB2 product. “All of our market share comes at the expense of Oracle’s,” said Mills. “And we love to do benchmarks again Oracle.”

Even as the Fates seem to be on IBM’s side nowadays, the stakes remain high for the users of these high-end database technologies and products. It’s my contention that we’re only now entering the true data-driven decade. And all that data needs to run somewhere. And it’s not going to be in MySQL, no matter who ends up owning it.

October 19th, 2009

Speaking of SOA: Are services nouns or verbs?

Posted by Dana Gardner @ 11:09 am

Categories: .NET, Agile Development, Application Lifecycle Management, Cloud computing, Developer Tools, Eclipse, Enterprise Java, IT Service Management, SOA, SOA Governance, SOA architect, Software Development, Software Infrastructure, Web Services, governance, management

Tags: Operation, ZapThink LLC, Policy, SOA, Simple Object Access Protocol, Object-oriented, Service-Oriented Architecture (SOA), Web Services, SOAP, Ooa/Ood/Oop

This guest post comes courtesy of Jason Bloomberg, managing partner at ZapThink.

By Jason Bloomberg

ZapThink revels in stirring up controversy almost as much as we enjoy clarifying subtle concepts that give architects that rare “aha!” moment as they finally discern the solution to a particularly knotty design problem. Last month’s “process isomorphism” ZapFlash, therefore, gave us a particular thrill, because we received kudos from enterprise architects for streamlining the connections between Business Process Management (BPM) and Service-Oriented Architecture (SOA), while at the same time, several industry pundits demurred, disagreeing with our premise that services should correspond one-to-one with tasks or subtasks in a process.

Maybe we got it wrong, and inadvertently mislead our following of architects? Or perhaps the pundits were off base, and somehow ZapThink saw clearly a best practice that remained obscure to other experts in the field?

Upon further consideration, the true answer lies somewhere in between these extremes. Now, we’re not reconsidering the conclusions of the process isomorphism ZapFlash. Rather, further explanation and clarification is warranted.

As with any best practice, process isomorphism doesn’t apply in every situation, and not every service should correspond to a process task or subtask. That being said, there is also a good chance that some of our esteemed fellow pundits might not be opining from a truly service-oriented perspective, as many of their comments hint at an object-oriented (OO) bias that may be too limiting in the SOA context.

In fact, understanding which services the process isomorphism pattern applies to, and how other services support such services goes to the heart of how to think about services from a SOA perspective.

The object-oriented context for services

In the early days of web services, as various standards committee members tried to hash out how core standards should support the vision of SOA, the SOAP standard for message transport was an acronym for the “Simple Object Access Protocol.” The reasoning at the time was that services were interfaces to objects, and hence service operations should correspond to object methods, also known as remote procedures.

SOAP was nothing more than a simple, XML-based way of access those methods. Over time, however, people realized that taking this Remote Procedure Call (RPC) approach to service interfaces is too limiting: It leads to tightly coupled, synchronous interactions that constrain the benefits such services could offer. Instead, the industry settled on document style as being the preferred interface style, which expects requests and responses to conform to schemas that are included in the service contracts by reference, where the underlying service logic is responsible for validating interactions against the relevant schemas.

Document style interfaces provide greater loose coupling than their RPC-style cousins because many changes to a service need not adversely impact existing service consumers, and furthermore, document style interfaces facilitate asynchronous interactions where a request need not correlate immediately with a response. In fact, the W3C eventually dropped the “Simple Object Access Protocol” definition of SOAP altogether, and now SOAP is just SOAP, instead of being an abbreviation of anything.

The answer is straightforward: If a service has no operations, then what it’s supposed to do is understood from the context of the service itself.

However, document style interfaces still allow for operations, only now they’re optional rather than mandatory as is the case with RPC-style interfaces. The fact that operations are optional is a never-ending sense of confusion for students in our Licensed ZapThink Architect course, perhaps because of the object-oriented pattern of thinking many of today’s techies follow, often without realizing it.

How would you ever know what a service is supposed to do, the reasoning goes, if you don’t call an operation on that service? The answer is straightforward: if a service has no operations, then what it’s supposed to do is understood from the context of the service itself. For example, an insurance company may want a service that simply approves a pending insurance policy. If we have an approvePolicy Service, the consumer can simply request that service with the policy number of the policy it wants to approve.

Nouns vs. Verbs

The insurance policy example brings up a fundamental question. Which is the service, the insurance policy entity or the approve policy task? In other words, should services be nouns or verbs? It’s possible to design services either way, as Entity Services, which predictably represent business entities, or as Task Services, that represent specific actions that implement some step in a process, in other words, verbs. Which approach is better?

If you look at the question of whether services should be nouns or verbs from the OO perspective, then services are little more than interfaces to objects, and hence it’s best to think of services as nouns and their operations as the verbs. For example, following the OO approach, we might have an insurance policy object with several operations, including one that approves the policy, as the following pseudocode illustrates:

myPolicy = new Policy (); … successOrFailure = myPolicy.approve ();

The first statement above instantiates a particular policy, while the second one approves it, and returns either success or failure.

Now, it is certainly possible to create a Policy Service as an Entity Service that has an approve operation that works more or less like the example above, with one fundamental difference: because services are fundamentally stateless, you don’t instantiate them. Here, then, is pseudocode that represents how an Entity Service would tackle the same functionality:

request to create new policy, specifying create policy operation –> Policy Service –> response with policy number 12345
…
request to approve policy 12345, specifying approve policy operation –> Policy Service –> response with success or failure

Note that we’re representing service interactions as input and output messages that contain documents, where in this case, the input documents specify operations. In this example, there is no object in the OO sense representing policy 12345 and maintaining the state information that indicates whether or not that particular policy is approved or not.

Instead, the underlying service implementation maintains the state information. There is only the one Policy Service, and it accepts requests in the form of XML documents and returns responses, also in the form of XML documents. If a request calls the create policy operation, then the Policy Service knows to create the policy, while a request that specifies the approve policy operation follows the same pattern.

Note that the fact that the Policy Service has a document style interface gives us two advantages: First, we can make certain changes to the service like adding new operations without adversely impacting existing consumers, and second, its stateless nature enables asynchronous interactions, where instead of returning success or failure of the approve request, perhaps, the service returns a simple acknowledgment of the request (or perhaps no response at all), and then notifies the consumer at some point in the future that the policy has been approved, either through a one-way notification event or possibly as a response to a further query.

Task services as verbs

While there is a significant role for Entity Services in SOA, it is important to break free from OO-centric thinking and consider other types of services as well that serve other purposes. In fact, there is another way of offering the same functionality as the Entity Service above where the Services represent verbs rather than nouns, what we call Task Services. Here is the pseudocode for this situation:

request to create new policy –> createNewPolicy Service –> response with policy number 12345
…
request to approve policy 12345 — > approvePolicy Service –> response with success or failure

In this example, neither Task Service has any operations, but rather the functionality of each Service is understood from the context of the Service. After all, what would an approvePolicy Service do but approve policies? If you read the process isomorphism ZapFlash, the benefits of delivering capabilities as Task Services is clear. If you design each Task Service to represent tasks or subtasks in business processes, then it’s possible to build a service-oriented business application (SOBA) that is isomorphic to the process it implements.

Combining entity and task services

A casual reading of the process isomorphism ZapFlash might lead you to think we were suggesting that all services should be Task Services. However, in spite of the fact that architects with OO backgrounds often rely too heavily on Entity Services, such services do play a critical role in most SOA implementations.

Remember that in the enterprise context, services expose existing, legacy capabilities and data that are typically scattered across different applications and data stores, limiting the enterprise’s agility and leading to high integration maintenance costs, poor data quality, reduced customer value, and other ills all too familiar to anybody working within a large organization’s IT department. SOA provides best practices for addressing such issues by abstracting such legacy capabilities in order to support flexible business processes.

Both Entity and Task Services help architects connect the dots between legacy capabilities on the one hand, and flexible process requirements on the other, as the figure below illustrates:

In the figure above, the bottom row contains Entity Services, which directly abstract underlying legacy capabilities. Above the Entity Services lie the Task Services, which may actually be abstractions of individual operations belonging to underlying Entity Services. The top layer contains Process Services, which are typically compositions of Task Services. In other words, Process Services are interfaces to SOBAs, and when those SOBAs are compositions of properly designed Task Services, they will exhibit process isomorphism.

The essential question for the architect is which capabilities to abstract in which service layer. Take for example the Address Change Task Service. Changing addresses is a common example of a particularly challenging task in many large organizations, because address information is typically maintained by different applications and data stores in a haphazard, inconsistent manner. To make matters worse, there may be addresses associated with customers, policies, or other business entities.

When architecting the Customer Entity Service, the core design principle is to pull together the various instances of customer-related information and functionality across the as-is legacy environment into a single, consolidated representation. Such a Service will likely have an update address operation, and the Customer Entity Service’s logic will encapsulate whatever individual queries and API calls are necessary to properly update customers’ addresses across all relevant systems.

The Address Change Task Service, then, abstracts the Customer Entity Service’s update address operation, as well as whatever other address change operations other Entity Services might have. The Service logic behind this Task Service understands, for example, that insured properties in polices have addresses and customers have addresses, and these addresses are related in a particular way, but are by no means equivalent.

The ZapThink take

As is usually the case, architects have several options at their disposal, and knowing which option is appropriate often depends on the business problem, an example of the “right tool for the job” principle. If the business problem is process-centric, say, a need to streamline or optimize the policy issuance process, then implementing SOBAs as compositions of Task Services will facilitate process flexibility.

In other cases, the business problem is more information-centric than process-centric, for example, putting consolidated customer information on a call center rep’s screen. In such instances the architect’s focus may be on an Entity Service, because the rep is dealing with a particular customer and must be able to interact with that customer in a flexible way.

The big picture of the SOA architect’s challenge, of course, is delivering agility in the face of heterogeneity. On the one hand, the IT shop contains a patchwork of legacy resources, and on the other hand, the business requires increasingly agile processes. Understanding which capabilities belong in Entity Services and which belong in Task Services is a critical part of the best practice approach to SOA.

This guest post comes courtesy of Jason Bloomberg, managing partner at ZapThink.

---

SOA and EA Training, Certification and Networking Events

In need of vendor-neutral, architect-level SOA and EA training? ZapThink’s Licensed ZapThink Architect (LZA) SOA Boot Camps provide four days of intense, hands-on architect-level SOA training and certification.

Advanced SOA architects might want to enroll in ZapThink’s SOA Governance and Security training and certification courses. Or, are you just looking to network with your peers, interact with experts and pundits, and schmooze on SOA after hours? Join us at an upcoming ZapForum event. Find out more and register for these events at http://www.zapthink.com/eventreg.html.

---

October 13th, 2009

Engine Yard draws funding as it ushers more developers onto the Ruby services train

Posted by Dana Gardner @ 10:55 am

Categories: .NET, Agile Development, Amazon, Apache, Developer Tools, Eclipse, Enterprise Java, Google, JBoss, Java, Microsoft, Open Source, SaaS, Software Development, Software Infrastructure, Testing Tools, Virtualization, Web Services, Web Technology

Tags: Developer, Java, Ruby, Tony, Engine Yard, Ruby On Rails, Scripting Languages, Software/Web Development, Web Development, Dana Gardner

This guest post comes courtesy of Tony Baer’s OnStrategies blog. Tony is a senior analyst at Ovum.

Developers are a mighty stubborn bunch. Unlike the rest of the enterprise IT market, where a convergence of forces have favored a nobody gets fired for buying IBM, Oracle, SAP, or Microsoft, developers have no such herding instincts. Developers do not always get with the [enterprise] program.

For evidence, recall what happened the last time that the development market faced such consolidation. In the wake of web 1.0, the formerly fragmented development market – which used to revolve around dozens of languages and frameworks – congealed down to Java vs .NET camps. That was so 2002, however, as in the interim, developers have gravitated toward choosing their own alternatives.

The result was an explosion of what former Burton Group analyst Richard Monson Haefel termed the Rebel Frameworks (that was back in 2004), and more recently in the resurgence of scripting languages. In essence, developers didn’t take the future as inevitable, and for good reason: the so-called future of development circa 2002 was built on the assumption that everyone would gravitate to enterprise-class frameworks.

Java and .NET were engineered on the assumption that the future of enterprise and Internet computing would be based on complex, multitier distributed transactional systems. It was accompanied by a growing risk-aversion: Buy only from vendors that you expect will remain viable. Not surprisingly, enterprise computing procurements narrowed to IOSM (IBM, Oracle, SAP, Microsoft).

Different dynamic

But the developer community lives to a different dynamic. In an age of open source, expertise for development frameworks and languages get dispersed; vendor viability becomes less of a concern. More importantly, developers only want to get the job done, and anyway, the tasks that they perform typically fall under the enterprise radar.

Whereas a CFO may be concerned over the approach an ERP system may employ to managing financial system or supply chain processes, they are not going to care about development languages or frameworks.

The result is that developers remain independent minded, and that independence accounts for the popularity of alternatives to enterprise development platforms, with Ruby on Rails being the latest to enter the spotlight.

In one sense, Ruby’s path to prominence parallels Java in that the language was originally invented for another purpose. But there the similarity ends as, in Ruby’s case, no corporate entity really owned it. Ruby is a simple scripting language that became a viable alternative for web developers once David Heinemeier Hansson invented the Rails framework. The good news, Rails makes it easy to use Ruby to write relatively simple web database applications. Examples of Rails’ simplicity include:

• Eliminating the need to write configuration files for mapping requests to actions
• Avoiding multi-threading issues because Rails will not pool controller (logic) instances
• Dispensing with object-relational mapping files; instead, Rails automates much of this and tends to use very simplified naming conventions.

The bad news is that there are performance limitations and difficulties in handling more complex distributed transaction applications. But the good news is that when it comes to web apps, the vast majority are quite rudimentary, thank you.

The result has propelled a wave of alternative stacks, such as LAMP (Linux-Apache web server-MySQL-and either PHP, Python, or Perl) or, more recently, Ruby on Rails. At the other end of the spectrum, the Spring Framework takes the same principle – simplification – to ease the pain of writing complex Java EE applications – but that’s not the segment addressed by PHP, MySQL, or Ruby on Rails. It reinforces the fact that, unlike the rest of the enterprise software market, developers don’t necessarily take orders from up top. Nobody told them to implement these alternative frameworks and languages.

Although hardly the only cloud provider out there that supports RoR development, Engine Yard’s business is currently on a 2x growth streak. Funding stages the company either for IPO or buy out.

The latest reminder of the strength of grassroots markets in the developer sector is Engine Yard’s securing of $19 million in C funding last week. The backing comes from some of the same players that also funded SpringSource (which was recently acquired by VMware). Some of the backing also comes from Amazon, whose Jeff Bezos owns outright 37Signals, the Chicago-based provider of project management software that employs Heinemeier Hansson. For the record, there is plenty of RoR presence in Amazon Web Services.

Engine Yard is an Infrastructure-as-a-Service (IaaS) provider that has optimized the RoR stack for runtime. Although hardly the only cloud provider out there that supports RoR development, Engine Yard’s business is currently on a 2x growth streak. Funding stages the company either for IPO or buy out.

At this point the script sounds similar to SpringSource whose new owner, VMware, is launching a development and runtime cloud that will eventually become VMware’s Java counterpart to Microsoft Azure.

It’s tempting to wonder whether a similar path will become reality for Engine Yard. The answer is that the question itself is too narrow. It is inevitable that a development and runtime cloud paired with enterprise plumbing (e.g., OS, hypervisor) will materialize for Ruby on Rails. With its $19 million funding, Engine Yard has the chance to gain critical mass mindshare in the RoR community – but don’t rule out rivals like Joyent yet.

This guest post comes courtesy of Tony Baer’s OnStrategies blog. Tony is a senior analyst at Ovum.

August 20th, 2009

SpringSource Enterprise Java Cloud Foundry mixes best of open source with PaaS for application lifecycle efficiency

Posted by Dana Gardner @ 9:51 am

Categories: .NET, Agile Development, Amazon, Apache, Application Lifecycle Management, Cloud computing, Developer Tools, Eclipse, Enterprise Java, Google, Internet, Java, Microsoft, Open Source, Oracle, Software Development, Software Infrastructure, Virtualization, Web Services, Windows, datacenters

Tags: Java Application, Foundry Networks Inc., Open Source, PaaS, VMware Inc., SpringSource, Programming Languages, Java, Software Development, Software/Web Development

Take the BriefingsDirect middleware/ESB survey now.

SpringSource made headlines last week when VMware scooped up the Java infrastructure and management firm for $420 million in a move to breed easier cloud migration. Now, the spotlight is on the San Mateo, Calif. company once again as it leverages one of its own recent cloud industry acquisitions.

On Wednesday, SpringSource rolled out a beta of Cloud Foundry, an enterprise Java cloud offering that lets developers deploy and manage Spring, Grails and Java applications in a public cloud environment.

SpringSource is essentially offering a self-service, pay-as-you-go, public cloud deployment platform on which to build, run and manage the entire Java Web application lifecycle. Nice! Cloud Foundry promises to launch and automatically scale Java Web applications in the cloud with a few clicks of a mouse.

This is the clear path for open source and Java developers to the cloud. Microsoft will have its hands full just keeping the .NET developers and operators on the farm, so to speak.

The ability to develop Java applications in the cloud quickly with quality only further eases the deployment of Java applications into cloud containers, either internal, external or both. This must be VMware’s thinking … get the developers on board, and the operators will follow. It’s worked before. Only this time it’s the virtualized container that’s the target — the cloud OS, rather than the platform OS. And it’s the cloud container that now benefits from the tools-to-target synergy.

This also makes moot the rip and replace argument against changing from installed platforms (like Windows). When you’re moving the runtime up into a cloud, you don’t care what the underlying platform is. You want to be able to develop well, and then get your operations requirements met on on performance, security and cost.

Because these are Java applications, this will appeal to the mission-critical apps set along those requirements. When enterprise CIOs begin to gain the insights into IT financial management of their traditional development and deployment strategies — and then compare and constrast to these cloud lifecycle methods and costs — the worm then turns.

The vision we’re seeing from VMware and others speaks to dramatically cutting the total and ongoing cost of IT when the full development and deployment equation is factored. It’s about Moore’s Law moving off of the silicon and up and into the clouds.

Rod Johnson, CEO of SpringSource, is bragging about the benefits of Cloud Foundry:
“Unlike competitive offerings, our cloud service does not come with compromises; companies can deploy full-feature Java Web applications, built using SpringSource tools. C-level technology executives can seamlessly add cloud computing as a strategic option as part of their development roadmap.”

SpringSource is once again demonstrating the power of open source in the cloud by adding another piece of the “Java in the cloud” puzzle. Cloud Foundry plays off the strength of SpringSource core technologies. But SpringSource is also leveraging technologies from other developers to flesh out the big picture.

For example, SpringSource will rely on Hyperic CloudStatus to gain cloud health monitoring data. SpringSource will also tap Hyperic HQ-powered functionality to offer insights into application performance and service levels. Hyperic HQ works with Cloud Foundry’s technology to automatically scale cloud deployments by understanding how applications are working and interacting with other IT resources.

The VMware Connection

Of course, SpringSource holds several pieces of the “Java in the cloud” puzzle internally. Beyond Cloud Foundry, there’s SpringSource’s tc Server. Based on Apache Tomcat, it provides a lightweight container for deploying Java Web applications in the cloud. SpringSource is also ramping up quickly to make its Tool Suite available within the next 90 days. The Tool Suite will offer direct deployment of Java applications—through Cloud Foundry—into the public cloud.

How does this fit into VMware? SpringSource plans to bring Cloud Foundry’s capabilities to VMware’s vCloud service provider partners and internal VMware vSphere environments to offer infrastructure choice, deployment flexibility and enterprise services.

SpringSource will offer the same capabilities to Amazon Web Services, and plans to enrich Cloud Foundry’s capabilities with enhanced cloud management features and new services in the coming months.

Take the BriefingsDirect middleware/ESB survey now.

BriefingsDirect contributor Jennifer LeClaire provided editorial assistance and research on this post. She can be reached here and here.

August 17th, 2009

Understanding the value of reference architectures in the SOA story

Posted by Dana Gardner @ 6:40 am

Categories: .NET, Apache, Cloud computing, Developer Tools, Eclipse, Enterprise Java, HP, IBM, ITIL, Java, Microsoft, Open Source, Red Hat, SOA, SOA Governance, SOA architect, Software Development, Software Infrastructure, datacenters, management

Tags: ZapThink LLC, Cookbook, SOA, Architecture, Ron Schmelzer, Architecture Framework, RA, Service-Oriented Architecture (SOA), Web Services, Middleware

This guest post comes courtesy of ZapThink. Ron Schmelzer is a senior analyst at ZapThink. You can reach him here.

Take the BriefingsDirect middleware/ESB survey now.

By Ron Schmelzer

There’s nothing more that architects love to do than argue about definitions. If you ever find yourself with idle time in a room of architects, try asking for a definition of “service” or “architecture” and see what sort of creative melee you can start.

That being said, definitions are indeed very important so that we can have a common language to communicate the intent and benefit of the very things we are trying to convince business to invest in. From that perspective, a number of concepts have emerged in the past decade or so that have become top of mind for self-styled enterprise architects: architecture frameworks and reference architectures.

In previous ZapFlashes, we discussed architecture frameworks, which leaves the topic of reference architectures left untouched by ZapThink. Since we can’t leave a good argument behind, we’re going to use this ZapFlash to explore what reference architectures are all about and what value they have to add to the Service-Oriented Architecture (SOA) story.

What is a reference architecture?

One commonly accepted definition for reference architecture is that it provides a methodology and/or set of practices and templates that are based on the generalization of a set of successful solutions for a particular category of solutions. Reference architectures provide guidance on how to apply specific patterns and/or practices to solve particular classes of problems. In this way, it serves as a “reference” for the specific architectures that companies will implement to solve their own problems. It is never intended that a reference architecture would be implemented as-is, but rather used either as a point of comparison or as a starting point for individual companies’ architectural efforts.

Others refine the definition of reference architecture as a description of how to build a class of artifacts. These artifacts can be embodied in many forms including design patterns, methodologies, standards, metadata, and documents of all sorts. Long story short, if you need guidance on how to develop a specific architecture based on best practices or authoritative sets of potential artifacts, you should look to a reference architecture that covers the scope of the architecture that you’re looking to build.

One of the most popular examples of reference architectures in IT is the Java Platform Enterprise Edition (Java EE) architecture, which provides a layered reference architecture and templates addressing a range of technology and business issues that have guided many Java-based enterprise systems.

Reference architectures vs. architecture frameworks

While the above definition(s) may seem fairly cut and dried, there is a lot in common between the concepts of reference architectures and architecture frameworks. For some, this is where things get dicey and definitions get blurry. Architecture frameworks, such as the Zachman Framework, the Open Group Architecture Framework (TOGAF), and Department of Defense Architecture Framework (DoDAF) provide approaches to describe and identify necessary inputs to a particular architecture as well as means to describe that architecture. [Disclosure: The Open Group is a sponsor of BriefingsDirect podcasts.]

If a particular architecture is a cookbook that provides guidance on how to go about solving a particular set of problems with a particular approach, an architecture framework is a book about how to write cookbooks. So, architecture frameworks give enterprise architects the tools they need to adequately describe and collect requirements, without mandating any specific architecture type. More specifically, architecture frameworks describe an example taxonomy of the kinds of architectural “views” that an architect might consider developing, and why, and provides guidelines for making the choice for developing particular views.

This differs from the above concept of a reference architecture in that a reference architecture

Both frameworks and RAs provide best practices, and while it might be argued that RAs provide more of a methodology than a framework does, RAs are still not really characterized by their methodology component

goes one step further by accelerating the process for a particular architecture type, helping to identify which architectural approaches will satisfy particular requirements, and figuring out what a minimally acceptable set of architectural artifacts are needed to meet the “best practices” requirements for a particular architecture. To continue our analogy with cookbooks, if an architecture framework is a book on how to write cookbooks, then a reference architecture is a book that provides guidance and best practices on how to write cookbooks focused on weight loss, for example. This would then mean that the particular architecture you develop for your organization would be a specific cookbook that provides weight-loss recipes targeted to your organization. Indeed, if you get puzzled with the definitions, replacing the term “architecture” with “cookbook” is helpful: cookbook frameworks, reference cookbooks, and your particular cookbook.

Furthermore, most reference architectures emphasize the “template” part of the definition of a reference architecture. Both frameworks and RAs provide best practices, and while it might be argued that RAs provide more of a methodology than a framework does, RAs are still not really characterized by their methodology component. Most can be characterized by their template component, however. From this perspective, patterns are instances of templates in this context. In fact, multiple reference architectures for the same domain are allowable and quite useful. Reference architectures can be complementary providing guidance for a single architecture, such as SOA, from multiple viewpoints.

The value of a SOA reference architecture

In many ways, SOA projects are in desperate need of well-thought out reference architectures. ZapThink sees a high degree of variability in SOA projects. Some flourish and succeed while others flounder and fail. Many times the reason for failure can be traced to bad architectural practices, premature infrastructure purchasing, and inadequate governance and management. Other times the failure is primarily organizational. However, what is common in most successes is well-documented and/or communicated architectural practices and a systematic method for learning from one’s mistakes and having a low cost of failure.

Furthermore, we find that many architects spend a significant amount of their time researching, investigating, (re-)defining, contemplating, and arguing architectural decisions. In many cases, these architects are reinventing the wheel as their peers in other companies, or even the same company, have already spent that time and effort defining their own architectural practices. This extra effort is not only inefficient, but also prevents the company from learning from its own experiences and applying that knowledge for increased effectiveness.

From this perspective, SOA reference architectures can provide some help to those struggling

While the OASIS SOA Reference Architecture is certainly not the only valid one on the block, it certainly makes a good starting point for those looking for a vendor-neutral SOA reference architecture on which to base their own architectural efforts.

with their SOA efforts or thinking about launching a new one. SOA reference architectures allow organizations to learn from other architects’ successes and failures and inherit proven best practices. Reference architectures can provide missing architectural information that can be provided in advance to project team members to enable consistent architectural best practices. In this way, the SOA reference architecture provides a base of assets that SOA efforts can draw from throughout the project lifecycle.

Indeed, in order to gain the promised SOA benefits of reuse, reduced redundancy, reduced cost of integration, and increased visibility and governance, companies need to apply their SOA efforts in a consistent manner. This means more than buying and establishing some vendor’s infrastructure as a corporate standard or adhering to the latest WS-* standards stack. SOA reference architectures can serve as the basis for disparate SOA efforts throughout the organization, even if they use different tools and technologies. Good SOA reference architectures provide SOA best practices and approaches in a vendor-, technology-, and standards-independent way. Therefore, don’t go hunting for one from your favorite vendor of choice. In fact, if you got your SOA reference architecture from that vendor, you might want to consider dropping it in lieu of something more vendor-neutral.

In particular, OASIS offers a SOA Reference Architecture (RA) that “models the abstract architectural elements for a SOA independent of the technologies, protocols, and products that are used to implement a SOA. Some sections of the RA will use common abstracted elements derived from several standards.” Their approach uses the concept of “patterns” to identify different methods and approaches for implementing different parts of the architectural picture. While the OASIS SOA Reference Architecture is certainly not the only valid one on the block, it certainly makes a good starting point for those looking for a vendor-neutral SOA reference architecture on which to base their own architectural efforts.

The ZapThink take

Enterprise architects needs all the help they can get to make sure that they deliver reliable, agile, resilient, vendor-neutral architectures to their organization that meet the continuously changing requirements of the business. While certainly the art and practice of enterprise architecture continues to mature, companies should look to borrow as much best practices as they can and learn from others who have already gone down the EA and SOA path. If you plan to learn SOA, or any form of EA for that matter, as you go along, or even worse, from a vendor, then you risk the entire success of your SOA efforts. Rather, leverage (for free) SOA reference architectures so that you can advance at a faster pace and lower risk.

Bernard of Chartres put it best in the well-known saying: “We are like dwarfs on the shoulders of giants, so that we can see more than they, and things at a greater distance, not by virtue of any sharpness of sight on our part, or any physical distinction, but because we are carried high and raised up by their giant size.” Stand on the shoulders of other enterprise architecture giants and let them increase your vision and success.

This guest post comes courtesy of ZapThink. Ron Schmelzer, a senior analyst at ZapThink, can be reached here.

Take the BriefingsDirect middleware/ESB survey now.

---

SOA and EA Training, Certification,
and Networking Events

In need of vendor-neutral, architect-level SOA and EA training? ZapThink’s Licensed ZapThink Architect (LZA) SOA Boot Camps provide four days of intense, hands-on architect-level SOA training and certification.

Advanced SOA architects might want to enroll in ZapThink’s SOA Governance and Security training and certification courses. Or, are you just looking to network with your peers, interact with experts and pundits, and schmooze on SOA after hours? Join us at an upcoming ZapForum event. Find out more and register for these events at http://www.zapthink.com/eventreg.html.

August 14th, 2009

HP partners with iTKO on LISA services testing suite for SOA, BPM

Posted by Dana Gardner @ 9:56 am

Categories: .NET, Agile Development, Amazon, Cloud computing, Developer Tools, Eclipse, Enterprise Java, HP, IT Management, IT Service Management, ITIL, Open Source, SOA, SOA Governance, SOA architect, Software Development, Software Infrastructure, Testing Tools, Virtualization, Web Services, datacenters, governance, management

Tags: Hewlett-Packard Co., BPM, iTKO, SOA, System Dependency, Service-Oriented Architecture (SOA), Cloud Computing, Virtualization, Storage Management, Utility Computing

Take the brief middleware use online survey.

When HP inks a deal to resell your testing software, you know you must be doing something right.

HP is reselling iTKO’s LISA Virtualize product, a suite of test, validation and virtualization solutions optimized for distributed, multi-tier applications that leverage SOA, BPM, cloud computing, integration suites and ESBs. HP’s aim is to help customers reduce testing costs and speed the time to market for modern applications. [Disclosure: HP and iTKO are sponsors of BriefingsDirect podcasts.]

How does LISA help HP’s Quality and Performance Management solutions suite? By eliminating common system infrastructure dependencies during application testing. The idea is to trim both the cost and risk of modern Quality Assurance – a major issue for today’s enterprise.

Here’s how it works: LISA Virtualize does away with system dependency constraints by simulating the dynamic behavior and performance conditions of downstream system dependencies. In other words, you can see how systems react and respond as if they were running live – but they aren’t running live. That saves time and money.

Jonathan Rende, vice president and general manager of the Business Technology Optimization Applications, Software and Solutions group at HP, said: “Customers can reduce costs and speed up their ability to respond to business needs by modernizing their applications.”

By bringing together HP Quality Center and HP Performance Center solutions with iTKO’s LISA Virtualize software, Rende said customers can remove delay-causing system dependencies during testing processes. The result: saving time and lowering the cost of delivering complex applications.

To be sure, putting quality top of mind earlier in the development process is a key to reducing defects and speeding time to market. And Shridhar Mittal, iTKO’s CEO, claims the company’s virtualization capabilities lower test lab costs by up to 65 percent and shortening software release cycles by up to 38 percent.

If those claims hold true, it’s easy to see why HP is partnering with this young company. The running theme with this announcement is saving time and money – both critical selling points in a down economy.

Take the brief middleware use online survey.

BriefingsDirect contributor Jennifer LeClaire provided editorial assistance and research on this post. She can be reached here and here.

August 12th, 2009

Cloud computing proves a natural for offloading time-consuming test and development processes

Posted by Dana Gardner @ 10:51 am

Categories: .NET, Agile Development, Amazon, Application Lifecycle Management, Cloud computing, Developer Tools, Eclipse, Enterprise Java, Google, Java, Microsoft, Open Source, Podcasts, SOA, SOA Governance, SOA architect, SaaS, Software Development, Software Infrastructure, Testing Tools, VMware, Virtualization, Web Technology, Windows, datacenters, management

Tags: Podcasts, Cloud Computing, Virtualization, Internet, Hardware, Dana Gardner

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download or view the transcript. Learn more. Sponsor: Electric Cloud.

Our latest podcast discussion centers on using cloud computing technologies and models to improve the test and development stages of applications’ creation and refinement. One area of cloud computing that has really taken off and generated a lot of interest is the development test and performance proofing of applications — all from an elastic cloud services fabric.

The build and test basis of development have traditionally proven complex, expensive, and inefficient. Periodic bursts of demand on runtime and build resources are the norm. By using a cloud approach, the demand burst can be accommodated better through dynamic resources, pooling, and provisioning.

We’ve seen this done internally for development projects and now we’re starting to see it applied increasingly to external cloud resource providers like Amazon Web Services. And Microsoft is getting into the act too.

To help explain the benefits of cloud models for development services and how to begin experimenting and leveraging external and internal clouds — perhaps in combination — for test resource demand and efficiency, I recently interviewed Martin Van Ryswyk, vice president of engineering at Electric Cloud, and Mike Maciag, CEO at Electric Cloud.

Here are some excerpts:

Van Ryswyk: Folks have always wanted their builds to be fast and organized and to be done with as little hardware as possible. We’ve always struggled to get enough resources applied to the build process.

One of the big changes is that folks like Amazon have come along and really made this accessible to a much wider set of build teams. The dev and test problem really lends itself to what’s been provided by these new cloud players.

Maciag: The traditional approaches of the overnight build, or even to the point of what people refer to as continuous integration, have fallen short, because they find problems too late. The best world is where engineers or developers find problems before they even check in their code and go to a preflight model, where they can run builds and tests on production class systems before checking in code in the source code control system.

Van Ryswyk: At a certain point, you just want it to happen like a factory. You want to be able to have builds run automatically. That’s what ElectricCommander does. It orchestrates that whole process, tying in all the different tools, the software configuration management (SCM) tools, defect tracking tools, reporting tools, and artifact management — all of that — to make it happen automatically.

And that’s really where the cloud part comes in. … Then, you’re bringing it all back together for a cohesive end report, which says, “Yes, the build worked.” ElectricCommander was already allowing customers to manage the heterogeneity on physical machines and virtual machines (VMs). With some integrations we’ve added you can now extend that into the cloud.

There will be times when you need a physical machine, there will be times when your virtual environment is right, and there will be times when the cloud environment is right. … We may not want to put our source code out in the cloud but we can use 500 machines for few hours to do some load, performance, or user interface testing. That’s a perfect model for us.

… When you have these short duration storms of activity that sometimes require hundreds and hundreds of computers to do the kind of testing you want to do, you can rent it, and just use what you need. Then, as soon as you’re done with your test storm, it goes away and you’re back to the baseline of what you use on average.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download or view the transcript. Learn more. Sponsor: Electric Cloud.

August 12th, 2009

VMware fleshes out its cloud computing support model with SpringSource grab

Posted by Dana Gardner @ 8:25 am

Categories: .NET, Agile Development, Amazon, Apache, Application Lifecycle Management, Cloud computing, Developer Tools, Eclipse, Enterprise Java, Google, JBoss, Java, Linux, Microsoft, Open Source, Oracle, Red Hat, SOA, SOA Governance, SOA architect, Silicon Valley, Software Development, Software Infrastructure, VMware, Virtualization, Windows, datacenters

Tags: Cloud Computing, VMware Inc., SpringSource, Tony, Virtualization, Hardware, Dana Gardner

This guest post comes courtesy of Tony Baer’s OnStrategies blog. Tony is a senior analyst at Ovum. His profile is here. You can reach him here.

VMware’s proposed $362 million acquisition of SpringSource is all about getting serious in competing with Salesforce.com and Google App Engine as the Platform-as-a-Service (PaaS) cloud with the technology that everybody already uses.

This acquisition was a means to an end, pairing two companies that could not be less alike. VMware is a household name, sells software through traditional commercial licenses, and markets to IT operations. SpringSource is a grassroots, open source developer-oriented firm whose business is a cottage industry by comparison. The cloud brought both companies together that each faced complementary limitations on their growth. VMware needed to grow out beyond its hardware virtualization niche if it was to regain its groove, while SpringSource needed to grow up and find deeper pockets to become anything more than a popular niche player.

The fact is that providing a virtualization engine, even if you pad it with management utilities that act like an operating system, is still a raw cloud with little pull unless you go higher up in the stack. Raw clouds have their appeal only to vendors that resell capacity or enterprise large firms with the deep benches of infrastructure expertise to run their own virtual environments. For the rest of us, we need a player that provides a deployment environment, handles the plumbing, that is married to a development environment. That is what Salesforce’s Force.com and Google’s App Engine are all about. VMware’s gambit is in a way very similar to Microsoft’s Software + Services strategy: use the software and platforms that you are already used to, rather than some new

The most glaring omission is need for Java object distributed caching to provide yet another alternative to scalability.

environment in a cloud setting. There’s nothing less familiar to large IT environments than VMware’s ESX virtualization engine, and in the Java community, there’s nothing more familiar than the Spring framework which – according to the company – accounts for roughly half of all Java installations.

With roughly $60 million in stock options for SpringSource’s 150-person staff, VMware is intent on keeping the people as it knows nothing about the Java virtualization business. Normally, we’d question a deal like this because the company’s are so dissimilar. But the fact that they are complementary pieces to a PaaS offering gives the combination stickiness.

For instance, VMware’s vSphere’s cloud management environment (in a fit of bravado, VMware calls it a cloud OS) can understand resource consumption of VM containers; with SpringSource, it gets to peer inside the black box and understand why those containers are hogging resource. That provides more flexibility and smarts for optimizing virtualization strategies, and can help cloud customers answer the question: do we need to spin out more VMs, perform some load balancing, or re-apportion all those Spring TC (Tomcat) servlet containers?

The addition of SpringSource also complements VMware’s cloud portfolio in other ways. In his blog about the deal, SpringSource CEO Rod Johnson noted that the idea of pairing VMware’s Lab Manager (that’s the test lab automation piece that VMware picked up through the Akimbi acquisition) proved highly popular with Spring framework customers. In actuality, if you extend Lab manager from simply spinning out images of testbeds to spinning out runtime containers, you would have VMware’s answer to IBM’s recently-introduced WebSphere Cloudburst appliance.

VMware isn’t finished however. The most glaring omission is need for Java object distributed caching to provide yet another alternative to scalability. If you only rely on spinning out more VMs, you get a highly rigid one-dimensional cloud that will not provide the economies of scale and flexibility that clouds are supposed to provide. So we wouldn’t be surprised if GigaSpaces or Terracotta might be next in VMware’s acquisition plans.

This guest post comes courtesy of Tony Baer’s OnStrategies blog . Tony is a senior analyst at Ovum. His profile is here. You can reach him here.

July 17th, 2009

The cloud gets up close and personal

Posted by Dana Gardner @ 6:48 am

Categories: .NET, Agile Development, Amazon, Application Lifecycle Management, Cloud computing, Developer Tools, Eclipse, Google, HP, IT Service Management, Microsoft, Open Source, Red Hat, SOA, SOA Governance, SOA architect, Software Development, Software Infrastructure, Testing Tools, Virtualization, datacenters

Tags: Developer, iTKO, Service, Cloud, OSGi, Cloud Computing, Storage Management, Virtualization, Utility Computing, Storage

Can you fit a cloud on your laptop?

Probably not.

But you can mock up basic cloud services, such as those for a shopping cart application, on your PC so you can see how the Web app you are working on will interact when it eventually reaches out and touches the real cloud, says says Chris Kraus, product manager for iTKO, the testing software vendor, which offers tooling for recording or mocking cloud services.

He sees growing interest among customers for the personal cloud concept, allowing developers to code and test Web applications that will eventually interact with services in the cloud. Cloud services on a PC provide two major advantages for developers during coding and testing, he says. [Disclosure: iTKO is a sponsor of BriefingsDirect podcasts].

First, the developer working on a cloud application is free to work anywhere, anytime regardless of whether the real cloud services are available or accessible. If a cloud service for a shopping cart is down for some reason, developers are not impacted since their version of the service is on their laptop. They can also code when they are on a plane, or in another environment with no access to the cloud.

Second, although this is probably first in the minds of budget conscious IT managers, the developer is not running up charges for accessing the cloud services, Kraus says.

“If the services are hosted on a cloud from a third party and I have to maintain physical

What developers could use is a Personal Cloud that would allow them to configure their local environment in multiple ways and take it with them wherever they go

connectivity, I have to pay to do that,” he said. “If I have a personal cloud on my desktop, I can take development offline, interact with those services, make sure my HTML is tight, and do all the stuff that is important to me. Then I point it to the real cloud and actually get the development up.”

Mike Gualtieri, senior analyst at Forrester Research, also sees value in the personal cloud concept.

In a recent post on his blog, Developers Need A Personal Cloud, the analyst also sees the value, in terms of portability.

“What developers could use is a Personal Cloud that would allow them to configure their local environment in multiple ways and take it with them wherever they go,” he writes. “I know this sounds like virtualization and it is to some extent, but extend PC virtualization with cloud concepts and you get the Personal Cloud.”

One commenter on Gualtieri’s blog suggests this concept might be dubbed “local virtualization.”

I had an intriguing chat with HP’s Jeff Meyers and iTKO chief scientist and co-founder John Michelsen last month at HP’s Software Universe conference. The confluence of SaaS and cloud with application development and the test phase is changing rapidly, we observed.

Compressing the test phase into the development and production becomes more feasible. And as virtualization becomes more common, building an application or service in its own runtime stack bubble from inception to sunset starts to make sense. OSGi fits into the vision nicely.

And while we’re combining all the elements of an application and platform from cradle to grave, why not tune the whole package before, during and after development too … then load the entire package as a portable cloud-supported production unit?

Now, that’s a “personal” cloud (I prefer cloud service nodule), but with high service performance output, and far less time in cost in the total lifecycle. Higher overall quality too. What do you think?

BriefingsDirect contributor Rich Seeley provided research and editorial assistance on this post. He can be reached at RichSeeley@aol.com.

July 3rd, 2009

Oracle Fusion 11g Middleware: Executed according to plan

Posted by Dana Gardner @ 8:23 am

Categories: Agile Development, Application Lifecycle Management, BI, Cloud computing, Developer Tools, Eclipse, Enterprise Java, HP, IBM, JBoss, Java, Oracle, SOA, SOA Governance, SOA architect, Silicon Valley, Software Development, Software Infrastructure, Virtualization, Web Services, business intelligence, database, datacenters, governance, management

Tags: BEA Systems Inc., Oracle Corp., Tony, OSGi, Oracle WebLogic Server, Business Process Automation, Java, Programming Languages, Java Development Tools, Operational Planning

This guest post comes courtesy of Tony Baer’s OnStrategies blog . Tony is a senior analyst at Ovum. His profile is here. You can reach him here.

This week’s announcement by Oracle of the rollouts of Fusion Middleware 11g is a bit anticlimactic in that the details are pretty much according to the plan that came out exactly a year ago today. Although the Fusion stack is comprised of multiple parts, internally developed and acquired, the highlight is that it represents the fruition of the BEA acquisition. Oracle had Fusion middleware prior to acquiring BEA, but there’s little question that BEA was the main event. WebLogic filled the donut hole in the middle of the Fusion stack with a server that was far more popular than Oracle Containers for Java EE (OC4J). Singlehandedly, BEA catapulted Oracle Fusion into becoming a major player in middleware.

Oracle largely stuck to the previously announced roadmap for convergence of BEA products, with the only major surprises being in the details. As planned, Oracle incorporated WebLogic as the strategic Java platform, JDeveloper as the primary development environment, dual business process modeling paths, with master data management, data integration, and identity management driven largely by Oracle offerings with some added BEA content.

Although the Oracle Fusion product portfolio came from far more diverse sources than BEA (as Oracle was obviously a more aggressive acquirer), the result is far more unified than anything that BEA ever fielded. Before getting swallowed by Oracle, BEA had multiple portal, development, and integration technologies lacking a common framework. By comparison, Oracle has emphasized a common framework for mashing the pieces together.

That’s rooted in Oracle’s heritage for developing native tools and utilities, dating back to the Oracle Forms 4GL and the various utilities for managing the Oracle database;

It’s an outgrowth of the mentality at Oracle that good is the enemy of best, and that what Oracle is building is a platform rather than discrete products.

the tools were sufficiently native that they typically were confined to Oracle shops. But that approach to native tooling morphed with development of a broader framework that is optimized for Oracle platforms. It’s an outgrowth of the mentality at Oracle that good is the enemy of best, and that what Oracle is building is a platform rather than discrete products.

It’s an approach that also makes Oracle’s tagline of Fusion being standards-based as being more nuanced. Yes, the Fusion products are designed to support Oracle’s “hot pluggable” best of breed strategy to work with other vendors products, but for designing and managing the Fusion environment, Oracle has you surrounded with native tooling if you want them. Call it a subtle pull for encouraging customers to add more Oracle content.

That explains how, 6 – 7 years ago, Oracle began developing what has become the Application Development Framework (ADF) as its own model-view-controller alternative to the Apache Struts framework that it previously used in early versions of the JDeveloper Java tool. That approach has carried through to this day with JDeveloper, which provides a higher level, declarative approach to development that would not fit with traditional Eclipse IDEs. And that approach applies to Oracle Enterprise Manager (EM), which does not necessarily compete with BMC, CA, HP, or IBM Tivoli in application management, but provides the last mile of declarative deployment, monitoring, and performance testing capabilities for the Fusion platform.

Bringing together the Oracle and BEA technologies resulted in some synergies where the value was greater than the sum of its parts. A good example is the pairing of BA’s quasi-real time JRockit JVM with Oracle Coherence data grid, a distributed caching layer for Java objects. In essence, JRockit juices up performance of Coherence, which is used whenever you need higher performance with frequently used objects; conversely, Coherence provides a high end enterprise clustered platform that provides an excellent use case for JRockit.

As noted, while the broad outlines of Fusion 11g are hardly any mystery, there are some interesting departures that occurred along the way. One of the more notable was in BPM where Oracle added another option to its runtime strategy for Oracle BPM Suite.

Make no doubt about it, the Fusion 11g migration was a huge reengineering project, involving nearly 2000 development projects and over 5000 product enhancements. So it’s a shame that Oracle did not take the opportunity of re-architecting its middleware stack by migrating it to microkernel architecture, with OSGi being the most prominent example.

Originally, Oracle BPEL Process Manager was to be the runtime, requiring BPM users to map their process models to BPEL, essentially an XML-based sequential programming language that lacks process semantics. A year later, OMG is putting finishing touches to BPMN 2.0, a process modeling notation that has added support for executable models. And so with release of 11g, Oracle BPM Suite users will gain the option of bypassing BPEL as long as their processes are not that transactionally complex.

Make no doubt about it, the Fusion 11g migration was a huge reengineering project, involving nearly 2000 development projects and over 5000 product enhancements. So it’s a shame that Oracle did not take the opportunity of re-architecting its middleware stack by migrating it to microkernel architecture, with OSGi being the most prominent example. Oracle WebLogic Server is OSGi-based, but the BPM/SOA stack is not. Oracle remains mum as to whether it plans to adopt a microkernel architecture throughout the rest of the Fusion stack.

So why are we all hot and bothered about this? OSGi, or the principle of dynamic, modular microkernels in general, offer the potential to vastly reduce Java’s footprint through deployment of highly compact, servers that contain only the Java modules that are necessary to run. The good news is that this is potentially a highly economic, energy-efficient, space efficient green strategy. The bad news is that it’s not enough for the vendor to adopt a microkernel, as the user has to learn how to selectively and dynamically deploy them.

But as we just noted, OSGi seems to have lost its momentum of late. As we noted, in our Ovum research last year, we believed that OSGi was going to become the de facto standard for Java platforms as IBM and SpringSource fully migrated their stacks, and as rivals were providing at least tacit support. A year later, Oracle’s silence is deafening.

As we noted last week, Oracle’s pending acquisition of Sun adds some interesting dynamics to the plot, as Sun has continued to speak on both sides of its mouth on the topic: supporting OSGi for its open source Glassfish Java platform, while putting its weight behind Project Jigsaw that aims to redefine Java modularity as JSR 294. Unfortunately, announcement of Fusion 11g has not cleared up matters.

This guest post comes courtesy of Tony Baer’s OnStrategies blog. Tony is a senior analyst at Ovum. His profile is here. You can reach him here.