On this page

WSE: Compression Filters Update
SQL Server 2005 Beta 2 at MSDN Subscriber Downloads
SQL Server 2005: CLR Hosting – Establishing Balance
WSE and Plumbwork Orange
Mono 1.0 Hits RTM
Mono Roadmap Updated
Enforcing Xml Schema Validation
Consolidating some WSE efforts



The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

RSS 2.0 | Atom 1.0 | CDF

Send mail to the author(s) E-mail

Total Posts: 83
This Year: 0
This Month: 0
This Week: 0
Comments: 5

Sign In

# Wednesday, July 28, 2004
WSE: Compression Filters Update
Wednesday, July 28, 2004 6:21:46 PM UTC ( Tools | WSE )

I released some sample code for a WSE compression filter a few months back, and I have recently updated the code to be more in tune with the look and feel of the WSE extension model.

Since the initial release, I have submitted the code to the Plumbwork Orange project on GotDotNet. If you are looking for the most up-to-date version then that is definitely the place you would want to look. I have also made a snapshot of just the compression code available for download here.


This SOAP compression extension is an implementation of an idea by Martin Valland and me, and it is in no way an official specification controlled by a standards body.

This is a prototype implementation and it comes without warranty of any kind.

Comments [0] | | # 
# Monday, July 26, 2004
SQL Server 2005 Beta 2 at MSDN Subscriber Downloads
Monday, July 26, 2004 3:48:38 PM UTC ( SQL Server 2005 )

SQL Server 2005 Beta 2 Developer Edition is available for download at MSDN Subscriber downloads. Go fetch ;)

Comments [0] | | # 
# Wednesday, July 14, 2004
SQL Server 2005: CLR Hosting – Establishing Balance
Wednesday, July 14, 2004 2:30:06 PM UTC ( Architecture | SQL Server 2005 )

I’ve seen a lot of posts about the CLR Hosting support in SQL Server 2005, and quite a few of them discuss the possibility of moving business code into the SQL Server engine. I think it is time to establish some balance here, and I’m going to throw in my 2 cents.

CLR Hosting has a few obvious use cases, but it is in no way a replacement for T-SQL. If you are writing extended stored procedures then this is definitely the only logical way to go. It has a much better and safer programming model than the native one. If you are writing complex algorithms that can severely limit your result set then it is probably a good idea to put that into the server as well. T-SQL stored procedures that have massive amounts a non-dataset related code like encryption, conversions and extensive string manipulations could probably benefit from being completely or partially turned into managed CLR functions.

If you on the other hand are writing classical dataset manipulation and selection procedures, then T-SQL is a language that is highly optimized and specifically designed for just that purpose. You should keep in mind that managed stored procedures still use T-SQL to interact with the relational database engine; look at some code samples!

If you take a step back, you will see that you are making a decision about when it makes sense to utilize the database server processor over the application server processor. Clearly, application servers are a lot cheaper and usually a lot easier to scale out. At the end of the day, in any well designed distributed architecture, the database server is going to be your bottleneck. It would probably make sense to keep whatever processing you can away from that precious resource.

However, if you are using an algorithm to determine what records to return to the client, and you expect that it may severely limit the amount of records returned to the client, then it probably makes sense to put it on the database server. Returning 2GB of data to the application server, and then filtering away 98% before returning it to the client may be a massive waste of resources. You’ll have to make an informed tradeoff decision.

There are no absolute rules, but you will need to evaluate every single case for yourself. My advice is to stick with the way you’ve been writing applications with SQL Server 2000 and keep the T-SQL stored procedures the way they are. At least then you will know that whenever you utilize managed code in the SQL Server, you’ve made a conscious tradeoff rather then blindly following the ever popular anti T-SQL movement. Regarding business logic, keep it on your application tier where it has been living so happily over the last few years. Once again, if you do decide to move it to the SQL Server make sure it you’ve made a well informed decision that works with both your application and your business requirements.

Leave your defaults the way they are; it’s an evolution not a revolution.

Comments [0] | | # 
# Saturday, July 10, 2004
WSE and Plumbwork Orange
Saturday, July 10, 2004 8:31:29 AM UTC ( WSE )

