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 >[EMAIL PROTECTED] > >SAS... The Power to Know >http://www.sas.com > > > > > -- Thanks, Deepal ................................................................ ~Future is Open~
