>There are all kinds of standards and written material which MUST be consumed >to get "anything useful" out of the term SOA.
> If I told you I had a fully implemented and OASIS standard SOA at my > business, would that allow you to know that you could sell me you really > great authentication/ authorization service that was going to utilize > Google's new OAuth stuff? How would you know how I might integrate it? How > would you know whether I had any authentication/ authorization on any service > in my SOA at all? > SOA wouldn't tell you "anything useful" about how to make me your customer... SOA models business - the human world. In this world things change their not only usefulness nut meanings also depending on the context. You cannot take a SOA service and reuse it in different Executions Contexts (EC) assuming it will work the same way, it might nor becuase of the change in the EC. SOA service is not a programme (which, actually, works different on different platforms as well). If I know that Google's new OAuth stuff, for example, enforces on me its internal constraints and I cannot manage my contract with Google to my satisfaction, I WILL know that you would not by my service in suc conditions because OASIS declares that service consumer runs the ball, not provider, and that service may not expose its internal constraints on the consumer if every one of them is not listed and agreed in the Service Contract. OASIS SOA is very good abstraction which can drive your behavior leaving the full freedom in your implementation to you (you will not compromise OASIS SOA in the implementation if you agree with yourself). Questions like "How would you know how I might integrate it? How would you know whether I had any authentication/ authorization on any service in my SOA at all?" in essence, are marketing questions. SOA is not a technology, after all. > Which developers? Do you have names and addresses and are you sure that your list is complete? 8 years of intensive Web Service development under the banner of SOA is enough to be quite sure about adoption of that meaning of 'contract'. I do not need to disclose names but I can tell you that in the OASIS SOA RA, we have special control to avoid 'Web Service mentality' when writing about services. > So somebody wrote something into a document. Are you sure that everyone you have a conversation with has read this document? If they haven't, how do you know this? How do you know how much specific ignorance you will deal with as the conversation opens? Do you tell by the missing "hand slap" on the forehead from the DOH moment? This is not a problem. SOA Governance sets the architectural control process and procedure within project life-cycle. If the document was not read and, thus, not followed, it is easy to catch at the first review. The power of Policy is in that it does not ask its subject for agreement. Management is in place to enforce it in spite of developers' preferences. For example, Fidelity, when implemented Struts a few years ago, had a policy that required to validate ALL user inputs. Appropriate struts validation was added to the standard library and no code that did not use that validator was allowed into production despite any time dead-lines. That's simple. > I'm trying to make sure it's clear to you that I am asserting that there can never be a conversation about a topic as large as SOA and have the term "SOA" reveal anything to people who wish to form a "contract" about things that will happen between their SOAs. Saying SOA won't be enough to let anyone know what might work or not work, and what things might have to happen for the "contract" to be viable. That's all technology details. Disagree. OASIS SOA RA will set the standard on the service contact content. Today released TOGAF 9.0 also offers its own contract template. That is, if you refer to any one of them, people would know what you mean. > The interface documents the contract that the service provides from a data in/data out perspective. Secondary things such as QOS, availability, data integrity over time etc, are what 'legal contracts' are for. If the API needs to be part of the 'legal contract', then that will happen to. But the word 'contract' has legal, interface, architectural, performance, QOS etc perspectives which are only documented as part of "the legal contract" which may differ from the interface contract that the software provides as a "software component". I agree with combination 'interface contract'; I use it too but in the context of de-facto agreement between consumer and provider. However, this is not a service contract, which has different content and meaning. >> 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. >I know that your primary language is not english. I'm not quite sure what >these >two sentences are about. Can restate them or clarify so that I can >understand? >And this seems like an important instance of this specific issue. You used >words which you thought were useful and informative. Each word is spelled >correctly, but used together, in this way, they are not revealing to me. You have separated the comment into two parts and lost the sense. I am saying that interface is not a contract by semantic of the word 'contract' (which means an agreement between parties). Service interface is offered without any agreements. In the Service Contract, a consumer can choose which service interface to use; after this event we can say that the interface's contracted or, as mentioned above, use 'interface contract'. Anyway, it is not the major point. I wanted to outline only that _contract_ != _interface_ and _interface_contract_ != _service_contract_. I hope, this is in better English... :-) - Michael ________________________________ From: Gregg Wonderly <[email protected]> To: [email protected] Sent: Monday, February 2, 2009 9:26:53 PM Subject: Re: [service-orientated-architecture] Re: Service Façade Michael Poulin wrote: > > > 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 regularly order hot Tea at many US restaurants. It may be more uncommon to prefix your tea order with "hot" vs "iced" in some places, but not in my experience. This kind of different view on terminology and experience with specifics is why I think there is too pure of a view of SOA as a useful term. There are all kinds of standards and written material which MUST be consumed to get "anything useful" out of the term SOA. If I told you I had a fully implemented and OASIS standard SOA at my business, would that allow you to know that you could sell me you really great authentication/ authorization service that was going to utilize Google's new OAuth stuff? How would you know how I might integrate it? How would you know whether I had any authentication/ authorization on any service in my SOA at all? SOA wouldn't tell you "anything useful" about how to make me your customer... > 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. Which developers? Do you have names and addresses and are you sure that your list is complete? How can you be sure? > 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. So somebody wrote something into a document. Are you sure that everyone you have a conversation with has read this document? If they haven't, how do you know this? How do you know how much specific ignorance you will deal with as the conversation opens? Do you tell by the missing "hand slap" on the forehead from the DOH moment? I'm trying to make sure it's clear to you that I am asserting that there can never be a conversation about a topic as large as SOA and have the term "SOA" reveal anything to people who wish to form a "contract" about things that will happen between their SOAs. Saying SOA won't be enough to let anyone know what might work or not work, and what things might have to happen for the "contract" to be viable. That's all technology details. > 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. I am surprised that you can't imagine that ignorance will exist until education happens. The masses will always need help understanding what words mean, especially in context. > 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" But that is my point! Because "useful" varies, you can't depend on what bit of "useful" will happen. So, there will always have to be "additional qualification" paths in the conversation. > - 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? The interface documents the contract that the service provides from a data in/data out perspective. Secondary things such as QOS, availability, data integrity over time etc, are what 'legal contracts' are for. If the API needs to be part of the 'legal contract', then that will happen to. But the word 'contract' has legal, interface, architectural, performance, QOS etc perspectives which are only documented as part of "the legal contract" which may differ from the interface contract that the software provides as a "software component". > 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. I know that your primary language is not english. I'm not quite sure what these two sentences are about. Can restate them or clarify so that I can understand? And this seems like an important instance of this specific issue. You used words which you thought were useful and informative. Each word is spelled correctly, but used together, in this way, they are not revealing to me. Gregg Wonderly
