OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Consumer-Mediator-Service (was Reaching closure on Action)

David, I believe we are on the same plate  you accidentally deviated from the line of my statement.

I  am a fun of asynchronous service and all examples of yours are pleasant to me. When a consumer (subscriber) registers its intent to obtain a RWE with a Mediator/Broker/Destination (Queue/Topic), it is done via sending a message, right? So, the question here (and it is a complex question; I will elaborate later on it) are:
1) is a Mediator/Broker as SOA service or just SOA infrastructure element?
2) are Mediator/Broker and Provider constitute (together) one service to a consumer or two?
This is a different discussion than the one I responded though it relates to the Action discussion.

Here are my thoughts.

An orchestration is absolutely possible and needed and in SOA is represented as a service which implementation is orchestration implementation. That is, a process implementing orchestration is viewed as a service. Certainly, a consumer service may and can initiate an interaction with another service as prescribed or ad-hock (if the consumer decides it meets consumers needs). 

I am reading your a pure orchestration where there can be no composite services or even inputs from other sensing sources to tailor the action of a provider service because the initiation would not come from the consumer service as two things:
a) a pure orchestration is not a service but an infrastructural component which uses services (as orchestration activity providers). I do not see any problems with this. 
b) initiation of a process implementing mentioned orchestration comes from a component which is not represented as a service. Fine, why not?
Both cases may be in SOA environment as well as the orchestration wrapped as service. 

Your point, I guess, is how we can explain message exchange between the consumer component and the service engaged by the orchestration. I think, there is not interaction between consumer and service in this scenario, i.e. the question is not applicable. In SO interpretation of this case, a consumer does not know about service existence and invocation; it does not have a contract with the service and never evaluated service description. It is not consumer intent of obtaining a RWE from the service.

More difficult case when a consumer reviews Service Description, chooses the service but has to deal with an intermediary  Mediator/Broker/Destination instead. In a couple of my articles, I described this case as following:  consumer is interested in the service functionality and provided RWE; consumer does not know and does not care how the RWE provided; consumer does not know and does not care about infrastructure used to reach the service  consumer know only service logical and physical (reachability) interfaces. This leads to only one conclusion  an intermediary (including Mediator/Broker/Destination and ESB) belongs to the service provider from the service consumer perspective. An alternative view may be only if the intermediary explicitly represents service/provider and offers services functionality and RWE on behalf of the service.

I believe, this is the only SO approach. If a consumer has to deal separately with the intermediary, hoping that the service would perform in accordance to SLA, it is 1) an application stile, not SO; 2) it does not help consumer because the intermediary is not involved into contractual obligations to the consumer, i.e. consumer has not chosen intermediary SLA as appropriate for consumers needs.

I am not against ESB and Mediator/Broker/Destination; they implement a legitimate pattern. However, in SOA, they have to be used in the SO manner  as a part of the service for a service consumer. 

I also see your point where you try totally decouple consumer from the service. First, it is impossible because they have to agree on the messages taxonomy and semantic; second, consumer agrees to the providers communication and execution policies (and may not agree to the intermediary policies  unless they are the part of the Service Description). 

I think we should not try to merge SOA with EDA. They have different concepts and principles. Does EDA compliment SOA?  Absolutely, but they are not the same thing.

- Michael


I disagree with the last part which states "(i.e. consumer demonstrates an intent to obtain a RWE via interaction with the service  by sending/exchanging messages)".  In the Event Notification (MEP) the Service Consumer sends a "registerinterest" message to the Mediator Service (which could be a very simple Event Broker or a complicated Composite Service) not the actual participant which measures or causes the RWE. Question does this make the Mediator Service the actual Service Provider?

If I buy a NOAA weather radio and tune it to the correct frequency, when the National Weather Service sends the message out to "weather broker/mediator services" they convert the message to a radio transmission which lets me know to take action.  If it was a TV station and I tuned into the local TV station there would be warnings scrolling across the screen. If it was my cell phone company, I would get a broadcast message on my subscribing phone if I were in the warning area.

The Consumer "trusts" the Mediator and Providers promise to perform its service at some future time under specified conditions ("obligation") and demonstrates intent by performing both the subscription and action to listen/receive the share understanding of the future condition/obligation.  This is no different than making arrangements to have a stock broker buy/sell stocks on the consumers behalf at some future time and report the transaction to Consumer. 

Your condition "(i.e. consumer demonstrates an intent to obtain a RWE via interaction with the service by sending/exchanging messages)" negates the concept of choreograph or chained composite services because the consumer must initiate every consecutive service action directly.  Question does this mean services cannot initiate services? This is a pure orchestration where there can be no composite services or even inputs from other sensing sources to tailor the action of a provider service because the initiation would not come from the consumer service.  I can think of no more tightly coupled "SOA" that this.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]