"Nimai Malle" <ni*********@yahoo.com> wrote in message news:7a**************************@posting.google.c om...
That said, what I am interested in is what .NET Framework methods are
available (and possible used internally) for implementing the
functionality in HttpRuntime.ProcessRequest, for example.
From your first post and subject line, I would never have guessed you
were interested in the implementation of HttpRuntime.ProcessRequest( );
what it dealing with HTTP transport, and largely unrelated to SOAP? ;-)
ProcessRequest handles incoming HTTP requests (not necessarily SOAP,
but you know that) for ASP.NET. The file extension of the requested
resource is mapped to an HttpHandler implementation that knows how
to process and respond to that particular request. The handler is created,
and responsibility for driving the response is turned over to it.
If you look in the machine.config file, you will see an <httpHandlers> section
which associates types with various paths (often file extensions). When you
look at path="*.vb" for instance, you see it associated with the type: System.
Web.HttpForbiddenHandler. ASP.NET does not want IIS to answer requests
for source files that may exist in the web applications' folders, so this class will
construct a response that gets sent back to the end user saying "Forbidden."
One of those HttpHandlers, of course, is for the path="*.asmx", which is
a ASP.NET web service document. It's type is System.Web.Services.
Protocols.WebServiceHandlerFactory. That's about as soapy as Process-
Request itself gets.
If you want to see what .NET Framework methods HttpRuntime.Process-
Request uses internally, I suggest running ILDASM -- it's included in the
FrameworkSDK /bin folder (or the popular Reflector tool by Lutz Roeder)
-- on the System.Web assembly. It's not necessary to be fluent in MSIL
to read the disassembly, all of the .NET Framework method calls will jump
right out at you.
: : Anyway, I understand your reply. Thank you.
"Derek Harmon" <lo*******@msn.com> wrote in message news:uP*************@TK2MSFTNGP10.phx.gbl...
: :
For the particular three objects you have in your example,
you could parse the SOAPCall string as XML and interpret
it to route to the correct method of MyObject using a number
of System.Reflection methods, call the method and then
return a value that you'd have to format as SOAP to store
in SOAPResponse.
Let me elaborate, you may not have seen how this applies.
Use the System.Xml.* classes to interpret the SOAP envelope that
you're (it sounds like to me) posting from your SimpleWorkerRequest
subclass. The .NET Framework also uses System.Xml.Serialization
and the System.Runtime.Serialization.Formatters.Soap; but were I
writing it, I'd avoid using those if possible.
Use the classes in the System.Reflection namespace to instantiate an
instance of your object (e.g., ConstructorInfo or the CreateInstance( )
method of Type or AppDomain if you prefer) and invoke the right
method (e.g., MethodInfo or PropertyInfo; Invoke( ) or SetValue( )
methods).
Go back to the System.Xml.* classes to create the response containing
the method's return value; or to create a fault for any Exception you've
caught.
The actual WebService handler ASP.NET uses will look for (using
reflection) all sorts of Attributes adorning MyObject's metadata to
drive through certain parts of it's deserialization, processing, and
serialization of the response.
Derek Harmon