Rob,
nothing new under the Moon...
It is probably my fault - I could not clearly articulate my case. Actually, as
I said, I did not modify Documentum but set an independent service that used
Documentum WebPublisher as a resource. The service was triggered by the
publishing event. Documentum's behavior did not change, it was my service who
created new RWE.
In the contrast, when Documentum implemented similar (by RWE) solution via
targeted HTML notification, that was pure integration, as you said.
As of interface role for the service, it was my original idea but not necessary
only my idea ("Does a Web Service Make a Service for SOA?", MAY 13, 2006,
Sys-con)
I think that some interactions are "more SO" than others because they have to
preserve SO Principles. For example, service choreography as a concept or
pattern is fine with SO, however its current standardisation (and related
implementation) crosses into 'orchestration' pattern and violates a few SO
Principles (Service-oriented chess game: choreography or orchestration? Part 1)
- Michael
________________________________
From: reamon943 <[email protected]>
To: [email protected]
Sent: Sat, January 2, 2010 7:57:58 PM
Subject: [service-orientated-architecture] Re: Descriptions vs Contracts
--- In service-orientated- architecture@ yahoogroups. com, Michael Poulin
<m3pou...@.. .> wrote:
>
> 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).
IMO, what you described was an interface to Documentum, not a "service on top."
Who authored the code is immaterial.
The activity/characteri stics you described pertained to the interface. The
Documentum behavior (RWE) did not change. What changed is how messages get to
it.
> 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 :-) ]
To be clear, I don't think I credit you with coming up with that--just that it
is an aspect you've pointed out many times in the past.
>
> Generally, don't you think that a pub/sub (vs. P2P) as well as an
> orchestration (vs. choreography) are natural SO solutions/patterns?
I don't think any particular interaction style is "more SO" than any other.
Pub/sub and P2P interactions are fine. Orchestration vs. choreography both fit
in an SO environment.
-Rob
