[jboss-dev] Apologize (was Usecase xml ...)

Wed Nov 21 08:03:16 EST 2007

On Wed, 2007-11-21 at 00:46 -0500, Ke Jin wrote:
> It seems we have some communication problem. Let me clarify it again. I have never claimed using XSLT transformation to simplify XML configuration is my "just discovered idea". Because the key concept of this idea has been around for decades. I don't mind your yuck, neither care whoever want to claim it is their idea few years ago.

You are correct we have a communication problem
(many of them, I think :-).

I claim that preprocessors are not the way to go.
The model should be used by both the front end and backend.

If you know of examples that don't use preprocessors
but do bind models to implementations that "go back decades"
I'd like to know about them to understand the lessons
learned. :-)

If however you are only talking about preprocessors then yes
this hack has been around forever.

e.g. if you've looked at the gcc code
you write front ends and backends almost entirely in
c macros.

Why didn't they just define their own DSL? :-)

> 
> [snip]
> 
> >
> >> Fourthly, for using the XSLT, please read my post and article closely (pay 
> >attention to "higher order transformation"). The XSLT is just used as the core 
> >schema for model transformation, because it is standardized and ubiquitous 
> >(therefore, would be easy for third party support). None-XSLT transformation 
> >stylesheet schema can certainly be supported, and already supported by 
> >PocoCapsule for C++. 
> >> 

I don't care whether the preprocessor is XSLT or
some other transformation.

It's still a "script" that introduces cognative dissonance
(since you like long words :-) between what the user
defines and what the back end actually uses.

The use case xml we are discussing is a way to bind
the model/contract to the implementation details
without exposing those details to the user
(for clarity I also define user to include any management tool).

e.g. Using the example from my original post
(slightly extended to give more explanation):

<!-- Possible xml deployment of queue -->
<deployment xmlns:jms="urn:jboss:jms:2.0">
   <jms:queue name="MyQueue"/>
</deployment>

is programmtically 
(for just the basic queue model)

QueueModel model = new QueueModel();
model.setQueueName("MyQueue");

Something like (using JAXB):

@XmlElement("queue")
public class QueueModel
{
   @XmlAttribute("name")
   private String queueName;
}

You can then introduce the IOC part:

public QueueBeans extends QueueModel 
                  implements BeanMetaDataFactory
{
   List<BeanMetaData> getBeans() {
       Collections.singletonList(
       new BeanMetaDataBuilder(name, Queue.class.getName()).
           addProperty("model", this)).
   }
}

This effectively "transforms" the xml file into:
<deployment>
   <bean name="MyQueue" class="org.jboss.jms.Queue">
      <property name="model">queue-model-here</property>
   </bean
</deployment>

but it does it while still maintaining the link
between the front end DSM (the contract)
and the implementation.

Then handle implementation details 
(things that aren't part of the user contract) on the 
implementation class - you could also handle them
in QueueBeans:

public class Queue
{
   // The DSM
   @Inject
   private QueueModel model;

   // Implementation detail
   @Inject
   private QueueManager manager;
}

I know in the "loosely coupled" world of SOA
there is a tendency to not expose
models and use transformations to
translate different models/contracts.

This is a separate issue. i.e. multiple
models with only one being "native".

It's orthogonal to what we are discussing.

Translations/transformations are an unnecessary
step if the model can be used natively.

> >
> >The problem for me is that the XSLT (or similar approaches) 
> >looses what the user actually configures.
> >i.e. for programmatic deployment, error reporting 
> >or if they want to change the model dynamically.
> >
> >e.g. In our datasource that uses XSLT it is impossible to do:
> >
> >DataSourceModel dsm = new DataSourceModel(); // pun intended :-)
> >dsm.setPoolSize(20);
> >deploy(dsm);
> >
> >// Later - oops need to xslt, etc.
> >dsm.setPoolSize(40);
> >
> >You pretty much have to recreate the whole thing
> >because of implementation details. :-(
> >
> 
> Firstly, our configuration is not in the w3c XSLT but in a XML scheam similar to spring and jboss microcontainer.  
> 
> Secondly, the inconvenience of programmatic programming (I guess you meant "imperative" programming) in XSLT, is not the weakness of XSLT, but a paradigm shift for a classic OO mindset. XSLT is designed as a declarative language, delibrately avoided the concept of muteable variables which is vital for imperative (programmatic) configuration. This is just like not supporting pointers (i.e. direct memory access) in Java and not supporting record navigation (direct data access without cursors) in SQL DML had let a lot classic minds hard to accept them initially. The good frameworks nicely balances what code should be in the imperative language implemented components (beans), what code should be in the declarative XML configurations and XSLT stylesheets. Neither imperative programming style nor declarative paradigm is the silver bullet to address all issues at all levels.
> 
> Thirdly, all things in your mission impossible list are coincidentally supported in our IoC+DSM solution as handy to use features. For instance, our model transformer (even if it is based on XSLT 1.x) supports user-defined, subject specific and programmatic error reporting, our IoC container (and the core schema) supports dynamic configuration changes, and also it supports the configuration in your mission impossible increasing pool size example. 
> 

By Programmatic, I mean the opposite of
imperative. Everything that can be done
with xml should be doable from a java
program.

i.e. You shouldn't force people to make the
"paradigm shift" to IOC+DSM.

They shouldn't have to create a DOM tree
run it through an xslt before they can deploy a datasource
like they have do in our current implementation. :-)

> Cheers!
> Ke
> 
> >> Sincerely,
> >> Ke
> >> _______________________________________________
> >> jboss-development mailing list
> >> jboss-development at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/jboss-development
> >-- 
> >xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> >Adrian Brock
> >Chief Scientist
> >JBoss, a division of Red Hat
> >xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> >
> >_______________________________________________
> >jboss-development mailing list
> >jboss-development at lists.jboss.org
> >https://lists.jboss.org/mailman/listinfo/jboss-development
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx