[jira] [Created] (TUSCANY-3995) Adjust to JAXWS-2.2 specification of operation mapping to wsam:Action (e.g. adjust SOAPAction in SOAP Binding)

[Scott Kurz (Created) (JIRA)]

Adjust to JAXWS-2.2 specification of operation mapping to wsam:Action (e.g. 
adjust SOAPAction in SOAP Binding)
--

 Key: TUSCANY-3995
 URL: https://issues.apache.org/jira/browse/TUSCANY-3995
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-2.x
Reporter: Scott Kurz
Priority: Minor


JAX-WS 2.2 describes the default mapping of an operation to wsam:Action.   

In Tuscany we generate WSDL bindings with SOAPAction="urn:".

The WSA SOAP spec:
http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509/

says that wsam:Action and SOAPAction should match if they are each specified.   

So, 

1)  We should honor the @Action annotation and set this as the JavaOperation 
'action' in JAXWSJavaInterfaceProcessor (in case @WebMethod(action=) is not 
set, if both are set they must be equal).   Ideally we'd validate this.

2) If 'action' is still null after introspection the Java, we should probably 
generate this action per the JAX-WS 2.2 Sec 3.5.2 algorithm.

This would mean that our wsdlgen logic, which generates the SOAP Binding 
SOAPAction as "urn:"  would become irrelevant, since the action 
would always be set from Java.

This would seem to address
https://issues.apache.org/jira/browse/TUSCANY-3824
as well, at least in 2.x (though that one was targeted for 1.x).




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TUSCANY-3824) Incorrect WSDL generated for bare parameter style

[Scott Kurz (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-3824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165665#comment-13165665
 ] 

Scott Kurz commented on TUSCANY-3824:
-

See also, https://issues.apache.org/jira/browse/TUSCANY-3995  
not that I think it necessarily addresses every aspect of this JIRA

> Incorrect WSDL generated for bare parameter style
> -
>
> Key: TUSCANY-3824
> URL: https://issues.apache.org/jira/browse/TUSCANY-3824
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Axis Binding Extension
>Affects Versions: Java-SCA-1.6.1
>Reporter: Simon Nash
>Assignee: Simon Nash
> Fix For: Java-SCA-1.x
>
>
> For a method with 
> @SOAPBinding(parameterStyle=SOAPBinding.ParameterStyle.BARE), the JAX-WS RI 
> generates WSDL with a global element name and message part name that are the 
> same as the operation name. Tuscany generates WSDL with a global element name 
> and message part name of arg0, and it adds soapAction to provide the 
> operation name.
> The JAX-WS specification says that the global element name and message part 
> name must be the same as the operation name, so Tuscany is generating WSDL 
> for bare operations that doesn't conform to the JAX-WS rules. The JAX-WS 
> specification also says that soapAction should be null unless 
> @WebMethod(action=) is specified. The Tuscany WSDL generator should use 
> the correct JAX-WS mapping for the global element name and message part name, 
> and should remove the nonstandard addition of soapAction.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (TUSCANY-3994) Should new wsa:MessageID be constructed on binding.ws reference callback invocation?

[Scott Kurz (Created) (JIRA)]

Should new wsa:MessageID be constructed on binding.ws reference callback 
invocation?


 Key: TUSCANY-3994
 URL: https://issues.apache.org/jira/browse/TUSCANY-3994
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-2.x
Reporter: Scott Kurz
Priority: Minor


I noticed in Axis2ReferenceBindingInvoker.createOperationClient(Message msg)  
we do:

if (callbackEndpoint != null) {
  
  addWSAMessageIDHeader( sh, 
(String)msg.getHeaders().get("MESSAGE_ID"));


It seems there are two problems with this:

1)  We aren't always going to have a MESSAGE_ID header in the Tuscany message.  
 This is a problem if, say, Axis2's addressing module is enabled, in which case 
the appearance of any WSA headers is going to imply that wsa:MessageID must 
appear (except for in-only operations).

2) If the MESSAGE_ID is set, should we be propagating it?   Sure there could be 
some value in a propagated ID, but is this what is done with wsa:MessageID?   

Not fully grasping all the details of our async invocation support, I'm viewing 
the message id as the id for this message, which may be set in the service 
binding when an incoming request and seemingly then copied on through to the 
reference binding invocation.So it's a correlation id of sorts within this 
JVM for a bigger scope than just one binding->impl dispatch  but I don't 
think it should have a larger lifetime extending to other requests downstream.

Does that make sense?  Is there a better approach?

Such a code patch would be easy.. I just wanted to write this up to see if it 
makes sense.

Thanks,

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Fwd: Dynamic service references (summary)

[Simon Laws]

On Thu, Dec 8, 2011 at 4:22 PM, ant elder  wrote:
> On Thu, Dec 8, 2011 at 10:57 AM, Simon Nash  wrote:
>> ant elder wrote:
>>>
>>> This is good and i will have a go in 2.x to see if a similar approach
>>> works there. But i can't help thinking its a slightly convoluted
>>> approach and as we have more flexibility in 2.x to add more APIs I
>>> wonder if we should just add a more direct API method to set the URIs
>>> with extra methods on Node, or also perhaps something like being able
>>> to do: ((TuscanyServiceReference)serviceReference).setURI(uri)?
>>>
>> +1 for providing a more convenient solution in 2.x.
>>
>> A setURI() method would only work for certain binding types.  Perhaps
>> this could be generalized to use some kind of notion of endpoint.
>>
>> There's also the mysterious wiredByImpl notion from the SCA spec.
>> It might be good to use that as the base concept for this capability.
>>
>
> Ok i had a quick stab at this in r1211944 and 1211945 which enables
> setting the binding URI of a ServiceReference by casting it to
> org.apache.tuscany.sca.core.context.impl.ServiceReferenceImpl and
> calling setBindingURI. Eg
>
>        ServiceReference sr =
> componentContext.getServiceReference(Helloworld.class,
> "helloworldService");
>        
> ((ServiceReferenceImpl)sr).setBindingURI("http://localhost:8080/HelloworldService/Helloworld";);
>        return "client: " + sr.getService().sayHello(name);
>
> Obviously its not ideal to be casting to a that impl class and it
> should rather have an API/SPI interface to cast to. I haven't done a
> whole lot of testing but that that seems to work ok, can anyone see
> any obvious issues?
>
>   ...ant

Ant

I like the idea of being able to prod things into the service
reference. I have two immediate thoughts that are not well formed

- Could we remove the cast by providing a Tuscany specific
ComponentContext for wireByImp impls. We already have the Tuscany
RuntimeComponentContext.
- Are there binding specific things we will want to do. Nothing comes
to mind just yet although policy configuration might be a possibility.

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: Fwd: Dynamic service references (summary)

[ant elder]

On Thu, Dec 8, 2011 at 10:57 AM, Simon Nash  wrote:
> ant elder wrote:
>>
>> This is good and i will have a go in 2.x to see if a similar approach
>> works there. But i can't help thinking its a slightly convoluted
>> approach and as we have more flexibility in 2.x to add more APIs I
>> wonder if we should just add a more direct API method to set the URIs
>> with extra methods on Node, or also perhaps something like being able
>> to do: ((TuscanyServiceReference)serviceReference).setURI(uri)?
>>
> +1 for providing a more convenient solution in 2.x.
>
> A setURI() method would only work for certain binding types.  Perhaps
> this could be generalized to use some kind of notion of endpoint.
>
> There's also the mysterious wiredByImpl notion from the SCA spec.
> It might be good to use that as the base concept for this capability.
>

Ok i had a quick stab at this in r1211944 and 1211945 which enables
setting the binding URI of a ServiceReference by casting it to
org.apache.tuscany.sca.core.context.impl.ServiceReferenceImpl and
calling setBindingURI. Eg

ServiceReference sr =
componentContext.getServiceReference(Helloworld.class,
"helloworldService");

((ServiceReferenceImpl)sr).setBindingURI("http://localhost:8080/HelloworldService/Helloworld";);
return "client: " + sr.getService().sayHello(name);

Obviously its not ideal to be casting to a that impl class and it
should rather have an API/SPI interface to cast to. I haven't done a
whole lot of testing but that that seems to work ok, can anyone see
any obvious issues?

   ...ant

Re: Runtime properties reference?

[Simon Laws]

On Thu, Dec 8, 2011 at 2:33 PM, ant elder  wrote:
> On Thu, Dec 8, 2011 at 2:22 PM, Simon Laws  wrote:
>> I note that the TuscanyRuntime class allows properties to be passed in
>> to the constructor. Is there a reference/help somewhere that lists
>> what properties are supported?
>>
>
> The interface org.apache.tuscany.sca.runtime.RuntimeProperties has
> constants for some of the ones that are supported.
>
>   ...ant

Ah, excellent thanks.

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: Runtime properties reference?

[ant elder]

On Thu, Dec 8, 2011 at 2:22 PM, Simon Laws  wrote:
> I note that the TuscanyRuntime class allows properties to be passed in
> to the constructor. Is there a reference/help somewhere that lists
> what properties are supported?
>

The interface org.apache.tuscany.sca.runtime.RuntimeProperties has
constants for some of the ones that are supported.

   ...ant

Runtime properties reference?

[Simon Laws]

I note that the TuscanyRuntime class allows properties to be passed in
to the constructor. Is there a reference/help somewhere that lists
what properties are supported?

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: Happy Birthday Tuscany

[Simon Nash]

Thanks for the reminder of this happy event :-)  I wonder how project age
years translate to human age years?  It feels like we're out of childhood
and probably past the teenage years, but not yet a fully mature adult.
Thoughts?

  Simon

Florian Moga wrote:

Cool anniversary! Nice to know about it :)

