You are viewing a plain text version of this content. The canonical link for it is here.
Posted to muse-user@ws.apache.org by "Vinh Nguyen (vinguye2)" <vi...@cisco.com> on 2007/02/06 20:19:35 UTC
ssl support
Does Muse have support for SSL? At the least, it would be nice to have
an easy way to update the URI in an EPR to have the prefix "https"
instead of "http". I'm not sure if it's easier for me to create the
util, or to have it in Muse. I would assume the rest of the work isn't
in Muse's domain? We have two scenarios:
1) SSL is used directly between the client and the server hosting the
Muse app. So the client must connect using "https", and the app must
return an EPR containing "https".
2) SSL is used between the client and the webserver, but is not used
between the webserver and the app server hosting the Muse app. So the
app will never return "https", but the webserver has the responsibility
for converting to "https" to the client, and to back to "http" from the
client.
Re: Handling Faults in Muse (client/server).
Posted by Daniel Jemiolo <da...@us.ibm.com>.
I believe that, at the very least, the server-side exceptions should be
SoapFault or BaseFault, depending on whether WSRF is used in the WSDL. It
would also be nice to have wsdl2java generate the fault classes for custom
fault types, since all that is involved is sub-classing
[SoapFault|BaseFault] and adding the constructors of the base class. Can
you open a JIRA item for this? It will be low priority for 2.2, probably
going into 2.3, because Andrew already has a full plate on wsdl2java
stuff.
In the meantime, adding your custom faults can be done manually by
subclassing the BaseFault class - all you have to do is add the
constructor(s) and you're ready to go.
On the client side, I believe the faults should remain as SoapFaults since
the methods may throw networking/WS-A faults as well as your custom
faults.
Dan
"Baseer Khan \(bakhan\)" <ba...@cisco.com> wrote on 02/08/2007 02:15:38
AM:
> I have a general question on How are faults handled in Muse Client and
> Server.
>
> For a given operation X defined as some porttype in a wsdl that throws
> faults F1 and F2 I see the following happening when wsdl2java is run -
>
> On Server Side:
> 1) All operations defined as some capability are shown as throwing
> generic Exception.
>
> On Client Side:
> 1) All operations defined as part of Proxy are shown as throwing
> SoapFault.
>
> In either of these cases I do not see code for Faults F1 and F2 added by
> wsdl2java.
>
> Questions -
>
> How should faults be handled on server and client in view of
> WS-BaseFaults Specification? General outline or guidelines would be much
> appreciated.
>
>
> Thanks.
>
> --Baseer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
Handling Faults in Muse (client/server).
Posted by "Baseer Khan (bakhan)" <ba...@cisco.com>.
I have a general question on How are faults handled in Muse Client and
Server.
For a given operation X defined as some porttype in a wsdl that throws
faults F1 and F2 I see the following happening when wsdl2java is run -
On Server Side:
1) All operations defined as some capability are shown as throwing
generic Exception.
On Client Side:
1) All operations defined as part of Proxy are shown as throwing
SoapFault.
In either of these cases I do not see code for Faults F1 and F2 added by
wsdl2java.
Questions -
How should faults be handled on server and client in view of
WS-BaseFaults Specification? General outline or guidelines would be much
appreciated.
Thanks.
--Baseer
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
Re: ssl support
Posted by Daniel Jemiolo <da...@us.ibm.com>.
I met with the Cisco developers that frequent this list today, and one of
the things we discussed was HTTP vs HTTPS. I'm sharing these thoughts here
for the benefit of other users:
The team determined that having http:// in the EPR address should not be a
problem for secure messages because the WS-A headers are part of the SOAP
envelope and not used by the HTTP/SOAP server for routing. Tomcat will
route an https:// request to the right application, it will go through
Axis2, and then Muse, where the WS-A headers (with a http:// address) will
be processed. This is valid because WS-A headers are really about
identifying the resource and not the type of transport used to talk to it.
The team will report back if they have any problems getting Axis2 to
accept requests with HTTPS transport but HTTP URIs in the WS-A Address
(since Axis2 analyzes the WS-A headers during request processing).
Dan
"Vinh Nguyen \(vinguye2\)" <vi...@cisco.com> wrote on 02/06/2007
02:19:35 PM:
> Does Muse have support for SSL? At the least, it would be nice to have
> an easy way to update the URI in an EPR to have the prefix "https"
> instead of "http". I'm not sure if it's easier for me to create the
> util, or to have it in Muse. I would assume the rest of the work isn't
> in Muse's domain? We have two scenarios:
>
> 1) SSL is used directly between the client and the server hosting the
> Muse app. So the client must connect using "https", and the app must
> return an EPR containing "https".
> 2) SSL is used between the client and the webserver, but is not used
> between the webserver and the app server hosting the Muse app. So the
> app will never return "https", but the webserver has the responsibility
> for converting to "https" to the client, and to back to "http" from the
> client.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org