Bypassing Serialization/Deserialization in WebService/AP.NET

[ashoksrini]

Hi All,

I have the below requirement and would like to get some feeback from the
group on the best way to implement:

1. I have WSDL defined exposing few web services.
2. We dont have a requirement to have a server web service class. (reasons
below)
3. I want to develop something like this - when client makes a web service
call, on the server I can intercept the SOAP message (XML doc itself),
inspect some headers and then get the SOAP body and then pass on the body
(XML) to a method in another class. As you can see, there is no use of having
a ASP.NET server class, since all my web services have to be dealt in the
same way (i.e get the body xml and call the same method on the same class
passing the xml).
4. What we are trying to avoid, is the unecessary serialization and
deserialization that happens when web service call has to be converted to a
service class method object and etc.

Given this, one of the ways to do it is to have a custom httphandler
(registered in web.config) and get the http request stream in the handler
class, inspect it and pass on the body. This would imply that when the
handler class receive the response back, then it would have to manually
create the SOAP response XML, which would mean that the handler should
maintain the request that came in and map the request to response etc.
So finally my question....is it possible to do this another way, leveraging
the ASP.NET infrastructure (creating soap response, faults etc), but without
the additional serialization, deserialization overhead?

If you have read till here, thanks for your patience

[Henk de Koning]

Actually it turns out this is quite simple. Just use a normal web method, but
type its (one) parameter as [XmlAnyElement] XmlNode [] theBodyStuff.

Now the direct children of your <soap:body> element will be directly morphed
into the XmlNode array without deserialization .

You can process soap header like normal. Here is a prototype of a webmethod
which should do what you want. It takes any body without deserialization and
allows you to touch any header sent to it:

public class CFlexservice
{
public SoapUnknownHead er[] _theHeaders;

[WebMethod]
[SoapHeader("_th eHeaders", Direction=SoapH eaderDirection. InOut)]
[return:XmlAnyEl ement]
public XmlNode [] FlexMethod([XmlAnyElement] XmlNode [] _bodyStuff)
{
// ... your stuff here ...
}
}

BTW, I typed this by heart, so don't trust me ;-)

HTH,

-- Henkk
"ashoksrini " wrote:

Hi All,

I have the below requirement and would like to get some feeback from the
group on the best way to implement:

1. I have WSDL defined exposing few web services.
2. We dont have a requirement to have a server web service class. (reasons
below)
3. I want to develop something like this - when client makes a web service
call, on the server I can intercept the SOAP message (XML doc itself),
inspect some headers and then get the SOAP body and then pass on the body
(XML) to a method in another class. As you can see, there is no use of having
a ASP.NET server class, since all my web services have to be dealt in the
same way (i.e get the body xml and call the same method on the same class
passing the xml).
4. What we are trying to avoid, is the unecessary serialization and
deserialization that happens when web service call has to be converted to a
service class method object and etc.

Given this, one of the ways to do it is to have a custom httphandler
(registered in web.config) and get the http request stream in the handler
class, inspect it and pass on the body. This would imply that when the
handler class receive the response back, then it would have to manually
create the SOAP response XML, which would mean that the handler should
maintain the request that came in and map the request to response etc.
So finally my question....is it possible to do this another way, leveraging
the ASP.NET infrastructure (creating soap response, faults etc), but without
the additional serialization, deserialization overhead?

If you have read till here, thanks for your patience

[ashoksrini]

umm...not sure if that will work.

My web services defined in WSDL will look like this (represented in .NET
class)

CreateSalesOrde r(SalesOrder)
CreatePurchaseO rder(PurchaseOr der) etc.
"Henk de Koning" wrote:

Actually it turns out this is quite simple. Just use a normal web method, but
type its (one) parameter as [XmlAnyElement] XmlNode [] theBodyStuff.

Now the direct children of your <soap:body> element will be directly morphed
into the XmlNode array without deserialization .

You can process soap header like normal. Here is a prototype of a webmethod
which should do what you want. It takes any body without deserialization and
allows you to touch any header sent to it:

public class CFlexservice
{
public SoapUnknownHead er[] _theHeaders;

[WebMethod]
[SoapHeader("_th eHeaders", Direction=SoapH eaderDirection. InOut)]
[return:XmlAnyEl ement]
public XmlNode [] FlexMethod([XmlAnyElement] XmlNode [] _bodyStuff)
{
// ... your stuff here ...
}
}

