Hi Pat,
issue with event-oriented (ie mature message-oriented) software is that
it is somewhat difficult to do atm. Have a look at the event packages in
excalibur CVS, and at the by-now-famous SEDA paper for promising work.
> What do you think component-structure fragility means?
that's the nice thing about high-level thinking: it can mean anything.
> As we move to Intelligent Apps (???),
marketing terms yada yada yada
> Servlets/Web Services seem too
> busy/too chatty {presentation layer}
a lot of software needs a presentation layer. Servlets is really neat
for that. Web Services as advocated by MS/IBM is a presentation layer
towards other software, which means web services is nothing more than
enabling your applications to use a communication protocol based on XML.
Which is nice, but definately not as much of a revolution as it sounds.
Leave the buzz already =)
> and EJB seems legacy oriented
> (legacy oriented programming ;-) {business layer}.
yep. All of the java "enterprise" platform is very much "enterprise". In
99% of cases I suspect enterprise solutions are in use because no
"middleware" solutions exist.
> So what is the
> intelligent platform? Something like EOB? I peeked at that and it seemed
> early/rough.
it is, very much early, and somewhat like my 'vision' for the future.
What will happen is that JSR 111 (the Services proposal, partly based on
avalon) will rock the java world, and then we will see architectures
like EOB replace EJB. This is if everything goes as planned....
> You seemed to imply you really like the separation of behavior and
> structure.
uh...the separation of behaviour and data. Separation of behaviour from
structure leaves you with either functional programming or procedureal
programming which we know is not cool =)
> I've been learning SQL3 and do you think SQL3's object types
> would be going in the wrong direction?
dunno; I only use SQL92. I do know the oracle extensions to that for
support of objects are yucky.
> It seems we need to compose a real relational/logic
> system augmented with a behavior system as a separate dimension of
> concern.
Systems I design generally have a pure relational setup at the database
level (ie tables with relational constraints), and then an abstraction
from that for flexibility (ie views), and then a procedureal library on
top of that.
In the middleware, the first thing you do is abstract away from SQL to
create a data module based on that procedureal library, preferably using
an automated tool.
The middleware uses COP, with the data module as a vital piece.
The middleware is 'included' in a servlet via a central component (the
container). The servlet then couples presentation layer (ie uses
VelocityService) to the middleware.
Example Setup
=============
CREATE TABLE bla
{
id,
name,
}
CREATE TABLE blaDecorator
{
content
}
CREATE VIEW blaView
{
id,
name,
content
}
CREATE PROCEDURE getBla
{
return select * from blaView;
}
CREATE PROCEDURE setBla( id, name, content )
{
insert into blaView (id, name, content)
}
[JDBC LAYER]
[OJB-style LAYER]
class ContextBuilderImpl implements ContextBuilder
{
DataModuleComponent dm;
service( ServiceManager sm )
{
dm = (DataModuleComponent)sm.lookup(
DataModuleComponent.ROLE );
}
getContext( ResultData rd )
{
// figure out which methods to call on dm based on rd,
// use result of method calls to fill in context
}
}
class MyServlet
{
static MyContainer mc;
static
{
mc = new MyContainer();
}
handleRequest( request, response )
{
RequestProcessor rp =
(RequestProcessor)mc.getServiceManager().lookup(
RequestProcessor.ROLE );
ContextBuilder cb =
(ContextBuilder)mc.getServiceManager().lookup(
ContextBuilder.ROLE );
TemplateStore ts =
(TemplateStore)mc.getServiceManager().lookup(
TemplateStore.ROLE );
VelocityService vs =
(VelocityService)mc.getServiceManager().lookup(
VelocityService.ROLE );
ResultData rd = rp.process( request, response );
Context c = cb.getContext( rd );
Template t = ts.getTemplate( rd );
vs.process( c, t, request, response );
}
}
My hope is that at one point Turbine will follow this general pattern
(though it should be a lot more powerful, of course =). You'll replace
"MyContainer" with "Plexus", "MyServlet" with "TurbineServlet", and all
the other stuff referenced like RequestProcessor exists as a service
within Fulcrum.
In current in-house setups we do not use OJB but hand-built data
modules, firebird as the RDMDS, and wrappers around Turbine 2.1 fulcrum
stuff to implement the various components required, and a custom
container based on a version of phoenix that embeds the standalone
turbine.
For more complex setups you add another layer between middleware and
data, this could be EOB. EJB is to
> Knowledge is *neither* power nor behavior.
yup =)
LSD
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
