XML includes and getting data from external source.

When using XMLTextReader ever wondered how to read the include files. Recently I was stuck with a similar problem after much head scratching finally resolved it. Here is the code.

Ok I was trying to read an xsd schema and every time it included schemalocation I would get stuck so I decided to resolve it using  getEnity method.

 

Dim vreader As New XIncludingReader(" the url where the schema is")

Dim resolver As New XmlUrlResolver

Dim i As Integer = 0

Dim fur As Uri

Dim s As Stream

Dim xtext As StreamReader

Dim st As String

 

vreader.XmlResolver = resolver

     

If (vreader.Name = "schemaLocation") Then

   fur = resolver.ResolveUri(New Uri("….location"), vreader.Value)

   If Not fur Is Nothing Then

      ‘Ok going to get the data from the location

      ‘the beauty of this thing is if your location is on the file or in a url

      ‘it will resolve it fine.

      s = resolver.GetEntity(fur, Nothing, GetType(Stream))

      xtext = New StreamReader(s)

      st = xtext.ReadToEnd

      Console.WriteLine(st)

   End If

End If

 

Enterprise Architecture and Big Mac's

Last night lying in bed I had a thought...is Enterprise Architecture like a Big Mac, what is it we are really trying to do when we define an architecture. Create a set of rules and methods such that we don't re-invent the wheel every time we pick up a project but have an underlying framework that we can work with which will define consistent results. Now to that effect one company that has made consistency its main game is Mc Donald's with their Big Mac's. Now where ever you go in the world (mind you I have eaten at a few Mac Donald's around the world) the Big Mac always taste the same and it does not require a rocket scientist to make it either. So does this mean by if we were to define a framework for developing software and make all developers follow it with an iron will we will get consistently good quality software, Joel does not think so http://www.joelonsoftware.com/articles/fog0000000024.html . He says following recipes or Methodologies do not guarantee good quality software. Now I would agree with that to some extent to produce really good quality software you need good developers and mind you methodology or framework is no substitute for talent as many big consulting companies would have you believe otherwise. This would almost imply that software development should be done by talented people and every time you developed something it is ok to start fresh. To some extent this line of thought says software development is not engineering but an art form.

 

In my opinion software development is a mix of art form and engineering. Bridges which are built to laws of physics can still be pretty and functional, in this instance laws of physics form the framework on which bridges are build (also the civil engineering codes). Keeping to that we can define the rules to which software should be built sharing a common thread and knowledge pool. Such that what we build is not a chaotic collection of monolithic software but a consistent group of software each having its individuality yet sharing common thread of interoperability. So Architecture which defines enough to share and yet not constraint creativity is hard work...perhaps it may be the holy grail. I am still looking if anyone has found it please let me know.

Tracing Web Service calls

Got back from Germany yesterday and still getting over the jet lag. Saw a good post on Christians ( http://weblogs.asp.net/cweyer/archive/2004/08/19/217441.aspx ) web site on tools to trace web service calls, most of these were using WSE 2.0 to achieve this functionality. For the past year or so I have been using Fiddler http://www.fiddlertool.com/fiddler/ and must say I have not had any issues. The best features I liked with fiddler is the ability to capture a request modify and resend it. It is a cool tool if you are serious about web services. Defiantly worth a look see...

Visiting Germany

I am in Germany (Neuss near Düsseldorf) this week and flying back to Sydney on the weekend. Firstly I must say Lufthansa know how to take care of their frequent travellers and really go out of their way to may the trip nice. On my flight between Singapore to Frankfurt they bumped me up to business class I was not complaining :-) So it pays to travel with one airline all the time.

Focus on Problems vs. Focus on Solutions

I came across this story recently...how often are we the enterprise architects guilty of the same.....:-)

---

When NASA began the launch of astronauts into space, they found out that the pens wouldn't work at zero gravity (Ink won't flow down to the writing surface). In order to solve this problem, it took them one decade and $12 million. They developed a pen that worked at zero gravity, upside down,underwater, in practically any surface including crystal and in a temperature range from below freezing to over 300 degrees C.

And what did the Russians do.......................................??

The Russians used a Pencil !!!!!!!!!!!

---

One of the most memorable case studies on Japanese management was the case of the empty soap box, which happened in one of Japan's biggest cosmetics companies. The company received a complaint that a consumer had bought a soap box that was empty. Immediately the authorities isolated the problem to the assembly line, which transported all the packaged boxes of soap to the delivery department. For some reason, one soap box went through the assembly line empty. Management asked its engineers to solve the problem. Post-haste, the engineers worked hard to devise an X-ray machine with high-resolution monitors manned by two people to watch all the soap boxes that passed through the line to make sure they were not empty. No doubt, they worked hard and they worked fast but they spent whoopee amount to do so. But when a rank-and-file employee in a small company was posed with the same problem, did not get into complications of X-rays, etc but instead came out with another solution. He bought a strong industrial electric fan and pointed it at the assembly line. He switched the fan on, and as each soap box passed the fan, it simply blew the empty boxes out of the line.

Moral of the story: KISS (Keep It Simple,Stupid) I.e. always look for simple solutions. Devise the simplest possible solution that solves the problem :-)

