In today's post:

1. Check out this post that announces availability of the final version of WWSAPI runtime for Windows XP, Vista, Server 2003 and Server 2008. This version corresponds to the one released in Windows 7 and Windows Server 2008 R2.Please make sure to regenerate all code using the new version of wsutil.exe tool. You will also need to rebuild all source code that used any of the pre-released versions of this API.
2. To develop for the final version of the runtime, you need to install Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1. Check out this post on the Windows SDK team's  blog to learn more about contents of the SDK, which help you with development of applications and services that use WWSAPI. Check out the Learning Path for WWSAPI to find links to materials that help you to start with using this API in your product. More links to other resources available to you are on the Connecting C and C++ code with web services page on my blog.
3. I would like to use this opportunity to share with you my plans for Windows 8. I am shifting my focus to another project and I will not be working on Windows Web Services for Windows 8. You may still get an occasional reply from me or a response to your questions on the forum. However, most likely someone else from the Windows Web Services team is going to reply to you in the future.

This is all news for today. Start on updating your prototypes to the RTM version of down level installers. I am looking forward to talking to you about Windows 8 when the time is right.

Nishant Sivakumar has put together a great article describing how to use WWSAPI to build native code clients to WCF services and how to implement web services in native C++ code using WWSAPI. You may find it on code codeproject.com. Thanks Nish!

If you had a chance to attend my talk during TechReady9, you may find below the links to the content I have mentioned during the talk. Thanks everyone for great questions, all feedback and comments. Looking forward to chat with you more and dig deeper into how Windows Web Services can help your customers.

• Videos of past talks and tutorials, http://channel9.msdn.com/tags/WWSAPI/
  • PDC 2008 is an introduction level talk with architecture overview and detailed walkthrough steps required to build a native code client to a web service, http://channel9.msdn.com/pdc2008/PC01/
  • Building native code client and web service is step by step tutorial of how to use WWSAPI for these two tasks. Both videos cover steps necessary for the Server platform. For example, they talk about opening ports that are blocked by default on the Server platform.
• Hao has several posts on his blog about WWS -> WCF interop for different bindings. Here are the direct links to some of the posts that I have mentioned.
  • WWSAPI client to WCF service that uses BasicHttpBinding
  • WWSAPI client to WCF service that uses WSHttpBinding
  • WWSAPI client to WCF service that uses WSFederationHttpBinding
  • WWSAPI client to WCF service that uses NetTcpBinding
  • WWSAPI client to WCF services using HTTP header authentication and WSHttpBinding or BasicHttpBinding
• I have also mentioned the demo that shows performance advantages of native code only web services over a web services built with WCF that uses P/Invoke to native code. You can find instructions on how to build and use this demo in this post.

If you have any other questions, just shoot me an email and I will answer them for you. Thanks again for stopping by and I hope you have liked the session. Please do not forget to fill out evaluation and provide me any feedback you may have on how I could make the session better.

For sometime I thought that I should post a native code sample of a client code to Exchange Web Services. After all, we have used WSDL for EWS to tune wsutil.exe and test interoperability during developement of WWSAPI. I have even built a prototype but never had a chance to finish it. However, after this post on forums by steve_olivier with a sample of WWSAPI based client, I do not think there is much left for me to show in an example. Thanks Steve! If you are interested in building native code clients to EWS, check out this discussion on the forum and let me know if you have any issues. Just add your questions to the discussion on the forum or comment on this post. 

 

You can now find two more videos on building both client and service in native C/C++ code on Windows Server 2008 R2. There are on the channel 9: http://channel9.msdn.com/tags/WWSAPI. The videos show step by step creation of a client and a service from the sample I used during TechEd 2009. You can find source code for this sample with instructions on how to build it here. Try it out and let me know of any comments.

Updated on 10/01/2009 - This version is not available anymore.

Windows Web Services API Release Candidate is now available for Windows XP, Windows Vista, Windows Server 2003 and Windows Server 2008. The table below summarizes level of Service Packs and CPU architectures supported by the Release Candidate:

Same as the Beta, this release is available in four languages: English, German, Japanese and Arabic. You can download the installers from http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=18901.

To develop code using this version of the runtime, you will need Windows SDK for Windows 7 RC. Please try this version and let us know how it works for you.

Thanks everyone for attending the session on building web services in C++ code during TechEd 2009! I greatly appreciate all your questions, comments and suggestions. Please fill out the evaluation of this session if you have done this yet. To evaluate this session, open Session List page, search for DTL311 session. Once the search finds the session, find on the page "Evaluate this session" button. Clicking on this button will open up very small questionnaire. If you have time, please provide any comments on the session in the edit box also.

A copy of the presentation is available here. You can find instructions for setting up the demo and the source code for the demo in this post. You can find the video recording of this talk here.

During the talk, I have mentioned the upcoming dev lab. Several of you have asked me for details. The lab will take place on May 19-21 as part of "Enterprise Network Solutions" virtual lab. You can find more information about the lab in this post.

