RE: Response on Building a suite of applications with Turbine

["Riley, Cameron" <CR...@ekmail.com>]

Shaun,

Sorry for the late reply, I have been in Australia the last two weeks,
woohoo :)

>Say each "module" within your webapp suite of applications accesses a
>different database, possibly on the same database server (mysql) or maybe
on
>a different type of database server altogether (SQLServer).  Do you do this
>and how do you cope with it?  Where and how do you switch databases?  We
are
>using Torque and does this help or affect the problem as I haven't seen
>where to set the database yet?

Apart from the legacy ASP app, we only use the one database. To avoid table
naming clashes, we use the COMPONENT_TABLENAME, same as what Turbine has.
The components have been done so they can use the data they need from each
other. Torque has been great, it has allowed consistent refactoring of the
Databases with minimal impact on the higher level code. 

The SCADA components are all based on iFix, which is proprietary. To get
real time data to a WAP app from that, the System Engineers came up with
what they have been calling a soft-PLC. It is basically a protocol/driver
converter and emulator designed initially to get around all the hassles of
Modbus, Modbus+ and all the other funky protocols and drivers. They added to
it so that it could connect to the SCADA Dynamic Db and Persistent Db so
that it could display real time data in a WAP display. So far it has only
been deployed in WAN's and hasnt had to be integrated into the web
application. 

I just sat through an Iconics presentation selling their wireless
connectedness through MS CE, so that sort of utility is moving to the cost
of donuts (as long as you use all the MS technologies or buy the rest of the
Vendors package). Trouble with SCADA is, all the vendors are in bed with MS
and there is no culture of OSS, including amongst the system engineers that
implement the solutions. That kind of culture is changing in this office ;) 


>Also, I see you have access permissions built into your webapp which is
>something I would like to do. Again where do you keep the centralised
>Turbine permissions tables and how does this affect things.

All the data is kept in the one database, and all security stuff is done
through the TURBINE tables. For the outside applications that dont
communicate through HTML or WAP, we use a mix of HTTP and XML to communicate
between the components. One of the components is a PDA app that is written
in eVB. So it can communicate with Turbine, we make HTTP requests and data
is sent in XML. We sub-classed org.apache.turbine.modules.Action and
manipulate the Printwriter Object directly through data.getOut(). There is a
formalised interface of actions and replies the eVB app can request and
recieve. That way it integrates with the Turbine components pretty
transparently to the user. We got client a couple of weeks ago that wanted
the same application running on PalmOS. It will connect up via the same
style of interface.


>Finally, you talk about external ASP based apps that you link into your
>framework.  We have exactly the same situation, although not ASP based.
>When we link to our external application it takes us out of our framework
so
>we lose the layout, navigation etc.  Our only solution is to open up the
app
>in a separate window so that you still have the webapp running in the
>background.

The ASP app is a legacy app, which fortunately hasnt had to have been
absorbed yet. It covers the project management side of the Suite and so far
no client has requested the Project Management component with the Asset
Management components yet. We have a current lightweight integration of the
ASP app though, the link generated in the Velocity Template handles the
login stuff for the ASP app and then loads into a new Layout that is a Frame
using the VelocityOnlyLayout Object. Like;

  -------------------------------
  Turbine app frame
  -------------------------------


   Legacy app frame


  -------------------------------

Noone has bought the two components together yet, so we havent had to go
deeply into integrating those two components beyond the appearance of
working together. It works ok as far as we have tested though, users have to
be duplicated in the two db's which isnt good, eventually though the
security component of the ASP app will be done through the Turbine app using
http req/res same as what the eVB app is using.

Hope that helps? 




Cameron Riley



---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org