axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike_McAn...@wendys.com
Subject Re: runtime lifecycle implementation semantics
Date Tue, 16 May 2006 16:06:13 GMT
I would just like to say, this seems non-intuitive.

If I have a service tag with a name attribute, I expect the name specified 
in the tag to determine the name of my service, not the arbitrary name of 
my archive file (which may have versioning information attached to it).

Now, if the name attribute is optional then I could understand using the 
name of the archive file in the absence of the name attribute.

My expectation is that the purpose of the services.xml file is 
configuration of my services.  As such, I would expect any information in 
the services.xml to take precedence over arbitrary environment features 
like the name of my archive file.


Mike McAngus
Associate Chief Engineer, Enterprise Architecture
Wendy's International, Inc.
One Dave Thomas Boulevard
Dublin, OH 43017
614-764-6776




Deepal Jayasinghe 
05/16/2006 09:11 AM
Please respond to
axis-dev@ws.apache.org


To
axis-dev@ws.apache.org
cc

Subject
Re: runtime lifecycle implementation semantics






Hi Tony
pls see my comment blow;

Tony Dean wrote:

>Deepal,
>
>My wsdl contains:
>
><service name="WebServiceMaker">
>  ...
></service>
>
>My services.xml contains:
>
><service name="WebServiceMaker" scope="application">
>  ...
></service>
>
>Hence you should be able to associate the service name with the wsdl 
service.  That's what I thought you were doing in .9x.  It seems to have 
changed in 1.0.
> 
>
We have not changed that. What we have done is if the root element of
the  services.xml is <service> then we ignore the name attribute and set
the name as the archive name. If the root element is  <serviceGroup>
then the name of the service will be the name of the name attribute.
So change your services.xml to following format and then there wont be
any dependencies on archive file name
<serviceGroup> 
    <service name="WebServiceMaker" scope="application">
         ...

   </service>

<serviceGroup>