Lastly, you can find links to all online resource available to you for building web services and clients to web services in C and C++ code on this page.

Thanks again for attending the session and for your comments and suggestions.

Tracing in Windows Web Services uses Event Tracing to let you know about what happens inside the WWS runtime after your code calls into the API. Tracing is available on all versions of Windows we support (XP, Vista, 2003, 2008 and 7). In case of Windows 7, once you install Windows 7 Release Candidate and Windows SDK for Windows 7 RC, you can use tracing to troubleshoot communication issues in your applications that use WWS.  Traces are logged for major events like entry and exit into Ws*() function; any runtime errors including SOAP faults; start and completion of any I/O and SOAP messages sent and received (not available on Windows XP). There are three levels of tracing. In verbose mode, the runtime saves traces for all events. In Info mode, it only saves informational traces such as start and completion of I/O. In error mode, only errors are logged. Windows SDK for Windows 7 RC contains a batch script called wstrace.bat. This batch file provides a convenient way to:

• Create and delete a trace log
• Enable and disable tracing
• Update the tracing level (info/error/verbose)
• Converting trace logs to CSV files

A typical sequence of commands for collecting traces is as follows:

1.     Run Windows SDK CMD Prompt as administrator.

2.     To create trace log run the following command. The third parameter indicates the mode of tracing you are going to use. In the example below, I set Verbose mode.

> wstrace.bat create verbose

3.     Enable tracing

> wstrace.bat on

4.     Start dumping of tracing messages to a file

> wstrace.bat dump > C:\Temp\wwstraces.csv

5.     Switch to your application and run your scenario

6.     Switch to the command prompt and press Ctrl+C. This should stop tracing and wstrace batch file

7.     Turn off tracing

> wstrace.bat off

8.      Delete tracing log

>  wstrace.bat delete

Once you are done, you can open .csv file in Excell. Each event trace is saved in one row. You can sort by process ID to separate events from different clients and services. The logs are usually self-explanatory and they should point out the root cause of an issue.

To learn more about tracing options available to you, run wstrace.bat without any commands. It will print out all different options supported by the tracing. Check out this section in MSDN documentation for more details on tracing and commands for wstrace.bat. Try it out and if you have any feedback, please leave comments or ask questions on the forum.

You have probably already noticed that Windows 7 Release Candidate became available earlier this week. To continue using Windows Web Services on Windows 7 Release Candidate, you need to download Windows SDK for Windows 7 RC. It is available in ISO and Web Setup format.  Web setup allows you to install a specific subset of the SDK you select without having to download the entire SDK. ISO setup allows you to burn a DVD that will install the entire SDK.  There are three ISO images available for different the CPU platform x86, x64, or Itanium. However once you install the SDK with either of three ISO images, you can build applications that target any of three CPU platforms. 

If you have already built a code using Windows Web Services API from Windows 7 Beta, you have to be aware that the team has made several breaking changes. The easiest way to migrate your code is:

1.      Regenerate all .c and .h files from WSDL and XSD files using the RC version of wsutil.exe

2.      Rebuild all your code using the new generated code

The changes you need to make are minor and mostly around type of the parameters. If you have not been using the generated code, please watch after similar changes in types and function signatures also. If you need any help or have any questions, please just leave comments on this post or ask questions on the forum.

There is one very helpful feature available for you in the RC that deserves a special attention. The RC version of the WWS Runtime fully supports tracing. In my next post I will outline how to use tracing.

For some time I was planning to put together one page with top resources available to developers to start using WWSAPI. Yeasterday I have finally found time to do it. Here it is:

http://blogs.msdn.com/nikolad/pages/connecting-c-c-and-web-services.aspx

I will keep updating this page with new resources as they come online. At some point, something similar should appear on MSDN.

I came across a great post from Dan Driscoll in which he outlines which stacks are available on Windows for building web services. He is absolutely right in describing the purpose of all 4 stacks available and it worth of quoting him. Here are 4 stacks available on Windows with my comments on each of them:

