+1 with Steve. Hitoshi, if you want to read about Intent and SO, I would recommend reading OASIS SOA RAF (available till 13 Jan. from OASIS Home page).
- Michael ________________________________ From: Steve Jones <[email protected]> To: [email protected] Sent: Mon, January 4, 2010 11:40:22 AM Subject: Re: [service-orientated-architecture] Descriptions vs Contracts I disagree. While Integration solution talk about business value their intent is purely technical, the business value is a hoped for by product of the integration. This for me is the difference that IT needs to make, namely the switch between burbling about technology and claiming mythical value against committing against business value and then worrying about the technology. I saw one IT presentation last year that talked about "business value" without a single quantifiable metric against which this value would be proven. That is what business driven SOA should be doing, starting with the service, capabilities, metrics and measures and THEN worrying about how best to support them with technology. Steve 2010/1/4 Hitoshi Ozawa <htshoz...@gmail. com> > > > > > > > > > > > > > > > > > >> > >> > >Intent? If intent is all the difference, they're probably the same. It's very >easy to talk about having intention to deliver business value and just do what >IT have been doing over the years. :-) > >H.Ozawa > > >2010/1/2 Steve Jones <jones.steveg@ gmail.com> > > > >>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. >> >> >>Steve >> >> >> >>2009/12/29 Dennis Djenfer <d...@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 <d...@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 <d...@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 <htshoz...@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, >>>>>>H.Ozawa >>>>>> >>>>>>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. >>>>>>> >>>>>>> >>>>>>>Steve >>>>>>> >>>>>>> >>>>>>> >>>>>>>2009/12/23 Hitoshi Ozawa <htshoz...@gmail. com> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>So Steve, you're designing all your services these way. >>>>>>>> >>>>>>>>H.Ozawa >>>>>>>> >>>>>>>>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. >>>>>>>>> >>>>>>>>> >>>>>>>>>Steve >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>2009/12/22 Hitoshi Ozawa <htshoz...@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"? >>>>>>>>>> >>>>>>>>>>H.Ozawa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>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. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>Steve >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>2009/12/22 Hitoshi Ozawa <htshoz...@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. >>>>>>>>>>>> >>>>>>>>>>>>H.Ozawa >>>>>>>>>>>> >>>>>>>>>>>>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" >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>Steve >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>2009/12/19 Hitoshi Ozawa <htshoz...@gmail. com> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>Andrew, >>>>>>>>>>>>>>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. >>>>>>>>>>>>>> >>>>>>>>>>>>>>H.Ozawa >>>>>>>>>>>>>> >>>>>>>>>>>>>>2009/12/18 Andrew Herbst <herbst_andrew@ yahoo.com> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>Greetings: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>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. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>Andrew Herbst >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >> >
