Q
Problem solve Get help with specific problems with your technologies, process and projects.

Stateless and stateful WS in the Grid community

What is special about Web services being "stateless"? What difference does it make when the Grid community exploits this fact and says that a Grid service (GS) is a stateful Web service? Every GS is a WS not the vice versa, can you comment please?
The Web services standards (XML, XML Schema, SOAP, WSDL, WS-Security, etc.) are specifically designed to be composable extendable building blocks that can be used to create higher level, higher value, architectures.

Hundreds of organizations are moving forward with specific Service-Oriented Architecture (SOA) designs built on top of these Web services standards. These SOA designs most often include specification of common infrastructure and centralized capabilities, in the areas of security, root-cause analysis, SLA enforcement, application network visualization, etc., that go far beyond what is mandated by the base Web services standards.

ebXML (Electronic Business using eXtensible Markup Language) is another example of a higher level architecture built on Web services standards.

Part of the Grid community is working to define a Grid Service Architecture that includes a Grid Programming Language, Grid SDK, GridBeans, and a client framework. This architecture is defined on top of the Web services standards and includes some common infrastructure along the lines of what we are seeing with SOA deployments. Within the scope of these efforts it is correct to say that every Grid service is a Web services, but not every Web service is a Grid service.

I suspect we will see many of these efforts around Grid Service Architecture get rolled up into the SOA implementations that are already underway.

It is true that there is nothing in the Web services standards definitions that require statefullness in a Web service implementation. Taking this approach allows the base Web services standards to be applied across both statefull and stateless use cases, and it allows for very loosely-coupled usage patterns. I believe this flexibility is a good thing.

While the base standards don't require statefullness, it is often the case that specific Web service implementations and Web service intermediaries (that are part of an SOA infrastructure deployments) do maintain state. They may do this to implement higher value shared capabilities (such as malicious attack detection and response), or to optimize performance, or to implement business logic.

I don't believe it is too useful to compare and contrast Web services and Grid services. GS is built on WS so they are therefore at different levels and don't make a good comparison. The important thing to keep in mind is that adopting the Web services standards is the right thing to do, but not sufficient. Large organizations need to think through the SOA they will build out to manage those services, and the infrastructure elements that will implement that SOA. The GS related tools coming out of the Grid community are just one example of an effort to provide a holistic SOA framework.

Dig Deeper on Topics Archive

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchSoftwareQuality

SearchAWS

SearchCloudComputing

TheServerSide.com

Close