>Why are you dependent upon the name of the archive?  I changed the name 
of the archive (in my case the name of the exploded directory) to 
WebServiceMaker (it was SASWebServiceMaker) and it is working as I expect 
now.
>
>Thanks.
>
>-----Original Message-----
>From: Deepal Jayasinghe [mailto:deepal@opensource.lk] 
>Sent: Monday, May 15, 2006 1:02 PM
>To: Tony Dean
>Cc: axis-dev@ws.apache.org
>Subject: Re: runtime lifecycle implementation semantics
>
>btw what is the name of service archive file , service name always be the 
name of the archive file if the services.xml has only one service.
>So wsdl service name should be equal to the name of the service.
>  - if the service name is foo.aar  (services.xml exactly look like 
yours)
>  - then wsdl service element should look like
> 
> 
>
><service name="foo">
>      <port name="WebServiceMakerPort" 
binding="tns:WebServiceMakerBinding">
>         <soap:address location="$WEBSVC_URL$"/> </port>
>
> 
> 
>Tony Dean wrote:
>
> 
>
>>Also, do you know why 
>>http://localhost:8080/axis2/services/SASWebServiceMaker?wsdl is 
>>returning
>>
>>- <error>
>> <description>Unable to generate WSDL for this service</description>
>> <reason>Either user has not dropped the wsdl into META-INF or 
>>operations use message receivers other than RPC.</reason>
>> </error>
>>
>>I'm using RawXMLINOutMessageReceiver.
>>
>>meta-inf/services.xml
>>
>><service name="WebServiceMaker" scope="application">
>> <description>SAS BI Web Services (WebServiceMaker)</description>
>> <parameter locked="xsd:false" 
>>name="ServiceClass">com.sas.web.services.maker.axis2.WebServiceMakerPor
>>tTypeSkeleton</parameter>
>> <operation name="MakeWebService">
>>   <messageReceiver 
>>class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
>> </operation>
>> <operation name="ListWebServices">
>>   <messageReceiver 
>>class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
>> </operation>
>></service>
>>
>>meta-inf/service.wsdl
>>
>><?xml version="1.0" encoding="utf-8"?>
>><definitions name="WebServiceMaker"
>>            xmlns="http://schemas.xmlsoap.org/wsdl/"
>>            targetNamespace="
http://support.sas.com/xml/namespace/biwebservices/webservicemaker-9.2"
>>            xmlns:tns="
http://support.sas.com/xml/namespace/biwebservices/webservicemaker-9.2"
>>            xmlns:typesns="
http://support.sas.com/xml/namespace/biwebservices/webservicemaker-9.2"
>>            xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
>>
>>  <types>
>>     <schema xmlns="http://www.w3.org/2001/XMLSchema"
>>             targetNamespace="
http://support.sas.com/xml/namespace/biwebservices/webservicemaker-9.2"
>>             xmlns:tns="
http://support.sas.com/xml/namespace/biwebservices/webservicemaker-9.2"
>>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>             elementFormDefault="qualified">
>>
>>        <complexType name="StringArrayType">
>>           <sequence>
>>              <element name="string" type="string" minOccurs="0" 
maxOccurs="unbounded"/>
>>           </sequence>
>>        </complexType>
>>
>>        <element name="MakeWebService" type="tns:MakeWebServiceType"/>
>>        <complexType name="MakeWebServiceType">
>>           <sequence>
>>              <element name="omrURI" type="string"/>
>>              <element name="omrUserID" type="string"/>
>>              <element name="omrPassword" type="string"/>
>>              <element name="storedProcessPaths" 
type="tns:StringArrayType"/>
>>              <element name="serviceName" type="string"/>
>>           </sequence>
>>        </complexType>
>>
>>        <element name="MakeWebServiceResponse" 
type="tns:MakeWebServiceResponseType"/>
>>        <complexType name="MakeWebServiceResponseType">
>>           <sequence>
>>              <element name="MakeWebServiceResult" type="string"/>
>>           </sequence>
>>        </complexType>
>>
>>        <element name="ListWebServices" type="tns:ListWebServicesType"/>
>>        <complexType name="ListWebServicesType"/>
>>
>>        <element name="ListWebServicesResponse" 
type="tns:ListWebServicesResponseType"/>
>>        <complexType name="ListWebServicesResponseType">
>>           <sequence>
>>              <element name="ListWebServicesResult" 
type="tns:StringArrayType"/>
>>           </sequence>
>>        </complexType>
>>
>>        <element name="FaultException" type="tns:FaultException"/>
>>        <complexType name="FaultException">
>>           <sequence>
>>              <element name="ExceptionMessage" type="string" 
minOccurs="0" maxOccurs="unbounded"/>
>>           </sequence>
>>        </complexType>
>> 
>>     </schema>
>>  </types>
>>
>>  <message name="MakeWebServiceRequest">
>>     <part name="parameters" element="typesns:MakeWebService"/>
>>  </message>
>>  <message name="MakeWebServiceResponse">
>>     <part name="parameters" element="typesns:MakeWebServiceResponse"/>
>>  </message>
>>  <message name="ListWebServicesRequest">
>>     <part name="parameters" element="typesns:ListWebServices"/>
>>  </message>
>>  <message name="ListWebServicesResponse">
>>     <part name="parameters" element="typesns:ListWebServicesResponse"/>
>>  </message>
>>  <message name="FaultException">
>>     <part name="fault" element="typesns:FaultException"/>
>>  </message>
>>
>>  <portType name="WebServiceMakerPortType">
>>     <operation name="MakeWebService">
>>        <input message="tns:MakeWebServiceRequest"/>
>>        <output message="tns:MakeWebServiceResponse"/>
>>        <fault name="fault" message="tns:FaultException"/>
>>     </operation>
>>     <operation name="ListWebServices">
>>        <input message="tns:ListWebServicesRequest"/>
>>        <output message="tns:ListWebServicesResponse"/>
>>     </operation>
>>  </portType>
>>
>>  <binding name="WebServiceMakerBinding" 
type="tns:WebServiceMakerPortType">
>>     <soap:binding transport="http://schemas.xmlsoap.org/soap/http" 
style="document"/>
>>     <operation name="MakeWebService">
>>        <soap:operation soapAction=""/>
>>        <input>
>>           <soap:body use="literal"/>
>>        </input>
>>        <output>
>>           <soap:body use="literal"/>
>>        </output>
>>        <fault name="fault">
>>           <soap:fault name="fault" use="literal"/>
>>        </fault>
>>     </operation>
>>     <operation name="ListWebServices">
>>        <soap:operation soapAction=""/>
>>        <input>
>>           <soap:body use="literal"/>
>>        </input>
>>        <output>
>>           <soap:body use="literal"/>
>>        </output>
>>     </operation>
>>  </binding>
>>
>>  <service name="WebServiceMaker">
>>     <port name="WebServiceMakerPort" 
binding="tns:WebServiceMakerBinding">
>>        <soap:address location="$WEBSVC_URL$"/>
>>     </port>
>>  </service>
>></definitions>
>>
>>
>>
>>-----Original Message-----
>>From: Deepal Jayasinghe [mailto:deepal@opensource.lk]
>>Sent: Thursday, May 11, 2006 12:07 AM
>>To: Tony Dean
>>Subject: Re: runtime lifecycle implementation semantics
>>
>>Service scope will be equal to the scope of the service. The life time 
of the service is the life time of the service context.
>>
>>Tony Dean wrote:
>>
>> 
>>
>> 
>>
>>>Deepal,
>>>
>>>I forgot to ask.  How do you configure the service context scope?  I 
assume in service.xml.  Thanks.
>>>
>>>-----Original Message-----
>>>From: Deepal Jayasinghe [mailto:deepal@opensource.lk]
>>>Sent: Tuesday, May 09, 2006 11:45 AM
>>>To: axis-dev@ws.apache.org
>>>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_NAM
>>>>E, soapFaultCode);
>>>> 
>>>>messageContext.setProperty(SOAP12Constants.SOAP_FAULT_REASON_LOCAL_NA
>>>>ME, soapFaultReason);
>>>> 
>>>>messageContext.setProperty(SOAP12Constants.SOAP_FAULT_DETAIL_LOCAL_NA
>>>>M
>>>>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
>>>>tony.dean@sas.com
>>>>
>>>>SAS... The Power to Know
>>>>http://www.sas.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 
>>>>
>>>> 
>>>>
>>>> 
>>>>
>>>--
>>>Thanks,
>>>Deepal
>>>................................................................
>>>~Future is Open~
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 
>>>
>>> 
>>>
>>--
>>Thanks,
>>Deepal
>>................................................................
>>~Future is Open~
>>
>>
>>
>>
>> 
>>
>> 
>>
>
>--
>Thanks,
>Deepal
>................................................................
>~Future is Open~ 
>
>
>
>
>
> 
>

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




Mime
View raw message