Yukon Web Services
Hmmmm, sounded interesting and I walked inside. The session basically talked about the new HTTP services available right out of the box in SQL Server. This technology is basically an alternative to SQLXML. Note that I'm using the word alternative and not replacement, since I think SQLXML has many capabilities that Yukon Web Services does not have. Bascially, this feature uses the new HTTP.SYS kernel mode driver of Windows Server 2003 and thus, you would need Windows Server 2003 to utilize this feature. It is also planned to be provided along with Windows XP Service Pack 2. That definitely cuts out checking this thing on my laptop... :-(
Basically, T-SQL extensions have been added to allow the creation of end-points, which can expose services. Users can access these services via the WSDL that is automatically generated by these end-points. Once its SOAP enabled, there is then no dearth of clients that can make use of this feature. You can execute either stored procedures, or UDF's or ad-hoc SQL using this new feature and then get the results returned either as well known types (for functions since they have a return type) or as an array of objects (mainly for stored procedures since you cannot deterministically say what the stored procedure will return). Queries can be sent either over plain HTTP or over SSL and you can provide authentication for the user who is accessing the service. Errors from the code are handled as SOAP exceptions and you can also pass in parameters into the web service. You can also control the WSDL that way you want by providing a stored procedure that laid down the format of the WSDL. This feature is currently not there in the PDC bits, but will be added in RTM.
From the demo and the features that were shown, there are many issues that I find with this new method. These are my current thoughts and they can change once I wet my hands on this technology.
- SQLXML supported the use of templates that helped provide a level of abstraction for query execution to the user. Templates were basically XML files that laid down the input and the ouput requirements of the query.
- SQLXML also allowed you to specify schemas that let you control the way the XML was generated out of a call.
- One of the main tenets of having SQLXML at a higher abstraction from SQL Server was to allow scale-out scenarios in situations wherein the web-service is used by many clients. Since the new web service feature is hosted directly into SQL Server, there is no information on scalability and performance for large user loads. For example, what would happen if the terra server or the sky server (see my earlier posts regarding these terms) were hosted on Yukon web services?? Interesting exercise....
- From a web service and security point of view, I'm personally scared of exposing my SQL Server directly, since it is now on the onus of the server hosting this and SQL Server to protect itself against denial of service attacks and other hacks. Ideally database servers are embedded much inside of an enterprise...
- SQLXML as an abstracted service allowed Microsoft to play around the XML capabilities of SQL Server without affecting the relational engine. Now with the integration of this into SQL Server, handling product updates and keeping pace with future standards might force a build of the entire server.
- Most of the things shown in the demo are things that are achievable through SQLXML itself and it was not very apparent as to the highlights of this method.
Overall, this method may be useful for scenarios where we want direct access to SQL Server, but I'm not sure as to how people might take advantage of this feature. More needs to be tested and worked upon in this area for me to arrive at a proper conclusion and possibly take back some of my initial apprehensions :-)