Welcome to MSDN Blogs Sign in | Join | Help

 

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:

 Windows Version

Service Pack

x86

x64

ia64

Windows XP

SP3

Yes

Yes

No

Windows Server 2003

SP2, R2 SP2

Yes

Yes

Yes

Windows Vista

SP1

Yes

Yes

No

Windows Server 2008

SP1

Yes

Yes

Yes

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

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.

I have seen several questions about how to fill out a binding template for CreateServiceProxy(). Here are two examples which I believe should help you with this task.

In the first example, I increase the size of messages allowed for the client to send to the service. To do that the code changes the corresponding channel property for a channel that the Service Proxy is  going to use.

// defining the desirable maximum size for messages
ULONG maxMessageSize = 2147483647;

//changing a channel property
WS_CHANNEL_PROPERTY channelProperty[1];
channelProperty[0].id = WS_CHANNEL_PROPERTY_MAX_BUFFERED_MESSAGE_SIZE;
channelProperty[0].value = &maxMessageSize;
channelProperty[0].valueSize = sizeof(maxMessageSize);
WS_CHANNEL_PROPERTIES channelProperties;
channelProperties.properties = channelProperty;
channelProperties.propertyCount = 1;

// filling in out the template with the new channel property
WS_HTTP_BINDING_TEMPLATE templateValue = {};
templateValue.channelProperties = channelProperties;

// creating Service Proxy using the changed binding template
hr = WSHttpBinding_IArraySort_CreateServiceProxy(&templateValue,
                                                 NULL, 0,
                                                 &serviceProxy,
                                                 error);

In the second example, we provide a username and a password from the client to the service. We start from creating a User Credential structure that later on passed to the binding template. Username and password will be send to the service on a call to its operation.

// declare and initialize a username credential
WS_STRING_USERNAME_CREDENTIAL usernameCredential = {};
usernameCredential.credential.credentialType = WS_STRING_USERNAME_CREDENTIAL_TYPE;
usernameCredential.username.chars = username;
usernameCredential.username.length = wcslen(username);
usernameCredential.password.chars = password;
usernameCredential.password.length = wcslen(password);
// declare and initialize a username message security binding
WS_HTTP_SSL_USERNAME_SECURITY_CONTEXT_BINDING_TEMPLATE templateValue = {};
templateValue.usernameMessageSecurityBinding.clientCredential = &usernameCredential.credential;

// Creating Service Proxy using template fucntion generated from the metadata
hr = WSHttpBinding_ICalculator_CreateServiceProxy(    &templateValue,
                                                    NULL, 0,
                                                    &serviceProxy,
                                                    error);

These two examples demonstrate the general approach. There are 13 binding templates in the API listed here. They all can be filled in using the similar approach. Give it a try and if you have questions just post them as comments to this post.

I have uploaded the solution I have been using during MVP summit to demonstrate Windows Web Services API. This solution demonstrates three things:

  1. Using WWSAPI, it is possible two build both clients and web services completely in native code.
  2. Both clients and web services built using WWSAPI can interoperate with WCF based clients and web services and exchange data between them.
  3. Avoiding managed-native code Interop when it comes to presenting a native code computational engine as a web service can have significant performance advantages. In this demo, the native code wrapper of the native code computational engine is 4-6 times faster than managed code wrapper because of the cost of managed-native code interop.

