Archive for November, 2009

muSOAing for 11/28/09

November 29, 2009

The other day there was a very interesting question posted to the Service Oriented Architecture SIG “Do we need SOA for Cloud Computing”. This loaded question can be answered in two ways, the easy way and the hard way.

Let us do the easy part first. To answer this question, I will pose another question. So when someone says he has this or that portal or application up and running what is your first question? Gimme the URL. So there is this very rich application that your hard working nerdy friend has made available to the whole world (for free) burning a lot of calorie induced midnight oil and how do you get to it, through your humble URL.

So let us take a slightly different view of pretty much a very similar scenario. You as the head honcho of your small domain in this vast enterprise have received a missive from the higher ups to reduce costs for the FY by upto 25%. So what is the first thought that crosses your mind “Outsourcing” of course. Well not just outsourcing but actually appsourcing. You want the entire app outsourced and do not want to be responsible for any of it being enhancements, maintenance, upgrades etc. etc. So then what gives, “SaaS” of course. So your timesheet function is SaaSified. So your chief SaaSer shows up one find day and informs you that he is done SaaSing up the time sheet app.

So what do you ask him? What is the URL. So you see where we are going with this. So your timesheet app has been totally outsourced, it is available through a URL and for all that you know it is probably colocated in a Cloud along with other colocated apps. The SaaSer if he is clever and wants to reduce maintenance costs has realized the advantages of SOA and he has gone the whole nine yards with SaaS, including service enabling all the layers including EIS, Process Orchestration, Human Workflow, UI Framework and any other layers that may need to be there.

So what has been done really is an app is being served over the web, you are accessing APIs over the web. Whether a human is interacting with the system through a portal or a system is interacting with another system seamlessly by calling Web APIs (URLs) or services.

So next we will try to answer this the hard way. I might have given my answers in bits and pieces in my ealier posts but we will summarize in the next couple of posts.


muSOAing for 11/25/09

November 25, 2009

Continuing our talk on Governance, the next very important aspect is of course Security. What we normally gravitate to is WS-Security and it’s inherent constituents such as WS-Policy, WS-Authorization, WS-Trust etc. While WS-Security provides for several guidelines for implementing various forms of Federated and Non-Federated mechanisms, it’s constituents dictate how you would go about emplementing one of them.

If you have a federated security mechanism, you can implement features such as SAML Token assertion for one of your client applications that avails of the existing SOA infrastructure. The token is generated by a security provider and handed over to the initiating app which may be a Portal/Front End application and from thereon it is passed to the various layers and asserted there.

Non-federated mechanism as plenty including Kerberos, Client certificates, attachment of encrypted keys in SOAP headers and other methods. Depending on how extensive and pervasive your needs can be, some advance planning is required especially for federated mechanisms where you have to ensure that every participating application can digest and assert your token.

As I have mentioned before, these mechanisms become even more important if you are delivering applications over the web using a SaaS and/or a Cloud infrastructure. You are exposing a URL to the outside world and you have to ensure that no one accessing that URL with malicious intent to unleash some malicious malware into your network.

As a single point of entry, an ESB is typically the ideal place where you can implement such policies effectively. ESBs have matured significantly and can now perform a plethora of tasks. In my opinion some of them have been overloaded to include adapters and other callout mechanisms. Frankly speaking, these belong in another layer such as an Orchestration Engine and not in the ESB. An ESB can serve you very well if you plan out your runtime Governance strategy well but at the same time make sure that you are not stretching it’s limits just because it offers these other nice fancy features like adapters and orchestration, you will soon hit a wall an be talking about a migration strategy.

muSOAing for 11/11/09

November 11, 2009

One of the most commonly used runtime Governance features is mediation. Before the call even hits the actual service there will be need to intercept it for various different reasons. One of the primary reasons is to validate the authenticity of the request to see if it is coming from a valid source and the system that has requested the service is authorized to avail of the service.

This can be ensured in a variety of mechanisms, the most common being using various authentication mechanisms such as client certificates, non federated one like basic authentication and federated ones like SAML token assertion.

Another common reason for mediation is if some sort of orchestration has to be performed using simple service level orchestration.

So mediation is one of the most basic and oft used features.

muSOAing for 11/5/09

November 5, 2009

That was a long break. So work got in the way and interrupted my blogging schedule. Picking up from where we left, let us touch upon a few key points wrt Runtime Governance. The key aspects to these are the creation of Policies and the Auditing of those Policies, Mediation and Transformation, Routing and Security. These are precisely the features offered by a traditional ESB.

When it comes to the creation of Policies, some of the types of policies that may be enforced may be related to who has access to the service. You may want the service to be accessible only in your Intranet and that too only to certain types of users. A service that returns key HR information should be accessible only to HR managers for instance. Since services level the playing field and make applications web enabled and application functionality to be accessed from anywhere as an API call, such policies play an extremely critical role. At the same time do not go overboard in policy enforcement as it can affect your SLAs.

We will touch upon the other aspects of Runtime Governance in later posts.