The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

thabach (23) [Avatar] Offline
#1
Hello Arnon

IMHO, I think your definition of Message is too restrictive for a SOA. By precluding "plain" RPC you are not in compliance with the SCA (Service Component Architecture) specifications' view on the matter. Your definition precludes for example EJB native bindings in communication between services altogether. Is this delimitation really intentional ?

Regards, Christian.
arnonrgo (62) [Avatar] Offline
#2
Re: Section 1.1.1, Definition of Message.
Hi Christian,
The way I see it SCA is not limited to building SOAs - For instance it can be used to build component based "local" application. what you get in this situation is described in the spec as (section 2.2.2.2 in the Assembly Model spec): "
Local services are services that are designed to be only used “locally” by other implementations that are deployed concurrently in a tightly-coupled architecture within the same operating system process. Local services may rely on by-reference calling conventions, or may assume a very fine-grained interaction style that is incompatible with remote distribution. They may also use technology-specific data-types."

This is clearly not an SOA service, even though the confusing use of the word "service" (nothing new here - see my paper www.rgoarchitects.com/files/soadefined.pdf) - which means that the fact SCA can interact with EJB containers doesn't say much

Nevertheless, Services can interact with non-service consumers and if you tie a non-service consumer (such as a plain EJB component) to an SOA you do need to provide a translation that allows that connection such as translation from messages to RPC calls (which indeed SCA defines)

Lastly, the fact that the message is hidden from the final consumer it doesn't mean that it isn't a message in all the infrastructure layers. For instance, the naive usage of WS-* web-services in Java or .NET you just see it as a method call even though below the surface there's a SOAP message.

Arnon

PS
sorry for the delay in answering - I just returned from a week in US
thabach (23) [Avatar] Offline
#3
Re: Section 1.1.1, Definition of Message.
Hi Arnon
I do agree that local services which happen to be based on reference calling conventions, and/or do indeed implicate a fine grained interaction style (like the one in interacting with stateful services) should not be considered SOA services. Still in my opinion your definition of message does unnecessarily try to preclude EJB (i.e. IIOP-) messages (even though, they might indeed mirror a coarse-grained interaction, embodying a value message payload in targeting a stateless SOA service implementation).
What is really the point you are trying to make with your definition of message ? The "plain" RPC "messages" you cite in drawing the line, do typically have a distinct header and body segregation as well. I (still) don't get your point.
Regards, Christian.
arnonrgo (62) [Avatar] Offline
#4
Re: Section 1.1.1, Definition of Message.
Hi Christian,
I don't think that defining messages with header and body vs. methods calls
I am not sure about the RMI over IIOP implementations but as far as I can remember from my C++ CORBA days IIOP defined 6 or 7 message types some of them allowed (in addition to the GIOP) specific headers. I don't see (or try to say that there is ) a problem with implementing SOA over IIOP or EJBs (whether stateless or stateful)

I do think that RPC-type interactions, where you try to mask the existence of a network and which usually promoted fine-grained interactions is not suitable for SOA.
I (try) to explain the difference between RPC and Document oriented interaction in chapter 5 (Message exchange Patterns) which, as I see, is not available on MEAP yet - If you want you can send me your email and I'll send you back the pattern where I try to explain this difference.

Arnon
thabach (23) [Avatar] Offline
#5
Re: Section 1.1.1, Definition of Message.
Hi Arnon
thanks for your reply (and of course I am interested in chapter 5, my email can be found "encoded" on my profile page).
In my opinion the only particular property (and the point that should probably be made) in the definition of the message concept for SOA is self-containedness of messages. This does not necessarily imply document style messaging. Even though, admittedly in designing a document style messages based service, it is difficult to accidentally end up with an endpoint requiring a conversational style of communication (i.e. not a service) quite contrary to what might easily happen in designing a RPC based service.
Your writing about message headers and message bodies in section 1.1.1 does in my opinion really not bring any insight but rather confuses the attentive reader.
Regards, Christian.
arnonrgo (62) [Avatar] Offline
#6
Re: Section 1.1.1, Definition of Message.
Hi Christian,

> your writing about message headers and message bodies
> in section 1.1.1 does in my opinion really not bring
> any insight but rather confuses the attentive
I agree with some of what you said, in any event I take the point that it might be confusing and I'll try to rephrase my definition there in the next editing round

Thanks for the feedback

Arnon