August 2004 - Posts
At least, this is what the download page states ... really?
Let's test it. If you can report improvements in this area when installing the Microsoft .NET Framework 1.1 SP1, let me know. This should also affect the WsContractFirst tool.
Thanks.
Note: the other interesting links on the download page currently do not yet seem to work.
Announcing the next version of thinktecture's Web services contract-first tool, WsContractFirst v0.3
UPDATE: I uploaded a revised version September 1, 2004 - small bugfix for the XML comments feature!
NOTE: Get the download at the end of this article
Maybe some of you know that I am a big believer in contract-based Web services design and development. Web services contracts can be expressed explicitly in .NET code (see Steve's opinion) or by using schema (XSD) and WSDL. When using the second approach you may want a tool that can generate .NET code from your WSDLs/XSDs.
The .NET Framework's and Visual Studio .NET's intrinsic tools somehow don't cut it, sorry.So, did you ever want 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. Our add-in for Visual Studio .NET 2003 automatically determines the project's programming language and accordingly generates source code (currently C# and VB.NET are supported).
New Features in v0.3 (compared to v0.2):
- More 'intuitive' GUI (e.g. default button, tooltips on controls etc.) - well at least for an angle brackets guy ... :)
- If you right-click on a WSDL file in project you can choose 'Generate Web service Code...'
-
- If you right-click on a project you can choose 'Choose WSDL to implement...'
-
- And then there is still the Tools menu item 'Web service Contract-First...'
- Can add an external WSDL to the project and generate code based on it. Just enter the URI of the WSDL into the textbox
- Can mark classes as [Serializable]
- Can generate collection-based members instead of arrays
- Comment propagation from WSDL into proxy classes
- Can enable automatic validation of incoming SOAP messages on service side (by using a custom SoapExtension)
- Saves configuraton form settings
- Some few bug fixes
This is the dialog you will be presented when choosing one of the above described options to enter the contract-first path in VS.NET:
This is the description of each option in the configuration dialog (from left to right, top to down):
- The location of the Web service message and interface contract (WSDL). Can be a URL or file location.
- Enable this if you want to generate consumer-side proxy code to consume a Web service based on the WSDL.
- Enable this if you want to generate code for a service-side Web service facade based on the WSDL.
- Check this to get public properties in your data classes instead of public fields.
- Check this to get runtime serializable data classes.
- Generates collection-based members instead of arrays.
- Check this to enable Web service endpoint configuration in a .config file.
- Check this to get read-only access to the actual SOAP message in your client code.
- Enables XSD-based validation on incoming SOAP messages
- Please enter the name of .NET proxy file that gets generated.
- Please enter the name of .NET namespace for the client proxy.
- Please enter the name of .NET service facade file that gets generated.
- Please enter the name of .NET namespace for the service code.
- Save dialog settings for future use.
When done, you will hopefully see this message when clicking the 'Generate' button ...
Feel free to leave any comments, flames, or rants here.
Special thanks to all testers (too many to list here ;)).
Download: Get it here (ca. 260 KB)
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.
Today I got inspired ;)
Just listened to Keith Ballinger (Keith, your blog is dead ...?) talking about WSE 2.0 - it was good and fun and he showed some live coding samples. OK. But there is always some 'toy factor' with those demos. They are hosted in command line applications or maybe in a Windows Forms app to show how powerful SOAP messaging can be. But we all know that in many cases - if not all - it is very important to have a good, a rock solid process model for your applications. When we do production-ready applications with Web services facades then we really need a good place where all this runs - and do not want our customers to have to run command line apps.
No, I do not want to stress on the various different options of available hosting models and technologies on the Windows platform. Don Box did quite a good job on that.
But, I think there is one really good hosting model you can leverage for this: COM+. Not talking about using the services COM+ offers, like transactions, security et. al. Just the fact that COM+ is a mature and good technology with a good process model (whatever you want to understand by 'good' here).
So I wrote a small and very simple sample for this scenario. Let's take the famous StockService project from the WSE 2.0 Quickstart samples, just for convenience. We are especially interested in doing WSE-based SOAP messaging based on TCP. We do not talk about extending ASMX with WSE, we want 'true' messaging capabilities. Therefore we use a SoapService-derived class for our Web service.
[SoapActor("soap://StockService")]
public classStockService : SoapService
{
[SoapMethod(http://Stockservice/StockQuoteRequest)]
publicStockQuotes GetStockQuotes(StockQuoteRequest message)
...
Now, in order to being able to host a WSE-based Web service inside COM+, I decided to let the COM+ server application run as an NT Service. This NT Service is the host process for the Web service with COM+ delivering the process model and thus we do not have to care about the nasty scalability, robustness issues we would have to implement manually, otherwise.
Obviously, we need a piece of code in order to actually start-up and register our WSE-based Web service so that service consumers can send messages to our endpoint. This is achieved by implementing the IProcessInitializer interface. The WSEShim class is soley there to properly set up all needed COM-related information so that our DLL may be registered with COM+. There are no public methods and we surely do not want to open up our actual service methods (like GetStockQuote) by connecting to the component via DCOM - all we want is SOAP messaging over TCP, fine.
public classWSEShim : ServicedComponent, IProcessInitializer
{
EndpointReference endpoint = null;
public void Startup(objectpunkProcessControl)
{
Uri via = newUri("soap.tcp://" + System.Net.Dns.GetHostName() + "/StockService");
Uri address = newUri("soap://StockService");
endpoint = newEndpointReference(address, via);
SoapReceivers.Add(endpoint, typeof(StockService));
}
public void Shutdown()
{
SoapReceivers.Remove(endpoint);
}
}
As a last step, register the DLL as a COM+ app (regsvcs.exe) and start the COM+ NT service and off we go: a WSE-enabled SOAP messaging service hosted inside COM+, with a powerful process model.
Thanks to my friends Dariusz, John, and Benjamin for discussing this topic.
If you ever had the chance to use a tool to generate .NET code inside Visual Studio .NET from a Web services interface and message contract (aka WSDL & XSD) that offers the following features in addition to this) - would you actually use it?
- More 'intuitive' GUI (e.g. default button, tooltips on controls, correct tab order) - well at least for an angle brackets guy ...
- If you right-click on a WSDL file in project you can choose 'Generate Web service Code...'
- If you right-click on a project you can choose 'Choose WSDL to implement...'
- And then there is still the well-known Tools menu item 'Web services Contract-First...' - Can add an external WSDL to the project and generate code based on it.
Just enter the URI of the WSDL into the textbox
- via HTTP (be suprised what happens when entering something like '.asmx?wsdl' ...)
- via file system - Can mark classes as [Serializable]
- Can generate collection-based members instead of arrays
- Can enable automatic validation of incoming SOAP messages on Web service side (by using a custom SoapExtension)
- Saves configuraton settings
- Some few bug fixes
Let me know ...
Yes, now you have a good time viewing the traced WSE 2.0 messages - whether they flow over HTTP or TCP or ... OK, a version 1.0 - but very amazing. Simon did it and uses the standard WSE tracing feature to put up a nice GUI.
There is also another, but rather limited (when it comes to transports) tracing tool from Mike.
Expect more by the end of next week. Some good testers are currently busy. Thanks.
Simon Guest has some invaluable Top Ten Tips for Web Services Interoperability. Don't ask - do it! (At least some of these points may render redundant with .NET 2.0).
Microsoft's SharePoint now speaks WSRP (Web Services for Remote Portlets). Very important step based on a spec not too many people know or even care about.
WSRP version 1 defines a web service standard (interface and semantics) that allows for the "plug-n-play" of content sources (e.g. portlets) with portals and other aggregating web applications.
Part 1: The Web services empire strikes back - Introductory thoughts
Part 2: The Web services empire strikes back - Inner Workings
Part 3: The Web services empire strikes back - Web Services in Visual Studio 2005
Part 4: The Web services empire strikes back - WS-I BP Conformance
Part 5: The Web services empire strikes back - Custom XML Serialization
Still a few to go ...
This one seems just like a small improvement, but I am sure a lot of developers will clap hands now. When having a Web service that exposes a method for querying, let's say, the status of a certain order, then it eventually will describe this order status information with a custom schema called OrderStatusInfo. At a later stage there might be a new Web service for placing orders from potentially any client application. This Web service will take an order and return information about the order status. As we already have an OrderStatusInfo schema we want to use this one, not a newly generated one.
When we now use wsdl.exe or the 'Add Web Reference...' dialog to add both services to any consumer application in order to create a proxy implementation for the services, we will get an error. The following command
wsdl.exe /out:Proxies.cs http://localhost:780/OrderService/OrderEntry.asmx?WSDL http://localhost:780/OrderService/OrderStatus.asmx?WSDL
will produce the following error when the WSDL either contains or references the exact same OrderStatusInfo schema.
Error: Cannot add service description with targetNamespace='http://msdn.microsoft.com/demos/Orders': schema with targetNamespace='http://msdn.microsoft.com/demos/Orders' already present in the description collection.
That's fine, that's correct.
But what happens when we build two separate proxies for the two services? Then a new proxy implementation file would be generated for each service as expected, but so would another OrderStatusInfo representation. This prevents the client from utilizing an instance of either one of the CLR representations with both services.
In order to enable a feature called proxy type sharing in our generated proxy file, we can use a new switch on the wsdl.exe tool:
wsdl.exe /out:ServiceProxies.cs /shareTypes http://localhost:780/OrderService/OrderEntry.asmx?WSDL http://localhost:780/OrderService/OrderStatus.asmx?WSDL
This will result in one file called ServiceProxies.cs which contains the proxy implementations for the OrderEntry and OrderStatus information as well as one single .NET representation of the OrderStatusInfo schema. Voila.
And please notice: this feature is not meant to share types between services and classes! We do not want to break one of the tenets of service orientation.
Looking for some good tools and samples to solve your .NET or Web services-related problem? The independent Microsoft Regional Directors (RDs) might help you with this list:
Regional Director Code Samples
Ah, you are asking what an RD is? No problem, my friend and fellow RD Clemens Vasters has a nice description of what RDs are and how they can help you.
More Posts
Next page »