cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [RT] Alternative Solution to XSP
Date Fri, 22 Jun 2001 21:02:53 GMT
giacomo wrote:
> On Thu, 21 Jun 2001, Berin Loritsch wrote:
> > The two methods were for situations where I needed to send the
> > result over a wire vs. embed in the Cocoon context.  What this
> > enabled was the possibility of creating XML fragments when and
> > where I needed them.  In fact, when I had business objects that
> > were composed of other business objects, all I had to do is call
> > the embedded object's toSAX() method and I had perfect results
> > every time.  This is a great timesaver for business object
> > modeling, and when you need to integrate business objects with
> > SOAP, JMS, or other distribution mechanism.  However the drawback
> > was that now my business object is the central concern.  When
> > it comes to displaying a business object, this is not always
> > the case.
> We've also thought alot about it in our company. We came to the solution
> that you need better ways of describing business objects and services
> that using plain Java. For that we've developed a toolkit that is able
> to generate your business objects out of a XML Schema definition. For
> now we have helper classes that let you easily marshal and unmarshal
> these objects from and to streams (Parser/ContentHandler,
> InputStreams/OutputStream) with Avalon components of course. Future
> improvements could be that you can generate a specific ContentHandler
> for unmarshalling (possibly chaining several together) or generate the
> Java code of what you've called the XMLizable interface because you have
> all the information to do so defined in the XSchema.

That sounds pretty cool.  I would have to play with it to see if I like the
way it functions, but it looks like what it does is right on.

> We also thought of (partly) using WSDL to describe the logic part of
> business objects/applications. I think even if you don't send messages
> over the wire it is a good standard to define logic in terms of methods
> and their required parameters and output types. This part of that
> toolkit could generate interfaces from the WSDL description which a
> normal skilled developer can implement as a concrete class. Using WSDL
> the tool kit could be enabled to generate XSP logicsheets which
> implement the services described by use of the generated interface. This
> would have the benefit of a strongly typed taglib system which XSP
> logicsheets developed by hand can do but is painfull and a mess to
> maintain (MVHO) on release changes.

That sounds really cool.  Could you give me a link on WSDL?  I am not
familiar with that.  Autogenerating logicsheets is awesome though.

> The toolkit it's only able to generate business objects from a subset of
> XSchema definitions so far but it suites my needs for now. Today I use
> that toolkit to enable a C2 app to talk to browsers as well as to SOAP
> client offering the same services using the same logic pieces. It uses
> CORBA services in the backend which also get converted/deconverted from
> and to those business objects to and out of the usual Structs CORBA idls
> definitions generate. The system uses specific adapters to convert a
> request into a general request business object. Every
> logic/service/manipulations are made on these business objects. The
> steps are chained using Actions. When it comes to need to serilaize
> objects onto a SAX Stream its a matter of getting the serializer from
> the ComponentManager and send it down the pipeline where it is
> transformed depending on the original requesting client type. The
> serializers don't need to use reflections because they business objects
> can tell the serializers what to do.

I think you lost me a couple of times here.  The sentences just seemed
to ramble in a couple of places.  I think I got the overall gist of everything,
and it sounds excellent.  My questions are "How does it scale?" and "How
does it perform?".  I would need to know because I would need to estimate
hardware requirements for our clients.

Overall I like this approach.  In my 2 minute review, I think that this
is very promissing.  I won't be able to offer any deeper insights until
I have time for all this to sink in--which will most likely be done after
my vacation next week.
View raw message