Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > ASP .Net Web Services > Cannot access Soapheader in SoapExtension

Reply
Thread Tools

Cannot access Soapheader in SoapExtension

 
 
Andy Kendall
Guest
Posts: n/a
 
      09-06-2006
I have a problem accessing my custom SoapHeader from a SoapExtension. My
extension has no compile time reference to the class derived from
SoapHeader, so how can cast it into a SoapHeader of the correct type?


Thanks,

Andy


 
Reply With Quote
 
 
 
 
John Saunders
Guest
Posts: n/a
 
      09-06-2006
"Andy Kendall" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
>I have a problem accessing my custom SoapHeader from a SoapExtension. My
> extension has no compile time reference to the class derived from
> SoapHeader, so how can cast it into a SoapHeader of the correct type?


XML.

John


 
Reply With Quote
 
 
 
 
Andy Kendall
Guest
Posts: n/a
 
      09-07-2006
Care to elaborate? Do you mean XML deserialization?

"John Saunders" <john.saunders at trizetto.com> wrote in message
news:(E-Mail Removed)...
> "Andy Kendall" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
> >I have a problem accessing my custom SoapHeader from a SoapExtension. My
> > extension has no compile time reference to the class derived from
> > SoapHeader, so how can cast it into a SoapHeader of the correct type?

>
> XML.
>
> John
>
>



 
Reply With Quote
 
John Saunders
Guest
Posts: n/a
 
      09-07-2006
"Andy Kendall" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> Care to elaborate? Do you mean XML deserialization?
>
> "John Saunders" <john.saunders at trizetto.com> wrote in message
> news:(E-Mail Removed)...
>> "Andy Kendall" <(E-Mail Removed)> wrote in message
>> news:%(E-Mail Removed)...
>> >I have a problem accessing my custom SoapHeader from a SoapExtension. My
>> > extension has no compile time reference to the class derived from
>> > SoapHeader, so how can cast it into a SoapHeader of the correct type?

>>
>> XML.
>>


Ok, I apologize. I thought I had a SOAP Extension which was accessing the
headers as XML. I was mistaken, it accesses them as a SoapHeader-derived
object.

So, to your question: I don't understand how a class, "A", without a
compile-time reference to another class, "B", could cast an object to an
instance of class "B". This question is independent of SOAP Extensions and
Headers. In fact, once it had been cast to class "B", how would class "A"
reference the methods, fields, etc., of class "B" if it has no compile-time
reference to it?

I think more detail is required.

John


 
Reply With Quote
 
Andy Kendall
Guest
Posts: n/a
 
      09-07-2006
Well, given that only xml data is being transferred between client and
server, I wondered if it was possible to create an identical class
definition and cast it into that. After all, normally when you create a web
service and a client VS generates the server and client proxy class and it
works fine - these two classes are not the same - i.e. No binary .dll or
similar has to be shared between client and server but you can use
DirectCast on the base class as if they were.

I tried creating an identical SoapHeader class in my SoapExtension project
in an identical namespace but it complains with "invalid cast" It makes me
wonder how the runtime knows that the xml representaion of my soapHeader
class coming over the wire is not based on the one defined in my
SoapExtension priject but on the SoapHeader defined on the web service
instead - does the deserialised XML have some kind of guid or reference to
the assembly?

I can do what I need to do by adding a reference to the web service .dll
file into my SoapExtension project, but I would rather not have that
dependancy. I also suspect you can do it with manual deserialisation (?) I
just wondered if there was an easier way.

Incidentally, I also notice there is no way to access the raw XML from the
base SoapHeader class, otherwise I would have just used that.

"John Saunders" <john.saunders at trizetto.com> wrote in message
news:%(E-Mail Removed)...
> "Andy Kendall" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
> > Care to elaborate? Do you mean XML deserialization?
> >
> > "John Saunders" <john.saunders at trizetto.com> wrote in message
> > news:(E-Mail Removed)...
> >> "Andy Kendall" <(E-Mail Removed)> wrote in message
> >> news:%(E-Mail Removed)...
> >> >I have a problem accessing my custom SoapHeader from a SoapExtension.

