The IT Strategy Letter
A digest of Doug Kaye's weblogs for the week ending November 26, 2002 (Subscribe)

The Service Grid: Point and Counterpoint

[This week, another special edition. In the October 21, 2002, issue of the IT Strategy Letter, I linked to a white paper entitled Some Security Considerations for Service Grids (PDF, 23pp.) in which Martin Milani and John Seely Brown defended certain security aspects of the Service Grid as put forth in an October 2001 HBR article by Brown and John Hagel. In my review I questioned four aspects of the Hagel-Brown article. On October 28, 2002, I received the following in email from Martin Milani, which is reprinted with his generous permission. Our mutual objective is to encourage further discussion on the topic of the Service Grid.]

Per our view, the security service grid is not merely a replacement for firewalls of any kind. In fact the enterprise will protect is perimeter and connection to the service grid via firewalls. In figure 2.4 [in the original white paper] we have a graphical representation of how we envision the enterprise would connect to a service grid, which includes firewalls on the edge of the enterprise. We believe there are a number of different reasons why the service grid is a key enabler and an important piece of the webservices puzzle, one of those reasons is a reduction in the complexity of security management but that is only one of the many different advantages.

Let us discuss and address the four different points raised by Doug at a more granular level:

Point 1
I think a service-grid provider may actually be more vulnerable than an individual corporate IP address for two reasons. First, a well-known service-grid provider may be considered more enticing target by hackers, and therefore attract more such attacks. Second, a DoS attack aimed at one service-grid customer can impact the performance of other customers by denying the availability of shared resources. IOW, if a hacker goes after my web service that's advertised as responding at a WSN that we both use, your web service may also suffer DoS. This wouldn't be the case if we didn't share the resources.

Response 1
We would not argue about the fact that a service grid might be a more enticing target for hackers. However, we would state that the service grid construct would be designed and erected with security as the core fundamental design pattern and the key architectural design guideline, from perspectives of software and network design. Service grids would be managed by security experts and monitored and enhanced all the time. Service grid operators would be closely working with and correlating efforts with multiple backbone providers and ISPs. It is easy to see that it will be much more effective in managing security than most enterprises could ever be for skill reasons if nothing else. In the paper we have touched on quite a few different ways the service grid could be protected, some admittedly are quite complicated.

Point 2
I don't see how this is any better (but I admit, no worse) than a single corporate connection through an XML firewall appliance. Someone still has to manage the many point-to-point relationships involving a wide variety of security technologies and standards. It's just a standard outsource/DIY tradeoff. It isn't inherently better or even easier if done by the service-grid vendor.

Response 2
From the firewall perspective only, an enterprise could use the same technologies as a service grid provider would use to protect its perimeter assuming it had the expertise and resources.. It is also important to note that an XML firewall which is a new and unproven technology only examines XML messages within the SOAP protocol (http). We believe opening up you enterprise applications to the outside world directly via SOAP is an extremely risky move! Again without going into details here, XML level security is only one of layers of security that is needed. In our paper we argue the need for multi-layer and multi-tier framework.. We also provide a glimpse of what opening up the internal applications to the outside world might look like using the service gird services as proxies hence protecting the internal applications. We also strongly caution against the myth of "XML will cure cancer and all evil" phenomenon.

Point 3
In practice, the service-grid customer still has the obligation to determine and express to the provider all of the rules required to create and enforce the security policies. There may only be a single physical/virtual connection to the service grid, but there are no fewer application-to-application (or, more precisely business-to-business) relationships. The service-grid vendors don't make business decisions for you. The only step they'll handle is transcribing into their systems the rules you create.

Response 3
Yes, the business rules and security policies are created by the enterprise. What the service grid operators would offer (and that are extremely important) are neutral (third party) audit trails and non-repudiation. Non-repudiation by definition is something that only a trusted third party can reasonably provide. This is why Escrow companies/clearing houses and law firms often handle complex transactions. From a technical perspective non-repudiation can only be supported if the same exact token technology is used between two companies and that in fact would be prerequisite before any application connectivity can resume. The service grid construct will take care of this by offering non-repudiation in a multiple certificate/token type technology world. Compliance to certain security standards and rules could also only be verified by the service grid real time. Laws such as the patriot act which require companies to provide details of any transactions to law enforcement in 48 hours or less makes this even more interesting, specially when multiple organizations are involved in a transaction. The service grid - acting as a trust broker - also manages trust. In a multiple service provider world in which multiple parties provide the same service (this is how the real world works); trust and quality of service (both of which are products of the history of previous interactions and transactions among different participants ) services could only be provided by a neural third party service gird provider. Again we refer you to the paper regarding trust and quality of service issues.

Point 4:
I've contended in the past that such mediation is only required when the associated standards either haven't been agreed to or haven't been universally adopted. Today, this is the case for much of the web-services protocol stack, but over time it will be less so. Milani & Brown may, in fact agree, if my inference from the following is correct: It also speeds up the adoption of web services by organizations, as they do not need to wait for standards and the expensive and cumbersome task of replacing already existing technologies and infrastructures.

Response 4:
We believe we are in agreement here. We still think comprehensive Webservices standards are a long ways off. Even when all parties do agree on certain standards for webservices, with history as a witness we believe not everyone will adopt these standards, CORBA and OSI are great examples.

In closing we would like to thank Doug for his review of our paper and his thoughtful input. John Hagel, John Seely Brown and I envision the world of websevices that is not limited to simple application integration or one in which one can use a stock quote providers piece of code to present a stock quote on a corner of a web page. We believe ultimately, the world would comprise of many sophisticated distributed software ecosystems that will run and facilitate mission critical applications and business processes and transactions among their constituents. We believe the world will be multi-protocol and dynamic in which different technologies will best address different needs for a very long time. RPC and SOAP/http which toady's webservice's stack is based on will only address certain areas of software architecture where they fit specific needs best. There are many areas where RPC is not a well-suited architecture for design and other paradigms would be much better suited. In fact the first of the web-based applications such as SMTP/mail, ftp, news and DNS did not use RPC like communication. So in this chaos we call the technology world today, in order to evolve, we believe the service grid concept is a fundamental first step.

Martin Milani
October 28, 2002
(Reprinted with Permission)

Subscription and Contact Info

The IT Strategy Letter is published weekly by Doug Kaye.


View or search newsletter archives
Email Doug or visit his site at

©2002 Doug Kaye ()


"...essential reading for anyone seeking to deploy this technology."

--John Hagel, III,
management consultant
and author of
"Out of the Box"


Read More Reviews of Loosely Coupled