RE: [soa-rm] Semantic Meaning of Message

["Vyas, Neeraj" <Neeraj.Vyas@ca.com>]

In addition to it, I will see service in different contracts like
Service to Requestor Contract, Service to Service-Container contract. 

1. Service to Requestor Contract: This contract will tell the protocol
to be followed while communicating to service (will cover all points
mentioned by you). Here we should also provide reference model to
specify how to search specific services i.e. service search model (e.g
UDDI), Look at service metadata (e.g. WSDL) to invoke service on the fly
(e.g. WSDL to Java) without any prior concrete definition of service
client or requestor. More to come here.   

2. Service to Service-Container contract: This contract will define how
your service should interact with the service container and vice versa.
This will include defining the life cycle of Service within service
Container. It should define architecture to deploy service within its
container. Container should be able to send different events/callback
like service start, service stop, Handle-Request (call back method
before processing request), Handle-Response (call back method before
sending response to requestor), Handel-Fault (Callback methods to handle
any fault condition before sending actual fault to requestor). This
lifecycle and callback contract with service container will allow our
SOA-RM to support on demand Security and management of the services by
placing third party management and security product API calls from
within lifecycle/callback methods. This kind of architecture will also
support satisfying day to day changing business needs for cross cutting
concerns for deployed services. So without changing the actual service
you can keep putting handlers for request/response/fault to add any
business demand like logging, transaction handling, service routing,
orchestration, security, management, and any custom requirement. 

Any thoughts anybody??  

Thanks and Regards
Neeraj Vyas
CA Computer Associates
neeraj.vyas@ca.com

-----Original Message-----
From: Ken Laskey [mailto:klaskey@mitre.org] 
Sent: Monday, April 11, 2005 1:50 AM
To: Vyas, Neeraj
Cc: Gregory A. Kohring; soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] Semantic Meaning of Message

Thus we need the capability for an entity to invoke a service, to  
receive the results of that invocation back (e.g. some data, some  
report on a change of state, some response about the extent to which  
the request was satisfied), and to be informed if the invocation failed

in some standard way (that the invoked service could respond with a  
standard fault message) or in a way that the infrastructure needed to  
intercede. What architectural pieces does this imply?  I would see
- a mechanism to generate a request,
- a mechanism to carry the request to the service,
- a service mechanism to receive the request,
- a mechanism to generate a response (per request or fault),
- a mechanism to carry the request back,
- a mechanism to receive the response,
- a mechanism to monitor that a request and/or response has entered the

"carry" mechanism and intercede in case of fault within that mechanism.

Now you can say that we assume some of that exists outside the SOA we  
will define, but you've got to say it!

What other patterns (e.g. I need to find a certain type of service)  
imply what other needed mechanisms?

Ken

On Mar 31, 2005, at 7:54 AM, Vyas, Neeraj wrote:

>
> With respect to the question -- If "message" is too "concrete", what
is
> the abstraction?
>           I think abstract concept could be Service Request, Service
> Response and Service Fault. So in any case service consumer will send
> the request to actual service to consume it and would accept a
response
> from it, or in case of failure of service execution it would except
the
> cause of it (fault information). So in my opinion while defining a SOA
> reference model we need to define what request/response/fault model
one
> should use. Concrete concept can be Message, Event, Input/Output
> Parameters, Exceptions, etc. based on the communication channel one is
> using. Service can be defined as Request only or Request-Response,
this
> information can be collected from the service meta model.
>
>
> Thanks and Regards
> Neeraj Vyas
> CA Computer Associates
> neeraj.vyas@ca.com
>
> -----Original Message-----
> From: Gregory A. Kohring [mailto:kohring@ccrl-nece.de]
> Sent: Thursday, March 31, 2005 2:11 PM
> To: soa-rm@lists.oasis-open.org
> Subject: [soa-rm] Semantic Meaning of Message
>
> Hi,
>
> OK, I have looked at all three examples Duane gives and found that
> while none of them explicitly use the term "message", they all
> define concepts which have a similar semantic meaning.
>
> The RCS reference model, for example, uses the word "event" in much
> the same way an web service person would use the word "message".
>
> The OSI reference model is concerned about communication protocols
> and how they interact. It does not use the word "message", but does
> talk about exchanging "data" between protocols.
>
> The ITA reference model, again does not use the word "message", but
> does use the word "protocol" in a way which can be interpreted as a
> "message exchange pattern".
>
>
> So, while these reference models do not use the word "message", they
> do use terms denoting a similar concept.
>
>
> If "message" is too "concrete", what is the abstraction?
>
>
> Several posters have suggested that some form of "communication" is
> implicit in the definition of a service and therefore does not have
> to be explicitly mentioned.  But doesn't this go against the idea of
> building a reference model?  Shouldn't a reference model explicitly
> define all of its elements?  I would argue that anything which is not
> an implementation detail should appear in the reference model. (How
> you implement the message is an implementation detail, but not the
> concept of the message itself.)
>
>
> Cheers,
>
> Greg
>
>
> --  
> ======================================================================
> G.A. Kohring
> C&C Research Laboratories, NEC Europe Ltd.
> ======================================================================
>
>
------------------------------------------------------------------------

------------------
Ken Laskey
MITRE Corporation, M/S H305     phone:  703-883-7934
7515 Colshire Drive                        fax:        703-883-1379
McLean VA 22102-7508