On Thu, Dec 8, 2011 at 6:16 AM, Nirmal Fernando > wrote:


Happy Birthday Tuscany!! :)


On Thu, Dec 8, 2011 at 5:06 AM, Raymond Feng mailto:enjoyj...@gmail.com>> wrote:

Wow, six years!

Raymond Feng
Sent from my iPhone

On Dec 7, 2011, at 2:30 PM, ant elder mailto:ant.el...@gmail.com>> wrote:

 > Its six years today since Tuscany started as an incubator
project at
 > the ASF [1].
 >
 >   ...ant
 >
 > [1] http://apache.markmail.org/message/sc4h3eyfo46tlbfp




-- 
Best Regards,

Nirmal

C.S.Nirmal J. Fernando
Department of Computer Science & Engineering,
Faculty of Engineering,
University of Moratuwa,
Sri Lanka.

Blog: http://nirmalfdo.blogspot.com/

Re: Fwd: Dynamic service references (summary)

[Simon Nash]

ant elder wrote:

This is good and i will have a go in 2.x to see if a similar approach
works there. But i can't help thinking its a slightly convoluted
approach and as we have more flexibility in 2.x to add more APIs I
wonder if we should just add a more direct API method to set the URIs
with extra methods on Node, or also perhaps something like being able
to do: ((TuscanyServiceReference)serviceReference).setURI(uri)?


+1 for providing a more convenient solution in 2.x.

A setURI() method would only work for certain binding types.  Perhaps
this could be generalized to use some kind of notion of endpoint.

There's also the mysterious wiredByImpl notion from the SCA spec.
It might be good to use that as the base concept for this capability.

  Simon


   ...ant

-- Forwarded message --
From: Simon Nash 
Date: Wed, Dec 7, 2011 at 1:04 PM
Subject: Re: Dynamic service references (summary)
To: u...@tuscany.apache.org


Millies, Sebastian wrote:

Thank you very much for all your help, Simon.


You're very welcome.  I'm glad this is working for you now.



I summarize here the result of this discussion for everyone's benefit:

For dynamic web service endpoints, get a wsdl for the web service and define
a service reference with interface.wsdl using wsdl.binding and a dummy
URI in the binding.ws element.


One small point--it doesn't need to be interface.wsdl.  It should also work
if you use interface.java.

 Simon




 
   


At run time get the service reference, serialize it to XML, replace the
dummy URI with the real endpoint URI, deserialize the reference and call the
service method. The serialization coding goes like this:

 public String serializeServiceReferenceXML( ServiceReference sr )
   throws IOException
 {
   ServiceReferenceImpl sri = (ServiceReferenceImpl) sr;
   return sri.toXMLString();
 }

 public ServiceReference deserializeServiceReferenceXML( String serializedSR 
)
   throws Exception
 {
   StringReader reader = new StringReader( serializedSR );
   XMLStreamReader xmlReader = 
XMLInputFactory.newInstance().createXMLStreamReader( reader );
   ServiceReferenceImpl sri = new ServiceReferenceImpl( xmlReader );
   return sri;
 }

The deserialized reference will work also when using policy sets (I have tested
that with basic authentication).

For background on the changes that have been made to the 1.x  trunk to make
this possible, refer to TUSCANY-3984.

-- Sebastian

IDS Scheer Consulting GmbH
Geschäftsführer/Managing Directors: Kamyar Niroumand, Ivo Totev
Sitz/Registered office: Altenkesseler Straße 17, 66115 Saarbrücken, Germany - 
Registergericht/Commercial register: Saarbrücken HRB 19681
http://www.softwareag.com

Re: Happy Birthday Tuscany

[Simon Laws]

On Thu, Dec 8, 2011 at 7:24 AM, Florian Moga  wrote:
> Cool anniversary! Nice to know about it :)
>
> On Thu, Dec 8, 2011 at 6:16 AM, Nirmal Fernando 
> wrote:
>>
>> Happy Birthday Tuscany!! :)
>>
>>
>> On Thu, Dec 8, 2011 at 5:06 AM, Raymond Feng  wrote:
>>>
>>> Wow, six years!
>>>
>>> Raymond Feng
>>> Sent from my iPhone
>>>
>>> On Dec 7, 2011, at 2:30 PM, ant elder  wrote:
>>>
>>> > Its six years today since Tuscany started as an incubator project at
>>> > the ASF [1].
>>> >
>>> >   ...ant
>>> >
>>> > [1] http://apache.markmail.org/message/sc4h3eyfo46tlbfp
>>
>>
>>
>>
>> --
>> Best Regards,
>> Nirmal
>>
>> C.S.Nirmal J. Fernando
>> Department of Computer Science & Engineering,
>> Faculty of Engineering,
>> University of Moratuwa,
>> Sri Lanka.
>>
>> Blog: http://nirmalfdo.blogspot.com/
>>
>

Gone in a flash!

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com