Loading ...
Sorry, an error occurred while loading the content.

Re: [service-orientated-architecture] Re: Descriptions vs Contracts

Expand Messages
  • Steve Jones
    +1 Steve 2009/12/28 Gregg Wonderly
    Message 1 of 77 , Dec 29, 2009


      2009/12/28 Gregg Wonderly <gergg@...>

      I think one of the still, largely unrecognized issues is that developers really
      should be designing services as RPC interfaces, always. Then, different service
      interface schemes, such as SOAP, HTTP (Rest et.al.), Jini, etc., can be more
      easily become a "deployment" technology introduction instead of a "foundation"
      technology implementation that greatly limits how and under what circumstances a
      service can be used. Programming Language/platform IDEs make it too easy to
      "just use" a single technology, and then everything melds into a pile of
      'technology' instead of a 'service'.

      Gregg Wonderly

      Michael Poulin wrote:
      > I think, one interesting aspect of service orientation is berried in
      > this CBDI phrase: use of the spec as a public description requires much
      > deeper shearing of the service semantics between the service developers
      > and " the service consumers and solution architects". This is a BIG
      > problem!
      > It limits abilities of the service providers to advertise the service to
      > different consumer societies, different audiences, and different areas
      > of Business. To be used in Business, the shared semantics must be
      > minimal and it is not any close to the development vocabulary. Thus, I
      > can conclude that the CBDI's approach (based on the quote posted by
      > Dennis) is good if "developers and testers, ...service consumers and
      > solution architects" belong to the same society that shares all low
      > level details about the service. This may cause problems even inside the
      > same enterprise if it is large enough (CORBA Object Trading Service has
      > taught us hard lessons with this regard).
      > - Michael
      > ----------------------------------------------------------
      > *From:* Dennis Djenfer <dej@...>
      > *To:* service-orientated-architecture@yahoogroups.com
      > *Sent:* Fri, December 25, 2009 12:13:11 AM
      > *Subject:* Re: [service-orientated-architecture] Re: Descriptions vs
      > Contracts
      > Ok. In this case I think CBDI are using the specification both for
      > internal use by developers and for public use by service consumers. The
      > CBDI Wiki has the following to say about the Serice Specification:
      > "Though it initially acts as an instruction to the developers and
      > testers, it is subsequently utilized by the service consumers and
      > solution architects."
      > // Dennis Djenfer
      > Michael Poulin wrote:
      >> ...actually, the semantic of the name. To my knowledge, OASIS used
      >> term 'Service Description' to avoid term 'specification' . The former
      >> was viewed as publicly available 'specification' for the service
      >> consumers while actual service specification was meant for the
      >> internal use for the developers. (When Amazon
      >> - publishes PC specification, it is not the real one, it is dedicated
      >> to the buyers. So, instead of explaining which spec is meant, OASIS
      >> just used different term).
      >> - Michael
      >> ----------------------------------------------------------
      >> *From:* Dennis Djenfer <dej@algonet. se>
      >> *To:* service-orientated- architecture@ yahoogroups. com
      >> *Sent:* Wed, December 23, 2009 4:01:41 PM
      >> *Subject:* Re: [service-orientated -architecture] Re: Descriptions vs
      >> Contracts
      >> Michael Poulin wrote:
      >>> It is very interesting and informative post, Lawrence!
      >>> Here is a little challenge (again): a service is built against its
      >>> specification - documented or not. You can derive a public
      >>> announcement from this spec - Service Description. As Service
      >>> Description may have versions, as the service spec may have versions.
      >>> Together, this becomes difficult to manage (on the producer's side).
      >> What makes you believe that the Service Specification is not the same
      >> thing as a Service Description (except for the name)?
      >> // Dennis Djenfer
      >>> "we do find a lot of reluctance to make this effort - particularly to
      >>> make the investment if such a registry/catalog isn't already in
      >>> place, and as often as not " - is, unfortunately , a common place. We
      >>> tried to fight it with IT Governance that treated each service as an
      >>> independent product, i.e. with full and maintained across projects
      >>> documentation. This, implicitly, answers the question - what should
      >>> be documented. Because of such governing policy, not many components
      >>> and RPCs were considered as services (in the end) - only the ones
      >>> that had particular and strong business/technical meaning.
      >>> SO as the concept and related Governance must prevent even an idea of
      >>> shortcutting on service-consumer relationship - they must be treated
      >>> as independent in spite of any administrative/ management ownership
      >>> boundaries. This is why I position Architecture above Management. The
      >>> major principle during the service design and implementation - no
      >>> concrete assumptions of the future consumers ( and, especially, who
      >>> will command them); nothing more than a potential category of them.
      >>> If your team/management violates this principle, they are not
      >>> service-oriented yet.
      >>> - Michael
      >>> ----------------------------------------------------------
      >>> *From:* LAWRENCE <l.wilkes@btinternet .com>
      >>> *To:* service-orientated- architecture@ yahoogroups. com
      >>> *Sent:* Tue, December 22, 2009 2:06:20 PM
      >>> *Subject:* [service-orientated -architecture] Re: Descriptions vs
      >>> Contracts
      >>> --- In service-orientated- architecture@ yahoogroups. com
      >>> <mailto:service-orientated-architecture%40yahoogroups.com>, Michael
      >>> Poulin <m3poulin@.. .> wrote:
      >>> >
      >>> > As I guess, Lawrence, the service specification is an internal
      >>> document. While I fine with deriving Service Description from the
      >>> service spec, it would be interesting to know how you have resolved
      >>> the ownership issue of this specification; does it belong to IT or to
      >>> Business? Example: consumer provides the instructions and funds and
      >>> the service invests them accordingly; who is the custodian of the
      >>> service spec?
      >>> Our approach is to have a multi-facetted Service Specification that
      >>> addresses all audiences. As you don't want separate business and IT
      >>> specifications that drift out of synch, it is better to have them as
      >>> different properties of the same specification. (of course, that
      >>> still requires someone to keep the properties in synch - but common
      >>> ones should be shared, not duplicated)
      >>> As listed in our wiki, http://cbdi. wikispaces. com/Service+
      >>> Specification, <http://cbdi.wikispaces.com/Service+Specification,> we
      >>> have several sections in our specification
      >>> * Service properties that provides basic information on the status
      >>> and history of the service
      >>> * Business properties that show how the Service supports the
      >>> business, and who in the business is responsible for the Service
      >>> Technical properties that provide a more IT-centric view of the Service
      >>> * Quality of service that is or should be offered by the Service -
      >>> such as the reliability or security requirements
      >>> And at the more detailed level
      >>> * Functional behavior of the individual operations, including the
      >>> operation signature, together with the pre and post conditions that
      >>> must be met by the provider and consumer
      >>> * Details on message exchange
      >>> * A Service Information Model that details the information that is
      >>> stored or retrieved by the Service.
      >>> One of the key challenges though is where/how to document and store
      >>> such information. Ideally, a template such as ours should be turned
      >>> into a schema in some form of registry/catalog product - we have for
      >>> example worked with IBM WebSphere Service Registry and Repository,
      >>> and SAG Centrasite, and also Orbus Software iServer this year to
      >>> provide examples of this. It is well beyond the scope of UDDI, so
      >>> clearly requires some effort.
      >>> However, we do find a lot of reluctance to make this effort -
      >>> particularly to make the investment if such a registry/catalog isn't
      >>> already in place, and as often as not I believe our template just
      >>> becomes rows in an Excel spreadsheet. ... or pages on a wiki.
      >>> The other important question to ask is does every service need to be
      >>> documented to this extent? But this is a much the age old question of
      >>> do I really need to produce this much documentation as much as
      >>> anything else.
      >>> Answers might be, well only if
      >>> * there is true organizational separation of provider and consumer,
      >>> or specifier and implementor
      >>> * it is a shared service - many consumers
      >>> * the behavior is anything other than obvious (e.g. I think I can
      >>> guess that the UpdateCustomerPhone Number operation does - but then
      >>> again, can I? Does it validate the area code? does it allow
      >>> international numbers? never so simple...)
      >>> The difficulty then is what doesn't appear to need documenting today,
      >>> might do tomorrow. e.g. we never thought it would be shared - but it
      >>> was...
      >>> One of the things we are working on at the moment is to ensure that
      >>> as much as possible of our service specification template can be
      >>> captured in our UML profile, so at least the capture can be
      >>> 'automated' to some extent (in that properties can be infered from
      >>> associations for example, and transformations from UML to XML or
      >>> WS-Protocols)
      >>> Process-wise, we don't see the Service Spec as something that is
      >>> fully developed in one pass. Rather it evolves from just description
      >>> level properties at the planning stage, through the detailed
      >>> specification of operations at the provisioning stage, to the
      >>> addition of technical run-time details once provised and deployed.
      >>> But these are all 'views' of the same asset - not different
      >>> documents. Equally, new operations may get added over time.
      >>> - Lawrence Wilkes, Everware-CBDI

    • Michael Poulin
      I would say half-full - SOA as an architectural style is still not solid enough. As of SO Principles, Thomas Earl made a great job by formulating early
      Message 77 of 77 , Jan 15 9:44 AM
        I would say "half-full" - "SOA as an architectural style is still" not solid enough.

        As of SO Principles, Thomas Earl made a great job by formulating early version of them. Then, he tried to review and re-comment on them when understanding of SOA changed. These very Principles are the most popular and I did not see any explanations from the authors proposing different principles on what was the reason for the difference.  I also reviewed the Thomas Earl' edition of  SO Principles but I posted pages of my arguments for every change I proposed (http://www.ebizq.net/blogs/service_oriented/2009/02/principles_of_service_orientation_reviewed.php). It is another thing if everybody agrees with my version or not but there is a foundation to reach the agreement.

        - Michael

        From: Dennis Djenfer <dej@...>
        To: service-orientated-architecture@yahoogroups.com
        Sent: Fri, January 15, 2010 2:24:19 PM
        Subject: Re: [service-orientated-architecture] Descriptions vs Contracts


        Michael Poulin wrote:

        it seems we agree to disagree.
        That's fine with me.

        I listed SO Principles not to explain why my solution is service-oriented but to illustrate that some of the SO Principles appeared in your initial list were addressed.
        The list enumerates the principles from Thomas Earl (except for Service Interoperability, my mistake). The problem is that if you look up service-oriented principles in another book, you'll find a different set of principles and goals. How is it possible to judge if something is a service-oriented when we can't agree about the principles? And even worse, we don't know how to consistently interpret the principles. SOA as an architectural style is still quite fuzzy.

        // Dennis Djenfer

        Here are only two comments:
        1) about 'Service Reusability - DOC sent HTTP notification to preliminary configured URI regardless if there is anybody to accept it with no ability to re-send it' - indeed, DOC's solution is NOT about reusability but about, as you correctly said, availability. While my solution was about reusability.

        2) the differences of well-known execution context for all applications and service execution context are in 1) service execution context has clear and consistent definition - it is set of execution policies; 2) service execution context includes both technical and business policies; 3) depending on the execution context (policies) the service RWE may differ.

        If J2EE claimed Facade Pattern as a J2EE Pattern for EJB, Execution Context with special definition via policies (SOA RM and RAF) may be a SO Principle...

        - Michael

        From: Dennis Djenfer <dej@algonet. se>
        To: service-orientated- architecture@ yahoogroups. com
        Sent: Thu, January 14, 2010 1:37:32 PM
        Subject: Re: [service-orientated -architecture] Descriptions vs Contracts


        Michael Poulin wrote:

        Sorry, Dennis, I mislead you with 'Principle', it is purely cultural :-); "available in Principle" means available theoretically (because the Principle is the place with no problems whatsoever). The concept of Principle has, probably, different name in English-speaking culture.

        Actually, I think the meaning of those terms are the same in English, Russian, and Swedish. I was just reading your answer a little bit too fast. Sorry 'bout that.

        On a serious note, I think that following SO Principles are applicable to my solution and less applicable to the Documentum's (DOC) solution:
        Service Reusability - DOC sent HTTP notification to preliminary configured URI regardless if there is anybody to accept it with no ability to re-send it

        I wouldn't classify this as reusability, but rather as availability. Availability is important, but it doesn't help us distinguish between services and non-services.

        Service Relative Autonomy - DOC notification service owned the trigger inside the DOC
        Your solution publishes meta-info into a topic. The topic is part of your services public interface. There's a pretty good chance that the pub/sub mechanism is implemented as an observer pattern under the hood. Hence, I don't think there is much difference with regard to this quality attribute.

        Service State Management - durable subscription in MOM allowed to configure the message state lifetime
        That's good, but is this quality attribute something we can use to distinguish between a service and non-services? I don't think so.

        Service Discoverability - regular service feature provided by RMI (response from the RMI service provided information for JMS subscription to particular Topic on-line)
        I think this is an important attribute of a service, but your exemple doesn't say much about this. First, the consumer must be able to find the service, e.g. by using a registry/repository , wiki, hypertext links from other services and so on. Second, the consumer must be able to get all necessary information about the service to be able to decide if the provided service is what he/she need. Third, the consumer must be able to get all necessary information about how to connect to the service.

        Discoverability is important, but it still is a grey zone when it comes to distinguish between a service and a non-service. For example, imagine two companies, company A and company B, that implements the exact same business functionality and encapsulates it as a software unit. Company A describes the service and puts the description in a registry/repository , but company B doesn't. At company B you must find "John" and ask him about the service. He will tell you everything you need to know about how to use and connect to the service.

        Is it only company A that has a service or has Company B also a service, although it is a bit harder to find?

        Service Execution Context - different Topics were configured for the message lifetime differently depending on the lifetime of the published content
        I must admit I have trouble understanding what exactly constitutes the execution context, although I understand it in principle :-) And by the way, I don't think execution context is a service oriented principle. Any software component that interacts with another software component has an execution context.

        I'm not sure if a topic is part of the execution context, but it's certainly part of the public interface of the service. When you configure a different topic it's basically equivalent to creating a new method on a RPC interface. In the solution from DOC I guess you could have the user register for a new subject instead.

        Service Separation of Concerns  - DOC's solution served only DOC while my solution could serve any content publisher performing Content Notification service (the meta-information about published materials was sent in the notification message).
        This is a very good principle to follow for almost any architecture, but is it something we can use to distinguish between a service and a non-service? Not really.

        I think that I developed a real service using technology capabilities because it could serve anybody who had access to JMS providing meta- information about published materials from an arbitrary Publisher (service resource).
        I say that we have one good technical solution and one not-so-good technical solution to solve the business problem, but I don't think we're able to point to anything specific and say "this solution is a service oriented and the other is not". What we can do is to look at different quality attributes and aspect that we have agreed about are important for a service oriented solution and compare them with each other. We may then be able to say that service A is better than service B with regards to those quality attributes or aspects. Unfortunately, it's much harder to tell when something is a service or not. In most cases it ends up in a discussion with subjective opinions about what constitutes a service.

        Actually, I see two problems:
        1: Is it possible to unambigously judge when something is service by just examine one potential service?
        2: Is it possible to unambigously judge when a solution is service-oriented by looking at a map of  potential services?

        // Dennis Djenfer

        - Michael

        From: Dennis Djenfer <dej@algonet. se>
        To: service-orientated- architecture@ yahoogroups. com
        Sent: Fri, January 8, 2010 1:51:06 AM
        Subject: Re: [service-orientated -architecture] Descriptions vs Contracts


        What is the difference in business intent between the two solutions you have described? As far as I can see the business intent of both solutions is to timely publish authored content on the web. Of course, we could look at the business intent of the Documentum application only, but in that case I think we're talking about "a pieces of technology that may at a 2nd remove deliver a business value" as Steve expressed it.

        On a technical level, both solutions deal with the problem of getting the information from the Documentum application to the ATG Dynamo server as soon as there is any newly authored content in the Documentum application. Both solutions accomplish that goal. I have no problem recognizing that your solution is better than the one suggested from Documenten, but the difference is in the choosen design pattern. Your solution uses the Publish-Subscribe pattern, Documentum's solution uses the Observer pattern. Clearly, Publish-Subscribe is better suited to a distributed environment than the Observer pattern.

        You claim that we can unambigously define service orientation from the principles. Which principles are you refering to? A bunch of principles that are quite popular has been written down by Thomas Erl:

        Standardized Service Contracts
        Service Loose Coupling
        Service Abstraction
        Service Reusability
        Service Autonomy
        Service Statelessness
        Service Discoverability
        Service Composability
        Service Interoperability

        I must admit that I have a hard time to tell that your solution is service oriented and Documentum's is not, just by looking at the above principles.

        // Dennis Djenfer

        Michael Poulin wrote:

         it is surprise to me that you see only different technologies in my example. I think I was clear on difference of the behavior and roles. Can you tall a difference between good service in the shop and bad service? I can: if the sales person ignores the entier queue and sees the first customer only, I suggest it is the bad service (typical to England and France and almost never found in the US).

        So, I do not share your concerns. Unambiguously defined service orientation is available in Principle; in real life we deal with grades of service orientation.

        - Michael

        From: Dennis Djenfer <dej@algonet. se>
        To: service-orientated- architecture@ yahoogroups. com
        Sent: Thu, January 7, 2010 1:06:30 PM
        Subject: Re: [service-orientated -architecture] Descriptions vs Contracts


        In the example from Michael, where he considered one solution to be more service oriented than another, the business intent was the same. As far as I'm able to interpret his exemple, the difference was in the choosen technology and the implementation of the technology.

        Actually, after all this years with service orientation, I think we have learned a lot, but we still can't unambiguously define a service and tell a service oriented solution apart from a non-service oriented solution. The grey zone is as big as ever.

        On the positive side I think SOA has helped many people in IT too think more about the business side of solutions to problems that involves IT. I also think SOA and the principles of service orientation has raised many important and worthwhile questions and discussions during the years, but I find it ironic that it still is very hard to unambigously tell if a solution is service oriented or not.

        // Dennis Djenfer

        Steve Jones wrote:

        Technology v Business intent.  Integration solutions are purely about the connection of pieces of technology that may at a 2nd remove deliver a business value.  A service is directly about the delivery of the business value.

        In other words (and I think the SOA-RM does this brilliantly) its the difference between technology infrastructure (the Execution Context in the SOA-RM) and the actual capabilities and service.  Integration solutions place the technology at the heart and then plug things together, SOA places the capabilities and services at the heart and relegates the internals to just plumbing.


        2009/12/29 Dennis Djenfer <dej@algonet. se>

        Ok, so what is the behavior of your solution that makes it qualify as service oriented and not as a pure integration solution?

        // Dennis Djenfer

        Michael Poulin wrote:
        Qualification 'into service', IMO, is not in the interface but in behavior of the entity.
        - Michael

        From: Dennis Djenfer <dej@algonet. se>
        To: service-orientated- architecture@ yahoogroups. com
        Sent: Sun, December 27, 2009 5:11:11 PM
        Subject: Re: [service-orientated -architecture] Descriptions vs Contracts


        I wonder if that is enough to qualify as a service oriented solution. With that kind of reasoning a Web Service slapped on a database because an application needed the data would be service oriented.

        // Dennis Djenfer

        Michael Poulin wrote:

        Service orientation in my solution is in Documentum service offered a service (via JMS) and all interested (the ATG Dynamo servers) were able to use it.  In the contrast, the Documentum's solution was based on blind push of information to pre-defined IP address with no mechanism for the consumers to change them at wish (but only through the negotiation with and reconfiguration of the Documentum server). I think that my solution was service-oriented while the Documentum's one was much more traditional P2P integration. This is the about "the right way of thinking" or freedom for consumers (specific to SO) rather than technology comparison.

        - Michael

        From: Dennis Djenfer <dej@algonet. se>
        To: service-orientated- architecture@ yahoogroups. com
        Sent: Sat, December 26, 2009 10:23:30 PM
        Subject: Re: [service-orientated -architecture] Descriptions vs Contracts


        I don't get why your solution is service oriented. All I can read from your exemple is two kind of solutions for an integration problem. They have different technical solutions and quality attributes, but I don't get why one of them is service oriented.

        // Dennis Djenfer

        Michael Poulin wrote:

        I think, Sun Tzu  in his  The Art of War  has given us the receipt for SOA implementation for downtime saying "Nothing is as important as having the right way of thinking."

        SO is about SO thinking; SO needs technologies and expensive systems at the very last, if ever, moment. SO is not in technologies like BPEL and others. You can build service orientation into regular code if you think first about it.

        For example, several years ago I had a problem to solve: our Documentum server prepared Web content, which had to be used by the Application/ Web Servers (ATG Dynamo that time) to publish on the Web, but did not notify ATG Dynamo when the content was ready. Our Business publisher authored the content but could not manage the publishing time. In my SO Solution, I placed Documentum' s meta-file about prepared content into MOM/Topic and made all ATG Dynamo servers to subscribe to the Topic announcements. The ATG Dynamo servers used to be re-booted nightly but they were able to get all missed information and the new one due to the durable subscription to the MOM Topic. Where ATG Dynamo servers were shut down and where they (or their replacements) came up on-line (i.e. their IP address) did not matter to the solution. [When Documentum learnt this solution from us, they provided a free integration Documentum-ATG Dynamo via Web channel. In their solution, Documentum not only updated the data-store with the prepared content but also sentthe  appropriate Web 'requests' to the registered ATG Dynamo servers. It looked fine except for the cases when ATG Dynamo servers lost all information when being down and had to get on-line with exactly the same IP address they registered with the Documentum server before. This was pure integration solution while I can consider my solution was much more service oriented.]

        - Michael

        From: Hitoshi Ozawa <htshozawa@gmail. com>
        To: service-orientated- architecture@ yahoogroups. com
        Sent: Fri, December 25, 2009 10:56:29 PM
        Subject: Re: [service-orientated -architecture] Descriptions vs Contracts

        I think you've hit the major difference we're having. I'm in an actual project and tailoring my service so they can actually be implemented with the current available technology, development members, and other constraints. Also, with the economic slow down, it is also necessary to reduce cost.
        There was a mention of BPEL in the other thread, and I think the basic technology is interesting, but the current situation requires too knowledge of too many specifications that it almost impossible to educate development members to complete a project in time. Of course, in a small project, I can just do it myself but in a large project, that's impossible.
        SOA is dying not because the theory behind it is bad, but that what most people are preaching can not currently be implemented in a project. The tight economy is also sifting the emphasis from "to be" more toward  "can be".

        Anne's cartoon showed a "SOA dinosaur", but IMHO the dinosaur really isn't the concept of SOA itself, it more of us who's not adjusting to the current economic market.
        Happy Holidays,
        2009/12/25 Steve Jones <jones.steveg@ gmail.com>

        I'm designing them in this way but unfortunately in implementation there isn't the technology to support this stuff.  WS-Contract or WS-SLA never happened and there isn't anywhere near the formalism required.


        2009/12/23 Hitoshi Ozawa <htshozawa@gmail. com>

        So Steve, you're designing all your services these way.

        2009/12/23 Steve Jones <jones.steveg@ gmail.com>

        I can't see why not, although I'd reword it to be

        In order to ship the carton a valid set of legal constraints, written in French, must be agreed.

        Take Air Traffic Control, there are two official global languages for ATC there is English (used in 99% of the world) and there is French (guess where that is used) but they are both official languages at the service description level.   Now some people can constrain their description to say "we only accept English" but this is still at the service description level as an individual contract (with a plane) has not yet been entered into.


        2009/12/22 Hitoshi Ozawa <htshozawa@gmail. com>
        We're talking about service description. Is it alright to have "ship the carton with a valid set of legal constraints in French"?

        2009/12/23 Steve Jones <jones.steveg@ gmail.com>


        I can't see why a contract of send invoice via SOAP would be a problem with the description being "send invoice", why would it be a problem?

        I think we are in danger of disappearing into semantic holes.  I could argue that if the objective (service description) was to woo a lady then the choice of the language (service contract) could be either English or French.  In French we could take the Cyrano de Bergerac approach while in English we could fall back on the Bard of Avon.  Here the language is the piece that seals the deal and is linked to the specific consumer of the service, in other words the language chosen (the contract) is linked to the specific engagement between the producer and consumer.


        2009/12/22 Hitoshi Ozawa <htshozawa@gmail. com>

        Hi Steve,
        So are you implying "send invoice using SOAP"  is alright?
        If you are, I sure would like to see the system with such a design. :-)
        French and English are languages people use to rely concepts. British law is a concept. Concepts described in the British law does not (should not) change whether it's written in English or in French.
        2009/12/21 Steve Jones <jones.steveg@ gmail.com>


        I actually think that French and English is fine.  It is like having a shipping contract, there are a huge number of different legal jurisdictions that you could potentially use to ship the product from A to B (the description) but when you formalise the contract you pick a single legal country as your escalation point.

        So in other words the description of A to B just says "ship the carton with a valid set of legal constraints" while the contract says "ship the carton with British Law as the legal framework"


        2009/12/19 Hitoshi Ozawa <htshozawa@gmail. com>

        I think you're beginning to understand the concept, but your example is missing the point.
        Your analogy with French and English is inappropriate unless you're thinking of a translation service.
        Service description describes the semantic capabilities of the service while service contract describes the set of rules  used in an instance of an interaction. 
        2009/12/18 Andrew Herbst <herbst_andrew@ yahoo.com>
        Another question from an SOA neophyte.  Thanks for responding to my earlier questions.
        So, roughly speaking, a service description is like me announcing to the world:  “I can interact in French or in English”, whereas, a service contract is like me agreeing to speak French with a specific other person in the context of some very specific interaction.
        I realize this is a very basic question, and it may well not really be the aim of this group to deal with such basic things.  I will therefore take no offence if no one addresses this.
        Andrew Herbst

      Your message has been successfully submitted and would be delivered to recipients shortly.