Archive for December, 2009
Entity Framework, IronPython and PODO’s – Can it be done? - Part 1
Let’s go on a journey that takes two interesting technologies that have been to date, confined to an interoperability argument that left them barely on speaking terms. Of course I am speaking figuratively but what I’m trying to convey here is that, languages built to run on the DLR are currently limited in ways that preclude them from working seamlessly with the LINQ based ORM technologies from Microsoft, namely the Entity Framework and LINQ To SQL. This of course does not mean that languages such as IronPython are stuck in some ADO.NET void, that is not the case at all. In fact if you want to check how to use ADO.Net Data Readers etc, from IronPython I suggest check out chapter 13 of IronPython in Action (in fact if IronPython is of interest I can highly recommend the book).
Before we continue lets touch on some background. An important part of getting IronPython entities working alongside the Entity Framework, required that the Entity Framework would be calling back into our IronPython code. In recent times, a new feature was added to IronPython 2.6 which accommodated this requirement. The __clrtype__ feature allows customization of the classes that constitute the underlying CLR types for IronPython classes. If you want to find out more about this you should read the series of posts by Harry Pearson on the subject.
So with a fistful of interest in the DLR and the dynamic languages built on it, I became curious about whether the new advances and features in the Entity Framework version 4.0 combined with the addition of __clrtype__ meta class for IronPython, would bring these two technologies any closer to working together. After some pointers in a recent discussion with Michael Foord, I was willing to bet that some form of interop between the two (EF and IronPython) would now be possible; I was gambling on the added support for POCO in the Entity Framework and the customising of CLR types generated for IronPython to provide the neccessary hooks to effectively create PODO’s (Plain Old DLR Objects) that would map successfully as Entity Framework entities. Here is what I was hoping a PODO might look like.
class Customer(object): __metaclass__ = clrtype.ClrClass _clrnamespace = “EntityFramework.Podo“ _clrfields = { “_customerId“:str, “_companyName“:str, “_contactName“:str } @property @clrtype.accepts() @clrtype.returns(clr.GetClrType(str)) def CustomerID(self): return self._customerId @CustomerID.setter @clrtype.accepts(clr.GetClrType(str)) @clrtype.returns() def CustomerID(self, value): self._customerId = value @property @clrtype.accepts() @clrtype.returns(str) def CompanyName(self): return self._companyName @CompanyName.setter @clrtype.accepts(str) @clrtype.returns() def CompanyName(self, value): self._companyName = value @property @clrtype.accepts() @clrtype.returns(str) def ContactName(self): return self._contactName @ContactName.setter @clrtype.accepts(str) @clrtype.returns() def ContactName(self, value): self._contactName = value
First up, I guess that in a pure sense this is not so compliant in the P part of PODO right? The Decorators on our functions do bleed out the technology a little but I am not going to let the goal get hung up on this point.
My initial thoughts also considered that with Code Only mapping I might be able to do away with any need to provide any supporting infrastructure code created in a statically typed language (C# or VB.NET).
In Part 2.0 of this series of posts we will start the journey in earnest and see what successes and hurdles we hit along the way. Rather than keep you waiting to find out whether this is all going to end well and keep you dangling under false pretences, let me just say that it partially works. The fact that it partially works gives me hope the rest of this series might help uncover or encourage a way to make these two technologies work together in a more complete way.
Language exploration odyssey – Concurrency
First time in a long while that a book purchase has been made by myself over the counter yesterday! I was compelled on a whim, a sudden urge took grip; and so it was that ‘Programming Erlang’ somehow made it’s way into my hands.
I sat down and started to read. Immediately I bought into the authors style and tone and before long my existing curiosity for the burgeoning wave of languages designed to address concurrency, seemed to suddenly have acquired a learning strategy. Start at the beginning I thought! Learn Erlang as a jumping off point for comparison with other languages designed to address this problem space. Ok I will also admit that my time in the Telco industry predicated me toward the choice just a touch.
Subjugating Temporal anomalies to satisfy software’s Prime Directive
Having just read one of Howard Dierking’s latest posts regarding how we reason about time when it comes to software, I am reminded about the benefits that one way messaging and publish / subscribe can bring to the table. It stands to reason that we all want our code to execute faster and our applications to respond to their users in a timely fashion; ‘slow’ is not a word users or developers alike want to hear when discussing or describing their systems. Howard’s post is a discussion that came out of his reading a book by Steven Seow titled “Designing and Engineering Time: The Psychology of Time Perception in Software”. I personally haven’t read the book however my interest in doing so has certainly been raised. I am interested here in turning the architectural spotlight onto the strategies for managing time.
Howard includes the following table in his post (the first two columns), demonstrating how perceptions of time in software / human interaction can be managed effectively. As my mind turned to thinking about publish subscribe and one way messaging I decided to add another column to this table clarify my thinking.
| Performance Dimension | Management Strategy | One Way Messaging Pub / Sub Strategy |
| Actual Performance – the precise time durations for completing a task | Operational Management – purely technical strategy (e.g. change the way it works to make it faster) | Let’s push aside algorithmic tweaking designed to speed up computation for just a moment and consider this aspect from a scaling / throughput perspective. In systems that attempt to address this through stateless web services, the strategy is one of scaling out the web servers. If we bring durable queuing into the focus then we can rather more cheaply apply divide and conquer, with patterns such as ‘competing consumer’. In terms of NServiceBus the Distributor is an excellent choice here. Again this is looking at it from an architectural viewpoint. |
| Perceived Performance – the approximate duration for completing a task as experienced by the user | Perception Management – make the task feel like it takes less time (examples include distractions, progress indicators, etc.) | Sending commands or messages to the server for processing and distract the user by maintaining UI state as though the command had been processed. One example is showing blog comments to the submitting user only, whilst waiting for the moderator to approve it. |
| User Tolerance – based on expectations, the approximate duration threshold where anything beyond will be considered slow by a user | Tolerance Management – focus on making users more tolerant of a longer duration when it cannot be shortened or “disguised” | Initial immediate response followed by a subsequent response via a different channel than that sent the message / request. Examples such as Amazon purchases that provide an immediate response and then provides confirmation email. |
In request / response systems, often the focus goes into that described in row 1 column 2 above; that is we tend to narrow in on speeding up our code, substituting for faster implementation technologies or even scaling up our hardware. In the case of stateless Web Services it’s also common to scale out the web servers. With one way messaging and NServiceBus we can increase our throughput and speed (both real and perceived) by scaling out our services and what’s more this can be achieved relatively cheaply with commodity hardware.
It’s also worth noting that the effects of implementing durable queues play’s into the Reliability aspect of the system and when those queues are placed physically adjacent with task based smart client applications that both send and receive messages, then it’s possible to create the perception that work is submitted immediately; potentially it may be repudiated later if there is something wrong with the submission itself. Maintaining a low number of these repudiated work submissions (command / messages) can increase the tolerance levels and the perceived improvement in speed in getting through the work itself.
