REST and XML with WWSAPI

Question

I was able to implement REST and XML variants based on SOAP with WCF using

XMLServiceHostFactory. Here is the VB.NET code:

===========================================

Public Class XMLServiceHostFactory

    Inherits ServiceHostFactory

    Protected Overloads Overrides Function CreateServiceHost(ByVal serviceType As Type, ByVal baseAddresses As Uri()) As ServiceHost

        Return New XMLServiceHost(GetType(Service), baseAddresses)

    End Function

End Class

Public Class XMLServiceHost

    Inherits ServiceHost

    Public Sub New(ByVal serviceType As Type, ByVal ParamArray baseAddresses As Uri())

        MyBase.New(serviceType, baseAddresses)

    End Sub

    Protected Overloads Overrides Sub ApplyConfiguration()

        MyBase.ApplyConfiguration()

        For Each endpoint As ServiceEndpoint In Me.Description.Endpoints

            If endpoint.Name = "SereviceRESTEndpoint" Then

                Dim newBinding As New CustomBinding(endpoint.Binding)

                Dim webMEBE As WebMessageEncodingBindingElement = newBinding.Elements.Find(Of WebMessageEncodingBindingElement)()

                webMEBE.ContentTypeMapper = New XMLWebContentTypeMapper()

                endpoint.Binding = newBinding

            End If

        Next

    End Sub

    Public Class XMLWebContentTypeMapper

        Inherits WebContentTypeMapper

        Public Overloads Overrides Function GetMessageFormatForContentType(ByVal contentType As String) As WebContentFormat

            Return WebContentFormat.Raw

        End Function

    End Class

End Class

===========================================

Is this possible with WWSAPI?

Answer 1

Hello,

With the version of WWS that ships with Windows 7 and Windows Server 2008 R2, building REST services is not supported. You won't be able to build the services you have implemented with VB. At this point, WWS only helps with building SOAP based services and clients to SOAP based services.

Thanks,
Nikola

---

Nikola Dudar is the Program Manager for Windows Web Services API team. This post is provided "AS IS" with no warranties, and confer no rights. Use of any samples is subject to the terms specified at http://www.microsoft.com/ info/cpyright.htm

Answer 2

I believe I can develop these extensions - they will be just  a wrapper around SOAP. 
I needed to know about your plans.

One more question. Can we host WWSAPI server in IIS?

Thanks,

Constantine

Answer 3

Hi Constantine,

We do not provide direct guidance around hosting of WWSAPI services in IIS. There are several ways of hosting native code in IIS like ISAPI extensions for example. From WWSAPI standpoint, the service has to run as part of some process and the Service Host should be able to register listener on a specific URL address. As long as IIS passes the messages on this URL to the process where the Service Host runs, it should work.  I will find time later this year to look into this scenario and post some form of tutorial.

Thanks,
Nikola

---

Nikola Dudar is the Program Manager for Windows Web Services API team. This post is provided "AS IS" with no warranties, and confer no rights. Use of any samples is subject to the terms specified at http://www.microsoft.com/ info/cpyright.htm

Answer 4

Hi Nikola,

If WWSAPI services can be hosted in IIS, this will give a quick migration path 

for WCF services and also a functionality not otherwise possible.

Let me share some of my experience creating web services (>5 years, >30 ASMX
and WCF web services) for a well established company.

What was most important from customers' point of view related to WCF:

1) Running in IIS compatibility mode was important because only that way 

we can get the IP address of the caller. This combined with CustomerID

adds the functionality for relating the CustomerID and customer license

tied to IP address.

2) Multiple end points are confusing to them. One end point is very easy to 
explain and deal with internally.

3) We had a big problem related to http and https. With ASMX by default

hosted in IIS getting https functionality is as easy as adding an "s" to http

and it is transparent. With WCF there is no other way but to add a different 

end point. Customers are asking why they need to handle this on client side.

It was easier before. In this case the company decided to have only https

which solution is a compromise.

4) I created REST, XML, SOAP versions all based on SOAP. Recently a big customer

using SAP needed integration. It turned out SAP was not implementing the SOAP

standard right and they made a patch. During the time they released the patch ( 2 weeks)

I offered the customer to try REST. He made and tested his application for one day!

For comparison he was running in a loop with SAP implementing SOAP right for three months.

One day rather three months is not exaggregation. Finally after SAP issuing the patch 

I asked them to test the SOAP version. It worked fine but told us it will go with REST.

5) The perofrmance of WCF being based on .NET is not good no matter what you do.

6) Web.Config configuration is very easy to deal with and maintain.

REST was easy to implement based on SOAP with above mentioned extension I wrote.

SOAP is easier to develop and maintain because there are very good MS tools.
REST is easier to work with, you can use it from the browser for a quick test, and intgrate it

easy too.

Bottom line - the pattern I followed SOAP as a basis, REST and XML as extensions

proved good. 

In my opnion WWSAPI is the right solution from performance stand point. In order to have a

success it needs IIS hosting, REST functionality and configuration possibilities similar like

Web.Config in WCF. These to be an option is someone needs them.

Best Regards,

Constantine

Answer 5

Thanks for sharing for your thoughts! We will consider this information in the planning for the next version.

Thanks,
Nikola

---

Nikola Dudar is the Program Manager for Windows Web Services API team. This post is provided "AS IS" with no warranties, and confer no rights. Use of any samples is subject to the terms specified at http://www.microsoft.com/ info/cpyright.htm