Addicted to the power of LightSwitch since the first time I ever saw a demo of it, I immediately realized that LightSwitch offered me a window of opportunity to found my own software company, which will officially be born on 2nd April, 2012...
LightSwitch is a truly unique tool to write small to medium-sized business applications in virtually no time, with enough flexibility to avoid hitting a "brick wall", which is all-too-often the case in classic RAD frameworks. The previous sentence contains a lot of LightSwitch praising and loving, but also contains one of my biggest worries. What about large enterprise application? What if my applications start off small, but become giant successes? Will my beloved technology become a burden once business starts growing?
- Can LightSwitch handle extremely large applications? Is there a limit on how much functionality I can fit in one LSML? Will an enterprise LightSwitch application load fast enough?
- Can LightSwitch handle horizontal scaling scenarios? Can I do a distributed installation of a LightSwitch application over several servers to support a massive amount of simultaneous users?
- How can I reuse screens and entities between my customers when they have similar needs? Is a VSIX extension really the only way? And will I be able to partially update one functionality without fear of breaking other parts of the application?
- LightSwitch can help me develop at lightning speed, but is that the only aspect of a smooth running company? How can LightSwitch help me to align customers, developers, salesmen, ... Or help me keep track of versions, servers, feature requests, installations, ...
- How are multiple developers going to work on the same LightSwitch application? Merging the LSML file on a daily bases will be hell...
Will LightSwitch not only lift me up my feet, but still carry me once I hit cruise speed?
One night - for some reason, my best ideas always hit me about 4-5 hours before my alarm clock tells me to get up and get ready for work - I remembered an essay which contained the statement that "our vision on reality is shaped, and thus limited, by the language that we use".
By simply using a different lingo (the one used when talking about enterprise service oriented architecture taxonomy), my vision of LightSwitch, and thus its limitations, drastically changed.
LightSwitch Taxonomy 101
LightSwitch Application (LS APP)
To try to speak the same language again, let's have a quick look at the anatomy one of the most "complex" LightSwitch application that we can develop today. Not mentioning cosmetic extensions, a LightSwitch application itself will generate three core components: a single SilverLight application, that connects to a single WCF service, which in turn connects to a single SQL database, and perhaps you'll use one of three other datasources: an external database, a sharepoint database, or an external WCF RIA Service.
This is what we formerly called a LightSwich application, however from now on, a LightSwitch app will be considered no more than a LightSwitch project structure in Visual Studio... When creating a new LightSwitch application, you can choose to think about the result as a "module".
A LightSwitch "module" should immediately shape the mental picture that what you are designing is a well-scoped, reusable part of a greater organism.
LightSwitch Entity Module (LS EM)
A LightSwitch Entity Module is a LS APP that has the only responsibility to design simple database entities on which other modules can perform CRUD operations. It contains no business logic or validation. (Note: A LS APP will generate a WCF service and a rather empty SilverLight component as well, we'll just never use them.)
External Process Module (EX PcM)
An External Process Module is any module that can provide access to external processes to the end-user, or to our LightSwitch Process Modules. By external, I am not necessarily trying to indicate that the source code of those modules is not under our control, but merely referring to the fact that they are not written in LightSwitch.
LightSwitch Process Module (LS PcM)
A LightSwitch Process Module is a LS APP that implements a particular business process. It (optionally) contains its own entities, logic, screens, and references whatever LS EM, EX PcM or other LS PcM it needs to materialize that business process.
Any LightSwitch Module needs careful scoping / designing before development, but this is especially easy to violate when talking about LS PcM. Consider the functionality of managing customers for my software company. My sales force needs software to work with those customers, so that they can schedule meetings to talk about improvements or new feature requests. The development team will need software to work with these customers as well, so that they can implement user stories for them, contact them to discuss that implementation, ... Engineering will also need software to work with these customers, as they'll want to keep track of the installed software versions, the servers, staging areas, ... And finally, the accountant will need these customers in his accounting suite, so that he/she can bill the customer correctly. Although it might seem a good idea to create a "Manage Customers LightSwitch Process Module", it's a much better and maintainable idea to create four separate LS PcM, because you are dealing with four separate business processes, each with its own logic, references and screens, and most likely with a shared "Customer LS EM" containing common "Customer" entities. The four separate LS PcM will not only be smaller and more maintainable, but they will load faster too.
LightSwitch Utility Module (LS UM)
A LightSwitch Utility Module is a non-application specific module that provides some reusable functionality. Ideally, but not always, you can package these as a VSIX extension. Good examples are generic reporting extensions, logging functionality, or the built-in LightSwitch security module (users, groups & rights).
LightSwitch Portal Module (LS PtM)
A lot of the popular application frameworks, such as PRISM or Caliburn, implement the concept of a "shell", which blends together different modules or subsystems into a single UI at runtime.
Even after numerous attempts, I still haven't succeeded to implement this runtime weaving in LightSwitch.
However, you can still create a LS APP that provides a rather similar experience to the end-user, considering you can host a web browser in a LightSwitch (desktop) app (thanks Tim Leung for that article, you're a genius!), and a SilverLight application (LS PcM) is hosted in a normal web page:
Above is my first succeeded attempt to create a LightSwitch Portal Module. I was working on a proof-of-concept of two interacting LightSwitch applications (hence the "student"/"teacher" entities) when I read Tim Leung's article. I just had to try it right there right then. If you click on the image and pay attention to the web page property, you'll see that you could create and test your own LS PtM with two simple LS APPs, right from the Visual Studio debugger!
A LightSwitch Portal Module is a LS APP that provides a user a single entry point into a Business Network and the ability to "portal" to the process module of his choice.
Business Network
A Business Network is a collection of different modules that support a company in its business. This network can be partially or completely private (not accessible outside the company domain for example). It can contain numerous External and LightSwitch Modules. Business networks of allied companies could also partially overlap.
MyBizz Network
In the picture above, you can see a (simplified) example of such a network.
Two actually.
The network on the left is the network that will fulfill my startup's needs, the network on the right is one that I created for demo purposes... Let's just say - to avoid legal matters - that "a certain real estate company" already saw this "demo that I just had lying around" and "might" become my first paying customer on 2nd April. Both networks happen to be distributed over both a private (Windows 2008) and a public (Windows Azure) server, totaling 4 servers...
What the picture doesn't show, is that both networks actually overlap. It would be more obvious if I'd draw the dependencies between the different components, but that quickly turns the overview into a messy web...
The demo customer's skinrepository pulls resources from my business (central) skin repository, my STS (see later: single-sign-on) is a trusted STS of the demo customer's STS, and his MITS (My Issue Tracking System) reads and writes to my PITS (Public Issue Tracking System).
Our two Business Networks contain over 235 entities, hundreds of screens, about every extension I could think of writing (including the Achievements extension to encourage my sales force to write up decent specs for each customer requirement, for which they earn points, which could be materialize in a bonus plan, meanwhile making the work for the developer easier... and a very early alpha version of the skinning extension...), almost all of the free extensions I could get my hands on (thanks to all the community contributors!), and some commercial extensions.
MyBizz Portal
I'm still playing around with the portal application at the moment, but have come to a point where I am satisfied enough to "reveal it to the public".
Getting Started with MyBizz Portal...
Upon a "clean" install, an administrator user can start the application, and after logging in is greeted with the main - and only - screen of the application...
To explain what you are seeing here... I have a LS EM that contains the core data, one of the entities is called a "MyBizzModule". In my portal application, I connect to that data, and show it in a custom Silverlight Control. Because there are no other screens, and no commands, I opted to use a blank shell extension.
Because there's only one module configured (in other words: only one MyBizzModule record in the database), the only option this application offers us now is to click the lonely red box icon at the bottom...
When clicked, the module opens and displays its login screen to us... (You might have to enlarge the image to see that it's actually a LightSwitch application being shown IN another LightSwitch application).
Single-Sign-On
After logging in, we can see the main screen of the module. This LS PcM allows us to manage all the modules in a Business Network, only one is configured at the moment.
Name, Image and Portal site should need no explanation, but the fourth one is a very special one which will take more than an hour to explain in detail.
In my Business Network, I have a WCF service that fulfills the role of a Security Token Service. The login screens used throughout the Business Network are actually all "hacked" custom implementations.
Instead of authenticating with the current LightSwitch application, they request an encrypted token from the STS, and use that token as a key to log in - or, and only if automatic authentication fails, present the login screen to the user. When I logged in to the portal application, the portal application kept the token in memory.
Now, if I check the "Include Security Token" checkbox, and portal to the module, the encrypted token will be passed in the query (I did the same thing with the "LightSwitch Deep Linking") to the module. The "hacked" login screen will pick up the token and try to use that token to log in automagically.
This functionality will be really important for the end-user, we do not want him to enter a username & password every time he/she portals to a different module, hence the "single-sign-on"...
Another major benefit is that one STS can "trust" another STS. This means that I can log on to my Business Network, and navigate to a "public" module from an allied company's Network. That module will recognize that the token I'm trying to use was issued from my STS, and map my claims (permissions) accordingly.
Another thing that I'm trying to pass through, is information about the "default skin" that should be used. This feature is in an EXTREMELY early alpha stage, so I won't go into it too deep.
Last property, the required claim, simply allows the administrator to indicate that only users with the given permission (claim) can view / use the module, allowing fine-tuning of users&groups at a much higher level than the classic screens & entities level that we LightSwitch developers have been doing so far...
Moving On
Enough explaining, let's give that module some values & restart the application (changes in the configured modules still require a restart at this point... ).
You can see that the "Cosmopolitan.Blue" skin has been loaded (unfinished, based on a Silverlight theme and the LightSwitch Metro theme sources), and that I did not need to log on a second time to enter the module... (Well, kind of hard to post a screenshot of the latter.) Let's have some fun and add two sample modules, one portal to Twitter and one to MSDN.
Clicking the bird in the middle shows that the portal application is (obviously) not limited to LS PcM alone, any link that can be shown in a web browser will do...
Finally, just to show my custom SilverLight control - 3 icons really don't do it justice, these screenshots below are from my Business Network as it is today, roughly 2 months before my company will actually be born...
Which results in this layout...
And For Bonus Points...
Basic Questions
What does your application (or extension) do? What business problem does it solve?
From a technical point of view: it's a webbrowser wrapper with an advanced URL management system.
From a LightSwitch point of view: it's a LightSwitch application that manages my LightSwitch applications.
From a functional point of view: it's an application that allows a user to portal anywhere he wants ( / is allowed to ) inside my LightSwitch Business Network...
From a personal point of view: it's the last of the missing pieces of the puzzle, it will help me manage my startup (customers, sales force, expenses, keeping track of projects & LightSwitch applications, ...) , and gave me the confidence that truly anything is possible with LightSwitch.
How many screens and entities does this application have?
The application has 1 screen and 1 entity.
Additional Questions
Did LightSwitch save your business money? How?
Not yet, but I strongly believe it will save me loads once my company is born... I can however say that without LightSwitch, the chances of me starting a company after my day job, and actually producing working software, would pretty much be zero.
Would this application still be built if you didn’t have LightSwitch? If yes, with what?
Most likely, it wouldn't have been built.
How many users does this application support?
In theory, over 7,023,324,899; especially since the modules can be deployed on and load balanced over separate servers. The databases would be the only bottleneck.
How long did this application take to actually build using LightSwitch?
Less than a week. Most time was spent trying to make a radial ItemsControl. I have limited experience as a developer, and none as a designer... Another two evenings were spent writing this article & taking screenshots. The LightSwitch part took me 15 minutes. (Developing both Business Networks took me 6+ months, of course)
Does this application use any LightSwitch extensions? If so, which ones? Did you write any of these extensions yourself? If so, is it available to the public? Where?
The LS PcM in the Business Networks also use...
- LightSwitch Achievements - homebrewn and part of a blog post series, so available to public soon.
- LightSwitch STS - homebrewn and won't be available to public anytime soon, however I'm porting the ability to inject a custom login screen to EME soon.
- LightSwitch Skin Studio - homebrown and available to public later this year... Much, much later...
- Many, many, many commercial and free extensions - a special thanks to the LightSwitch crew, Allesandro, Tim, Yann, Bala and Michael for contributing so much to the community! (So sorry in advance if I forgot anyone special!!)
How did LightSwitch make your developer life better? Was it faster to build compared to other options you considered?
LightSwitch gave me an incredible passion & energy to build applications that support the customer's process, I wouldn't find the energy to do this in any other technology that I know of at the time of writing... It does all the tedious and boring tasks for you with a few clicks, and lets you focus on what really makes your application stand out.
Additional Additional Questions
Can LightSwitch handle extremely large applications? Is there a limit on how much functionality I can fit in one LSML? Will an enterprise LightSwitch application load fast enough?
Yes, if you find any way to split your extremely large applications in many different modules, and bring them all together, there should be no limits for any LightSwitch developer. The solution I choose (using a webbrowser control) fits my business' needs perfectly, and because modules are only loaded when you actually access them, drastically reduces the load time of the application.
Can LightSwitch handle horizontal scaling scenarios? Can I do a distributed installation of a LightSwitch application over several servers to support a massive amount of simultaneous users?
Yes, it does!
How can I reuse screens and entities between my customers when they have similar needs? Is a VSIX extension really the only way? And will I be able to partially update one functionality without fear of breaking other parts of the application?
A VSIX is one way, and sometimes the best way. If you truly want to reuse screens & entities, distributing your application over multiple, reusable modules, adds a whole new dimension of benefits to the LightSwitch way of development.
LightSwitch can help me develop at lightning speed, but is that the only aspect of a smooth running company? How can LightSwitch help me to align customers, developers, salesmen, ... Or help me keep track of versions, servers, feature requests, installations, ...
LightSwitch helped me build several LS PcM to keep track of my business process in just a couple of days...
How are multiple developers going to work on the same LightSwitch application? Merging the LSML file on a daily bases will be a hell...
Not if they work on one module each...
Where is the source?
You wish ;) (Although parts could be polished, then published on my blog, on demand.)
