|
Sponsored Links
Resources
.NET Research Library
Get .NET related white papers, case studies and webcasts
|
News
News
News
|
Messages: 12
Messages: 12
Messages: 12
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
WSE 2.0: Finally Web Services without HTTP
WSE 2.0's new messaging API enables Web Services to take a much needed first step towards message transport independence by enabling the sending of SOAP messages via TCP with no dependence on IIS or HTTP.
In the standard .ASMX pipeline, SOAP messages are tightly tied to the HTTP transport. WSE 2.0 includes a new Messaging API that delivers on SOAP's original intent by separating the message from the transport protocol. WSE 2.0 includes support for sending SOAP messages via TCP or HTTP with the ability to extend the infrastructure to include other transport mechanisms. These features combined with the implementation of the WS-Addressing Specification allows for true peer-to-peer communication using SOAP messages.
While the examples listed on the article show how to create and use these new features at a fairly low level including dispatching of the incoming messages, it also introduces the SOAPClient and SOAPService classes from which you can easily create components that communicate across process or machine boundaries.
Read more about Web Service Messaging in WSE 2.0 on MSDN.
|
|
Message #129712
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
Interoperability?
Question for anyone who may know:
If an application on .NET is speaking SOAP over TCP using WSE 2.0, what do you need on the other side? Can it be a Linux or Solaris machine, or do you need a Microsoft .NET stack on the other side?
|
|
Message #129714
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
Interoperability?
There wouldn't be much point to it if it wasn't interoperable, it would just be SOAP based remoting.
|
|
Message #129724
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
Interoperability?
I agree. Are you confirming that it's interoperable or just saying that there would be no point if it wasn't? If it's interoperable do you know, is there an example of a WSE 2.0 client talking to a WSE 2.0 server on Linux?
|
|
Message #129744
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
Interoperability?
Why not? You should be able to have a listener on linux server on some port to receive soap messages and then you can use that to send messages from .net client.
|
|
Message #129755
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
WSE 2.0 Is not "Linuxable" per se
An important point to remember is that WSE 2.0 is Microsoft's implementation of web service enhancements including supporting of industry standard specifications like WS-Security, WS-Addressing, etc. In order for a Linux application to interop with a .NET WSE2.0 interface you will need to implement the Linux side using a technology that supports those specifications AND also separates the SOAP messaging from the transport protocol, i.e. can listen on a TCP port for a SOAP message.
As a .NET nerd, I'm woefully ignorant of whether such a technology exists on the Linux side but if it does, let me know and maybe we as a community can investigate interoperability options.
|
|
Message #129758
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
WSE 2.0 Is not "Linuxable" per se
Thank you very much Paul. That's exactly the info I was looking for.
|
|
Message #129761
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
WSE 2.0 Is not "Linuxable" per se
In order for a Linux application to interop with a .NET WSE2.0 interface you will need to implement the Linux side using a technology that supports those specifications AND also separates the SOAP messaging from the transport protocol, i.e. can listen on a TCP port for a SOAP message. As a .NET nerd, I'm woefully ignorant of whether such a technology exists on the Linux side but if it does, let me know and maybe we as a community can investigate interoperability options. Given that interoperability is one of the major reasons for web services, is this not needed to complete the interoperability picture? If Microsoft are going to implement a proprietary way of sending SOAP over TCP shouldn't they also provide listeners to decode this on other platforms?
|
|
Message #129774
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
WSE 2.0 Is not "Linuxable" per se
It depends on the underlying protocol as to whether there is a standard way of transporting SOAP or not. For example BEEP specifies a SOAP binding. If someone wrote a BEEP plugin for WSE2.0 you would expect it to interoperate with a BEEP/SOAP server/client on Linux or anything else.
|
|
Message #129782
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
Interoperability is Standards based
Interoperability is acheived via the use of industry standards like SOAP and XML. That is, the .NET application expresses any data it's sending/recieving as XML and then wraps that in a SOAP message which is also XML. This message is ultimately interoperable as it can be read and handled by any technology that supports the industry standards of SOAP and XML (Which are the basis for Web Services).
Now comes .NET specific implentation of those standards. When a fully interoperable SOAP message is received, .NET proprietarily handles that by either kicking of the ASMX pipeline in the case of ASP.NET hosted Web Services or if you have a WSE2.0 enabled application listening on a TCP port by unwrapping the SOAP message and calling the appropriate methods passing the data from the body of the SOAP message to that method. This by the way is a HUGE over simplification, but you get the idea.
The transport of these SOAP messages over TCP is also interoperable in that just about any technology can open and listen on a TCP Port because TCP is the industry standard protocol for networking. The fact that WSE2.0 does the work for us doesn't decrease interoperability, it just increases a .NET developer's productivity. If there are no Linux based development tools that do the same to improve the developer experience, I'm sure there will be soon.
The important point of the article is that using WSE 2.0 we can separate the interoperable SOAP messages from the transport protocols we use to send them bouncing around the Internet.
|
|
Message #129976
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
WSE 2.0 Is not "Linuxable" per se
I'm not sure that there's a need to provide "listeners" for TCP SOAP messages on other platforms. For the SOAP/HTTP case Microsoft only provides listening technology for its own platforms and the story is the same for SOAP/TCP.
If interoperability is important then it's probably better to stick to HTTP right now as everyone has that. If you _did_ want to pick up the TCP messages on another platform then writing that listener wouldn't be too tricky but (still) HTTP would probably be your first choice.
|
|
Message #130023
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
Great!
I have read some microsoft documentation and let me tell you, in 30m I had 3 senders and 1 server receiving thousands of messages in TCP, and has worked great! Ok, it was only in microsoft world, but the receiver can listen to a port in other operation system like linux and read de XML message! Why not?
|
|
 |
