Boeing Application Integration Framework

[Boeing Jeff]

This is certainly a space we've extensively explored and have
implemented an "application integration" solution at a "prototype"
level. This includes a SPARQLFlow transform engine implemented as
cocoon Transformer plugins in combo with an OWL "SPARQLFlow" model, as
well as a SPARQLServerPages cocoon Transformer that allows sparql to
be embedded in dynamic html/xsl pages for creating a GUI for the
framework. This cocoon based architecture has been holding up well
for us thus far. I'd be interested in hearing about other similar
implementations.

[stub]

> I'd be interested in hearing about other similar implementations.

The approach we've been taking is similar in some respects. I'd like
to hear more about your SPARQLFlow and SPARQLServerPages.

When possible, we use Flex to create a Flash GUI, connecting to Cocoon
web services on the back end. In addition to looking nice and
providing
a satisfying user experience, the Flash component holds state for us
so
we don't need to hold session state on the server or using kludged
URLs/javascript/etc.

We do still create HTML output as well, but we have avoided any
"server pages"
style mixed-language coding. Instead we'll make a pipeline that
performs all
application functions and produces pure domain-specific XML output,
which we
can then test at the XML level with no GUI involvement. From there we
run a
straight-up XSL transform to render HTML as the last stage. But I'd
be interested
to hear more about or see your SPARQLServerPages language whenever/
wherever
you can share it, since it sounds like there might be some good ideas
in there.

At the head of the service pipelines we often use RequestGenerator to
turn
request variables into XML, and a simple jx generator to throw
session
variables (e.g. the logged-in userID) into the pipeline as well.
Aggregate those two generator results, and now you've got the whole
relevant context encoded as XML and ready to drive application
functionality
in the transformers.

From there, of course, it's transformers all the way down, including
SPARQL transform plugins like you describe (and as implemented in
Peruser).
Two other nifty things to mix in are the Cocoon SQLTransformer and
XSLT2+XPath2 processing using Saxonica. The latter provides a rich
lisp-like functional programming environment for pasting bits of
data together, explicit looping over sequences, etc. The
SQLTransformer
provides connectivity to SQL databases - usually via stored procedure
calls which are set up by an XSL transform in the preceding pipeline
stage.

It sometimes happens that we find ourselves doing multiple SPARQL (and
sometimes Fresnel) query operations interspersed with multiple SQL
queries/updates, in the course of a single pipeline execution. The
performance has been fine in every case we've tackled that way so
far,
but it's certainly not optimal and there's also the question of
transactional
consistency to consider when updates+queries are occuring in multiple
transformers.
I'm interested in your results in these areas with your SPARQLflow
approach.

peace,

Stu