Christian Weyer: Smells like service spirit

A hint for Indigo (PDC) and ASMX 1.1 interoperability

Fumiaki Yoshimatsu reports about his first experiences in developing with Indigo.

I have just done some experimental interoperation between Indigo and 1.1 asmx.  Here is the code I wrote.  It worked fine so far.  Enjoy.

Hosting Web services on your mobile device - finally a managed way

In a new MSDN article called .NET Compact Framework Mobile Web Server Architecture  the two authors introduce a small Web server for the .NET Compact Framework. So we are finally able to at least host ASMX (-like) Web services on our Pocket PC and similar devices.

Get technical insight on the implementation of Mobile Web Server architecture. Understand use cases, the web server framework and future developments in the architecture.

The most interesting part of the architecture for me is the support of a so called SOAP Module which handles SOAP-based Web services communications in a similar way like ASMX does:

Soap Module
The Soap Module addresses the requirements of processing web service remote invocation by clients. The current implementation supports GET, POST and SOAPAction operations. Typically GET and POST operations are utilized for browser request, returning an XML string to represent the results of operation. SOAPAction is used to identify SOAP packets requested by applications utilizing the particular web service.

Additionally, the SOAP Module provides facilities to automatically generate WSDL files from a requested web service. Therefore, it eliminates the need for developers to manually create the WSDL files confirming to their web service application. A WSDL file is used to define the entry points and contracts as well as describe the service of the application, thus allowing other web services or applications to utilize the web service correctly.

Would be nice they also supported the disabling of automatic WSDL generation - which makes sense in a lot of situations.
Anyway, sweet thingie, definitely want to see it improving ...

"There were no errors while compiling this service."

OK, first steps done - now let's get to the metal ...
BTW, this very same Web service can also be accessed over TCP - 'through' ASP.NET! Surprise - more explanations to come ...

ANN: Improve your "Contract First" Web services development experience: WsContractFirst v0.2 - forget about wsdl.exe

WsContractFirst
A Visual Studio .NET Add-In for improved 'Contract First' Web services development

For quickstarters:

New features in 0.2 (download link at the end of the article):

• Adding to the service side stub code generation, it now adds an .asmx default implementation (automatic WSDL generation disabled, obviously).
• The client side developer gets access to the raw SOAP message - either as a byte[] or simply as a string.
• Do you hate that wsdl.exe and the Visual Studio .NET "Add Web Reference ..." dialog always and only can produce public fields for members in data classes (based on the XSD)?
  This tool can optionally generate private fields with public property wrappers.
• Dynamic vs. static URL reference (you can configure the Web service endpoint URL either in App.config or Web.config).
• Serveral bug fixes and internal improvements

For a basic introduction:

I am happy to announce version 0.2 of a tool - a Visual Studio .NET Add-In - called WsContractFirst. The first bits (version 0.1) already have made it through the blogosphere and rumbled in Web services town - nice.
Microsoft obviously did not have enough time for adding a nice little feature to their prime IDE. So I had fun spending my time with getting to know the beloved and still COM-based extensibility model of Visual Studio .NET.

Yeah, a lot of people will rant that it is just the GUI-fied version of wsdl.exe - well, no. It is a complete new write-up, I am not leveraging wsdl.exe through the command line but use the .NET framework classes directly. So the code is completely extensible, sometime later I will eventually publish the code and might turn the whole thing into a GotDotNet Workspaces project.

So what does it do, dude?
Ever wanted to simply right-click on a WSDL file in Visual Studio .NET and generate code from that Web service contract? Now you can - whether it be a client-side proxy class or a server-side stub skeleton: you choose. The Add-In automatically determines the project's programming language and accordingly generates source code (currently C# and VB.NET supported). The tool's functionality can also be reached through a common menu item entry in VS.NET's Tools menu.

The Add-In handles the import of external schemas and WSDLs better than wsdl.exe. The code that makes the Add-In breathe is based on snippets of my formerly released DynWSLib to dynamically call Web services at runtime without 'any' knowledge of the WSDL beforehand (well, yes: this is somehow contradictory to the 'Contract First' approach. But it is actually useful in some verly limited uses cases such as testing. Actually the lib is used in a client side service invocation factory in a .NET-based Grid computing project). BTW, it would be nice if the server-side stub code would not produce an abstract class, but an interface instead - just what Indigo is capable of, as Don showed at PDC.

