Monday, August 21, 2006

SOA Questions answered

I am thankful to Sam Lowe for pointing out work going on at OASIS forum, which seeks to address core issue of service definition. The published SOA reference model does provide necessary conditions as to what a service definition entails. These definitions are more from point of view of a service provider. They state, if I have a capability, which I want to expose as a service what minimally I must provide for the capability to be successfully exposed as service. This will help address questions such as

  • What is its execution context (i.e. pre and post conditions)

  • What are the expected service levels? Etc.
There is one more addition I would love to see to this reference model. This is more from the point of view of a consumer, which in turn can help service providers in service evolution. This addition will help answer questions for a service consumer such as

  • If I do not have the right service that I need for the task at hand, can I choreograph existing services into a composite service using services I have?

  • Will this composite service have required functional and non-functional properties?

This would need specification of composability in both functional as well as non functional sense. I should be able to specify a ‘Plan of Action’ using services and should be able to specify functional and non-functional constraints on this PoA. This PoA is not necessarily only temporal (e.g. like a process) but can also be structural too. (E.g. like a ‘Join’ in relational world). Reference model then can constrain the service specification such that using service specification I should be able to check viability of this PoA.

Usages of this PoA are manifold.
E.g.

  1. A consumer can request a PoA to be executed instead of individual services. SOA infrastructure can execute this PoA, possibly using an ESB. This specification will help ESB infrastructure to do necessary optimizations, to provide required non-functional capability.

  2. If there are enough consumers asking for this PoA a service provider may decide to provide this PoA as a composite service. Thus helping service providers evolve the services that their consumers demand the most.

Tuesday, August 08, 2006

SOA - more Q&A

As far as SOA goes the predicament of service granularity is going to haunt everybody.What level of services? Would we have elementary services, which then are composed into composite services usable by services consumer? Or lets not worry about granularity, just define the services from consumer perspective and be done with it. Oh, what about evolution of services? What abput multiple perspetives? Questions galore, no answers...
IBM fellows do talk about this and in general about maturity of SOA. They have put some material which touches upon these areas. I hope they have some answers.
Interestingly IBM's SOMA (appears to be an hybrid approach which borrows from MDA) looks most promising. But as IBM says, the whole area is so immature. For now, it might suffice to say that SOA is a journey and may talk a long time to finish it. Have patience, this is the right path but a slightly longer one.

Monday, August 21, 2006

SOA Questions answered

I am thankful to Sam Lowe for pointing out work going on at OASIS forum, which seeks to address core issue of service definition. The published SOA reference model does provide necessary conditions as to what a service definition entails. These definitions are more from point of view of a service provider. They state, if I have a capability, which I want to expose as a service what minimally I must provide for the capability to be successfully exposed as service. This will help address questions such as

  • What is its execution context (i.e. pre and post conditions)

  • What are the expected service levels? Etc.
There is one more addition I would love to see to this reference model. This is more from the point of view of a consumer, which in turn can help service providers in service evolution. This addition will help answer questions for a service consumer such as

  • If I do not have the right service that I need for the task at hand, can I choreograph existing services into a composite service using services I have?

  • Will this composite service have required functional and non-functional properties?

This would need specification of composability in both functional as well as non functional sense. I should be able to specify a ‘Plan of Action’ using services and should be able to specify functional and non-functional constraints on this PoA. This PoA is not necessarily only temporal (e.g. like a process) but can also be structural too. (E.g. like a ‘Join’ in relational world). Reference model then can constrain the service specification such that using service specification I should be able to check viability of this PoA.

Usages of this PoA are manifold.
E.g.

  1. A consumer can request a PoA to be executed instead of individual services. SOA infrastructure can execute this PoA, possibly using an ESB. This specification will help ESB infrastructure to do necessary optimizations, to provide required non-functional capability.

  2. If there are enough consumers asking for this PoA a service provider may decide to provide this PoA as a composite service. Thus helping service providers evolve the services that their consumers demand the most.

Tuesday, August 08, 2006

SOA - more Q&A

As far as SOA goes the predicament of service granularity is going to haunt everybody.What level of services? Would we have elementary services, which then are composed into composite services usable by services consumer? Or lets not worry about granularity, just define the services from consumer perspective and be done with it. Oh, what about evolution of services? What abput multiple perspetives? Questions galore, no answers...
IBM fellows do talk about this and in general about maturity of SOA. They have put some material which touches upon these areas. I hope they have some answers.
Interestingly IBM's SOMA (appears to be an hybrid approach which borrows from MDA) looks most promising. But as IBM says, the whole area is so immature. For now, it might suffice to say that SOA is a journey and may talk a long time to finish it. Have patience, this is the right path but a slightly longer one.