• Generic Web Services Stacks
• Windows Communication Foundation (WCF) is for building web services and clients using managed code (C#, VB, etc). It is for developers who use managed code in developing their products
• Windows Web Services API (WWSAPI) is for building web services and clients in native C/C++ code and for avoiding introduction of a dependency on .Net Framework for this task.  It is for developers who prefer to or have to use native C/C++ code in their products. The goal for this API is to enable native code developers to connect their code to web services in most if not all scenarios available to managed code developers.
• Specialized Web Services Stacks
• Web Services on Devices API (WSDAPI) is the one-stop shop for building applications around Device Profile for Web Services or WS-Discovery.  It is for developers who use any of these three technologies and work with devices. 
• Windows Remote Management (WinRM) is implementation of WS-Management Protocol that allows hardware and operating systems, from different vendors, to interoperate. It is a set of tools and scripting API for IT professionals who write scripts to automate the management of servers and ISV developers who build management applications.

As you can see, there is actually very fine lines between these stacks and developers who are expected to use them. Hopefully this makes this story more clear for you.

If you have started using Web Services API and building either clients to web services or web services in native code, here is an event where the product team that works on the API can help you. On May 19-21 there will be WWSAPI-specific "virtual lab" scheduled as part of "Enterprise Network Solutions" with Windows Server 2008 R2. As an attendee of this lab, you join the event using Microsoft LiveMeeting and you "bring" your code to the event by hosting a development configuration at your location. Then as you develop new features using Windows Web Services API, we are helping you with any issues you encounter while you use the API and it tools.

Below are some details of how this "virtual lab" is organized and list of requirements to participate in it. If you are interested, please use the Contact Form on Phil's blog to tell us more about your Windows Server 2008 R2 solution and to request more information.  

Who can participate in the lab?

This "virtual lab" is available primarily for registered Independent Software Vendor (ISV) Partners. The focus of this lab is only on solutions that leverage new features of Windows Server 2008 R2.   Note that this is not a traditional training event.  Your solution must use new features in Windows Server 2008 R2 like Windows Web Service API. There are a limited number of presentations, and hands-on-lab exercises are optional.  We expect all attendees to have a working knowledge of Microsoft Server technologies. You are also going to receive complementary preparatory materials. 

Agenda for the Virtual Lab

A Virtual Lab event takes place within "Virtual Rooms". Virtual Rooms are independent LiveMeeting sessions accessible within a specific schedule. The Main Room is where you and all other attendees gather for keynote presentations and open-forum discussions. The Lab Room is where all attendees obtain guidance related to optional Hands-on-Labs. The Chalk-Talk Room is where attendees interact directly with Microsoft Product Team members and Subject Matter Experts. The Project Room is where you and your team independently develop, build, and test your Windows Server 2008 R2 solution.

How to register?

If you are interested, please use the Contact Form on Phil's blog to tell us more about your Windows Server 2008 R2 solution and to request more information. If you are accepted, you will receive more details about how you can get ready for the lab.

If you have attended MIX 2009, you may already know that with Windows Azure Tools and SDK March 2009 CTP it is now possible to bring native C/C++ code onto the Azure Services cloud. If you are like me who was not at MIX 2009, you may find a compilation of links to interesting videos in this post. In addition, Cloud computing team has several posts on their blog that outlines this new CTP and answers basic questions around VS tools support for Azure services. Jim Nakashima has posted a detailed walkthrough for integrating native code into Web or Worker Roles. However at this point, you still have to use P/Invoke to integrate your native code with managed code that implements the rest of web and worker roles. But I think it should be possible to completely skip P/Invoke if you use Windows Web Services API and this is something I am planning to investigate in coming weeks.

If you speak Italian, there are two great resources to learn more about connecting your native C/C++ code and web services.

1. Raffaele Rialdi has started series of posts on his blog about how to use API for building both web services and clients to them in native code. He has presented the API in a session during Basta! Conference and Win7 pre-launch.
2. Mario Fontana has also posted very detailed step-by-step guides for building web services in C/C++ and clients to web services in C/C++. I also know that he has also built a very cool sample to demonstrate integration between a WWSAPI based native code client and a Biztalk Orchestration with SAP. I can't wait to see a post on his blog showing this demo.

So if you speak Italian, you can follow blogs of Raffaele and Mario to get updates on the API. Grazie e ciao!

If you are interested in learning more about Windows Web Services API and how to use them to connect native code and web services, here are the upcoming events for you.

1.       Microsoft Virtual TechDays for Developers take place on April 1, 2009. You can participate in an online meeting where we will look on how you can build web services and clients to them using WWS API. You can register for the session here. In this session, I plan to spend majority of the time on introducing the API and showing how to use it to build simple clients to WCF services and native code only web services.

WIN301 Building Web Services and Clients to Web Services in Native Code

In this session, we look into how you can use Windows Web Services API to connect native code to SOAP-based Web services. We discuss building both Web services that expose native code and native code clients to Web services. We drill down into how this API helps in building applications that take full advantage of the Microsoft software and services platform. We use Microsoft Visual Studio 2008 SP1 and Windows SDK for Windows 7 in all demos.

 

2.       Visual C++ Development Laboratory runs from May 4 through May 8, 2009 in the Platform Adoption Center  on Microsoft Campus. During the lab, Visual C++ team is going to help you with porting your code to Visual Studio 2010. At the same time, the team that works on WWS API can help you start using WWS API in your code. It is a great opportunity for you to meet the team in person. Space is limited and if you and your company are interested please go to this registration page to apply.

3.  Microsoft TechEd North America 2009 takes place in Los Angeles, CA from May 11 through May 15, 2009. I am also preparing a session for this conference. I am planning to spend 20% of it on introduction of the API and then show API in action for the rest of the time. This is session DTL311 with title “Connecting Native Code and Web Services Using Windows Web Services API”.

 

I am looking forward to meeting you at these events and helping you to use the API in your products.