Great example, Gregg. When I traveled from the US to the UK and had some tea, I 
clearly recognised which tea I was having (because US tea was always with ice 
:-)  )

I know two major approach to new things: one is follow after people, another 
one - lead people. In architecture of building and landscape, you can put the 
path-ways up-front placing some grass around them or you can leave the grass 
everywhere and see where people prefer to cross the place. Both approaches are 
valid. 

The ony one thing is hidden in the latter case - people do not cross the place 
accidentally, they go to some targets. That is, the architect put targets 
outside of place deliberately, i.e., once again, people where led but 
implicitly. 

We have several standard bodies and chap developers. Developers adopted the 
meaning of 'contract' following WSDL/Web Service specification. Technical 
Committees in OASIS, OMG and The Open Group shifting for interpretation of SOA 
service as Web Service and they, correspondingly, change the semantic of 
'contract'. I think it is valid process and result. 

Now, we have the legacy interpretation and standardised one. Which one we 
better use for avoiding ambiguity? There nothing wrong with ATG's nucleous but 
the standard named the same functionality Servlets. The same is here, plus, as 
you know, the standard bodies have started the process of mapping/matching 
between their ontologies for the same reason - reduce ambiguity. In this case, 
I simply surprised by ignorance demonstrated with regard to the standards.

Everything has to have its own semantic and it used to change depending on the 
context (it is a feature of many languages including English). I think you are 
playing with words a bit because "anything useful" means different things to 
different people. What is not useful for you, may be useful for me, with or 
without "additional qualification"

- Michael

P.S. 'contract' is not only "a hint of a formal agreement", it is agreement 
between two or more parties. How an interface exposed by the service provider 
alone can become an agreement? With whom? Consumers must take it but this does 
not mean they agree with this particular interface syntax and semantics. So, 
using 'contract' in place of interface in not much scientific, if you want.




________________________________
From: Gregg Wonderly <[email protected]>
To: [email protected]
Sent: Friday, January 30, 2009 10:05:34 PM
Subject: Re: [service-orientated-architecture] Re: Service Façade


Michael Poulin wrote:
> Sure, Anne. I prefer OASIS SOA definition and it is my business to 
> promote it. BTW there is one more OASIS standard on the way (public 
> draft) on SOA Ontology, and they also in sync with OASIS SOA (thanks 
> God!). So, my 'flexibility' is in that I prefer to setup the terms 
> before the conversation though this is not easy some times.

If I tell a story about traveling from the US to the UK and having some chips 
and tea in the afternoon, what would you think I meant when I said "chips"?  Is 
it the US chip, or the european chip?  Would the place that I was born affect 
your assumption?

Terms and standard phrases are always nice, but if they are not uniformly 
understood and globally equal in definition, than one has a harder time having 
a 
conversation with them.  The word "contract" is not a well defined and 
uniformly 
understood (one meaning and application) term.  So, it's not really productive 
to use it for anything more than a hint of a formal agreement.

Lawyers and language specialists/ majors often qualify the use of such terms 
because they know that the single word is easy to say, but doesn't easily 
convey 
any particular meaning without additional qualification.

This is what makes SOA a non-starter.  It doesn't convey anything useful 
without 
additional qualification, and once you start down that path, the conversation 
will inevitably touch all kinds of places that make it much richer in content 
and meaning to the two parties because they used more descriptive terms and 
phrases that help each other see very specific detail.

Gregg Wonderly
    


      

Reply via email to