cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Subject Re: [RT] Alternative Solution to XSP
Date Fri, 22 Jun 2001 21:42:26 GMT
On Fri, 22 Jun 2001, Berin Loritsch wrote:

> giacomo wrote:
> >
> > On Thu, 21 Jun 2001, Berin Loritsch wrote:
> >
> > 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.

You'll find it on the W3C site at

> > 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.

To be honest, I don't know. It is about two or three weeks in the state
where it is now and we haven't made any tests right now. But anyway the
design is open for improvements.

> 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.

Have nice vacation.


To unsubscribe, e-mail:
For additional commands, email:

View raw message