You may download the solution from MSDN Code Gallery page located here. This sample has one solution with five projects.

  1. SortLibrary
    1. This is a native code DLL with two exports that both WCF and WWSAPi based services will call.
    2. First export is a function that implements InsertionSort algorithm. This represents one of the best possible cases of managed-native code Interop. InsertionSort is one function call that takes byte array. There is minimal cost of marshaling and managed/native context switch.
    3. Second function implements QuickSort() algorithm. This represents the worst-case scenario for managed-native code interop. In this case, the algorithm asks its caller to implement a callback that the algorithm is going to use to compare elements. This results in very chatty interface between managed and native code. Of course, this significantly increases the cost of managed – native code interop in this case.
  2. Sort Service using WCF
    1. This is a WCF based service. It wraps Sort Library and allows remote callers to pass data to SortLibrary.DLL. Once SortLibrary.Dll returns back the sorted data, this service returns the data back to clients.
  3. Sort Service Host using WCF
    1. This is the host process that we use to launch the WCF service. Once started, it going to start Service Host object and the service is going to process request from its clients.
  4. Sort Client using WCF
    1. This is the client application build using WCF. Initially it is setup to talk to WCF service. However a small change to <endpoint address=http://localhost:8080/SortService ../> in app.config from http://localhost:8080/SortService to http://localhost:8080/FastSortService will redirect this client to talk to the service built in native code using WWSAPI.
  5. SortService using WWSAPI
    1. This is a web service built 100% in native code using WWSAPI. Similarly to SortService built with WCF, this web service wraps SortLibrary.DLL and enables remote callers pass data to SortLibrary.dll and returns the data back to them.
  6. SortClient using WWSAPI
    1. This is a native code client to both WCF and WWSAPI based services. Initially it is setup to talk to the native code service. However, with a small change on the line #66 in SortServiceClient.cpp, you can redirect this client to talk to WCF based service. To be specific,
      1. With this value of the URL, the client will communicate with the native code web service

        WS_STRING url = WS_STRING_VALUE(L"http://localhost:8080/FastSortService");

      2. With this value of the URL, the client will send data to the web service built in managed code using WCF

        WS_STRING url = WS_STRING_VALUE(L"http://localhost:8080/SortService");

To build this demo, you need to have Visual Studio 2008 SP1 with Windows SDK for Windows 7 installed on your computer. You can build it from Visual Studio or using command line script in the root folder of the demo. To build 32 bit version, run build_demo_x86.cmd. To build 64-bit version, run build_demo_x64.cmd.

To run this demo, you need to prepare your machine to run WCF samples using One-Time Set Up Procedure for WCF Samples. After you are done with this, you may start the demo using either launch_demo_x86.cmd or launch_demo_x64. Here what you should expect after you launch the demo:

  1. Two new command line windows should start on the background. One of them will print "SortService using WCF is up and running...". Another one will print "SortService using WWSAPI is up and running...". These are web services that clients going to access.
  2. In the command prompt window where you have launched the demo, the program will ask you to enter the name of the file. You can enter either big.txt or small.txt.

    Sort Client built using WCF is up and running

    Please enter the path to the file: small.txt

  3. The Client is going to send data to the service. Once it receives it back, the client prints out the amount of time this roundtrip took.

    >launch_demo_x86.cmd

    Sort Client built using WCF is up and running

    Please enter the path to the file: small.txt

    Type the number of the sort algorithm to use:

    0- Insertion Sort

    1- Quick Sort

    2- Both

    Your Choice >> 2

    Insertion Sort Total Time: 00:00:00.2808018

    Quick Sort Total Time: 00:00:01.2480080

  4. After that another native code client is going to start. Again enter either big.txt or small.txt:

    Sort Service Client built using WWSAPI is running...

    Please enter the path to the file: small.txt

  5. The Client is going to send data to the service. Once it receives it back, the client prints out the amount of time this roundtrip took.

    Sort Service Client built using WWSAPI is running...

    Please enter the path to the file: small.txt

    Type the number of the sort algorithm to use:

    0- Insertion Sort

    1- Quick Sort

    2- Both

    Your Choice >> 2

    Insertion Sort Total Time: 0.437 seconds

    Quick Sort Total Time: 0.312 seconds

  6. The demo will stop. You can now close two windows that represent the services by switching focus into them and clicking any button.

Please note that this sample is provided solely to demonstrate a possible use of the API. It is not meant to be a production quality code. It is provided are provided "AS IS" with no warranties, and confer no rights. Use of this sample is a subject to the terms specified at http://www.microsoft.com/ info/cpyright.htm. If you have any questions or comments on the demo, please send me your feedback.

