Archive for October, 2009

muSOAing for 10/13/09

October 13, 2009

Maybe I have mentioned this before or I am saying the same thing in a different way. SOA is probably the only technology to be totally backed by standards. For the basic services themselves you have standards such as WSDL 2.0, JAXB and XML Schema. For Registries you have UDDI. For ESBs the industry has to a great extent agreed upon the core features that should constitute an ESB such as mediation, transformation, orchestration, routing, discovery. For more complex decision based Orchestration you always have your low level Process Orchestration engines or specific BPM engines that only do Service Orchestration without having to write any code.

There are other new areas such as CEP where the standards and features are still evolving. So when you talk about Governance taking into account all of this, you are talking about Governance at a very broad level so there is a wide swath both in the length and breadth of your organization and this puts it on par with Corporate Governance. So think of SOA Governance as a very critical aspect of your overall IT Governance strategy since it encompasses not only your own Organization but has implications on how other Organizations will interact with you when you expose your services for external consumption.

Given this background, it is quite obvious that SOA Governance entails a lot of discipline. To enforce this discipline what you need are a set of Policies and Procedures for various aspects of your SOA strategy ranging from your development and deployment strategy for services to your runtime strategy in terms of how you will expose your services, who can access your services and what are your QOS and SLAs for these services. So here I have mentioned two important aspects of Governance being the design time aspects you have to consider and also the runtime aspects. Within each you have several patterns that can be applied depending on the types of consumers and the traffic and hit rates you might expect.

Advertisements

muSOAing for 10/08/09

October 8, 2009

Before we explore the intricacies of SOA Governance, let us first examine for a minute all the events that let us to this point where the need for strict Governance became mandatory. The Internet has been in around in some form or shape since the late 60s.

The most ubiquitous application in this nascent Internet was email. Later on this technology called the browser came along served to democratize Internet and and created this whole new web by marrying together all the core constituents of the Internet and helped to open this technology to the masses. In this same vein, I would say that SOA has served to democratize web technology and in the process demystify myriad terms that were hitherto the exclusive domain of consultants. It has been the main enabler for serving useful technology over the web. If you look at it another way, SOA being this technology that spanned domains, business units, organizations and even geographic boundaries, the chance that it might be misused is perhaps a very gross understatement.

Every SOA implementation has to be designed keeping in mind that it can be and perhaps will be abused and misused. The threats are both within and without it’s defined execution boundary. So with the exposure of a seemingly harmless URL can portend very deep implications that will carry down to the very heart and core of that system which will service this URL. Think of every sort of threat you can come up with and you have your laundry list of items you have to consider as part of your security and governance for your services.

The term Governance is still quite fuzzy and it’s boundaries and what constitutes this particular function are widening every day. Suffice to say that to cover this vast ground a strategy should be in place right from get go, from the point where you start designing your services upto the point where you deploy and run your services. To grapple with this conundrum, the industry has (thankfully) begun to see these as two distinct components, being design time and run time Governance.