Hi again, I think we're having a gap in communication between members of this list because some are still thinking in terms of OFOM (Old fashioned object methodology) while some are thinking in DCI. H.Ozawa 2010/1/8 Dennis Djenfer <[email protected]>
> > > 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: > > Dennis, > 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 <[email protected]> <[email protected]> > *To:* [email protected] > *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. > > Steve > > > 2009/12/29 Dennis Djenfer <d...@algonet. se <[email protected]>> > >> >> >> 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> <[email protected]> >> *To:* service-orientated- architecture@ yahoogroups. >> com<[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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> >> >> > > >
