Embedding lightSwitch in enterprise services (part 1/n)
I have the ambitious plan to start a series on embedding LightSwitch in other software enterprise components. I start in complete greenfield or tabula rasa mode. I even don’t know yet what I will investigate and discuss in this article series. So, even this introduction article is under construction. I hope I can soon remove this previous sentence and replace it by kind of structured table of content.
In this article, I will discuss first why I’m interested in integrating LightSwitch into other enterprise services. I’ll try to give also a rough idea on what type of enterprise integration I have in mind. I’ll explain also how I understand runtime and design time integration.
“LightSwitch is only meant for small and simple applications, not for large and complex applications”.
Yeah, we hear that a lot. When you make such a statement the only thing you prove is that you have really have no understanding about online transaction processing (OLTP) applications or line of business applications.
My view on things here is that a line of business application should never be complex. Of course, the framework you select, will heavily impact the level of complexity when looking into the code involved.
I can build exactly the same application with LightSwitch but resulting in a completely different size in code base, with code which is only relevant when thinking in terms of code that adds business value. The LightSwitch code which is typically addressing the complexity of the line of business application plumbing is just part of the LightSwitch framework. But, can we say that this application is less or more complex than the aforementioned MVC app? The answer is: by and large NO. Same look and feel, same business logic means same level of complexity. So, in the above discussion “complexity” has really no meaning.
Handling genuine complexity
So, let’s give now meaning to the word complexity.
A line of business application can become complex when the level of difficulty and the amount of business rules grow. That’s a no brainer. My point is how to address this complexity and to question if all this needs to be part of the typical online transaction processing. Good design and architecture and the basic principles of Service Oriented Architecture (SOA) learn us that we should typically isolate this in separate (runtime) components. For example:
- Isolate long running processes in a dedicated WCF service and call the asynchronously inside the request-response pipeline of the online transaction processing application;
- Instead of generating complex reports on the IIS server inline in the request-response pipeline, let them being generated by a separate process;
- For more complex interaction with other processes where recoverability, coping with duplicate messages and the transactional aspect of things are important, persistent message queuing should be used via a service bus.
All the above aspects can become really complex when looking to the overall application, but this should never have impact on the one part of this overall application structure, which is named the line of business app, which should, as I started this chapter, never be complex.
Runtime and design time integration
Integrating enterprise services is not only a matter of runtime components. I’ll try to cover in this series also a way how you can organize things in a visual studio solution. An example can clarify. A potential WCF service that interacts with a LightSwitch app potentially needs access to the same underlying Entity Framework model of the LightSwitch app. There are simple techniques ensuring that both models are always in sync. That’s what I call design time integration.
A call for real enterprise scenarios
Obviously I have some scenarios in mind, but I would like to encourage readers to drop me a line if they have specific ideas and scenarios for LightSwitch enterprise integration.