SOAP/HTTP without IIS-ASP.Net

  • Thread starter Thread starter aaa.aaa
  • Start date Start date
A

aaa.aaa

Hello,

I wonder whether with the DotNet framework 2.0, it would be possible to
write a windows application service which incorporated a server HTTTP
"embedded" (via code) without using IIS locally.

The purpose of the application is to consume SOAP messages over HTTP
containing objects (described in a blueprint XSD) and return reply
containing objects serialisé with xml (via their XSD schema)

XML-based messaging protocols have messages (requests) that travel in
both directions, this means that each end entity is both a SOAP client
and a SOAP server.
Implementations MUST be able to function as both a SOAP client and a
SOAP server

I do not want to have to install IIS and go through web services as in
the messages SAOP there would be no description of methods, but the
description of objects.

Let me know namespaces and classes.
As one example of code, or link on the web.

Thanks
 
You can do as much of this yourself as you want - it's just a question of
how much code you want to write.

At the "do it the hard way" end, you can write a socket listener that
listens on port 80, parses text, turns that into SOAP, then does the
relevant xsd validations. Doing this would be nuts, but it would be
possible.

WCF procivides the ability to write custom transports - there are samples
for TCP and UDP listeners. You can also write custom serializers (for
example, see the JSON serializer). I'm not sure how this would interact with
SOAP though.

At this point, you should probably poke around the documentation for WCF,
regarding custom channels, listeners, and serializers. You may be able to
get very close to what you're looking for with little code.
 
Thanks for your comment.

What will be from your point of view the best way to do it ?

With IIS & ASP.NET & DotNEt 3.X ?
instead of own solution ?

Can you develop your point of view ?

Thanks




Chris Mullins [MVP - C#] a écrit :
 
Thanks for your comment.

What will be from your point of view the best way to do it ?
With IIS & ASP.NET & DotNEt 3.X ?
instead of own solution ?

Can you develop your point of view ?

To complement :

The Implementers are REQUIRED to use this stack protocol :

Messaging uses XML
SOAP
HTTP
SSL
TCP
IP
Ethernet

All the schema (xsd) will be provided by an administration.

XML-based messaging protocols have messages (requests) that travel in
both directions, this means that each end entity is both a SOAP
client and a SOAP server.
Implementations MUST be able to function as both a SOAP client and a
SOAP server

Chris Mullins [MVP - C#] a écrit :
You can do as much of this yourself as you want - it's just a question
of how much code you want to write.

At the "do it the hard way" end, you can write a socket listener that
listens on port 80, parses text, turns that into SOAP, then does the
relevant xsd validations. Doing this would be nuts, but it would be
possible.

WCF procivides the ability to write custom transports - there are
samples for TCP and UDP listeners. You can also write custom
serializers (for example, see the JSON serializer). I'm not sure how
this would interact with SOAP though.

At this point, you should probably poke around the documentation for
WCF, regarding custom channels, listeners, and serializers. You may be
able to get very close to what you're looking for with little code.
Click to expand...
Click to expand...
 
Hi,

Your choice would be to use WCF with the following options:
- basicHttpBinding (ASP.Net WebServices compliant)
- transport mode security (HTTPS, requires a server certificate)
- the rest of your requirements will be fullfilled as well

Although, I would discuss netTcpBinding with administrators as it uses much
more efficient serialization and offers much better network performance
(when we are talking about the amount of the data sent over the wire,
negotiating security, etc.).

The main question is _WHY_ HTTP, SOAP and XML are required?

A bit more of basic information you can find here:
http://msdn2.microsoft.com/en-us/library/ms730879.aspx

--
Best regards,
Cezary Nolewajka

Consultant | Microsoft Services | Microsoft | Poland

aaa.aaa said:
Thanks for your comment.

What will be from your point of view the best way to do it ?
With IIS & ASP.NET & DotNEt 3.X ?
instead of own solution ?

Can you develop your point of view ?

To complement :

The Implementers are REQUIRED to use this stack protocol :

Messaging uses XML
SOAP
HTTP
SSL
TCP
IP
Ethernet

All the schema (xsd) will be provided by an administration.

XML-based messaging protocols have messages (requests) that travel in
both directions, this means that each end entity is both a SOAP
client and a SOAP server.
Implementations MUST be able to function as both a SOAP client and a
SOAP server

Chris Mullins [MVP - C#] a écrit :
You can do as much of this yourself as you want - it's just a question
of how much code you want to write.

At the "do it the hard way" end, you can write a socket listener that
listens on port 80, parses text, turns that into SOAP, then does the
relevant xsd validations. Doing this would be nuts, but it would be
possible.

WCF procivides the ability to write custom transports - there are
samples for TCP and UDP listeners. You can also write custom serializers
(for example, see the JSON serializer). I'm not sure how this would
interact with SOAP though.

At this point, you should probably poke around the documentation for
WCF, regarding custom channels, listeners, and serializers. You may be
able to get very close to what you're looking for with little code.

--
Chris Mullins

Hello,

I wonder whether with the DotNet framework 2.0, it would be possible to
write a windows application service which incorporated a server HTTTP
"embedded" (via code) without using IIS locally.

The purpose of the application is to consume SOAP messages over HTTP
containing objects (described in a blueprint XSD) and return reply
containing objects serialisé with xml (via their XSD schema)

XML-based messaging protocols have messages (requests) that travel in
both directions, this means that each end entity is both a SOAP client
and a SOAP server.
Implementations MUST be able to function as both a SOAP client and a
SOAP server

I do not want to have to install IIS and go through web services as in
the messages SAOP there would be no description of methods, but the
description of objects.

Let me know namespaces and classes.
As one example of code, or link on the web.

Thanks
Click to expand...
Click to expand...
Click to expand...
 
Back
Top