Great news! The Beta version of WWSAPI for Windows XP, Windows Vista, Windows Server 2003 and Windows Server 2008 is available now on the Connect site for Windows Networking. This release contains the same version of the runtime as in Windows 7 Beta. It is available in four languages: English, German, Japanese and Arabic. You may find the table that summarizes level of Service Packs and CPU architectures supported by this release in this announcement on the WNDP connect site. Below is the list of direct links to pages from where you can download the installers that are part of this release. 

Windows Vista RTM and SP1 and Windows Server 2008 RTM and SP1, all languages.

X86 – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16646
X64 –  http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16648
Itanium – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16650

Windows XP SP2 and SP3

X86 English – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16651
X86 German – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16652
X86 Japanese – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16653
X86 Arabic – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16654

X64 English – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16662
X64 German – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16667
X64 Japanese – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16669
X64 Arabic – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16664

Windows Server 2003 SP2 and R2 SP2

X86 English – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16656
X86 German – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16658
X86 Japanese – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16659
X86 Arabic – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16660

X64 English – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16662
X64 German – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16667
X64 Japanese – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16669
X64 Arabic – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16664

Itanium English – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16670
Itanium German – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16672
Itanium Japanese – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16671
Itanium Arabic – http://connect.microsoft.com/WNDP/Downloads/DownloadDetails.aspx?DownloadID=16673

To report installation issues and runtime issues, please submit the feedback using http://connect.microsoft.com/WNDP/Feedback site. 

For reference documentation for the API, check out MSDN site http://msdn.microsoft.com/en-us/library/dd430435(VS.85).aspx.

To get answers to all questions about the API and this installer, please use http://social.msdn.microsoft.com/Forums/en-us/wwsapi/threads/ forum or comment on this post. I would be glad to answer your questions.

Several developers have asked me this question and I have decided to create one blog post with the answer. If you use Windows 7 Beta version of wsutil.exe, you would see that it might not generate _CreateServiceProxy helper function in some cases for services that use WsHttpBinding. In Beta, wsutil.exe would issue the following warning:

No supported policy setting was found in input metadata. No policy information is generated.

Hao has mentioned the root cause of the issue in one his posts about WWSAPI to WCF Interop. To reiterate, the root cause of the issue is that WWSAPI in the first version (Windows 7) does not support full message security mode. Same time, the full message mode is the default security mode for wsHttpBinding in WCF. To use WWSAPI to build clients to this service, you have to change <security> configuration setting of the binding from "message" to "transport" with appropriate user authentication setting. Here is an example of the change.

Before:

<bindings>

    <wsHttpBinding>

        <binding name="wsHttpBindingWithTransportSecurity">

            <security mode="message">

            </security>

        </binding>

    </wsHttpBinding>

</bindings>

After (note that you have to change clientCredentialType to a desired setting in your case):

<bindings>

    <wsHttpBinding>

        <binding name="wsHttpBindingWithTransportSecurity">

            <security mode="Transport">

                <transport clientCredentialType="SomeCredType"/>

            </security>

        </binding>

    </wsHttpBinding>

</bindings>

Also in RC version of wsutil.exe, we have changed the warning message to describe the root cause of the problem. Now wsutil.exe outputs the following for this scenario:

warning WSUTIL0089 No supported policy setting has been found in the input metadata. The service may be using a binding configuration non-supported by WWSAPI such as message security setting. See documentation for the list of configurations supported by WWSAPI.

Policy information is not generated.

I hope that this post helps you with troubleshooting this issue.

I have just learned that there is a video on WWSAPI at Channel9. Back in October of the last year, Yochay Kiriaty, Phil Pennington and myself got together to talk about the API. Yochay and Phil has come prepared with a long list of questions. I have tried to answer all of them. It was fun discussion. The delay in publishing the video was caused by an issue with the recording. Yochay was able to fix it recently and publish the video to Channel9. Check it out when you have time. If you have any questions, please let me know and I would be happy to answer them.
More Posts Next page »
 
Page view tracker