In case you need to get up to speed on SharePoint Products and Technologies.

 

A typical usage of SharePoint is to use its form or document libraries as steps in a workflow process, like an approval process for example, for any form or document. Each work flow step = one document library.  If I had a workflow that contained 10 steps, I will have 10 document or forms libraries.

 

Jan Tielen has built an excellent workflow engine, called, Workflow Lite for SharePoint that uses an XML configuration file to describe the number of workflow steps, plus other elements such as properties and actions.  Properties reference document library columns, in which you customize and actions describe, well, actions like copy this document from one workflow step (i.e. document or form library) to another.

 

The idea is that you install Jans workflow engine, which is a .NET assembly that hooks into SharePoints document library event handler (a service point).  Once installed, the assembly reads the (XML) configuration file which contains all of the named workflow steps, properties and actions.

 

Here comes the software factory bit, which can be on demand.  The XML configuration file can be viewed as one part of a software factory schema in which we can build a user interface to filling out the schema with workflow steps along with properties and actions.  Another XML configuration file, (actually a SharePoint site template) can be used to specify the overall look, feel and some functionality (i.e. document library columns) of the overall SharePoint site, in which the workflow executes inside of.  You know, your company name goes here, upload your logo, URL naming conventions, etc.  We can also build a user interface to this part of the software factory schema.  Both XML documents represent the entire SharePoint workflow application, not only from a design point of view, but also used by the software factory template and at run-time.

 

In fact, I could set up an on-line web site with these two user interfaces and have anyone come to the site, fill out the forms that describe the SharePoint site definition and workflow schemas.  You could then press order, in which I will get your instance of a software factory schema. I can then use this customized factory schema in my software factory template, and with some Visual Studio scripting, I can check out Jans Workflow Lite from my source code control system, along with a SharePoint site generator, which will take the site definitions values from your order and build out a SharePoint site along (including the library columns) with the workflow, etc.  In fact, since I already know the steps in the workflow process, I can even write an automated test script to test out and certify.

 

I can then (automatically) back the site up and package the whole thing as an MSI (installer) file (from Visual Studio) and send it to you, an hour later after you ordered it. Running the installer deploys the solution to your environment, performs a self-test of the workflow steps and voila!  Hows that for an on-demand software factory?  Need changes? Go back to the web site, make them using your original specification files and re-order.  Just like that.  Sounds like an on-demand software product line for workflow applications in SharePoint.

According to my last post, I can draw a piston in a CAD program and have a (CAM) milling machine automatically produce the output.  Big deal, old hat, so what?  In the software world, we are dealing with sizes and complexity way beyond a piston.  There is no doubt of that.  However, in the design of a race car engine, it is not just the pistons being designed (and drawn), but also the aluminum engine block, rods, bearings, crankshaft, etc.  In fact, everything is designed and machined. And in the case of a race car engine, all of the parts are hand assembled in the end.

 

Thats because, people will say, that an engine is a well known entity and we have done them over and over again for what, 75 years?  I put it to you that a software invoicing application, is an invoicing application, is an invoicing application.  Just like the hundreds of thousands (millions?) of login dialog boxes that we, as programmers, continue to proliferate on an ad hoc, one off basis, we continue to maintain that every software job is 100% custom.  I call bullshit.  Btw, so does the CEO of SAP See slide 12.

At 5by5Software, we performed 25 application integration projects over a 4 year period, all of them very different for different vertical industries, yet they were all the same.  We knew the names of the applications (i.e. end points) to be connected, the names of the adapters, connectors or interfaces (whatever you want to call them) to each of these applications and whether we could purchase adapters off the shelf or we would have to build them (which was the only custom development piece in the entire project), the data (i.e. XML schemas) or messages that flowed to and from the application integrations, what type of communication it was (i.e. one-way asynch, one-way asynch with response, two-way request response, two-way synch on aysnch) and which application triggered the business event to kick-off the integration and whether it was a scheduled event or not.  Thats it.

 

In fact, that is it.  Sure I am leaving out some details, but those are just implementation choices and do not affect the fundamental design pattern as stated above.  In fact, every application integration job will have that same pattern, over and over again.  What does this have to do with code generation?  Well, everything, actually.  If the pattern is repeatable, then there must be a way to define all of the pieces or parts, just like in our race car engine up front.  If we can define (and draw) those parts (pieces, components, whatever) 100% complete up front, then we can code generate the solution, cause this is the same thing over and over again.  Some would call these software product lines (not what your think in the traditional sense of the term "product").

 

As discussed in the previous post, we seem to have software design patterns for everything, so why are we not using code generators with these patterns?  Do our tools suck?  Are we daft? Are we resistant to change?  Fearful that code generation is a career limiting move?  What then?

 

Next post, more code generation - software factories

I am going to discuss code generation over the next few posts for a couple of reasons.  One is that it is fundamental to the process of software industrialization and second, most programmers, that I know of anyway, dont like code generators, for a variety of reasons.

 

Maybe I should step back and give you my definition of what code generation means to me.  I am pretty sure we all have different ideas as to what this means.  Again, I will draw upon our analogy of AutoCAD.  Lets say I produce a drawing of a piston used for a race engine.  Once I have completed the drawing, I can then save the entire definition of that race piston in a universal file (i.e. DXF) format.  I can then take that piston file definition and feed it into a Computer Numerical Control (CNC) milling machine, which will produce (in our terms, code generate) the output, virtually 100% complete, save for a few finishing touches (i.e. polishing).

 

Thats the key.  I am required to produce a drawing that is 100% complete up front (i.e. design) before I can mill out the piston for my race engine.  When do we specify (i.e. design) anything that is 100% complete up front in the software world?  If I can design a software part or solution 100% up front, then I can code generate the solution, given the proper tools.

 

As a programmer, I would rather build the (code generator) tool that is going to produce the solution rather than the solution itself.  Why?  Because, in my experience, I know I am going to have to do it over and over again, just to get it right. 

 

Traditionally, I would incrementally iterate my way through the solution code several dozen (or even hundreds) of times which will ensure I have a POS by the time it is ready to deploy into production. 

 

So give me a design tool that allows me to draw and define what is supposed to be built (saved in a universal file format) and then I can build a code generator to read the design file and produce the solution output.  The effort is in the design and code generator, not in the solution code. It takes minutes to code generate a solution - every time.

 

Hey, I like to code as much as the next programmer.  But I am getting too old and tired and cant stay up to 4am for a week in a row when it comes down to crunch time for the final push to deliver I dont know what to the client.  If I am going to code anything, it is going to be a code generator.

 

If I build a code generator to read a file format that contains the definition (i.e. design) of a solution, then I can make changes to the design, just like when I want to change the shape or dimensions of the piston.  And if I am really smart, I would have a library of piston designs that I have accumulated over time, along with other reusable design pieces or parts (read: design patterns). 

 

We have several excellent books that document design patterns for virtually everything in software, including the infamous (Gamma et all), EAI design patterns, and in fact, if you type in software design patterns in Google, you get 18,900 hits.  So why dont we have code generators that take these design patterns as input?  Why not create a standardized library of design patterns that any IDE can read and produce the required output in your language of choice?  Oops, there is that word again, standard.

 

Next post will delve deeper into code generators.