BTW, I typed this by heart, so don't trust me ;-)

HTH,

-- Henkk
"ashoksrini " wrote:

Hi All,

I have the below requirement and would like to get some feeback from the
group on the best way to implement:

1. I have WSDL defined exposing few web services.
2. We dont have a requirement to have a server web service class. (reasons
below)
3. I want to develop something like this - when client makes a web service
call, on the server I can intercept the SOAP message (XML doc itself),
inspect some headers and then get the SOAP body and then pass on the body
(XML) to a method in another class. As you can see, there is no use of having
a ASP.NET server class, since all my web services have to be dealt in the
same way (i.e get the body xml and call the same method on the same class
passing the xml).
4. What we are trying to avoid, is the unecessary serialization and
deserialization that happens when web service call has to be converted to a
service class method object and etc.

Given this, one of the ways to do it is to have a custom httphandler
(registered in web.config) and get the http request stream in the handler
class, inspect it and pass on the body. This would imply that when the
handler class receive the response back, then it would have to manually
create the SOAP response XML, which would mean that the handler should
maintain the request that came in and map the request to response etc.
So finally my question....is it possible to do this another way, leveraging
the ASP.NET infrastructure (creating soap response, faults etc), but without
the additional serialization, deserialization overhead?

If you have read till here, thanks for your patience

[Dilip Krishnan]

Hello Henk,
That will work provided you only have one soap action i.e. FlexMethod in
this case. However try using WSE 2.0 and use the soap receiver that can accept
any input and any action. Either way you would need to do what WSE does behind
the scenes ;)

HTH
Regards,
Dilip Krishnan
MCAD, MCSD.net
dkrishnan at geniant dot com
http://www.geniant.com

Actually it turns out this is quite simple. Just use a normal web
method, but type its (one) parameter as [XmlAnyElement] XmlNode []
theBodyStuff.

Now the direct children of your <soap:body> element will be directly
morphed into the XmlNode array without deserialization .

You can process soap header like normal. Here is a prototype of a
webmethod which should do what you want. It takes any body without
deserialization and allows you to touch any header sent to it:

public class CFlexservice
{
public SoapUnknownHead er[] _theHeaders;
[WebMethod]
[SoapHeader("_th eHeaders", Direction=SoapH eaderDirection. InOut)]
[return:XmlAnyEl ement]
public XmlNode [] FlexMethod([XmlAnyElement] XmlNode [] _bodyStuff)
{
// ... your stuff here ...
}
}
BTW, I typed this by heart, so don't trust me ;-)

HTH,

Hi All,

I have the below requirement and would like to get some feeback from
the group on the best way to implement:

1. I have WSDL defined exposing few web services.
2. We dont have a requirement to have a server web service class.
(reasons
below)
3. I want to develop something like this - when client makes a web
service
call, on the server I can intercept the SOAP message (XML doc
itself),
inspect some headers and then get the SOAP body and then pass on the
body
(XML) to a method in another class. As you can see, there is no use
of having
a ASP.NET server class, since all my web services have to be dealt in
the
same way (i.e get the body xml and call the same method on the same
class
passing the xml).
4. What we are trying to avoid, is the unecessary serialization and
deserialization that happens when web service call has to be
converted to a
service class method object and etc.
Given this, one of the ways to do it is to have a custom httphandler
(registered in web.config) and get the http request stream in the
handler class, inspect it and pass on the body. This would imply that
when the handler class receive the response back, then it would have
to manually create the SOAP response XML, which would mean that the
handler should maintain the request that came in and map the request
to response etc. So finally my question....is it possible to do this
another way, leveraging the ASP.NET infrastructure (creating soap
response, faults etc), but without the additional serialization,
deserialization overhead?

If you have read till here, thanks for your patience

[erymuzuan]

Use SoapExtension class and override othe ProcessMessage method, take a
lookt at the MSDN documentation for details

// then you can write your method someting like this, preserving the WSDL

[MyOwnSoapExtens ionAttribute]
[WebMethod]
public SalesOrderRespo nse CreateSalesOrde r(SalesOrder);
regards
erymuzuan msutapa

ashoksrini wrote:

umm...not sure if that will work.

My web services defined in WSDL will look like this (represented in .NET
class)

CreateSalesOrde r(SalesOrder)
CreatePurchaseO rder(PurchaseOr der) etc.
"Henk de Koning" wrote:

Actually it turns out this is quite simple. Just use a normal web method, but
type its (one) parameter as [XmlAnyElement] XmlNode [] theBodyStuff.

Now the direct children of your <soap:body> element will be directly morphed
into the XmlNode array without deserialization .

You can process soap header like normal. Here is a prototype of a webmethod
which should do what you want. It takes any body without deserialization and
allows you to touch any header sent to it:

public class CFlexservice
{
public SoapUnknownHead er[] _theHeaders;

[WebMethod]
[SoapHeader("_th eHeaders", Direction=SoapH eaderDirection. InOut)]
[return:XmlAnyEl ement]
public XmlNode [] FlexMethod([XmlAnyElement] XmlNode [] _bodyStuff)
{
// ... your stuff here ...
}
}

BTW, I typed this by heart, so don't trust me ;-)

HTH,

-- Henkk
"ashoksrini " wrote:

Hi All,

I have the below requirement and would like to get some feeback from the
group on the best way to implement:

1. I have WSDL defined exposing few web services.
2. We dont have a requirement to have a server web service class. (reasons
below)
3. I want to develop something like this - when client makes a web service
call, on the server I can intercept the SOAP message (XML doc itself),
inspect some headers and then get the SOAP body and then pass on the body
(XML) to a method in another class. As you can see, there is no use of having
a ASP.NET server class, since all my web services have to be dealt in the
same way (i.e get the body xml and call the same method on the same class
passing the xml).
4. What we are trying to avoid, is the unecessary serialization and
deserializat ion that happens when web service call has to be converted to a
service class method object and etc.

Given this, one of the ways to do it is to have a custom httphandler
(registere d in web.config) and get the http request stream in the handler
class, inspect it and pass on the body. This would imply that when the
handler class receive the response back, then it would have to manually
create the SOAP response XML, which would mean that the handler should
maintain the request that came in and map the request to response etc.
So finally my question....is it possible to do this another way, leveraging
the ASP.NET infrastructure (creating soap response, faults etc), but without
the additional serialization, deserialization overhead?

If you have read till here, thanks for your patience

[Henk de Koning]

Well, the question was if it could be done using the aspnet pipeline ... I
agree you can do other stuff with WSE2, and you know what, with Indigo you
can ditch the web server entirely ;-)

Anyhow, you *can* expose multiple methods using the anyElement technique, as
long as you are willing to write the WSDL by hand (or tool, or create
skeleton webmethods first, capture the generated WSDL and then replace the
skeletons by corresponding any methods). The contract can be more strongly
typed than the implementation (or better, the typing can be enforced by
something else than the plumbing).

Remember that the only thing that determins delivery of a soap request to an
endpoint is the method name (in fact, the lack of support for overloading is
one of the big struggles in WSDL2 right now).

-- Henkk

"Dilip Krishnan" wrote:

Hello Henk,
That will work provided you only have one soap action i.e. FlexMethod in
this case. However try using WSE 2.0 and use the soap receiver that can accept
any input and any action. Either way you would need to do what WSE does behind
the scenes ;)

HTH
Regards,
Dilip Krishnan
MCAD, MCSD.net
dkrishnan at geniant dot com
http://www.geniant.com

Actually it turns out this is quite simple. Just use a normal web
method, but type its (one) parameter as [XmlAnyElement] XmlNode []
theBodyStuff.

Now the direct children of your <soap:body> element will be directly
morphed into the XmlNode array without deserialization .

You can process soap header like normal. Here is a prototype of a
webmethod which should do what you want. It takes any body without
deserialization and allows you to touch any header sent to it:

public class CFlexservice
{
public SoapUnknownHead er[] _theHeaders;
[WebMethod]
[SoapHeader("_th eHeaders", Direction=SoapH eaderDirection. InOut)]
[return:XmlAnyEl ement]
public XmlNode [] FlexMethod([XmlAnyElement] XmlNode [] _bodyStuff)
{
// ... your stuff here ...
}
}
BTW, I typed this by heart, so don't trust me ;-)

HTH,

Hi All,

I have the below requirement and would like to get some feeback from
the group on the best way to implement:

1. I have WSDL defined exposing few web services.
2. We dont have a requirement to have a server web service class.
(reasons
below)
3. I want to develop something like this - when client makes a web
service
call, on the server I can intercept the SOAP message (XML doc
itself),
inspect some headers and then get the SOAP body and then pass on the
body
(XML) to a method in another class. As you can see, there is no use
of having
a ASP.NET server class, since all my web services have to be dealt in
the
same way (i.e get the body xml and call the same method on the same
class
passing the xml).
4. What we are trying to avoid, is the unecessary serialization and
deserialization that happens when web service call has to be
converted to a
service class method object and etc.
Given this, one of the ways to do it is to have a custom httphandler
(registered in web.config) and get the http request stream in the
handler class, inspect it and pass on the body. This would imply that
when the handler class receive the response back, then it would have
to manually create the SOAP response XML, which would mean that the
handler should maintain the request that came in and map the request
to response etc. So finally my question....is it possible to do this
another way, leveraging the ASP.NET infrastructure (creating soap
response, faults etc), but without the additional serialization,
deserialization overhead?

If you have read till here, thanks for your patience

[Dilip Krishnan]

> Well, the question was if it could be done using the aspnet pipeline

... I agree you can do other stuff with WSE2, and you know what, with
Indigo you can ditch the web server entirely ;-)
:)
Anyhow, you *can* expose multiple methods using the anyElement
You *cannot* expose multiple methods in ASP.net... only one method which
can handle many inputs!
technique, as long as you are willing to write the WSDL by hand (or
tool, or create skeleton webmethods first, capture the generated WSDL
and then replace the skeletons by corresponding any methods). The
contract can be more strongly typed than the implementation (or
better, the typing can be enforced by something else than the
plumbing).

Remember that the only thing that determins delivery of a soap request
to an endpoint is the method name (in fact, the lack of support for
overloading is one of the big struggles in WSDL2 right now).

Exactly my point!

<snip>

[Henk de Koning]

I am looking at a trace of a wsdl generated proxy that goes to the following
webmethods:

[WebMethod]
[SoapHeader("_my Headers", Direction=SoapH eaderDirection. InOut)]
[return:XmlAnyEl ementAttribute]
public XmlNode [] AnyMethod1([XmlAnyElement] XmlNode [] body)
{
body[0].InnerText = "Bye bye";
return body;
}

[WebMethod]
[SoapHeader("_my Headers", Direction=SoapH eaderDirection. InOut)]
[return:XmlAnyEl ementAttribute]
public XmlNode [] AnyMethod2([XmlAnyElement] XmlNode [] body)
{
return body;
}

So, I rather believe my own eyes than your remarks ;-). I stick to my point:
you *can* do multiple anyElement webmethods (as long as you give them
different names). What makes you believe this would be impossible ?

-- Henkk
"Dilip Krishnan" wrote:

Well, the question was if it could be done using the aspnet pipeline
... I agree you can do other stuff with WSE2, and you know what, with
Indigo you can ditch the web server entirely ;-)

:)

Anyhow, you *can* expose multiple methods using the anyElement

You *cannot* expose multiple methods in ASP.net... only one method which
can handle many inputs!

technique, as long as you are willing to write the WSDL by hand (or
tool, or create skeleton webmethods first, capture the generated WSDL
and then replace the skeletons by corresponding any methods). The
contract can be more strongly typed than the implementation (or
better, the typing can be enforced by something else than the
plumbing).

Remember that the only thing that determins delivery of a soap request
to an endpoint is the method name (in fact, the lack of support for
overloading is one of the big struggles in WSDL2 right now).

Exactly my point!

<snip>

[Dilip Krishnan]

Hello Henk,
Not to start an email war.. but i think we misunderstood each other.
What I tried to say was you cannot have multiple soap actions being handled
by the same web method with XmlAnyElement :) This is by virtue of the fact
that the soap action is infered from the method name if the action (SoapDocumentMe thod)Attribute
is not specified. You can by all means create as many methods as you want...
and all day. However it doesnt address the original problem

"3. I want to develop something like this - when client makes a web service
call, on the server I can intercept the SOAP message (XML doc itself),
inspect some headers and then get the SOAP body and then pass on the body
(XML) to a method in another class."

<snip>

So, I rather believe my own eyes than your remarks ;-). I stick to my
point: you *can* do multiple anyElement webmethods (as long as you
give them different names). What makes you believe this would be
impossible ?

Certainly possible ;)
Cheers!
Regards,
Dilip Krishnan
MCAD, MCSD.net
dkrishnan at geniant dot com
http://www.geniant.com