My
> >> > extension has no compile time reference to the class derived from
> >> > SoapHeader, so how can cast it into a SoapHeader of the correct type?
> >>
> >> XML.
> >>

>
> Ok, I apologize. I thought I had a SOAP Extension which was accessing the
> headers as XML. I was mistaken, it accesses them as a SoapHeader-derived
> object.
>
> So, to your question: I don't understand how a class, "A", without a
> compile-time reference to another class, "B", could cast an object to an
> instance of class "B". This question is independent of SOAP Extensions and
> Headers. In fact, once it had been cast to class "B", how would class "A"
> reference the methods, fields, etc., of class "B" if it has no

compile-time
> reference to it?
>
> I think more detail is required.
>
> John
>
>



 
Reply With Quote
 
John Saunders
Guest
Posts: n/a
 
      09-07-2006
"Andy Kendall" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Well, given that only xml data is being transferred between client and
> server, I wondered if it was possible to create an identical class
> definition and cast it into that. After all, normally when you create a
> web
> service and a client VS generates the server and client proxy class and it
> works fine - these two classes are not the same - i.e. No binary .dll or
> similar has to be shared between client and server but you can use
> DirectCast on the base class as if they were.


Ok, now, note that I haven't quite tried what I'm going to suggest. The
closest I've come to this had to do with SOAP faults.

If the SOAP Extension and the Web Service both access the same SOAP header,
then the definition of the SOAP Header should be in a common place. Perhaps
you can separate out the schema for the SOAP Header, and put the schema,
along with the code generated from the schema, into a separate project. That
project would "own" the piece of schema which defines these SOAP Headers.

This project would be referenced by the web service and by the SOAP
Extension.

I've done something similar with SOAP faults, which needed to be accessed
both by one web service and by some code common amongst several web
services. The schema, the generated classes, and the code to create
instances of the SOAP faults was all located in the common project.

I hope this helps. Please let us know how it works out. I don't yet have a
SOAP Header which is shared, but that might happen.

John


 
Reply With Quote
 
Andy Kendall
Guest
Posts: n/a
 
      09-08-2006
Thanks for the reply John,

I think what you suggest is the ideal way forward, however, our situation is
that the SoapExtension in question is just a temporary fix to be applied to
an existing live webservice. On the next build cycle, I think we will
seperate out as you suggest. As our SoapHeader was defined as public,
luckily I have been able to add a reference to the webservice .dll file so
it gets round the problem.

I'm still intrigued as to how visual studio/ASP.NET does it though. I mean,
in a normal visual studio scenario, you create you webservice with any
soapheaders, then you add a reference to that service from a client app. The
proxy classes generated on the client for the soapheaders are completly
different classes from the soapheader classes on the server and yet you can
create instances of them on the client, send them accross the wire and cast
them back into the correct type on the server and it all works swimmingly.
How does the runtime know not to throw an invalid cast exception?


"John Saunders" <john.saunders at trizetto.com> wrote in message
news:(E-Mail Removed)...
> "Andy Kendall" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > Well, given that only xml data is being transferred between client and
> > server, I wondered if it was possible to create an identical class
> > definition and cast it into that. After all, normally when you create a
> > web
> > service and a client VS generates the server and client proxy class and

it
> > works fine - these two classes are not the same - i.e. No binary .dll or
> > similar has to be shared between client and server but you can use
> > DirectCast on the base class as if they were.

>
> Ok, now, note that I haven't quite tried what I'm going to suggest. The
> closest I've come to this had to do with SOAP faults.
>
> If the SOAP Extension and the Web Service both access the same SOAP

header,
> then the definition of the SOAP Header should be in a common place.

Perhaps
> you can separate out the schema for the SOAP Header, and put the schema,
> along with the code generated from the schema, into a separate project.

That
> project would "own" the piece of schema which defines these SOAP Headers.
>
> This project would be referenced by the web service and by the SOAP
> Extension.
>
> I've done something similar with SOAP faults, which needed to be accessed
> both by one web service and by some code common amongst several web
> services. The schema, the generated classes, and the code to create
> instances of the SOAP faults was all located in the common project.
>
> I hope this helps. Please let us know how it works out. I don't yet have a
> SOAP Header which is shared, but that might happen.
>
> John
>
>



 
Reply With Quote
 