| |
|
New content on TheServerSide.NETNew content on TheServerSide.NETNew content on TheServerSide.NET |
 |
 |
Language "mashups" will become more prominent, and developers will become polyglots, one programmer suggests.
SearchWinDevelopment.com offers an introduction to the language, performance, testing and data management improvements in VS 2008.
VBCode.com code snippets cover all aspects of application development, from data binding to security to the user interface.
Get up to date on XAML best practices with a variety of articles, tutorials and webcasts. [SearchWinDevelopment.com]
One team's experience with the VSTS DB edition suggests that it can improve workflow for dev teams. It also enhanced Agile efforts.
(June 24, Article)
Microsoft has begun to include DSL tools in the VSTS kit. A new book by Steve Cook and other VSTS team members helps set the stage.
(June 24, Article)
Cartoon: Be it ever so humble there is no place like your home after you get a Microsoft Home Server .
(June 18, Cartoon)
Microsoft's Thom Robbins says new technology to highlight in NET 3.5 includes AJAX, LINQ for both C# and VB, as well as tooling enhancements intended to ease the task of building WPF, WF and WCF apps.
(June 29, Podcast)
Venkat Subramaniam discusses AJAX bottlenecks, the tenets of Agile development and more. He spoke at the Ajax Experience.
(June 25, Tech Talk)
In the second of a two-part series, Michele Leroux Bustamente discusses design decisions related to the claims-based security model. Read the story and walk through the process for creating a set of claims-based utilities to encapsulate claims authorization at the service tier.
(May 24, Article)
Understanding why the Entity Framework exists and learning where it can fit into your projects can get you prepared for the eventual release early next year.
(May 10, Article)
Resource: This learning guide gives you quick access to useful links on Windows Communication Foundation security information.
(April 24, Article)
TSS.NET's Jack Vaughan spoke recently spoke with Microsoft's Brad Abrams to find out what he is seeing in the field and what the chefs in Redmond are cooking. Along the way he discusses patterns of AJAX frameworks.
(April 11, Article)
In a two-part series, Michele Leroux Bustamente explains how claims-based security is supported by WCF, and how you can implement a claims-based security model for your services.
(March 29, Article)
Windows Workflow Foundation is a new technology that many developers will need to get their heads around. In a brief excerpt adapted from Programming Windows Workflow Foundation: Practical WF Techniques and Examples using XAML and C#, K.Scott Allen considers aspects of workflow definition.
(March 22, Chapter Excerpt)
|
|