The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

therealhoff (6) [Avatar] Offline

"One important differentiator between Object Orientation or Component Orientation and SOA is the existence of policy. If an interface or contract in SOA lingo, separates specification from implementation. Policy separates dynamic specification from static/semantic specification. Policy represents the conditions
for the semantic specification availability for service consumers."

Components had an external specification too. In CORBA, this was IDL. In COM+, this was IDL or the Type Library. .NET Components have this specification (type metadata) embeded in the assembly manifest. In short, Components also had an explicit separation of interface and implementation.

What you might mention is that the existing implementations all had shortcomings. COM+ metadata is dependant on the binary representation of the Component. .NET metadata has no dependence on the binary implementation of the .NET component, but it's still platform specific ( Java interop).

Services, on the other hand, can use a form of standards compliant separation of interface and implementation (ie..WS-*).

I do see what you are trying to say about the dynamic policy though (ie..queued vs not, security requirements, etc). Some of that dynamic policy is available as part of a .NET assembly manifest (ie.. using Code Access Security attributes), but the important point is that it's unavailable to non-.NET consumers.

If you like this line of thought, I can pull some quotes for you (Don Box, etc).
therealhoff (6) [Avatar] Offline
Re: Policy Definition
"The unique aspects of policy are that it can be updated in run-time and that it is externalized from the business logic. The Policy specify dynamic properties like security (encryption, authentication, Id etc.) , auditing, SLA etc."

All of these exist as Component Services as well. The COM motto was Configuration over Code. The differentiator here is that the COM stuff had to live in isolation (ie..from J2EE, EJB, and all the other Java stuff I'm not real familiar with).
arnonrgo (62) [Avatar] Offline
Re: Policy Definition
Hi Evan
I am trying to refine my SOA definition (after I was challenged by Pete Lacey - see the comments here: and I am still thinking that through

However, in any event, you should note that there's nothing in SOA that is entirely new, it is (IMHO) just a next step in the distributed system thinking and as such utilize ideas from previous attempts (like remote objects which COM+ and CORBA promoted)
Also note that SOA isn't equal to web-services and you can apply the same principles with other technologies (even ones like COM+ or CORBA)