Thursday, November 10, 2011

Mostly immutable

I have had the "pleasure" of working with BizTalk on a few projects now.

I will save my general impression of Biztalk for another post. This is just to mention a undocumented side effect in BizTalk.

One of the key things in BizTalk is that all messages are immutable. I have found this to be mostly true.

In the following Message_1 and Message_2 are messages and should be immutable (except for in the block that constructs them)

Variable_1 = Message_1;
XmlSplitter.GetSFPage(Variable_1,0,2);
Message_2 = new System.Xml.XmlDocument();
Message_2.LoadXml(Message_1.OuterXml);



Message_1 is constructed elsewhere and yet we are able to change it by loading it into an XmlDocument. the above code is XLANG and I think it's a bug that the first line of code does not clone the message.

Wednesday, June 15, 2011

Token based credit cards

Like so many others I have an account on the playstation network. I also have accounts on iTunes and on Amazon. What these services have in common is that they save you credit card information on their servers so you don't have to type them every time you need to buy something from them.

This makes it very easy for users to buy stuff from them once the users are logged into their systems. This design however has some serious flaws. A problem is that all the informations needed to withdraw money from your credit card is registered on each service provider. You have more or less handed out a master key to your bank account. Online trade is based on trust and although I do trust these sites not to misuse my creditcard details, they are just managed by humans and are therefore not perfect.

What I would like to see is some kind of token based credit card for the internet. For any site that would like to persist my credit card information I could create a token that they could use to withdraw money from my credit card in the future. This way I could remove their access to my credit card without closing the card entirely. If the token was compromised I could see from which site they got it.
If the tokens included knowledge of the site it was to be used with, it would also be possible for banks to invalidate all tokens issued for a specific site such as Playstation Network.

I just think the current creditcard technology on the net seems a bit outdated.

Friday, April 08, 2011

XPath - fixed!

As you might have read in my previous post, I'm not too happy about the way the XPath works with namespaces.

To make things better I have created some regular expressions that will allow me to write XPaths the way I want to write them and still have them work with real XPath engines out there. It makes the XPath ignorant towards namespaces that are not defined in my XPath query. Namespaces that are defined in my XPath query will be handled like before.

if(!xpath.StartsWith("/")){
xpath= "./" + xpath;
}
xpath = Regex.Replace(xpath,@"/(?[\w]+)\[","/*[local-name()=='${node}' and ");
xpath = Regex.Replace(xpath,@"/(?[\w]+)","/*[local-name()=='${node}']");

PS. I'll get back to the post and tidy the code up later

Saturday, April 02, 2011

namespace mismatch

Once in a while you come across technologies that on their own are great, but put together are painful. Either you just live with the pain, you deselect one of the technologies or you try to improve the way they interact. This is the case with namespaces and xml/xpath.

Let me just explain that I am a big fan of XML and of XPath and XMLSchemas. They are related and work quite nicely. The schemas describe the data structure and can be used for validation. The XML is the datastructure and XPath is the query language for searching in the datastructure. Together these are very powerful.

Over the years I have heard a lot of people complain about XML, but often they are using it for the wrong purpose, they don't know the power of XPath to assist them or they are drowning in namespaces and prefixes in their xml documents.

Namespaces in xml are introduced to allow cross references across schemas and thereby allowing reuse of schemas. Every namespace, other than the default namespace, is given a prefix. For loosely structured documents this enables the writer of the XML document to specify on every single element, in what namespace it is defined. A good example of that is the XSLT documents. Here prefixes helps the writer of the xml validate only the elements that are part of the XSLT transformation logic. For this purpose namespaces and prefixes are great.

What I generally see with custom xml structures however is that the structure is more strictly defined and name clashes are less likely.

If I were to define the way xml and xsd would work with namespaces I would make the namespace prefixes optional on xml nodes where type and namespace could be derived from its placement in the structure. If the schema eg. only allows for one type of "address" element at a given location, why should I specify what type of address element it is? Only where name and type clashes occur would I demand namespace prefixes.

Namespaces should be treated as metadata of elements. They are just for validation and identifying the type of an element where name clashes could occur. For everything else they are irrelevant.

