So there has been much ado from commercial technologists, analysts and press about the emergence of SOA as a silver bullet in the defining of a common Enterprise / Inter-Enterprise Service model, and in an approach to the re-factoring of existing legacy systems. Though there are almost as many approaches to SOA as there are articles defining and re-defining the terms, one of the critical lessons is that SOA will only yield as much agility as the infrastructure upon which it runs.

Coming from a history of grid/utility computing programs has afforded me the benefit of viewing enterprise resources as consistent modelable elements that can create a virtual deployment infrastructure for this next generation of agile enterprise services. What remains critical, and a common theme in my weblog has been the need to better elaborate the systemic requirements of a system - whether represented by a single service interface, or through a composite model, service level objectives remain a difficult to define, more difficult to measure, and virtually impossible to predictably enforce set of goals. A recent read of the Enterprise Grid Alliances “Reference Model” is illuminating; as I think that the industry, through GGF, EGA, DTMF UCWG, SNIA and even eTOM are getting close to a basic taxonomy in which a SOA is deployed (hopefully dynamically) against a Service Oriented Infrastructure (SOI). So what am I really saying? Model Driven Architecture is attempting to establish consistent patterns for the organization of object oriented services, with clear separation of concern, and appropriate compositional granularity. SOA’s are constructed through Directed Acyclic Graphs of these sub-systems that define their inter-relationship (though the complete vocabulary isn’t standardized). Now that we understand the components that make up an enterprise service, we need to determine how to apply these models against infrastructure, and once again MDA can serve us well.

Let’s take our infrastructure (pools of elemental resources) that can also be dynamically assigned, are themselves objects, which can leverage similar model based approaches to their organization we quickly begin to recognize the need for both “extension” - supporting a consistent interface to a domain model, whilst enabling the customization that is a natural byproduct of real-life variability. Models, for me are a composition of patterns that provide layered abstraction to mitigate complexity and support replacement… These models are really purpose built realizations of patterns based upon a set of concrete contexts - a complicated way describing constraint driven pattern application…. I want to remodel my bathroom, to build a plan I need to take existing patterns from some kind of “standard” catalog, and apply them given my constrains… I’m tall, so I want the countertops raised, I’m disabled so I need to extend the natural 18“ on center rule for toilet spacing to 36” for access… you get the picture. By producing models (either abstract or concrete) we can begin to elaborate a design, manifesting all of the complexity within a set of stackable “layers” that ensures both loose coupling/east of replacement, along with the traceability against requirements and constraints.

So finally to VOA or “Virtualization Oriented Architectures”; architectures built with clear layer based / atomicallly separable abstractions… VOAs are Models in which abstraction can be late bound, but coherently orchestrable designs. These designs need to describe the “virtualization” constraints in a way that deployment contexts can be manifest at runtime rather than design time, through a more consistent set of abstraction layers/patterns that reflect the platform layer, service layer that you wish to virtualize. In lay terms… virtualization provides a component and a container that inherently provides the lifecycle management of that component. For VOA to work (as SOA) the functional capabilities as well as the non-functional or systemic capabilities need to be declared at design time, and then contractually provided at runtime.

Technorati Tags: distributed system, soa, virtualizatoin

As many know HP announced it’s intention to buy OpsWare for $1.45B on Monday (7/23/2007). Some seem think that they are just buying into a negative cash flow business. My gut, tells me that OpsWare has had problems because deeper management software integration (OpenView) and HW integration would help them to create multiplicative value in operational efficiency; easing the “we’d buy it if it were just a little more integrated” denial.

So let me just play devils advocate… HP has been investing in virtualization/grid technologies… see HP SFS basically a bundled “storage grid that is Lustre ready, supporting 35+GB/s performance (ether) and 1PB of capacity built from small boxes (hp’s quote: ”3X the bandwidth at half the price of scalable NFS offerings.“)… Sun is trying the same thing with Constellation and their x4500 (thumpers), the challenge that we all have is that vertical scale brings systemness, but on a non-commodity price curve. The commodity/sedimentation / scale out architectures, however have a dirty little secret, as you scale out the complexity of management becomes high, and their provision becomes more rigid because of this… impacting capital arbitrage and schedulable density (fancy ways of saying, I have to lock apps to boxes to ensure that I can manage, instead of allowing apps to be dynamically scheduled to available resources (compute, network and storage).

In fact, what grid technologies do is add systemness to compute fabrics, and are hugely complimentary to existing virtualization / abstraction layers like VMware and Xen. So for me, Opsware is a ”platform“ that can help HP control the migration of their customers from static deployments/manual processes -> static deployments/automated processes -> dynamic deployments/automated processes.

I think that we’ll see other activity soon around BladeLogic from the like of BMC and IBM. The gauntlet has been thrown down!

Technorati Tags: distributed system, hp, network management

I was recently asked to contribute to a couple of articles(The Merging of SOA and Web 2.0,Experts See Link Between Virtualization, SOA) by Darryl Taft of eWeek(Ziff Davis). I initially took an excessively “SOI” approach to this discussion only to have a conversation with Steve Graham that really helped me establish a more realistic set of comments around the junction between Web2.0 (with it’s requisite behavioral challenges around collaboration, composition and empowerment/personalization), and my natural slant toward SOA - namely the changing dynamics of system composition with a strong bent toward “systemness” or NFR’s.
The quote is certainly more accurately attributed to sgg, but is certainly a collaboration!
Thanks Steve!

Technorati Tags: distributed system, rest, soa, ws

My feelings about WS-* vs. REST have never been hidden, in fact I wear them on my sleeve, and this analogy really cracked me up… some interesting comments as well.
The Cafes » North and South :

The analogy isn’t as silly as it sounds either. North Korean/Soviet style “communism” fails because it believes massive central planning works better than the individual decisions of millions of economic actors. WS-* fails because it believes massive central planning works better than the individual decisions of millions of web sites. It’s no coincidence that the WS-* community constantly churns out volume after volume of specification and one tool after another. The WS-* community really believes that developers are too stupid to be allowed to manage themselves. Developers have to be told what to do and kept from getting their grubby little hands all over the network protocols because they can’t be trusted to make the right choices.

Long live the empowered (highest common denominator) developer, see you in the deep end!

Technorati Tags: distributed system, ws, soa, rest