John Saunders
Guest
Posts: n/a
 
      09-08-2006
"Andy Kendall" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Thanks for the reply John,
>
> I think what you suggest is the ideal way forward, however, our situation
> is
> that the SoapExtension in question is just a temporary fix to be applied
> to
> an existing live webservice. On the next build cycle, I think we will
> seperate out as you suggest. As our SoapHeader was defined as public,
> luckily I have been able to add a reference to the webservice .dll file so
> it gets round the problem.
>
> I'm still intrigued as to how visual studio/ASP.NET does it though. I
> mean,
> in a normal visual studio scenario, you create you webservice with any
> soapheaders, then you add a reference to that service from a client app.
> The
> proxy classes generated on the client for the soapheaders are completly
> different classes from the soapheader classes on the server and yet you
> can
> create instances of them on the client, send them accross the wire and
> cast
> them back into the correct type on the server and it all works swimmingly.
> How does the runtime know not to throw an invalid cast exception?


It doesn't know. The cast is not invalid. It does not send instances across
the wire. It serializes a client instance, sends it across the wire, then
deserializes it into a totally separate server instance, which is of a type
unrelated to the type of the client instance.

No objects are ever transmitted in web services. Just XML.

John


 
Reply With Quote
 
Andy Kendall
Guest
Posts: n/a
 
      09-08-2006
Sure, but then whats different about that scenario and the one I first tried
where I had an identical class definition (with same namespace) in my soap
extension project?

I know there must be something in the serialised xml telling the runtime
that the serialised soapheader represents the soapheader class defined in my
web service and not the (identical) one defined in the soapextension
assembly - but I don't know what it is.



>
> It doesn't know. The cast is not invalid. It does not send instances

across
> the wire. It serializes a client instance, sends it across the wire, then
> deserializes it into a totally separate server instance, which is of a

type
> unrelated to the type of the client instance.
>
> No objects are ever transmitted in web services. Just XML.
>
> John
>
>



 
Reply With Quote
 
John Saunders
Guest
Posts: n/a
 
      09-08-2006
"Andy Kendall" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Sure, but then whats different about that scenario and the one I first
> tried
> where I had an identical class definition (with same namespace) in my soap
> extension project?
>
> I know there must be something in the serialised xml telling the runtime
> that the serialised soapheader represents the soapheader class defined in
> my
> web service and not the (identical) one defined in the soapextension
> assembly - but I don't know what it is.


I'm not sure of the step by step details, but it's something like this:

1) IIS receives a request directed at some file with a .asmx extension
2) Since there's a sctipt mapping between that extension and ASP.NET, the
request is sent to the ASP.NET worker process
3) The worker process looks at the file extension, and maps it to a
HttpHandler subclass, in this case, WebServiceHandler (I think)
4) WebServiceHandler opens the .asmx file and, based on its contents,
determines which WebService-derived class to use.
5) Based on the metadata on this class, it matches the incoming SOAP message
to a WebMethod
6) Based on the metadata on this WebMethod, it deserializes the SOAP message
6a) You have one or more [SoapHeader] attributes on your WebMethods, right?
6b) Each SoapHeader attribute refers to a public field in your WebService.
6c) The field has a type and maybe other attributes, which guide
deserialization of any matching SOAP headers in the message

So, no magic, just a bit of work going on in the background.

John


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
SoapExtension and SoapHeader nilesh.shah.uk@gmail.com ASP .Net Web Services 1 03-05-2007 02:39 PM
AXIS to emit SOAPHeader in wsdl davecline@gmail.com Java 0 12-14-2004 11:44 PM
AXIS to emit SOAPHeader in wsdl davecline@gmail.com Java 0 12-14-2004 11:44 PM
AXIS to emit SOAPHeader in wsdl davecline@gmail.com Java 0 12-14-2004 11:43 PM
SoapHeader problem All Smiles ASP .Net 0 05-20-2004 05:48 PM



Advertisments