That brings me on to XPath and namespaces. Namespace information is metadata as far as XPath is concerned and you have to ask for the details if you want to use it in the query. It's a different story with prefixes. Actually the prefix is part of the name you can search for. This makes absolutely no sense as prefixes are only valid within a single document, and a the next document you receive might have other prefixes but be just as valid. The impact is that you have to make your XPath queries quite verbose to ignore the prefix and it really is a painful experience. If I could redesign XPath, I would make XPath ignore the prefixes of elements to be the default behaviour. Actually I don't see where anyone should use the prefix knowledge in a search.


Tuesday, January 18, 2011

When descission makers are clueless

It's a well known fact that you don't have to know anything to make a descision. Not knowing anything really speeds up the process of descisions and in some cases the descisions are just as good. In some cases they come with a price of being worthless or even disasterous.

When you don't know about what you are to descide upon a common aproach is to seek advice by somebody that know something about the subject.

Clueless descissions are most destructive when done in higher management because the consequences are often bigger. This includes politicians that are elected to make descissions. In Denmark there have rescently been some bad examples of such descissions regarding IT.

  1. Descissions about open document standards. Politicians kept OOXML in the loop although there was a better alternative that was more open at that time.
  2. NemId was chosen as the new authentication for citizens of Denmark when communicating with the goverment. (about taxes and stuff). I have used it and its work nicely from the end users point of view. The problem with the solution is that is uses certificates with public/private keys...  The private keys are placed on a centralized server. They have broken basic security principles and I think that is a problem.
  3. Rejsekortet is a new way of paying for public transportation. To do this they implemented their own encryption algorithm. The system has not been put into production yet, but the encryption algoritm has already been broken.
  4. Digital elections. Computers can be used for almost anything else. Elections part of a democratic proccess is not part of what computers can be used for. Pure electronic elections don't support recounting of votes and tampering with all votes can't be guarenteed. Elections of less importance, with truely trustworthy third parties can be implemented. Everybody has a interest in a democratic election and there is no trustworthy part that can ensure that the votes are not tampered with. It has been decided by politicians that electronic elections will be tried out.

Dynamic method binding

One of the added features to C# 4.0 was dynamic objects. It gives late binding to C# so everything doesn't have to checked at compile time. In some cases this makes it a lot easier to use reflection as you don't have to use any of the .net API's to do so. You can act directly on the object as if you had the type at hand. All you need to know is the footprint of what you need to access. Most examples emphasize how this can be used when integrating with other technologies like old com objects etc, but I have been looking for usages outside that scope. One is ofcourse reflection, another one is dynamic method binding that I will try and explain.

Basic OO with cats and dogs.



I create the traditionel object structure to support me explain what I mean. Animal is a pure abstract concept, Cat is an Animal and so is Dog.

Make the animals make som noise
I have created a MakeSound method that operates on the interface and one for each of the classes. As there is no general sound that will match any animal I just print ????? to the screen when in the context of Animal.
What I want is to have a list of animals containing cats and dogs and then call the MakeSound for each animal in the list.
As in C# < 4.0
The big question is what method is actually called. The answer is that the method binding is done at compile time, the best match is the method that takes the interface as a parameter. All the objects are treated as of type Animal. This is the way it has always worked in C# and it should therefore be no surprise if you have been in a similar situation. The output is as follows.

Result of program with static method binding

Use of var keyword

With C# 3.5 the var keyword was introduced. One might think that this changed the way this would work as the programmer no longer defines the type and the framework should therefore be able to select a better method implementation automatically. The answer is that the var is just a way to have the compiler derive the type instead of the programmer. This is all done at compile time and the best match will therefore still be the method that operates on the interface.

Handle the objects as dynamic instead
The dynamic keyword was introduced with C# 4.0 and this changes the possibilities when writing code like this. When treating every object in the list as a dynamic object, the compiler won't bind to any method but will leave it to the runtime to make the connection. This means that the type of every object is considered and handled on its own and the items in the list won't nescesarily result in the same method being called. This can be very usefull when iterating tree structures etc. The downside is that you will have no intellisense and no compile time validation when writing the code.

As the best methods are now called, the output will be cat and dog specific.

Output when treating the objects as dynamic
This can definately clean up some of my code. I might write a comment along with the code so that people in the future can figure out my intentions.

Related posts:
Wrapping objects with interfaces
Dynamic duck typing in .Net 3.5