Mitch Denny asks whether anyone would like to see some Indigo content at Code Camp Oz. I reckon this would be great and am particularly interested in:
Currently I’m working on building a .NET API for connectivity into a SCADA system first developed in the late eighties. The server side runs on Solaris, SCO Open Server, Linux and Windows 2000/2003/XP. The implementation approach stays away from the RPC style and instead takes an asynchronous messaging approach to maximize performance and utilization of bandwidth. The design was influenced by reading the Enterprise Integration Patterns book. The key concepts were that communications are a Conversation between multiple parties and that the stack in RPC style comms is being used a store for conversation state. This lead to a realization that the program stack is so heavily ingrained as a concept in my mind, that I didn’t realize it was holding back my way of thinking about distributed systems.
Personally, I think the distributed objects approach still has plenty of legs even with all the SOA work going on at the moment. Its just a matter of finding an easy way for application programs that use distributed objects to not be hampered by using the stack as a conversation state storage mechanism and still be usable with other APIs that rely totally on the stack for their operation e.g. UI APIs, database APIs etc. Put in other words an “asynchronous distributed objects” direction is much more palatable to my sensibilities than the SOA direction.
The whole conversation/stack investigation and thought process has lead to the modeling of a Conversation as a base class in the application design mentioned earlier in this post. The application has specialized classes for long running application specific conversations and also a general purpose RequestReply specialization of a Conversation. The request/reply conversation is used for simple short application conversations where round-tripping doesn’t affect the application usability. The approach has worked very well so far, but the implementation is still in it’s infancy.
Getting back to the Indigo discussion, I’m currently skeptical with the whole SOA approach because it may end up just being RPC with angle brackets for the broad development community. The really interesting part of Indigo for me is the prospective of a clean attribute/annotation driven API and an easier way to implement heavily asynchronous systems easily. How asynchronous applications can be easily implementated using Indigo/SOA is the missing part of the puzzle for me at the moment.