Your statement seems to imply existence of an particular entity which must be used. In your opinion, what is the goal of SO?
H.Ozawa 2009/12/29 Michael Poulin <[email protected]> > > > 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> <[email protected]> > *To:* service-orientated- architecture@ yahoogroups. > com<[email protected]> > *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 > *T<http://www.1000ventures.com/business_guide/crosscuttings/cultures_sun_tzu_the_art_of_war.html>he > Art of > War<http://www.1000ventures.com/business_guide/crosscuttings/cultures_sun_tzu_the_art_of_war.html> > * 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> <[email protected]> > *To:* service-orientated- architecture@ yahoogroups. > com<[email protected]> > *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 <[email protected]>> > >> >> >> 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 <[email protected]>> >> >> >>> So Steve, you're designing all your services these way. >>> >>> H.Ozawa >>> 2009/12/23 Steve Jones <jones.steveg@ gmail.com <[email protected]> >>> > >>> >>>> >>>> >>>> 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 <[email protected]>> >>>> >>>>> >>>>> 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<[email protected]> >>>>> > >>>>> >>>>> >>>>>> >>>>>> 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 <[email protected]>> >>>>>> >>>>>> >>>>>>> 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<[email protected]> >>>>>>> > >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> 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<[email protected]> >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>>> 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<[email protected]> >>>>>>>>> > >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > > > > >
