Rob, what makes an application a service? IMHO, it is the application behaviour, not its interface. In my example, I have created a service on the top of Documentum (it was not an interface Documentum did not give us its code). The service used Documentum publishing engine as the data resource and operated triggered by the publishing events. [Thanks for reminding me that the 'interface does not make service out the application', I pleased you attribute it to m :-) ]
Generally, don't you think that a pub/sub (vs. P2P) as well as an orchestration (vs. choreography) are natural SO solutions/patterns? - Michael ________________________________ From: reamon943 <[email protected]> To: [email protected] Sent: Mon, December 28, 2009 3:17:16 PM Subject: [service-orientated-architecture] Re: Descriptions vs Contracts I don't see how it is SO either. Seems like the "service" label was put on an existing application along with a classic pub/sub interface. It's a nice technical solution to a technical issue but I don't see how it is anything other than a "pure integration solution." Maybe there is more to the story, Michael, but with the information provided it seems to be an example of one of the practices you (rightly) criticize--that placing a particular interface on an existing app makes it a service. I think one would be hard-pressed to argue that a pub/sub interaction is "more SO" than other interaction types. The part about the right way of thinking is good stuff. I'm just not sure the example really captures that. - Rob --- In service-orientated- architecture@ yahoogroups. com, Dennis Djenfer <d...@...> wrote: > > 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.1000vent ures.com/ business_ guide/crosscutti ngs/cultures_ > > sun_tzu_the_ art_of_war. html>he > > Art of War > > <http://www.1000vent ures.com/ business_ guide/crosscutti ngs/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
