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
|
|
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:[EMAIL PROTECTED]
>Sent: Monday, May 15, 2006 1:02 PM
>To: Tony Dean
>Cc: [email protected]
>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:[EMAIL PROTECTED]
>>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:[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_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
>>>>[EMAIL PROTECTED]
>>>>
>>>>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~