For those of you using the Microsoft Web Services Enhancements 2.0 or my WSE “WS-Compression” filters it is time to look at some very interesting developments in that area.

Over the last few months, I have been participation in a GotDotNet project aimed to provide free implementations of important WSE based infrastructure. You will find everything from WS-protocol implementations to helper classes, examples of WSE extensibility features and prototypes if some interesting ideas

With strong WSE personalities like John Bristowe and Christian Weyer heading up the project this is definitely something that carries a lot of potential.

Drop by the project workspace at GotDotNet!

Comments [0] | | # 
# Thursday, July 1, 2004
Mono 1.0 Hits RTM
Thursday, July 1, 2004 8:57:49 AM UTC ( General | Mono )

Mono, an Open Source implementation of .Net finally makes it to its first release, the big version 1.0. After years of development it’s nice to see the progress they’ve made.

Congratulations to the team.

Comments [0] | | # 
# Wednesday, April 28, 2004
Mono Roadmap Updated
Wednesday, April 28, 2004 6:56:42 PM UTC ( Mono )

The mono team has put up an updated roadmap for the mono project.

Beta 1: May 4th - Feature Complete

Beta 2: June 1st

Mono 1.0: June 30th

I guess this means that if they stay on track we will have a fairly stable multiplatform CLR and BCL this summer. The mono platform still lacks several critical enterprise features, but it is interesting to see what they have accomplished so far.

Comments [0] | | # 
# Sunday, April 25, 2004
Enforcing Xml Schema Validation
Sunday, April 25, 2004 3:26:08 PM UTC ( General )

Validating xml documents is one of the more common tasks when building extensibility points, integration infrastructure or enabling configuration support. The .Net Framework provides a type called XmlValidatingReader to help you with this task. There are however a few pitfalls you should be aware of if you want to be certain that an xml instance conforms to the provided xml schema.

Always Define a Validation Event Handler

The xml validation system uses severity levels to indicate the level of validation failure. There are two severity levels available; namely XmlSeverityType.Error and XmlSeverityType.Warning. The interesting thing is that unless you specify your own validation handler only the severity level of XmlSeverityType.Error will cause an exception to be thrown; all warnings are ignored.

This may not seem like a big issue until you realize that “missing schema for provided type” is a warning and not an error. Therefore, unless you have a schema loaded for the xml instance namespace, anything goes.

When you provide your own validation handler, you can intercept both severity levels and act accordingly. A simple default could be to throw the exception provided within the ValidationEventArgs parameter, as you will see in the sample below.

Always Specify a ValidationType

The default ValidationType is ValidationType.Auto, which means that unless you have provided a schema for the instance namespace, it will assume ValidationType.None and no validation takes place.

If you are using Xml Schemas, you should set this to ValidationType.Schema.

In Conclusion

The common theme here is that vanilla validation only works if you happen to have the same namespace in your xml instance and xml schema documents. Unless your application explicitly checks the namespace of the xml instances it processes, you could easily submit whatever xml document you wanted as long as it uses a different namespace than what the schema expects.

You will find a code snippet below that incorporates this advice, and hopefully gives you some ideas on how to address these issues in you code.

Code Snippet

static void ValidationHandler(object o, ValidationEventArgs args)
 throw args.Exception;

static void Validate(XmlReader reader, XmlSchema schema)
 XmlValidatingReader validatingReader = new XmlValidatingReader(reader);
 validatingReader.ValidationEventHandler += new ValidationEventHandler(ValidationHandler);
 validatingReader.ValidationType = ValidationType.Schema;
 while (validatingReader.Read());
Comments [0] | | # 
# Friday, March 5, 2004
Consolidating some WSE efforts
Friday, March 5, 2004 10:54:47 PM UTC ( WSE )

There seems to be quite a few WSE extension projects out there. Some of them implement custom transports, some implement custom filters and some implement public specifications.

Perhaps we should consolidate our efforts and set up a project on a public server like the GotDotNet workspaces. Create a Genghis for WSE if you will.

Just a thought ;)

Comments [0] | | #