On this page

C# samples and BCL type names
Asynchronous Messaging is Dangerous
Messaging is hot
A small sign of life
Enterprise Services and Exceptions II
Messenger and Paranoia
Enterprise Services and Exceptions
AOP and Enterprise Services



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

# Saturday, April 5, 2003
C# samples and BCL type names
Saturday, April 5, 2003 8:32:27 PM UTC ( General )

Brad Adams asks an interesting question regarding code samples and whether to use the native type names of the programming language or the more generic BCL type names.

My view on this is that once you choose to write an example or a code snippet in a specific programming language for whatever reason; you should adapt all of the features of that language. Both with regard to coding style, custom type names and special constructs (for instance the using statement in C#).

As of today both VB.NET and C# have pretty much the same language features, but if we look to the future we can see that the C# language is evolving (generics, iterators, anonymous methods, partial types). And I assume that VB.NET will evolve to better suit its users much in the same way. And more languages are coming. As the language differences increase it will start to look somewhat unnatural if you ignore its features, as I believe the type keywords to be.

In my experience most C# programmers are using the C# specific keywords and not the BCL types, I know I do. I guess I’m getting a weak pseudo code feeling when I see the use of BCL types in samples.

If you want to write generic examples that appeal to all user groups you should probably use a pseudo language, and I guess that’s not really a tempting options. If you have made a language decision, then use the language in a way that its users are most familiar with. Make the code samples feel natural, and appeal to their sense of best practice.

I guess this is a bit wider than the original questions, but I just wish there were more using statements in C# samples…

Comments [0] | | # 
# Friday, March 28, 2003
Asynchronous Messaging is Dangerous
Friday, March 28, 2003 11:30:36 PM UTC ( Architecture )

Messaging as an application design pattern has been around in enterprise applications for decades, but recently it has been getting a lot of community press as web services are starting to roll out and service oriented architectures are climbing the preferred design ladder.

One of the most interesting aspects of a message oriented programming is the inherent ability to approach an asynchronous design. Yet, for some reason the transition from synchronous operations seem to be very hard. I suspect that it is not necessarily the added technical complexity, but rather the fear of loosing control that is the primary obstacle. Now that we are moving towards factoring our systems into services this is a situation we must learn to master.

Looking at the way business transactions are done today, and the way they have been done for ages, we can easily see that quite a few of them are asynchronous. Either it is a matter of message exchange via regular mail, fax, e-mail or some messaging product like Microsoft BizTalk Server. When for instance a user compiles a set of requests into an order with a procurement system the transaction is committed long before the order has reached the supplier, or even before the order has left the procurement system. In this particular scenario we are used to an asynchronous interaction, and it is indeed the only way.

Keeping in mind the before mentioned example it is strange that we seem to be unable to apply the same pattern within our own applications. I guess to some extent it is because we feel that we are the masters of our own system and that we have the ability and the right to perform synchronous operations, and that we should do so either to uphold consistency or to provide accurate and immediate user responses. Just because we can!

Even though a synchronous design may provide you with the comforting feeling of control, as business processes become more complex and the amount of users increase this will prove to be a troublesome preference. As we start refactoring our applications into services and begin to enjoy the dynamic nature of GXA it will be unreasonable to except a synchronous processing pattern for a variety of different reasons; some concerning processing time, load balancing, transactional boundaries, internal system restrictions and manual processing tasks just to name a few.

I guess what I am saying is that we need to learn to let go, to be able to trust individual part of our own systems as well as external systems and embrace the black box nature of services. It’s important to note that asynchronous messaging is in no way synonymous with unreliable messaging. If we are able to do this then at least the fear of loosing control may fade away, and I guess the immediate user response is a user education problem.

Comments [0] | | # 
# Wednesday, March 26, 2003
Messaging is hot
Wednesday, March 26, 2003 5:40:53 PM UTC ( Architecture )

The blog community is discussing message oriented programming, service oriented architectures, and of course SOAP and RPC. It’s great to see so many smart people seeing the potential of these emerging architectural principles!

And for what it’s worth; I’m in the messaging camp!

Comments [0] | | # 
# Tuesday, March 25, 2003
A small sign of life
Tuesday, March 25, 2003 7:22:19 PM UTC ( General )

It has been some time since my last update. I guess there isn’t much to say except I’ve been really busy trying to combine downhill skiing with a lot of research and work. On top of that I’m squeezing in time to complete a couple of slide decks about message oriented architecture and GXA in dynamic environments.

Comments [0] | | # 
# Saturday, February 22, 2003
Enterprise Services and Exceptions II
Saturday, February 22, 2003 8:37:32 PM UTC ( Enterprise Services )

Tomas agrees with me that the exception irregularities found when using Enterprise Services are indeed interesting, and asks for clues. I have yet to find any, but I would be very surprised if it wasn’t related to the marshalling services.

After doing a series of tests I’ve found that all basic types (integer, string, decimal …) that probably have some optimized marshalling code introduce the exception problem, but as soon as you add a custom type to the method signature, either it is a value or reference type, the expected behavior takes place.

If I find the time I’ll try to delve more thoroughly into the problem area. This situation is really annoying and I have yet to see any documentation or discussion about the problem. Makes you wonder…

Comments [0] | | # 
# Thursday, February 20, 2003
Messenger and Paranoia
Thursday, February 20, 2003 7:51:03 PM UTC ( General )

I came across SIMP (Secway's Instant Messenger Privacy) from [email protected] here the day. It is a small utility designed to secure your MSN Messenger conversations providing both encryption and authentication services, and best of all it is free for both home and business use.

Usually I’m not a very paranoid person, but I enjoy privacy technologies as much as the next guy and this product is definitely worth a try.

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