This is the second step in my and other's vision of first designing the Web services contract (and policy!) and then generating code skeletons from that. Hm, maybe there are some guys out there who can help me with the first step of visually designing the contract ... Chris, where are you?

TODO:

• Testing, testing, testing (can need your help here)
• Adding desired features from users (well, need your help here, too :-))
• Make it more sexy ...?

Feel free to leave any comments, flames, or rants here or there.
Special thanks for testing, ideas, comments, and testing go to Tomas, Pierre, Christoph, Ralf, Klaus and Scott - not to forget Yasser. Thanks guys.

Download: Get it here!

DISCLAIMER:
The sample is provided as is. Be sure that it is actually only a sample and does not in any sense conform to any coding guidelines and has not been proven to be a stable product! The code has not been reviewed by third parties or even been refactored for optimization - be sure that it is still much improvable.
The author cannot be made responsible for any damage or inconveniencies but is willed to accept any questions and comments to this sample. Please notice that this code is only a technology demo and should not be included unedited into any serious project.

Indigo SMTP/POP3 transports details

Once again, I am reporting an interesting posting from the Indigo newsgroup - this time from Microsoft's Haktan Buyukcetin (I edited the text for betting reading, though). Enjoy!

Here is a high-level overview of how the SMTP/POP3 transports work:
 
1.   With the SmtpTransport you (user1 in the example below) send a SOAP message to another user’s (user2) mailbox using user1's relay server.
2.   After the message arrives in user2's mailbox, it will be stored in user2’s mailbox like a regular piece of mail with an attachment (the attachment is a SOAP envelope) until user2’s Pop3Transport polls for this message. The Service in Port2 does not have to be running at that time as long as its mailbox is operational. 
 
Functionally, you can think of the SMTP/POP3 transports like any other type of mail client (e.g., Outlook Express). There is no integration with other client apps.
 
You can share your own mailbox with these transports. These messages will appear in your mail client with subject line "@@SOAP.......".  If your client email program configuration is not set to download mails locally, the Pop3Transport will poll only for these SOAP messages, process them, and delete them from your mailbox periodically.
 
Here is an attached sample. Although port1 sends a message to port2, both ports are configured to send and receive messages:
 

class TestMessageHandler : SyncMessageHandler
{
   public TestMessageHandler() : base()
   {
   }
   public override bool ProcessMessage(Message message)
   {
     Console.WriteLine("ProcessMessage");
     return true;
   }
}
 

Test code:
 
string password1 = "password1"; // for port1 user Mail Server (Exchange) Password
string alias1 = "alias1"; // for port1 user alias
 
string password2 = "password2"; // for port2 user Mail Server (Exchange) Password
string alias2 = "alias2"; // for port2 user alias

string exchangeServer1 = "exchangeServer1"; // mail server's host name
string domain1 = "yourcompanydomain1.com"; 
 
string exchangeServer2 = "exchangeServer2"; // mail server's host name
string domain1 = "yourcompanydomain2.com"; 
 
Uri port1Address = new Uri("soap.mail://" + alias1 + "@" + domain1); // soap.mail://alias1@yourcompanydomain1.com
Uri port2Address = new Uri("soap.mail://" + alias2 + "@" + domain2); // soap.mail://alias2@yourcompanydomain2.com
 
Uri port1PopAddress = new Uri("pop://" + alias1 + ":" + password1 + "@" + exchangeServer1);
Uri port2PopAddress = new Uri("pop://" + alias2 + ":" + password2 + "@" + exchangeServer2);
 
// Sender code starts here
Port port1 = new Port(port1Address);
                 
// for sending messages
// you can set these from configuration as well
SmtpTransport smtpTransport1 = port1.Transports["soap.mail"] as SmtpTransport;
smtpTransport1.RelayServer = exchangeServer1;
smtpTransport1.Sender = alias1 + "@" + domain1;
 
