Apr 18, 2010

UnifiedBPM blog. First post!

Hi.
This blog will document the development of Unified BPM.
So what...is UBPM? Except a future Business Process Management system that's gonna take BizTalk down(yeah right).
Some time ago, I realised that so much in terms of parsers and connectivity was already done and available as free and open source software, that just connecting the dots could not be that hard.

Well, it was a little bit harder than I thought, since I decided to combine it with learning a new programming language.
So what did I need from that language?

I wanted it to be loosely typed, quick and great for both web(apache) and utility development.
I needed it to be able to parse and generate itself, that seemed to be the most uncommon thing.
I narrowed it down a bit and remained was Python, PERL and Ruby.
I felt attracted by the freedom of PERL and gave it a try.

But after clearing many a hurdle and testing almost all the technologies involved I came to the conclusion that I, amongst some other things, didn't like the OOP-paradigm of PERL.
Me, a pretty well-seasoned developer, should not have to struggle with something that basic. Also, the myriad of ways to do something would become a problem if the project grew and people contributed.

So I looked at Ruby and found that the documentation and the community, while being very active, lacked much in maturity and quality.
Remaining was Python, so Python it was. Also, I grew to like many things about the pythonesque approach. It was almost as clean as ruby while keeping a bit more traditional.

I have now, again, started to work through the things I need to get a system like this of the ground:
  1. Debugging programatically. I need to be able to do this to GUI:fy script creation.
  2. SOAP/WSDL functionality. Will be used for most of the internal and external communications. I want this system to be extremely standardized, safe and extensible and don't give a rats ass about 20% less performance than RPC if it saves me hassles with datatypes and pointless XML-traversal. See below for a working wsgi-example.
  3. Code generation and parsing. I need this as well to GUI:fy. One should not have to be an python hacker to use the system. But anything should be possible.
  4. Persistence. I will use mod_wsgi for most scripts, so I had to check that out. Found it to be quite flexible.
So why blog about it?

Well, while exploring the above technologies I have encountered numerous hurdles, for which the solutions presented while searching the web has either horrible explanations, bad examples or worse, are completely undocumented. And some of those I will present here.
Also, some people might get interested in the UnifiedBPM project.
For PERL, I actually have example code for all the above areas if anyone wants it. Personally, I can't stand it. :-)

Below is an Python example on how to use soaplib under Apaches' mod_wsgi. *Without* any frameworks like Django and other stuff involved. For some reason, this seems to be the only such example on the web:

#! /usr/bin/env python

from soaplib.wsgi_soap import SimpleWSGISoapApp
from soaplib.service import soapmethod
from soaplib.serializers.primitive import String, Integer, Array

class HelloWorldService(SimpleWSGISoapApp):

@soapmethod(String,Integer,_returns=Array(String))
def say_hello(self,name,times):
for i in range(0,times):
results+= 'Hello, ' + name
return results

def application(environ, start_response):
test = HelloWorldService()
results = test.__call__(environ , start_response)
return results

Actually, it was pretty straightforward, the __call__()-function takes the environment and start_response function. Only that nobody seemed to had done it before.
Also, the other examples (http://www.djangosnippets.org/snippets/979/) don't work for most because of this bug: http://github.com/jkp/soaplib/issues#issue/12 .
So I simplified it a little bit until the bug fix is properly bewildered. :-)