Navigation

Search

Categories

On this page

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
Some Avalon info

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

# 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] | | # 
# 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] | | #