RE: "Uh, what do I need this for" (was RE: XML.COM: How I Learne d to Love daBomb)

[Nicolas LEHUEN <nicolas.lehuen@ubicco.com>]

>> I have been developing for my company a kind of compiler 
>that enables us
>> to
>> embed XPath expression in Java code. We can now access any 
>random piece
>> of
>> data within a document as easily as we would have done with an object
>> model,
>> e.g. we can write things like invoice/line[5]/quantity in our Java
>> code
>> instead of invoice.getLine(5).getQuantity().
>
>You can't write invoice.getLine(5).setQuantity(10), nor 
>invoice.getTotalValue(),
>nor invoice.checkDeliveryAddressIsValid().

I only answered the first question in my previous mail... For
invoice.getTotalValue() and invoice.checkDeliveryAddressIsInvalid(), there
is indeed a problem. Whatever API or compiler you use, a pure data structure
does not contain any business methods. That's what I was referring to in the
4th point : this is NOT object-oriented programming, at least in the
business data domain (this does not means that the rest of your application
is not object-oriented).

However, if you read the J2EE blueprints (the official Sun recommendations
for implementing J2EE projects), you'll see that the situation is the same.
In fact, Sun recommend to build a DAO layer between the entity EJBs (which
contain the business logic such as checkDeliveryAddressIsValid) and the
database. This DAO layer can be generated automagically by an O/R mapper and
does not contain business logic at all, instead focusing on the problem of
data access. Thus, you get two layers of O/R mapping : the first one for the
DAO, the second one for the EJB (adding business logic).

What we do instead is to use XML in/as the DAO layer. If you need to add
business logic over this DAO layer, do it at your convenience. We use
separate process objects to do it. As our product is a multi-device
application layer, we have very few business logic on the presentation side.
Either the presentation-side business logic is simple, like a single-field
format validation, and we can easily implement it in the presentation layer
(based on schema specification) when processing forms (i.e. in the process,
not the entity), or it requires an access to the database, and we send all
data to a dedicated web service that can then use any technology (EJBs,
Tuxedo, etc.) to enforce business constraints.

Concerning the checkDeliveryAddressIsValid() method, we could do the same :
either the constraint can be expressed in a schema language, enabling us to
perform the check directly, or some Java code would have to be called. In
the latter case, the Java code could reside in the business process code, or
be associated to the schema, or even embedded in the schema (e.g. as XSDL
annotations !) and executed at will. The ability to dynamically generate,
compile and load Java code enables us to have a great flexibility on this
point.

Note that we have a bigger problem which is the non-support of transactions
by the current web services protocols. We use a kind of architectural
workaround for now (based on the fact that we "only" implement an
aggregation and presentation layers), but there is no doubt transaction
support will be required one day.

That's the reason why I am kind of skeptical about a transactional B2B use
of web services with the current technologies. But as a distributed
transaction relies basically on the propagation of the couple {transaction
monitor ID,unique transaction ID} accross processes, I don't think this is
something that can't be done with SOAP.

Regards,
Nicolas