---

Enterprise Application Development in .NET

I had recently posted the following comments on how well .NET or more specifically Visual Studio.NET supports enterprise space.

 

Recently in one of the discussions on Object Space I had posted regarding issues with .NET while developing Apps for the Enterprise. http://channel9.msdn.com/AddPost.aspx?PostID=6040

Then I thought the question I was asking is a bit more than object space hence the new thread. So guys (MS) how long before we have some of the functionality in .NET those Java App servers have (actually not similar implementation as I don’t agree with the way the App servers have been implemented). Also a few additional features like being able to build scalable distributed apps that can run in n-tier configuration without having to build all the infrastructure required. Support for Integration framework using Messaging be it XML or what ever format. Also will we be ever getting an Application server with support for some thing similar to Java Naming Service and so on.

At PDC I noticed that you had done a lot of work on Indigo which I loved and was upset as I wanted them now. Which brings me to my second question why is there such a tight coupling between OS and .NET framework. OS is there to provide a hardware abstraction and all the base services one would need to write software. Then on top you would need something like .NET which can abstract the OS differences to make our life easier. Keeping to that tune one would imagine all the Indigo stuff can be taken out and sold as a separate application server product which can run on any OS (I mean MS OS 2000, 2003). So why not do that and build an application server with all the indigo capability and ship it in next few weeks :-) I really don’t want to wait next 3 years for Longhorn to ship and be RTM'ed. By de-coupling .NET from the OS into an APP server implementation will ease the life of a lot of Enterprise Developers who don’t have to convince the Network Guys to change the OS just so we can use some nice features...you don’t know how hard that is.

The next post......

 

I was at the Object Spaces Presentation at PDC and would like to comment on a few things. Traditionally the MS programming model focused more on getting the developer to build solutions using existing MS products to marry them into a cohesive whole to solve an enterprise problem (this may or may not work all the time). Which is one of the reason why Enterprise Architects looked down on us poor MS-Oriented programmer (or MSOP’s), as our solutions were invariably constrained by the products that MS offered. Java with J2EE suffered no such constraints and offered what ever the J2EE APP Server offered. Having said that code portability among J2EE APP server went down the proverbial gurgler as functionality increased. The documentation on IBM's site to port BEA Web Logic to Web Sphere is over 300 pages long.

When .NET first come out it was a truly amazing (at least for me) platform and offered the enterprise developers a mechanism to break the product glue mentality. Then when I started using it, I found that it had all the features to do the job at least 90% of it. And the last 10% of the features it did not have took the 90% effort on my part. Also within the Microsoft developer community there is still a lot of focus on stitching products together and now instead of VB or C++ it is using VB.NET or C#.

 

At the PDC I did ask a few people about implementing the MVC controller pattern in ASP.NET and got varying answers but none solved the issue. The classic Model 2 pattern remains an enigma (No I don’t want to implement the UI application block), mind you it can be implemented if you change the rules a bit, but then some one said "if one makes enough assumptions one can hang an elephant by it's tail off a cliff". Next came the question of Container Managed Persistence (CMP) or Bean Managed Persistence (BMP) Object spaces would have solved CMP in a kind of way but not really so the performance hit of 50% was not something I was prepared to live with. BMP is there is a kind of way as long as we rolled our own.

Next came app servers and scalability using clustering. The one way I got around it was to use Lhotka excellent book on Business Objects. Which creates a kind of Object factory and a class in charge model using remoting. It takes sometime to do all the basic framework implementation as there is none provided by the framework. There is a possibility to implement clustering by having the remoting server on IIS with Windows Load Balancer. Again as in the previous post if only we had access to something like JNS (Java naming Service) all this would have been easier (Some may argue to use UDDI for the same purpose that comes with Windows 2003, it is not really the same).

The other challenge in Enterprise Systems is that the Business Rules change constantly and any implementation using if then structure are asking for trouble. I would love to have something like JESS (Java Expert System Shell) to write my rules in and have it compiled to .NET IL which inturn will work on the objects dynamically. Then when the rules change just recompile one component and hey presto..I had heard that guys at Sandia were thinking of porting JESS to C#. In my last email exchange with the JESS’s author he said J2EE is superior to .NET and he is sticking to it J http://herzberg.ca.sandia.gov/jess/.

This is my last peeve. In Visual Studio why is there no support for developing web services with contract first implementation. These days you have to first write a WSDL using XML Spy or something then use WSDL.EXE to generate the interface with /server switch and finally implement the abstract class. What a long winded way. Why not give developers the ability to develop the interface first and then the implementation. In a typical enterprise scenario you usually get the Interface contract before you can start implementing it. Also there is not support to write your own WSDL in VS.NET 2003 either (I mean a GUI front end).

There are a lot more peeves but I will stop now. But having said all this and having used JBuilder + WebLogic and tried hopelessly to do a good UI in java I would not trade .NET for anything. I would rather build what is not there in .NET than abandon the platform. I firmly believe within MS the change or awareness for Enterprise Systems has started and it is only a question of time....

Till then I will soldier on and hope some one is listening.