On this page

Enterprise Services and Exceptions
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



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

# Thursday, February 13, 2003
Enterprise Services and Exceptions
Thursday, February 13, 2003 7:07:27 PM UTC ( Enterprise Services )

Andreas Eide and I have been playing around with serviced components and custom exceptions, and so far we have discovered some interesting results.

I have a test-setup running Windows XP SP1 and the .Net Framework v1.0 SP2. I have created a serviced component and configured it to run in a server activated application. The component implements the test interface below and uses no configuration attributes. I have a client application that invokes all of the interface methods and each of the method implementations in the component simply throw the same custom ApplicationException derived exception.

The interesting thing is that three of the methods return the application exception while the last two return the custom exception to the client.

public interface ITest
  int Test1(); // ApplicationException
  object Test2(); // CustomException
  void Test3(); // ApplicationException
  void Test4(object o); // CustomException
  Guid Test5(DateTime dt); // ApplicationException

I guess what is left now is to figure out why this happens, and I guess there are quite a few things to consider. Does it have anything to do with reference objects vs. value objects being passed; does it have anything to do with the shared memory buffer sometimes used by LRPC? What is obvious though is that there is a difference in the way exceptions are marshaled across processes.

What is obvious though is that there is a difference in the way exceptions are marshaled across processes. It seems that in some cases IErrorInfo and Marshal.ThrowExceptionForHR does its magic and in other cases the entire exception object is marshaled transferred.

Comments [0] | | # 
# 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, 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] | | #