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 [email protected], 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.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
