RE: Business-Oriented XML
Uhhh, let me tell you what comes and goes much more often than platform languages: scripting languages. You're proposing to exchange a widely understood, highly evolved programming language with a homebrewed scripting language that has a very high likelihood of becoming nothing more than a blurb in the jakarta-general list archives in a few years. The mere fact that your script has an XML form doesn't inherently give it staying power; hell, I could pretty easily define an XML form for Java grammar if I wanted to. Java is obviously not the endpoint of language design, but it does happen to be about as good as we have come up with so far. It's a great tool for defining business logic because it's flexible, fast (enough), and very widely understood. It has sufficient critical mass that it will be around long after you have gotten tired of working on BOX. So I don't buy the argument that BOX buys you longevity - the world of software is littered with dead scripting languages for dead tools. The problem I have with the BOX concept is that it is a step *backwards* from all the progress we have been making towards three-tiered architectures. The idea of a new scripting language which abstracts the writing of business logic in some useful way is not bad. The idea of binding it tightly to an HTML publishing framework is *terrible*. You talk about how important it is to separate business logic from presentation, yet you seem to have missed the primary *reason* for this separation - so that the business layer can live on long after any particular presentation technology is dead and gone. The point is that business logic *can* be reused in a Swing client, or as a SOAP service, or as part of some sort of XML messaging system, or with the Microsoft Telepathy Mouse, or whatever else comes along. Tying your business logic to HTML or HTTP isn't any better than embedding it in JSP pages. Jeff Schnitzer [EMAIL PROTECTED] -Original Message- From: Dave Jarvis [mailto:[EMAIL PROTECTED]] Sent: Saturday, November 17, 2001 11:08 AM To: Jakarta General List Subject: Re: Business-Oriented XML Hi, Jeff. I'm with Jon here: Why the heck would you want to do this? See previous reply. In addition, languages come and go. Remember when TurboPascal was hot? QuickBASIC? C and C++? Perl? PHP? What happens in 5 years when another awesome language makes an appearance and everyone forgets Java? Legacy code, I believe is the term. COBOL, FORTRAN, Smalltalk, etc. Tying yourself to a language isn't a viable long-term strategy. I love Java, don't get me wrong. But don't fool yourself into thinking it's going to be around forever. ;-) (This isn't flame bait; I'm using history and nearly 20 years development experience as a guide.) XML, on the other hand, is a technology with staying power and a history that extends back into the late 1960s! Another reason is that you can write more efficiently in a new language. I've found that BOX source is typically 5 to 30 percent smaller than equivalent Java. It has an extremely tight focus on basic business logic. for defining business logic. Why? It's trivial to define such logic in Java, and doing so avoids the limitations of your script (whatever they may be). The only limits are those imposed by the processing engine's implementation language. (Currently Java, but could be C, C++, Perl, etc.) Again, coupling yourself to Java (or any language for that matter) is not a good thing from a long-term perspective. What if you wanted to use a one-way hash on the passwords? What if user I had a similar problem already. The solution: var name=hashKey expr=generateHashKey( $parameter, $parameter2, $parameter3 )/ So long as generatePasswordHash is available to the system (neither defined nor imposed), it'll work. information was stored in EJBs or LDAP? What if you wanted to use the standard J2EE authentication and role-based security system? Can your script handle this? This can be solved in either of two ways: 1) Set up a small (internal) server that uses an XML-based protocol for information exchange. 2) Write a wrapper function to extract the information you want (e.g., generateHashKey). You can use whatever scheme you would like to test the password, limited only by your ability to express the behavior in Java. Furthermore, it if test=!checkPassword( $password ) var name=Phase expr='badPassword'/ stop/ /if As before, not limited to a particular language. But you might as well use Java, because Java rocks. :-) this example, the yourHelper object). How would your system reuse business logic to build a Swing client? No -- but then again, that wasn't what it was designed to do. It is meant for e-commerce/web-based solutions (plus interacting with remote servers via XML, simple file I/O, and database laughter). Nearly all e-commerce sites do
Re: Business-Oriented XML
on 11/17/01 11:07 AM, Dave Jarvis [EMAIL PROTECTED] wrote: Turbine is coupled to Java. It's not easy to use any particular database (e.g., an entire help section on how to integrate Oracle). With BOX, you set the default database with a straightforward configuration file: JDBC_DRIVER=org.postgresql.driver.Driver DB_URL=postgres://whatever:5432 DB_USER=username DB_PASS=password -- JDBC_DRIVER=com.oracle.driver.Driver etc. Note that this is used by the processing engine. If you want to write a processing engine in another language (like C++), then you have to derive a mechanism to do the database connectivity. The business logic never needs to know. Even better, you can add a DB_NAME property and extend the BOX language thusly: sql name='POSTGRESQL' ... /sql This allows people to dynamically choose a different database during runtime (note: completely backwards and forwards compatible; BOX is extensible). Turbine, like Maverick, also lets you shoot yourself in the foot with JSP. Ok. Now you are getting personal (by comparing to Turbine) and making a complete fool of yourself with your ridiculous FUD statements. BOX is just another wannabe web framework that is inventing yet more technologies and claiming to be the 'best' because you happen to like it and it works for you. p.s. I don't think you will get far with an argument about being coupled to Java as being negative around here. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Business-Oriented XML
Hi, Jon. Jon Stevens wrote: Ok. Now you are getting personal (by comparing to Turbine) and making a complete fool of yourself with your ridiculous FUD statements. I believe Jeff asked me how BOX compares with other technologies. I'm pointing out some aspects where I believe BOX to be better (i.e., simpler). How can I avoid such comparisons of details when I was specifically asked to compare technologies? (As the saying goes, The devil is in the details.) As for FUD, I see no reason to view what I write as encorporating fear, uncertainty, or doubt in any of the current technologies that are being compared. Each of the technologies available have their strengths and weaknesses. BOX, for example, can't do many of the things that Cocoon is capable -- but the niches are somewhat different. Where Cocoon does everything, at the cost complexity, BOX focuses on a subset of the problems Cocoon solves. BOX is just another wannabe web framework that is inventing yet more To me, the term wannabe implies that it _isn't_ a web framework. Please review the original document (http://www.joot.com/box) and let me know where, in that description, you come to the conclusion it isn't a web framework. Then, either please retract the word wannabe, or please explain how you've used the term wannabe in a sense that isn't negative. :-) Thanks. technologies and claiming to be the 'best' because you happen to like it and it works for you. I have never claimed it to be the 'best'. Please point out exactly where I said BOX is the best, or stop saying things on my behalf. I apologize if this is the impression I've given; it is certainly not what was intended. I have, on numerous occasions, pointed out aspects of BOX that are _simpler_ than other technologies. (In many cases simpler is indeed better, but not always best.) What I'm trying to illustrate is that BOX architecture makes life very easy for e-commerce sites that follow the algorithm I've outlined in a previous message: 1) Send HTML to browser. 2) Get information from browser. 3) Do something with that information (database, file, simple calculations) 4) Repeat from Step 1. Yes, I like it. It's simple. Yes, it works for me. But it wasn't developed with me in mind. It was developed because I saw a problem in the industry that needed a simple solution. I couldn't find one, so wrote something simple and extensible, building upon neutral technologies (XML, XSL, HTML, etc.) to solve the problem. The problem was, How can I code an e-commerce site that uses any database while decoupling logic from presentation? The problem also encompassed the question, How can I do this easily? And the problem also contained, How can it be state-driven? p.s. I don't think you will get far with an argument about being coupled to Java as being negative around here. A fair number of years ago people would have said the same thing about ANSI C. SGML has been around (at least conceptually), as I've mentioned, since the late 1960s. XML serves as a wonderful mechanism for information interchange--and has 30 years of development behind it. C had a fabulous run of popularity (Perl, Java, and C++ are slowly replacing it). I don't see how presuming the possibility of Java fading away is an invalid argument. Moreover, I cannot see how safeguarding against coupling yourself to ANY programming language is bad. Unless you possess a crystal ball, please don't tell me Java is going to be around forever. Does that mean Java isn't a good technology? Heck no. Does it mean we should avoid Java? Heck no. Every type of technology has its place -- what you need to do is look at the PROBLEM and figure out what technologies form a robust solution. Java is not meant to be THE technology for ALL problems. Once again, I am, sincerely yours, Dave Jarvis -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Business-Oriented XML
On Sun, 18 Nov 2001 11:03, Dave Jarvis wrote: Hello, Pete. punts on database neutrality and just prays that the SQL between databases is identical. And of course everyone who has worked with SQL knows that this is far from being true. You got me on this one. If you write SQL using specific database extensions (i.e., non-ANSI SQL), then you will be tying yourself to a particular flavour of database. This is a very important aspect that, on a practical level, seriously needs further research. In the ideal world, of course, all SQL would port gracefully between database vendors. ;-) Nice but not always possible. For instance in some databases like Access (or is that a pseudo-database ;-] ) you need to quote datetime values with # characters rather than ' characters. No way to fix that ... besides not using Access ;) How do you handle different quoting requirements for different databases? How do you handle different databases id generators? How do you handle difference X ? If you really need to do something different, and you want to abstract it so that it's all in one place, you can wrap it in a function (generateNextID): ... snip ... Only viable if your application is generating the IDs. This is not always the case. Many (most?) databases have some sort of generator, sequence or unique column. In this case you want the database to manage the key generation. Some databases require you to pass in a function name in sql, some require you to omit the column in insert altogether and theres probably some that require you to do completely different things. And lastly, I will admit I'm open to ideas on how this could be implemented in a simple, straightforward fashion. :-) Useful pointers to research is appreciated! Persistence layers, OR tools and the like. Turbine Torques an example of a relatively good layer - nicest to use I have found in opensource world. Then you have more highend solutions like EJBs entity beans. The person everyone thinks highly of in persistence world is Scot Ambler - never read his work but it would be worth looking at his stuff. I have no doubts about the performance of the architecture. Most of the grunt work was already done for me (by lots of people whose work I admire and appreciate): loading XML, parsing XML, rendering an XML document, translating it into XSL, encapsulating HTTP, etc. The only layer I add is a simple set of statements that allow people to talk with a database, file systems, and remote servers. And I throw in a state machine for good measure. The bottleneck isn't BOX. ;-) How does Cocoon perform under the same minimal conditions as above? impossible to say without doing direct comparisons with comparable complexity etc of pages. However it sounds like similar performance to Cocoon1 based apps (Do you use DOM?). Cocoon2 is much faster, though I have never used it. It would be best to query their group to get proper statistics. -- Cheers, Pete *-* | Never argue with an idiot, they'll drag you down to | | their level, and beat you with experience | *-* -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Business-Oriented XML
on 11/16/01 8:58 PM, Dave Jarvis [EMAIL PROTECTED] wrote: sql select * FROM WIC.FOURNIS WHERE COD_CLIENT=? ORDER BY NOM_FOURNIS /select using value-of expr=#WIC_CLIENT/ /using container name=results/ /sql Why the heck would you want to do this anyway? You have to be nuts to write SQL by hand anymore and why would you want to embed it into your code anyway? You guys have totally lost touch with simple concepts like 'MVC'... Ewww... -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Business-Oriented XML
Hello, again.
Neeme Praks wrote:
Have you ever had a look at Apache Cocoon project? That achieves all the
Yes.
benefits you outlined in your paper plus more.
Here are a few items BOX addresses that Cocoon does not (as far as I can
discern; please correct my errors):
o doesn't provide an inherent state-based architecture (it's an aside,
not focus)
o doesn't automatically apply a different view of logic based on the
domain
o extremely complex; it mixes multiple languages and odd syntax (e.g.,
connectDatabase)
o makes it easy to couple presentation and logic (see below)
o lacks an integrated expression parser
o doesn't expose a consistent syntax for doing tasks such as:
- file I/O
- sending XML to remote servers
- calling native code (Java, C, Perl, etc.)
- SQL statements
o cookies, FORM parameters, and URL encoded variables are not treated
uniformly
o doesn't use plain XML (i.e., embeds other language source directly)
If there's interest, I would be more than happy to illustrate a full
cycle of data acquisition (via HTML FORM) to SQL deposit, retrieval, and
final HTML page. For those who enjoy gory details, I've made a brief
comparison of Cocoon and BOX for two very simple examples. The first is
a little counter program, the second shows how to do SQL in both
tongues.
Sincerely,
Dave Jarvis
-=( First Example )=-
]] Cocoon's Logic (18 lines of code; tied to Java) [[
?xml version=1.0?
?cocoon-process type=xsp?
?cocoon-process type=xslt?
?xml-stylesheet href=page-html.xsl type=text/xsl?
xsp:page language=java
xmlns:xsp=http://www.apache.org/1999/XSP/Core;
xsp:logic
static private int counter = 0;
private synchronized int count() {
return counter++;
}
/xsp:logic
page
pI've been requested xsp:exprcount()/xsp:expr times./p
/page
/xsp:page
]] Cocoon's XSP (6 lines of generated code) [[
?xml version=1.0?
?cocoon-process type=xslt?
?xml-stylesheet href=page-html.xsl type=text/xsl?
page
pI've been requested 0 times./p
/page
]] Cocoon's XSL (10 lines of code) [[
?xml version=1.0?
xsl:stylesheet
xsl:output method=html encoding=US-ASCII/
xsl:template match=page
xsl:apply-templates/
/xsl:template
xsl:template match=p
xsl:apply-templates/
/xsl:template
/xsl:stylesheet
BOX code, in my opinion, is much simpler and straightforward, as there
is no intermediary XSP page:
]] BOX's Logic (7 lines of code; tied to XML) [[
?xml version=1.0?
businessLogic
main
session name=count expr=#count + 1/
tag name=count expr=#count/
/main
/businessLogic
]] BOX's XML (4 lines of generated code) [[
?xml version=1.0?
document
count0/count
/document
]] BOX's XSL (7 lines of code) [[
?xml version=1.0?
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:output method=html encoding=US-ASCII/
xsl:template match=document
PI've been requested xsl:value-of select=count/ times./P
/xsl:template
/xsl:stylesheet
By adding babel tags around the English text, you automatically get
a stylesheet that is in the viewer's language (based on their browser's
Accept-Language). This is part of the architecture; no extra futzing is
required. BOX makes it difficult to couple logic and presentation. For
example, to write a p tag with logic, you must write tag
name=p/. XSL is where the p tag belongs; not snuggled in with
logic.
Let's look at a slightly more complex example, involving SQL. First
Cocoon, then BOX.
-=( Second Example )=-
]] Cocoon Logic (20 lines of code) [[
?xml version=1.0 encoding='ISO-8859-1' standalone=no?
?xml-stylesheet href=../xsl/wic_fournisseursListe.xsl
type=text/xsl?
?cocoon-process type=xsp?
?cocoon-process type=xslt?
!DOCTYPE page SYSTEM ./librairies/entity.dtd
xsp:page
language=java
xmlns:xsp=http://www.apache.org/1999/XSP/Core;
xmlns:session=http://www.apache.org/1999/XSP/Session;
xmlns:request=http://www.apache.org/1999/XSP/Request;
xmlns:response=http://www.apache.org/1999/XSP/Response;
xmlns:sql=http://www.apache.org/1999/SQL;
xmlns:log=http://www.arctis.com/2000/XSP/Log;
create-session=true
page title=Liste des fournisseurs
xsp:logic
try {
sql:execute-query
connectDatabase;
sql:doc-elementFOURNISSEURS/sql:doc-element
sql:row-elementFOURNISSEUR/sql:row-element
sql:query
SELECT * FROM WIC.FOURNIS
WHERE COD_CLIENT = 'session:get-value name=WIC_CLIENT/'
ORDER BY NOM_FOURNIS
/sql:query
/sql:execute-query
}
catch (Exception e) {
response:send-redirect location=wic_erreur.xml?Langue=FR/
}
/xsp:logic
/page
/xsp:page
]] Cocoon XSL (43 lines of code) [[
?xml version=1.0 encoding='ISO-8859-1'?
?cocoon-format type=text/xsl?
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns=http://www.w3.org/TR/xhtml1/strict;
xsl:import
Re: Business-Oriented XML
On Fri, Nov 16, 2001 at 08:58:06PM -0800, Dave Jarvis wrote: Hello, again. Neeme Praks wrote: Have you ever had a look at Apache Cocoon project? That achieves all the Yes. benefits you outlined in your paper plus more. Here are a few items BOX addresses that Cocoon does not (as far as I can discern; please correct my errors): o doesn't provide an inherent state-based architecture (it's an aside, not focus) Nope, they threw out the reactor (state machine) pattern as being too hard to manage. o doesn't automatically apply a different view of logic based on the domain Certainly can :) Have a look at Cocoon 2's class org.apache.cocoon.selection.HostSelector. o extremely complex; it mixes multiple languages and odd syntax (e.g., connectDatabase) That's just your particular XSP, which uses an XML entity connectDatabase; to pull in other XSP. If you put your logic in logicsheets as intended, then your XSP pages are pure XML. o makes it easy to couple presentation and logic (see below) Actually, XSP makes it easy to mix *content* and logic (presentation is in XSLs). o lacks an integrated expression parser o doesn't expose a consistent syntax for doing tasks such as: - file I/O - sending XML to remote servers Have a look at Cocoon 2's xscript SOAP demo (xscript being an XSP equivalent of James Strachan's xtags taglib). - calling native code (Java, C, Perl, etc.) - SQL statements o cookies, FORM parameters, and URL encoded variables are not treated uniformly o doesn't use plain XML (i.e., embeds other language source directly) Anyway, if you've got time, hop on cocoon-dev.. I'm sure there's much mutual learning to be had (it's a fun place to lurk anyway). Cocoon 2 has a very generic architecture, and I've no doubt that your code could be integrated as an XSP alternative. --Jeff -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
