Qualification 'into service', IMO, is not in the interface but in behavior of the entity. - Michael
________________________________ From: Dennis Djenfer <[email protected]> To: [email protected] 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> >
