Hi Jeff,
I think that any component based approach to software will inevitably lead to two steps of "constructing" components and then "composing" those components. It looks life Service Component Architecture SCA is yet another vendor driven standards approach attempting to dress up a mix of old technologies (corba) and technologies shown not to be practical (ws-*) in a new suit. The final "constraint" step in construct-compose-constrain is there as a separate step because ROC says that often constrain is better applied independently. This is for practical and reasons of principle. Practically is good when incrementally developing a system to get the structure and prove the concept on "good" data and then constrain it later with additional tests. Having the system as loose as possible lets it remain fluid and the best solution found. As a matter or principle sometimes having constraint as an independent layer leads to clear separation of concerns, however this is not always the case.
The Resource Oriented Computing ROC approach is independent of technology in the way that Object-oriented OO is. It is an approach to analyzing, designing and implementing systems that structures the problem space into resources - i.e. identifier addressable resources placed into structured address-spaces with a small set of verbs to act upon them with immutable representations as as the quantum of information. Contrast this with SCA where the definition is based around standards on how to bind network communications to specific programming languages. As an approach, binding objects to the network has been tried many times in many ways over the last decade and there aren''t many recognized successes. Contrast this with the World-Wide-Web WWW based on resource oriented principles, this has prospered without the backing of marketing campaigns by vendors.
One other interesting difference is that of the network boundary. Approaches such as SCA make the assumption that a network sits between their components. Now I understand that that doesn''t have to be the case and many components can sit upon one machine, but by assuming that they are limited to serializing and parsing their components information to bytes to send over the wire. ROC fairly seamlessly integrates with networking protocols but it base approach is that components are together on one virtual machine and share rich representations. This leads to efficiencies that make it practical to use the ROC approach in a scale invariant way all the way from low level software operations such as integer arithmetic up to large business processes. In doing so it enables core scaling and intrinsic caching which makes ROC so compelling.
I could go on but this is starting to sound like a marketing rant ;-)
Tony
I think that any component based approach to software will inevitably lead to two steps of "constructing" components and then "composing" those components. It looks life Service Component Architecture SCA is yet another vendor driven standards approach attempting to dress up a mix of old technologies (corba) and technologies shown not to be practical (ws-*) in a new suit. The final "constraint" step in construct-compose-constrain is there as a separate step because ROC says that often constrain is better applied independently. This is for practical and reasons of principle. Practically is good when incrementally developing a system to get the structure and prove the concept on "good" data and then constrain it later with additional tests. Having the system as loose as possible lets it remain fluid and the best solution found. As a matter or principle sometimes having constraint as an independent layer leads to clear separation of concerns, however this is not always the case.
The Resource Oriented Computing ROC approach is independent of technology in the way that Object-oriented OO is. It is an approach to analyzing, designing and implementing systems that structures the problem space into resources - i.e. identifier addressable resources placed into structured address-spaces with a small set of verbs to act upon them with immutable representations as as the quantum of information. Contrast this with SCA where the definition is based around standards on how to bind network communications to specific programming languages. As an approach, binding objects to the network has been tried many times in many ways over the last decade and there aren''t many recognized successes. Contrast this with the World-Wide-Web WWW based on resource oriented principles, this has prospered without the backing of marketing campaigns by vendors.
One other interesting difference is that of the network boundary. Approaches such as SCA make the assumption that a network sits between their components. Now I understand that that doesn''t have to be the case and many components can sit upon one machine, but by assuming that they are limited to serializing and parsing their components information to bytes to send over the wire. ROC fairly seamlessly integrates with networking protocols but it base approach is that components are together on one virtual machine and share rich representations. This leads to efficiencies that make it practical to use the ROC approach in a scale invariant way all the way from low level software operations such as integer arithmetic up to large business processes. In doing so it enables core scaling and intrinsic caching which makes ROC so compelling.
I could go on but this is starting to sound like a marketing rant ;-)
Tony
