Navigation

Search

Categories

On this page

AOP and Enterprise Services
Some Avalon info
VS.NET and side by side issues
Language Interoperability: A Plea for an Open Mind
Trust and Global Service Registries
Developer Lifestyles
Encoding Problems
XHTML 2.0 Moving Along
Time Zone Headaches

Archive

Blogroll

Disclaimer
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: 20

Sign In

# Wednesday, February 5, 2003
AOP and Enterprise Services
Wednesday, February 5, 2003 9:37:33 PM UTC ( Enterprise Services )

Once again Clemens has been down in his secret underground lab working on some new and exiting enterprise services enhancements. This time he has cooked up a way to write AOP style serviced component extensions in the same brilliant manner we have grown accustomed to. From the looks of it his framework is designed to provide AOP through interception techniques. Giving developers the ability to write these kinds of extensions is indeed a huge and very important improvement to the existing serviced component architecture.

The ability to effectively separate crosscutting concerns is extremely important in modern software designs. Security, adaptability and runtime tuning, monitoring, validation and physical tier independence are some of the areas where one might want to apply these techniques.

This sort of functionality has been on my wish list for some time now, and I can’t wait for the bits to come out.

Comments [0] | | # 
# Monday, January 27, 2003
Some Avalon info
Monday, January 27, 2003 6:06:59 PM UTC ( Avalon )

Bryan Little blogs about some info Franci Penov (Microsoft) posted about Avalon and Longhorn.

It is different as programming paradigm and prowides a lot more features than the current Windows Forms. It should be used instead of Windows Forms for native Longhorn apps.

I'm really looking forward to finding out more about this framework. I'm not usually excited about GUI technology, but Avalon seems very interesting ;)

Comments [0] | | # 
# Sunday, January 26, 2003
VS.NET and side by side issues
Sunday, January 26, 2003 8:20:10 PM UTC ( General )

Andreas Eide blogs about side by side issues with VS.NET 2002 and VS.NET 2003.

So, I have this project developed in Visual Studio .NET 2003 that I want to use at the customer site. At first I only needed the executables, so I set up Visual Studio .NET 2003 to compile to v1.0.3705 of the framework. This worked just fine. But now I want to use the source code at the customer site. I can’t open the VS.NET 2003 solution with VS.NET 2002. It says that the file is not a valid solution file. And I have found no way in VS.NET 2003 to save the solution in 2002 format.

This got me thinking about an article I read over at www.codeproject.com, so I did a quick search and found this tool; A Utility to Convert VS.NET 2003 Project Files.

Even though it is fairly annoying not being able to do a test compile of your current solutions without converting all the solution, project and resource files, this tool may be able to help ease some of the pain.

Comments [0] | | # 
# Tuesday, January 7, 2003
Language Interoperability: A Plea for an Open Mind
Tuesday, January 7, 2003 4:07:45 PM UTC ( General )

At the risk of relighting an old debate I feel that I need to type down a few thoughts on the topic of .Net language interoperability. Over the last couple of years I’ve been in countless .Net discussions, and quite a few of them have at one point or another touched this specific topic. Either it is a Java supporter claiming that this feature is effectively useless and will eventually create chaos or the never ending debate about whether C# or VB.NET is the wave of the future. This over-discussed yet underappreciated topic has none the less inspired me to publish a slightly different point of view.

I feel that a large part of the people I talk assume that language interoperability is all about making the right decision about what general purpose programming language to use, or if you read the marketing slogans; not making that decision at all. And I guess in a lot of cases it probably is. Yet it seems to me that one of its most appealing opportunities is effectively ignored.

The interesting thing about language interoperability is, in my opinion, not about making a choice between general purpose programming languages, but rather about all the cool special purpose languages that are or will be available. Today we have a regular expressions compiler, and soon we will probably have a XSLT compiler. Then we will most likely have the database languages, the reporting languages, the mathematical and scientific languages and of course the process and abstract state machine languages. And all of these different compilers will transform their various input formats into verifiable and easily accessible IL modules.

To me this is the true beauty of the language interoperability feature. It provides you with the opportunity to utilize languages that are designed to greatly simplify specific tasks, and then effectively integrating these languages with the general purpose programming language of your choice. This is what makes me hit the download button every time I see a new managed compiler. And quite honestly, whether you choose MC++, C# or VB.NET to do your work is no longer exiting or refreshing conversation material.

Comments [0] | | # 
# Monday, December 30, 2002
Trust and Global Service Registries
Monday, December 30, 2002 6:50:08 PM UTC ( Architecture )