// for receiving messages
// don't need if you don't want to receive any messages back
// you can set these from configuration as well
port1.TransportAddresses.Add(new Pop3TransportAddress(port1PopAddress)); 
port1.ReceiveChannel.Handler = new TestMessageHandler(); //don't need if you don't want to receive any messages back
port1.Open();
 
Message message = new Message(port2Address,"test content");
port1.CreateSendChannel(port2Address).Send(message);
 
Console.WriteLine("Message Sent");
Console.WriteLine("Press Enter to Continue");
Console.ReadLine();
port1.Close();
 
// receiver code starts here.
Port port2 = new Port(port2Address);
// for sending messages,
// don't need if you don't want to send messages back to the port1
// you can set these from configuration as well
SmtpTransport smtpTransport2 = port2.Transports["soap.mail"] as SmtpTransport;
smtpTransport2.RelayServer = exchangeServer2;
smtpTransport2.Sender = alias2 + "@" + domain2;
 
// for receiving messages
// don't need if you don't want to receive any messages back
// you can set these from configuration as well
port2.TransportAddresses.Add(new Pop3TransportAddress(port2PopAddress));
port2.ReceiveChannel.Handler = new TestMessageHandler();
port2.Open();
     
Console.WriteLine("Press Enter to Continue");
Console.ReadLine();
port2.Close();
 

Indigo marketing: playing with figures

OK, we all know the "ASP.NET 2.0 makes you new code 70% leaner - you won't even have to write so much code to have essentially everything in your web app" ... hm ... of course not. While I believe the magnitude of the mentioned figure might be correct (after playing with ASP.NET Whidbey a few times) it is just for the most common tasks, obviuosly.

And now Steven VanRoekel, from the Microsoft Web services marketing team, takes this basic idea and states in an interview that Indigo will tremedously reduce the number of lines of code you have to program to achieve your goal - well, I guess I do not need to comment on that. Every serious developer should be able to handle this statement on its own. I do not want to talk along the lines of  "Just trust the statistics you forged yourself" :-D - but more a bit of apples and peas ...

''If you got Visual Studio .NET in February 2002 to write that application -- we've done these tests -- it can take roughly 60,000 lines of code,'' he said. ''Using our WSE add-on tool, it takes roughly 12,000-13,000 lines of code to ensure security and reliability. With Indigo, it's one line of code. You basically just declare in your code 'make this confidential,' and we do all the heavy lifting behind the scenes through abstraction to secure it with the right protocols.''

Anyway, fact is indeed, that Indigo is all about productivity, yes!

Sometimes WS security is not WS-Security

As Hervey points out there are two flavros of Web serivces security base specifications. The one we all know is called WS-Security and is used widely by different vendors (such as Microsoft, BEA, IBM, ...).

Now with the advent of the final version of the WSE 2.0 Microsoft will completely switch to the new and revised OASIS WSS release - which of course is based on the former. That obviously means that for the next months we will see some problems in interoperability. As I much like to use IBM's ETTK for interop with the Java world I guess I have to come to a viable solution for that ...

Interoperability of ADO.NET typed DataSets with Java

WSE-like functionality for the .NET Compact Framework

The wonderful Casey Chesnut did it again. This time he surprises the Web services world with /spWse (call WSE from .NETcf). He follows the idea that if Microsoft is not going to give us what we really need - well, then we will do it ourselves :-)

This is my WSE library for the .NETcf including WS-Routing/WS-Addressing, DIME, WS-Security (Xml-Encryption and Xml-Signature). Includes a SmartPhone WinForm that calls the WSE2 samples as a unit test.

Kudos, Casey.

Indigo and MSMQ

Again, an interesting posting from the Indigo newsgroup which I want to share. This time from Krish Srinivasan (Microsoft).

Indigo provides a QueueService component that you can compose into an
application. It provides basic queuing behavior and GXA protocol support.
You could extend this Queue Service to build your own or compose this into
your application like a data structure.
MSMQ will be built on top of the Indigo Queue Service. So you could address
MSMQ as a web service and talk GXA protocols to it.