Friday, 16 November 2007

Intalio as a complete development environment?

Virgil Green, a contributor to the Intalio forum posed a question which approaches my own reason for studying Intalio

I've been considering BMPS in general and Intalio specifically as a development platform. I'm wondering if I'm expecting too much from this technology. I'd like to replace a complete software system including Contract Management, Claim Management, Invoicing, Letter Generation, etc.

My question is (rather broadly) whether the combination of Intalio Community edition (or any higher level edition), a database for which there are adapters, and a reporting tool such as BIRT provide sufficient tools to develop a complete enterprise system.


Business rules? Are they covered/enforceable in Intalio? User Inquiry and Data Entry? Are XForms enough? Am I expecting too much or should I continue to think of this software as middleware for moving data between other systems that handle those functions?

At present the answer is probably that you are asking too much of Intalio alone and that you are being very ambitious. However, the underlying ideas of Intalio and its open-source, and standards basis mean that there is likely to be a way of working with Intalio as a core to deliver a reasonable enterprise architecture.


I think it is a good idea to consider BPMS as the centre of an execution platform. Intalio then provides a good implementation of the BPEL engine and a corresponding designer. Because BPMS does not work well without people somewhere in the end to end operation, there is an element of human workflow required to complete the picture. Intalio adds to the BPMS a web application that implements the human workflow using a standard form expression BPEL4People. This is the TEMPO component. The Intalio Designer integrates this for you automatically. If you are happy to express your workflow with the BPEL4People constructs, and there are plenty of for and against arguments, that covers your business processes very well.


Either side of the business process management system you will require technology components that interact with people (the human interface) and services (the IT systems components for you Contract Management, Claim Management etc.).

Let us consider the services first. My observation of organisations which are not unduly tied into technology (a retailer or small manufacturer rather than a national Telco) is that when you manage the Business Process independently of the business services, the both the services and the business process implementations will become much simpler than if they are combined in say a customer management suite.


Intalio itself does not provide much in the way of application development of the kind you might find in IBM's Websphere or Microsoft Visual Studio. However, once the business processes are managed there may be little left to worry about other than the persistence layer of simple create, read, update and delete of data (CRUD). Of course there are a number of development tools that would work alongside Intalio to deliver the services components.



The user interface components of Intalio are designed for the workflow alone. This will not be sufficient for a complete software solution for many organisations. Although Intalio makes use of a generic user interface product (ORBEON ) which itself is a server implementation of the XFORMS standard, the method of development of user interface in Intalio does not allow the full capabilities of either to be used.

  • There is no direct control over the presentation within the designer. The view of the form is defined by CSS , but the CSS scripting has to be unpacked from the Intalio distribution and modified independently of the forms designer component.
  • The form input and output messages are defined automatically from the form components (widgets) which precludes the use of standard schemas common in business and government circles (for example the XNAL standard used for names and addresses).
  • Fundamental XFORMS presentation controls are not available within the designer (for example, Appearance, which is used by XFORMS implementations to decide how the input/output should be presented)
  • There is no control over XFORMS submission. Submission is limited to the messages to TEMPO.

However, the presentation layer of the architecture can be readily replaced with anything else that can communicate with SOAP (doc-literal) messaging. A commercial organisation might even consider using Microsoft Office as the presentation layer. Organisations with an architectural bias to Open Source and standards might still choose XFORMS but with a different development tool.



Whether Intalio is sufficient to develop for the enterprise will ultimately depend on the complexity of that enterprise. There will be plenty of businesses that perform their functions within Microsoft Office and Access environments. Intalio and a database would be a step up from that. MySQL and JDBC seems to fit well with Intalio. There are some samples of providing data access services through MySQL in Intalio.


At first glance, BIRT for reporting looks a good companion for Intalio in the development area as it is also based on the Eclipse development platform. However, the Intalio distribution seems a bit hostile to other Eclipse plug-ins. This may be resolved as Intalio matures.



Explicitly calling a business rules engine within the BPMS seems to be a reasonable approach and is readily achieved in Intalio provided the BRE provides a web service interface. Intalio provides a sample implementation with OpenLexicon.




Intalio could not be classed as a general development environment in its current incarnation but it is certainly capable of becoming one.

7 comments:

ccrystal122574 said...

Nice Article dave, very helpful and insightful.

Im just 3 months into developing on this platform and your article has shed some light indeed...

Chris
christiancrystal@gmail.com

srimal said...

Thanks for a very insightful article.

Regarding input/output i n forms widgets..

We have a requirement for developing table controls that have 'input-output behaviour'. The current designer
allows only 'input' or 'output' as separate behaviours.

Is there a possiblity of creating a custom wigdet for intallio forms to support table controls that have 'input-output behaviour?

Thanks in advance

Srimal.

David French said...

The options appear to be
1. Initiate a D3 development (and fund it to make it happen) within the Intalio stable. I would recommend against a custom widget or even a sensible implementation of the existing table one. Move to a more effective implementation of the XFORMS group ... which is how tables are delivered in native XFORMS implementations.
2. Deliver a stand-alone bit of XSLT to edit the XFORM file generated by the Designer to add XFORMS structures that work as you want them to (read up on XFORMS for this). You would need to avoid messing with Intalio's use of Input and Output structures. This approach is seriously hampered by the fact that each round trip through designer loses anything you put in.
3. Totally ignore licence restrictions and hack the designer to work how you want it. No, I don't think this is a good idea but if you are capable of doing it, there is probably a better job for you at Intalio.
4. Follow the information on replacing the UI completely and use a full featured UI development tool (there are a heap of them open source and proprietary). It will help if the tool that you choose allow you to introspect the wsdl.
I recommend this approach because it allows you to do contract-first design as well as recognise that the BPMS part of your business is not the only thing that users interact with and you may want a consistent user interface. Eclipse-based tools might be the best bet having the potential for integration (but not I think in the current community version of Intalio)

I suspect the use of XFORMS in designer was not intended as the ultimate solution ... more as a starter kit. Unfortunately having started with it you have to stop and get into a production version.

Crishantha Nanayakkara said...

Hi Dave,

I have been too following the thread and it has been quite informative.

Regarding the Srimal's question related to table control, would it be possible for us to tell how Intalio developed the Absence Request sample without using the Designer? That will help us to get an idea how we should exactly get about this problem.

Thanks
Crishantha

David French said...

You could ask Intalio or on the Tempo group but I recall a comment some time ago that the Absence Request example was hand coded XFORMS. That is not really a bad thing, most XFORMS work is done without a graphical editor ... just write the XML in a text editor and display the result in a browser window (XMLSPY does this well)

Antoine said...

Dave, I wish I had more time to react to your post with a complete answer ; that might come later.

Just one precision for now: we ship our EE version with BIRT for our BAM product.

Narendran Thillaisthanam said...

Very nice article. However, given that 3 years have passed since this got posted, I am curious to know how things stand now!! We are considering the enterprise version because of the additional bells and whistles - of which we feel rule engine and BAM are important.

Specifically, we are looking at Intalio with Drools (Govner) for BRE (BRMS). For UI, would Liferay/Socailportal (whicherver is shiped) isuffice to build a reason)able UI (along with Orbeon XForms?

Any first hand information of Intalio BPMS' shortcomings and how it has been addressed by enterprises would be really helpful.