When talking about service oriented architectures we basically talk about three fundamental pieces. There is a service consumer that queries a service registry or a service broker for a set of service providers that meet a set of supplied criteria. The service consumer then selects the preferred service based on a set of preferences, and the required operations are performed on the selected service.

The interesting thing about this is the fact that the industry has launched the vision of a global service registry where one could organize and resolve services using some sort of global taxonomy. Even though this approach might work for the most rudimentary of services what is increasingly interesting is the fact that their visionary samples tend to touch the area of B2B commerce. As most procurement managers know, one of the most important aspects of any supplier selection process is to establish a reliability level. When you find a supplier that satisfies your requirements you set up a trade agreement to ensure that the reliability level is agreed upon and maintained. You establish a trust relationship. The thing is that I fail to see how this is going to work with a global registry of supplier-like services. Where is the negotiation phase that is designed to establish a working business relationship with an implied two-way trust?

My point here is by no means to undermine the importance of a service broker or a service registry when it in fact is a hugely important part of any service oriented architecture. It will play an important role in making your application both pluggable and highly interoperable while effectively enforcing a much needed level of abstraction. But a successful registry has to be filled with a set of pre-approved services from a set of suppliers that the customer has established a healthy business relationship with. Providing such a private registry service makes perfect sense in any B2B architecture. Trying to solve the complexity of a negotiation phase in a machine readable service contract doesn’t.

Even though the industry is starting to address this issue, and somewhat shifted the focus towards local registries, I still see the oversimplified idea of a global registry in both technical writings and vision documents. Hopefully we will all accept that there is a reasonable complexity involved in streamlining current business processes.

Comments [0] | | # 
# Friday, December 27, 2002
Developer Lifestyles
Friday, December 27, 2002 6:21:48 PM UTC ( Security )

Keith Brown (Mr. Windows Security) has written an interesting piece about developer lifestyles in relation to security. Definitely worth a read!

Comments [0] | | # 
# Friday, December 20, 2002
Encoding Problems
Friday, December 20, 2002 8:25:07 PM UTC ( Blog )

I’ve been having some encoding problems with my RSS stream. There seems to have been some disagreement between my RSS generator, my web server, some RSS consumers and UTF-8. Hopefully it’s working better now.

Thanks to my friend Clemens for the heads up!

Comments [0] | | # 
# Wednesday, December 18, 2002
XHTML 2.0 Moving Along
Wednesday, December 18, 2002 9:14:33 PM UTC ( General )

The HTML Working Group has released the third Working Draft for XHTML 2.0!

All we need now is for Visual Studio and Internet Explorer to officially support XHTML versions 1.0 and 1.1 ;)

Comments [0] | | # 
Time Zone Headaches
Wednesday, December 18, 2002 8:43:54 PM UTC ( Architecture )

Globalization has never been an easy aspect of any development project. Lately I’ve been evaluating the requirements needed to serve users from different time zones, and at first sight this appeared to be a fairly manageable task. After all it’s just about storing all your dates in UTC time and then adding or subtracting the time difference to get the users local time. Or so it seemed…

First of all, there is no nice way of retrieving the local time zone from the user’s browser, short of using Passport and forcing the user to share his or hers time zone information. So, the user will have to choose the time zone he or she wants to use, and I guess the time zone support is worth the extra seconds spent during user registration.

Then, I entered the domain of the DST (daylight savings time/ summer time) monster. At first I thought it would be fairly easy to find a standard for this, or that Windows or the .NET framework would be nice enough to provide me with the necessary functionality.

The .NET framework does not, to my knowledge, support the ability to have different time zones attached to different threads, like they have with CultureInfo. But Windows 2000 does have a function that allows me to convert a given UTC date to a specific local time zone, just as long as I supply the time zone information; UTC offset and DST information. And it’s even possible to extract this information for every registered time zone from the Windows Registry. It’s not elegant, but it should work as long as I inserted the time zone conversion in the user interface layer. And I could even write my own .NET TimeZone implementation.

This could have been the end of my problems, but of course it wasn’t. As it turns out DST settings tend to vary between countries, and sometimes between regions within the same country and time zone. And to top it off, it varies from year to year. I’m not talking about fairly deterministic things like the last Sunday in March, but more like the time when Sydney had special DST settings during the Sydney 2000 Olympic Games and the fact that several countries, including Norway, decided to ignore DST for several non-consecutive years. I guess that is why Microsoft decided to releases a time zone editor for Windows. At least I can find comfort in the fact that the European Union has created a DST standard, but it doesn’t help historic dates much though.

So, I guess the only way to handle this problem is to create a time zone for each different combination of DST settings and UTC offsets, and collect all the relevant time zone information in a large table. I was hoping it wouldn’t have to come to that :(

Comments [0] | | #