Web service client, with embedded web server for SOAP callbacks - need clear guidance

[Paul McGuire]

I am working on an industrial application that reports data from industrial
processes. I am working to an industry standard interface spec, so I cannot
refactor the partitioning or redesign the interfaces. Here is my problem.

The industrial process implements a web service for registering data
collection schemes. I have to develop a client to receive the data.
To receive the data, the client code:
1. defines a data collection plan (creates local object, using types defined
in WSDL)
2. downloads the data collection plan to the process equipment (synchronous
method call)
3. activates the data collection plan, passing a URL for a callback
(synchronous method call)
4. listens for and collects data reported to the URL over SOAP (asynchronous
callback to client)
5. later deactivates the data collection plan

So the client must also implement a web service server to handle the
callback data reports.

I can't run the callback using IIS, so I plan to run an embedded web server
using Cassini-like technology. I can run the wsdl utility against the
consumer interface WSDL file, to generate the abstract proxy stub and data
types, and I can implement the derived class to actually perform the work.
But how do I tie the implementation object that instantiates the data
consumer class to the generated Host, Connection, and RequestHandler/Worker
classes? The incoming "request" (actually a data report) comes in over
SOAP, so I need something that will listen HTTP, render SOAP XML into method
invocation and deserialize method parameters, run my implementation, and
then reserialize any return parameters and send the response back over
SOAP/HTTP.

Can't use SOAP SDK 3.0, sproxy chokes on the complex data types defined in
the spec's WSDL.

Would prefer to use C# and .NET Framework 1.1. I read about HTTPListener in
the ServiceStation article, but this is in .NET Fwk 2.0, which is still
beta, and not sure I will be able to use it in my client environment.

I have googled far and wide for "web services", "without IIS", "eventing",
"remoting", you-name-it. I could really use some expert pointers. I'm lost
amid the come-and-go jargon, and can't figure out which technology horses
are today's stallions but tomorrow's goats.

Thanks!
-- Paul

[Dilip Krishnan]

Hello Paul,
Have you tried using WSE to create soap receivers. Dont need a server to
implement that. Also take a look at plumbwork orange [[url]http://sourceforge.net/projects/plumbworkorange/][/url]
The project has an implementation of WS-Eventing which is probably exactly
what yr looking for

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

> I am working on an industrial application that reports data from
> industrial processes. I am working to an industry standard interface
> spec, so I cannot refactor the partitioning or redesign the
> interfaces. Here is my problem.
>
> The industrial process implements a web service for registering data
> collection schemes. I have to develop a client to receive the data.
> To receive the data, the client code:
> 1. defines a data collection plan (creates local object, using types
> defined
> in WSDL)
> 2. downloads the data collection plan to the process equipment
> (synchronous
> method call)
> 3. activates the data collection plan, passing a URL for a callback
> (synchronous method call)
> 4. listens for and collects data reported to the URL over SOAP
> (asynchronous
> callback to client)
> 5. later deactivates the data collection plan
> So the client must also implement a web service server to handle the
> callback data reports.
>
> I can't run the callback using IIS, so I plan to run an embedded web
> server using Cassini-like technology. I can run the wsdl utility
> against the consumer interface WSDL file, to generate the abstract
> proxy stub and data types, and I can implement the derived class to
> actually perform the work. But how do I tie the implementation object
> that instantiates the data consumer class to the generated Host,
> Connection, and RequestHandler/Worker classes? The incoming "request"
> (actually a data report) comes in over SOAP, so I need something that
> will listen HTTP, render SOAP XML into method invocation and
> deserialize method parameters, run my implementation, and then
> reserialize any return parameters and send the response back over
> SOAP/HTTP.
>
> Can't use SOAP SDK 3.0, sproxy chokes on the complex data types
> defined in the spec's WSDL.
>
> Would prefer to use C# and .NET Framework 1.1. I read about
> HTTPListener in the ServiceStation article, but this is in .NET Fwk
> 2.0, which is still beta, and not sure I will be able to use it in my
> client environment.
>
> I have googled far and wide for "web services", "without IIS",
> "eventing", "remoting", you-name-it. I could really use some expert
> pointers. I'm lost amid the come-and-go jargon, and can't figure out
> which technology horses are today's stallions but tomorrow's goats.
>
> Thanks!
>

[Paul McGuire]

Dilip -

Thanks! WSE is dead-on what I needed.

I downloaded plumbwork orange, at first glance it seems to be overkill for
my needs, but it's good to know that if things get more complicated than I
currently envision, this event framework is close at hand.

-- Paul

"Dilip Krishnan" <dkrishnan@NOSPAM.geniant.com> wrote in message
news:91128632403924962296048@msnews.microsoft.com. ..

> Hello Paul,
> Have you tried using WSE to create soap receivers. Dont need a server to
> implement that. Also take a look at plumbwork orange

[[url]http://sourceforge.net/projects/plumbworkorange/][/url]

> The project has an implementation of WS-Eventing which is probably exactly
> what yr looking for
>
> HTH
> Regards,
> Dilip Krishnan
> MCAD, MCSD.net
> dkrishnan at geniant dot com
> [url]http://www.geniant.com[/url]
>

> > I am working on an industrial application that reports data from
> > industrial processes. I am working to an industry standard interface
> > spec, so I cannot refactor the partitioning or redesign the
> > interfaces. Here is my problem.
> >
> > The industrial process implements a web service for registering data
> > collection schemes. I have to develop a client to receive the data.
> > To receive the data, the client code:
> > 1. defines a data collection plan (creates local object, using types
> > defined
> > in WSDL)
> > 2. downloads the data collection plan to the process equipment
> > (synchronous
> > method call)
> > 3. activates the data collection plan, passing a URL for a callback
> > (synchronous method call)
> > 4. listens for and collects data reported to the URL over SOAP
> > (asynchronous
> > callback to client)
> > 5. later deactivates the data collection plan
> > So the client must also implement a web service server to handle the
> > callback data reports.
> >
> > I can't run the callback using IIS, so I plan to run an embedded web
> > server using Cassini-like technology. I can run the wsdl utility
> > against the consumer interface WSDL file, to generate the abstract
> > proxy stub and data types, and I can implement the derived class to
> > actually perform the work. But how do I tie the implementation object
> > that instantiates the data consumer class to the generated Host,
> > Connection, and RequestHandler/Worker classes? The incoming "request"
> > (actually a data report) comes in over SOAP, so I need something that
> > will listen HTTP, render SOAP XML into method invocation and
> > deserialize method parameters, run my implementation, and then
> > reserialize any return parameters and send the response back over
> > SOAP/HTTP.
> >
> > Can't use SOAP SDK 3.0, sproxy chokes on the complex data types
> > defined in the spec's WSDL.
> >
> > Would prefer to use C# and .NET Framework 1.1. I read about
> > HTTPListener in the ServiceStation article, but this is in .NET Fwk
> > 2.0, which is still beta, and not sure I will be able to use it in my
> > client environment.
> >
> > I have googled far and wide for "web services", "without IIS",
> > "eventing", "remoting", you-name-it. I could really use some expert
> > pointers. I'm lost amid the come-and-go jargon, and can't figure out
> > which technology horses are today's stallions but tomorrow's goats.
> >
> > Thanks!
> >

>
>