thanks Deepal! 

-----Original Message-----
From: Deepal Jayasinghe [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, May 09, 2006 11:45 AM
To: [email protected]
Subject: Re: runtime lifecycle implementation semantics

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_NAM
> E, 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
>[EMAIL PROTECTED]
>
>SAS... The Power to Know
>http://www.sas.com
>
>
>
>  
>

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



Reply via email to