runtime lifecycle implementation semantics

[Tony Dean <To...@sas.com>]

Hi ,

Could you please answer a few questions about lifecycle and runtime contexts?

You have addressed the issue of service lifecycle by providing init(ServiceContext) and destroy(ServiceContext) callbacks that are called during service initialization and service destruction, respectively.  Now as I understand it you also have a setOperationContext(OperationContext) callback that is called on every service invocation to provide an operation context.

>From the operation context, I can get the message context in one of two way it seems:

Map map = operationContext.getMessageContexts();

In this case, I'm not sure what to do with multiple message contexts.  Can you explain the need for a map?

MessageContext context = operationContext.getMessageContext(String);

In this case, I'm not sure what input String is designating.  Can you explain?

If there is documentation, please direct me to it.  I could not gather enough information from your javadoc.

The reason that I need the message context in the first place is so that I can create a detailed SOAP fault if an exception occurs:

    		messageContext.setProperty(SOAP12Constants.SOAP_FAULT_CODE_LOCAL_NAME, soapFaultCode);
    		messageContext.setProperty(SOAP12Constants.SOAP_FAULT_REASON_LOCAL_NAME, soapFaultReason);
    		messageContext.setProperty(SOAP12Constants.SOAP_FAULT_DETAIL_LOCAL_NAME, soapFaultDetail);

Maybe there is a better way to create custom, detailed faults now so that I do not need to set message context properties.  Please let me know that as well.

Thank you for your time!

-Tony

Tony Dean
SAS Institute Inc.
919.531.6704
tony.dean@sas.com

SAS... The Power to Know
http://www.sas.com

Re: runtime lifecycle implementation semantics

[Deepal Jayasinghe <de...@opensource.lk>]

Hi Tony
pls see my in line comments

Tony Dean wrote:

>Hi ,
>
>Could you please answer a few questions about lifecycle and runtime contexts?
>  
>
Life cycle of a service is determine by its scope , you can deploy a
service in one of the following scopes
   - request scope : life time of the service will be the life time of
request processing
   - transport scope : The life time of the service will be the life
time of the transport session and most of the time transport session is
manged by cookies
   - soap session scope : The scope maintained using service group id.
  - application scope : The life time of the service will be the life
time of the system

Here the service impl class will be stored in ServiceContext , so for
each scope you will be having service context and its life time vary
depending on the scope.
for example ,
  - if the service is deployed in application scope , then there will be
only one servicecontex for that service , o.w there can be multiple
service context for a given service on a given time.

>You have addressed the issue of service lifecycle by providing init(ServiceContext) and destroy(ServiceContext) callbacks that are called during service initialization and service destruction, respectively.  Now as I understand it you also have a setOperationContext(OperationContext) callback that is called on every service invocation to provide an operation context.
>
>>>From the operation context, I can get the message context in one of two way it seems:
>
>Map map = operationContext.getMessageContexts();
>
>In this case, I'm not sure what to do with multiple message contexts.  Can you explain the need for a map?
>  
>
Operation context is to represent a given MEP (Message Exchange
Patterns) , for a given MEP there can be multiple messages so there can
be multiple message contexts as well. That is why you can see a Map in
operation context. It should be note that each message in a given mep
has a unique name. 

>MessageContext context = operationContext.getMessageContext(String);
>
>In this case, I'm not sure what input String is designating.  Can you explain?
>  
>
The value of the string is the corresponding message label or the name
in a given mep. For an example if the MEP is in-out , then the value
could be "in"  or "out"

>If there is documentation, please direct me to it.  I could not gather enough information from your javadoc.
>  
>
I am very sorry for that :(

>The reason that I need the message context in the first place is so that I can create a detailed SOAP fault if an exception occurs:
>
>    		messageContext.setProperty(SOAP12Constants.SOAP_FAULT_CODE_LOCAL_NAME, soapFaultCode);
>    		messageContext.setProperty(SOAP12Constants.SOAP_FAULT_REASON_LOCAL_NAME, soapFaultReason);
>    		messageContext.setProperty(SOAP12Constants.SOAP_FAULT_DETAIL_LOCAL_NAME, soapFaultDetail);
>
>Maybe there is a better way to create custom, detailed faults now so that I do not need to set message context properties.  Please let me know that as well.
>  
>
I think Chinthaka can answer this better than me :)

>Thank you for your time!
>
>-Tony
>
>Tony Dean
>SAS Institute Inc.
>919.531.6704
>tony.dean@sas.com
>
>SAS... The Power to Know
>http://www.sas.com
>
>
>
>  
>

-- 
Thanks,
Deepal
................................................................
~Future is Open~