You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by davout <da...@dsl.pipex.com> on 2002/09/09 11:56:13 UTC
Access to soap message header?
Can a Java class representing an Axis web service method get access to the
header section of the originating soap message?
If so how?
Re: Can Message based Client call pass InputSource/InputStream
as an argument?
Posted by Jinghua Gu <eg...@cisco.com>.
Ok, I see. Thanks a lot!
Emily
At 10:46 AM 9/9/2002 -0700, Vadim Draluk wrote:
>Yes,
>
>you can use InputStream as parameter in
>SOAPBodyElement constructor, and then pass the latter
>as parameter in service invocation.
>
>Cheers
>
>Vadim
>
>--- Jinghua Gu <eg...@cisco.com> wrote:
> > Hi All,
> >
> > I have been see some message based examples where
> > they pass Elements as
> > client
> > call argument. Can I use InputSource/InputStream as
> > an argument for message
> > based applications.
> >
> > Thanks,
> > Emily
> >
Re: Can Message based Client call pass InputSource/InputStream as an argument?
Posted by Vadim Draluk <va...@draluk.net>.
Yes,
you can use InputStream as parameter in
SOAPBodyElement constructor, and then pass the latter
as parameter in service invocation.
Cheers
Vadim
--- Jinghua Gu <eg...@cisco.com> wrote:
> Hi All,
>
> I have been see some message based examples where
> they pass Elements as
> client
> call argument. Can I use InputSource/InputStream as
> an argument for message
> based applications.
>
> Thanks,
> Emily
>
Can Message based Client call pass InputSource/InputStream as
an argument?
Posted by Jinghua Gu <eg...@cisco.com>.
Hi All,
I have been see some message based examples where they pass Elements as
client
call argument. Can I use InputSource/InputStream as an argument for message
based applications.
Thanks,
Emily
RE: Access to soap message header?
Posted by Ricky Ho <ri...@cisco.com>.
The spec of WS-TX and WS-C hasn't fully flushed out how the programming
model should look like. So the following I describe is one possible approach.
There are also two types of transactions in WS-Tx, atomic transaction and
business activity, which has quite different behavior (but l'm not going
there).
>> Of course, the above bookticket(...) method won't be able to access the
>SOAP header
>information. But the handler code itself can certainly access the whole
>SOAP message including all the WS-Transaction header information.
><<
>
>I understand that - but how do you link up the handler that processes the
>header to the java class method (i.e. 'bookticket') that handles the ticket
>booking??
The linkage is because they are being executed within the same Java
thread. So the handler can put the transaction context into a ThreadLocal
object which can be picked up by the "bookticket" method.
>I understand your approach, but how is my sample airline ticket call
>supposed to know when its operating as a self-standing web service as
>opposed to being part of a wider transaction?
The objective of the design is so that your application code doesn't need
to be aware of all these pluming issue. In reality, your code may need to
mandate that it must be running inside a transaction. And I have some
debate in the WSDL forum about whether WSDL binding should capture
something like the "requireTransaction" attribute in the EJB
descriptor. But this is an area unbaked yet. Of course, it you really
need to know, you can use the approach I describe above using a ThreadLocal
object to share information.
Best regards,
Ricky
RE: Access to soap message header?
Posted by davout <da...@dsl.pipex.com>.
>>
I'm not sure which "Java method" are you talking about.
<<
my sample 'bookticket' method...
>> Of course, the above bookticket(...) method won't be able to access the
SOAP header
information. But the handler code itself can certainly access the whole
SOAP message including all the WS-Transaction header information.
<<
I understand that - but how do you link up the handler that processes the
header to the java class method (i.e. 'bookticket') that handles the ticket
booking??
I understand your approach, but how is my sample airline ticket call
supposed to know when its operating as a self-standing web service as
opposed to being part of a wider transaction?
RE: Access to soap message header?
Posted by Ricky Ho <ri...@cisco.com>.
At 08:41 PM 9/9/2002 +0100, davout wrote:
> >>
>I don't see this as a design flaw. And I don't see why is there a need
>(for WS-Coordination and WS-Transaction) to access the original header
>information from the original sender ? (the "co-ordination context"
>information embedded by WS-Transaction into the SOAP header is purely
>read-only and won't be modified along the handler).
><<
>
>Because they put co-ordination reference points, co-ordination server
>addresses and transaction ID's in the header area !
This is done before the SOAP message leaves the "sender" node (if the
client is also using AXIS, it can be done in one of the outbound request
handlers). When the SOAP request reaches the AxisServlet of the receiver
node, none of these headers need to be modified.
>One of the IBM concept papers uses the example of a travel company
>co-ordinating three bookings using this facility through three separate
>calls to different travel provider web services: like an airline ticket
>booking system, a hotel reservation system and a care rental booking system.
>
>If any of these single target services cannot confirm the requested
>reservation then all three are rolled back.
>
>You can imagine an airline booking web service with a method like....
>
> int bookticket(int agent, String PassengerName, String
> fromAirPort, String
>toAirport)
>
>With the WS-Transaction/Coordination data in the soap message header,
>somehow this web service now has to determine that its part of a
>distributed. Unless the Java method can gain access to this header data I
>don't see how it can work??
I'm not sure which "Java method" are you talking about. Of course, the
above bookticket(...) method won't be able to access the SOAP header
information. But the handler code itself can certainly access the whole
SOAP message including all the WS-Transaction header information. A
straightforward implementation is to have a handler that intercepts the
SOAP message before calling the bookticket() method. What this handler
does is to extract the registration service endpoint from the
WS-Transaction SOAP header and then make a call to it to enroll this
receiver node as a participant to the transaction.
Best regards,
Ricky
RE: Access to soap message header?
Posted by Ricky Ho <ri...@cisco.com>.
Totally !!
At 03:50 PM 9/9/2002 -0500, you wrote:
>I think perhaps we're all talking about different things. There are two
>discrete contexts at work here. The first context is the overall
>request-response architecture of a single SOAP request being posted to an
>Axis server by a client. The request is what is posted by the client, the
>response is what the client receives.
>
>Within that overall request, there are a number of smaller contexts. Each
>handler has access to a request and response object as well. The handler can
>modify the request it receives and the next message processor in the
>chain -- be it another handler or the web service being invoked -- receives
>the output response as its request. In this way, a (conceptual) flow is set
>up like:
>
>
> Client -> SOAP Request -> AxisServlet -> Handler A -> Handler B
> -> Web
>Service
>
>As far as the Client is concerned, it submits a single request and receives
>a single response. It doesn't care how many steps happened along the way, or
>if the request was modified before it got to the Web Services. As long as
>the general contract outlined by the WSDL is adhered to, the Client is
>happy.
>
>The Handlers and the Web Service, however, have access to and can modify the
>request (and response) as they see fit. They have the ability to read and
>re-write anything they touch.
>
>Now, the point you bring up about coordination and reference points existing
>in the header is valid. But it's fully supported by Axis as each step in the
>workflow outlined above has access to the header information. But you can
>imagine a scenario whereby the first handler in the chain validates that the
>incoming SOAP request is part of a transaction and removes the transaction
>ID from the header and places other relevant information in the SOAP body.
>The second handler in the chain is unaware (and doesn't care) that this
>change happened. Although the second handler doesn't have access to the
>*original* request that was submitted by the client, it doesn't matter
>anymore because the information the header contained was only valuable to
>the first handler in the chain.
>
>In other words, if it makes sense to the business process to modify the
>header, then it's up to the person implementing this process to do so. If it
>makes sense to just leave it alone, it again is the architect's decision.
>But the decision should have no bearing on the design of Axis as an enabling
>product.
>
>Regards,
> Rob
>
>
>
>
>-----Original Message-----
>From: davout [mailto:davout@dsl.pipex.com]
>Sent: Monday, September 09, 2002 2:41 PM
>To: axis-user@xml.apache.org
>Subject: RE: Access to soap message header?
>
>
> >>
>I don't see this as a design flaw. And I don't see why is there a need
>(for WS-Coordination and WS-Transaction) to access the original header
>information from the original sender ? (the "co-ordination context"
>information embedded by WS-Transaction into the SOAP header is purely
>read-only and won't be modified along the handler).
><<
>
>Because they put co-ordination reference points, co-ordination server
>addresses and transaction ID's in the header area!
>
>One of the IBM concept papers uses the example of a travel company
>co-ordinating three bookings using this facility through three separate
>calls to different travel provider web services: like an airline ticket
>booking system, a hotel reservation system and a care rental booking system.
>
>If any of these single target services cannot confirm the requested
>reservation then all three are rolled back.
>
>You can imagine an airline booking web service with a method like....
>
> int bookticket(int agent, String PassengerName, String
> fromAirPort, String
>toAirport)
>
>With the WS-Transaction/Coordination data in the soap message header,
>somehow this web service now has to determine that its part of a
>distributed. Unless the Java method can gain access to this header data I
>don't see how it can work??
RE: Access to soap message header?
Posted by davout <da...@dsl.pipex.com>.
I understand your approach, but how is my sample airline ticket call
supposed to know when its operating as a self-standing web service as
opposed to being part of a wider transaction?
-----Original Message-----
From: Allegar Robert [mailto:allegar_robert@bah.com]
Sent: 09 September 2002 21:50
To: axis-user@xml.apache.org
Subject: RE: Access to soap message header?
I think perhaps we're all talking about different things. There are two
discrete contexts at work here. The first context is the overall
request-response architecture of a single SOAP request being posted to an
Axis server by a client. The request is what is posted by the client, the
response is what the client receives.
Within that overall request, there are a number of smaller contexts. Each
handler has access to a request and response object as well. The handler can
modify the request it receives and the next message processor in the
chain -- be it another handler or the web service being invoked -- receives
the output response as its request. In this way, a (conceptual) flow is set
up like:
Client -> SOAP Request -> AxisServlet -> Handler A -> Handler B -> Web
Service
As far as the Client is concerned, it submits a single request and receives
a single response. It doesn't care how many steps happened along the way, or
if the request was modified before it got to the Web Services. As long as
the general contract outlined by the WSDL is adhered to, the Client is
happy.
The Handlers and the Web Service, however, have access to and can modify the
request (and response) as they see fit. They have the ability to read and
re-write anything they touch.
Now, the point you bring up about coordination and reference points existing
in the header is valid. But it's fully supported by Axis as each step in the
workflow outlined above has access to the header information. But you can
imagine a scenario whereby the first handler in the chain validates that the
incoming SOAP request is part of a transaction and removes the transaction
ID from the header and places other relevant information in the SOAP body.
The second handler in the chain is unaware (and doesn't care) that this
change happened. Although the second handler doesn't have access to the
*original* request that was submitted by the client, it doesn't matter
anymore because the information the header contained was only valuable to
the first handler in the chain.
In other words, if it makes sense to the business process to modify the
header, then it's up to the person implementing this process to do so. If it
makes sense to just leave it alone, it again is the architect's decision.
But the decision should have no bearing on the design of Axis as an enabling
product.
Regards,
Rob
-----Original Message-----
From: davout [mailto:davout@dsl.pipex.com]
Sent: Monday, September 09, 2002 2:41 PM
To: axis-user@xml.apache.org
Subject: RE: Access to soap message header?
>>
I don't see this as a design flaw. And I don't see why is there a need
(for WS-Coordination and WS-Transaction) to access the original header
information from the original sender ? (the "co-ordination context"
information embedded by WS-Transaction into the SOAP header is purely
read-only and won't be modified along the handler).
<<
Because they put co-ordination reference points, co-ordination server
addresses and transaction ID's in the header area!
One of the IBM concept papers uses the example of a travel company
co-ordinating three bookings using this facility through three separate
calls to different travel provider web services: like an airline ticket
booking system, a hotel reservation system and a care rental booking system.
If any of these single target services cannot confirm the requested
reservation then all three are rolled back.
You can imagine an airline booking web service with a method like....
int bookticket(int agent, String PassengerName, String fromAirPort, String
toAirport)
With the WS-Transaction/Coordination data in the soap message header,
somehow this web service now has to determine that its part of a
distributed. Unless the Java method can gain access to this header data I
don't see how it can work??
RE: Access to soap message header?
Posted by Allegar Robert <al...@bah.com>.
I think perhaps we're all talking about different things. There are two
discrete contexts at work here. The first context is the overall
request-response architecture of a single SOAP request being posted to an
Axis server by a client. The request is what is posted by the client, the
response is what the client receives.
Within that overall request, there are a number of smaller contexts. Each
handler has access to a request and response object as well. The handler can
modify the request it receives and the next message processor in the
chain -- be it another handler or the web service being invoked -- receives
the output response as its request. In this way, a (conceptual) flow is set
up like:
Client -> SOAP Request -> AxisServlet -> Handler A -> Handler B -> Web
Service
As far as the Client is concerned, it submits a single request and receives
a single response. It doesn't care how many steps happened along the way, or
if the request was modified before it got to the Web Services. As long as
the general contract outlined by the WSDL is adhered to, the Client is
happy.
The Handlers and the Web Service, however, have access to and can modify the
request (and response) as they see fit. They have the ability to read and
re-write anything they touch.
Now, the point you bring up about coordination and reference points existing
in the header is valid. But it's fully supported by Axis as each step in the
workflow outlined above has access to the header information. But you can
imagine a scenario whereby the first handler in the chain validates that the
incoming SOAP request is part of a transaction and removes the transaction
ID from the header and places other relevant information in the SOAP body.
The second handler in the chain is unaware (and doesn't care) that this
change happened. Although the second handler doesn't have access to the
*original* request that was submitted by the client, it doesn't matter
anymore because the information the header contained was only valuable to
the first handler in the chain.
In other words, if it makes sense to the business process to modify the
header, then it's up to the person implementing this process to do so. If it
makes sense to just leave it alone, it again is the architect's decision.
But the decision should have no bearing on the design of Axis as an enabling
product.
Regards,
Rob
-----Original Message-----
From: davout [mailto:davout@dsl.pipex.com]
Sent: Monday, September 09, 2002 2:41 PM
To: axis-user@xml.apache.org
Subject: RE: Access to soap message header?
>>
I don't see this as a design flaw. And I don't see why is there a need
(for WS-Coordination and WS-Transaction) to access the original header
information from the original sender ? (the "co-ordination context"
information embedded by WS-Transaction into the SOAP header is purely
read-only and won't be modified along the handler).
<<
Because they put co-ordination reference points, co-ordination server
addresses and transaction ID's in the header area!
One of the IBM concept papers uses the example of a travel company
co-ordinating three bookings using this facility through three separate
calls to different travel provider web services: like an airline ticket
booking system, a hotel reservation system and a care rental booking system.
If any of these single target services cannot confirm the requested
reservation then all three are rolled back.
You can imagine an airline booking web service with a method like....
int bookticket(int agent, String PassengerName, String fromAirPort, String
toAirport)
With the WS-Transaction/Coordination data in the soap message header,
somehow this web service now has to determine that its part of a
distributed. Unless the Java method can gain access to this header data I
don't see how it can work??
RE: Access to soap message header?
Posted by davout <da...@dsl.pipex.com>.
>>
I don't see this as a design flaw. And I don't see why is there a need
(for WS-Coordination and WS-Transaction) to access the original header
information from the original sender ? (the "co-ordination context"
information embedded by WS-Transaction into the SOAP header is purely
read-only and won't be modified along the handler).
<<
Because they put co-ordination reference points, co-ordination server
addresses and transaction ID's in the header area!
One of the IBM concept papers uses the example of a travel company
co-ordinating three bookings using this facility through three separate
calls to different travel provider web services: like an airline ticket
booking system, a hotel reservation system and a care rental booking system.
If any of these single target services cannot confirm the requested
reservation then all three are rolled back.
You can imagine an airline booking web service with a method like....
int bookticket(int agent, String PassengerName, String fromAirPort, String
toAirport)
With the WS-Transaction/Coordination data in the soap message header,
somehow this web service now has to determine that its part of a
distributed. Unless the Java method can gain access to this header data I
don't see how it can work??
RE: Access to soap message header?
Posted by Ricky Ho <ri...@cisco.com>.
I don't see this as a design flaw. And I don't see why is there a need
(for WS-Coordination and WS-Transaction) to access the original header
information from the original sender ? (the "co-ordination context"
information embedded by WS-Transaction into the SOAP header is purely
read-only and won't be modified along the handler).
Back to the generic situation, each AXIS handler is working in
"co-opertaive mode" to offload the certain processing of the endpoint (in
other words, each handler is part of the endpoint). In this "co-operative
mode", if there is a need to let the downstream handler knows about the
original state of the message, the handlers just need to share such
information among themselves in whatever way they want. I don't think the
AXIS engine need to provide a standard mechanism to achieve this type of
information sharing.
In fact, the message received from the AxisServlet may not be the original
message from the original sender. Think of a more general case where a
message leaves the sender travel across multiple intermediary nodes before
reaching the endpoint. It is possible for the message to be modified at
any of these intermediary nodes. Things get more complicated because these
intermediary nodes maybe working in a "competitive mode".
How to enforce a non-repudiated route and prevent the intermediary from
modifying information not targeted to them can be achieve via some
cryptographic technique. But currently there is no industry standard
around that. Although the web service architecture group in W3C did
mention about that.
Sorry for branching out too far ..
Rgds, Ricky
At 06:21 PM 9/9/2002 +0100, davout wrote:
>Isn't this a design flaw?
>
>If you look at all the web service standards coming out on things like
>'WS-Coordination' and 'WS-Transactions' they all based upon putting extra
>data into the soap message header area.
>
>How on earth is the Java web service class supposed to get access to this
>headre area info???
>
>
>-----Original Message-----
>From: Allegar Robert [mailto:allegar_robert@bah.com]
>Sent: 09 September 2002 18:53
>To: axis-user@xml.apache.org
>Subject: RE: Access to soap message header?
>
>
>There is no explicit access to the history like that .. if you have an
>architecture like:
>
> AxisServlet -> Handler A -> Handler B -> Web Service
>
>If either Handler A or Handler B modify the SOAP request or response
>(depending on where we are in the flow lifecycle), the changed message
>becomes *the* message. In other words, if Handler A modifies the message
>received from the AxisServlet, Handler B does *not* have access to the
>message that Handler A had -- Handler B only has access to the message
>modified by Handler A.
>
>Now just because access to this history isn't built-in doesn't mean you
>couldn't add it. A call to the getSession() method on MessageContext will
>retrieve the Session object associated with the webservice call. In theory,
>you could use this Session object to store the original (unmodified) SOAP
>message that came into the AxisServlet. This would maintain the state of the
>message as the MessageContext gets passed to and modified by each of the
>handlers in the chain, thereby ensuring you always had access to the
>original message.
>
>Regards,
> Rob
>
>
>
>
>-----Original Message-----
>From: davout [mailto:davout@dsl.pipex.com]
>Sent: Monday, September 09, 2002 10:07 AM
>To: axis-user@xml.apache.org; allegar_robert@bah.com
>Subject: RE: Access to soap message header?
>
>
> >> .. do you mean the SOAP header that is part of the overall envelope
>that's presented to the called web service for processing? <<
>
>Yes - the full soap message - including headers and body - that has
>originated the instantiation of the Java class
RE: Access to soap message header?
Posted by davout <da...@dsl.pipex.com>.
Isn't this a design flaw?
If you look at all the web service standards coming out on things like
'WS-Coordination' and 'WS-Transactions' they all based upon putting extra
data into the soap message header area.
How on earth is the Java web service class supposed to get access to this
headre area info???
-----Original Message-----
From: Allegar Robert [mailto:allegar_robert@bah.com]
Sent: 09 September 2002 18:53
To: axis-user@xml.apache.org
Subject: RE: Access to soap message header?
There is no explicit access to the history like that .. if you have an
architecture like:
AxisServlet -> Handler A -> Handler B -> Web Service
If either Handler A or Handler B modify the SOAP request or response
(depending on where we are in the flow lifecycle), the changed message
becomes *the* message. In other words, if Handler A modifies the message
received from the AxisServlet, Handler B does *not* have access to the
message that Handler A had -- Handler B only has access to the message
modified by Handler A.
Now just because access to this history isn't built-in doesn't mean you
couldn't add it. A call to the getSession() method on MessageContext will
retrieve the Session object associated with the webservice call. In theory,
you could use this Session object to store the original (unmodified) SOAP
message that came into the AxisServlet. This would maintain the state of the
message as the MessageContext gets passed to and modified by each of the
handlers in the chain, thereby ensuring you always had access to the
original message.
Regards,
Rob
-----Original Message-----
From: davout [mailto:davout@dsl.pipex.com]
Sent: Monday, September 09, 2002 10:07 AM
To: axis-user@xml.apache.org; allegar_robert@bah.com
Subject: RE: Access to soap message header?
>> .. do you mean the SOAP header that is part of the overall envelope
that's presented to the called web service for processing? <<
Yes - the full soap message - including headers and body - that has
originated the instantiation of the Java class
RE: Access to soap message header?
Posted by Allegar Robert <al...@bah.com>.
There is no explicit access to the history like that .. if you have an
architecture like:
AxisServlet -> Handler A -> Handler B -> Web Service
If either Handler A or Handler B modify the SOAP request or response
(depending on where we are in the flow lifecycle), the changed message
becomes *the* message. In other words, if Handler A modifies the message
received from the AxisServlet, Handler B does *not* have access to the
message that Handler A had -- Handler B only has access to the message
modified by Handler A.
Now just because access to this history isn't built-in doesn't mean you
couldn't add it. A call to the getSession() method on MessageContext will
retrieve the Session object associated with the webservice call. In theory,
you could use this Session object to store the original (unmodified) SOAP
message that came into the AxisServlet. This would maintain the state of the
message as the MessageContext gets passed to and modified by each of the
handlers in the chain, thereby ensuring you always had access to the
original message.
Regards,
Rob
-----Original Message-----
From: davout [mailto:davout@dsl.pipex.com]
Sent: Monday, September 09, 2002 10:07 AM
To: axis-user@xml.apache.org; allegar_robert@bah.com
Subject: RE: Access to soap message header?
>> .. do you mean the SOAP header that is part of the overall envelope
that's presented to the called web service for processing? <<
Yes - the full soap message - including headers and body - that has
originated the instantiation of the Java class
RE: Access to soap message header?
Posted by davout <da...@dsl.pipex.com>.
>> .. do you mean the SOAP header that is part of the overall envelope
that's presented to the called web service for processing? <<
Yes - the full soap message - including headers and body - that has
originated the instantiation of the Java class
RE: Access to soap message header?
Posted by Allegar Robert <al...@bah.com>.
When you say, "access to the header [in the] ... originating soap message"
in what context do you refer? Do you mean the SOAP header as it was before
it went through any deployed handlers? Or do you mean the SOAP header that
is part of the overall envelope that's presented to the called web service
for processing?
Rob
-----Original Message-----
From: davout [mailto:davout@dsl.pipex.com]
Sent: Monday, September 09, 2002 4:56 AM
To: Axis-User
Subject: Access to soap message header?
Can a Java class representing an Axis web service method get access to the
header section of the originating soap message?
If so how?