Re: Business-Oriented XML

[Jon Stevens]

on 11/18/01 9:11 PM, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:

> I think this is a little disingenuous. XML has its history in SGML, yes.
> However, the SGML standard (ISO 8879) was published in 1986. It's also true
> that SGML was originally based on GML. However, to claim that XML has "a
> history that extends back into the late 1960s" is really to claim that XML
> has a history in markup languages. Yep, and Java has a history in
> programming languages, which go back even further. ;-)
> 
> --
> Martin Cooper

I agree.

Creating a language parser and compiler is generally pretty difficult.
However, XML is easily parsed and converting the tags (markup) into
something that can be executed is pretty easily done.

It makes me want to puke every time I see someone repeat using XML as a way
to create their own language because when real languages are designed, quite
a bit of thought goes into creating the grammar and how things fit together.

When Joe Foo is able to snap together his own pseudo language out of XML
tags, I go running. It is just silly to use XML to define a language. It is
a markup definition tool. Having a way to easily parse it and deal with it
does not make it a language!

Regardless of history, I see BOX as being just another wannabe framework.
When I say wannabe, I don't mean that it doesn't yet exist or is trying to
be something it is not. I mean that it is some guy out there pushing on the
world what he has created for himself and completely ignoring the fact that
there are already a bazillion other tools out there that do exactly the same
thing, just as easily, only in different ways.

Yawn. This discussion is boring, how many times has someone come around here
pushing their new and improved web app framework that does everything?

-jon


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

Re: Business-Oriented XML

[martin . cooper]

I think this is a little disingenuous. XML has its history in SGML, yes.
However, the SGML standard (ISO 8879) was published in 1986. It's also true
that SGML was originally based on GML. However, to claim that XML has "a
history that extends back into the late 1960s" is really to claim that XML
has a history in markup languages. Yep, and Java has a history in
programming languages, which go back even further. ;-)

--
Martin Cooper


- Original Message -
From: "Dave Jarvis" <[EMAIL PROTECTED]>
To: "Jakarta General List" <[EMAIL PROTECTED]>
Sent: Saturday, November 17, 2001 11:07 AM
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:
>
> 
>
> 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
>
> 
>   
>   
> 
>
> 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 the following:
>
> 1) Present HTML to the user.
> 2) Gather information from the user.
> 3) Do something with that information.
> 4) Loop to Step 1.
>
> I'm under the impression that Cocoon is a bulldozer for such a trivial
> scheme.  BOX, keeping the analogy, would be a shovel: simple,
> straightforward, precise, and almost intuitive.  (The only truly
> intuitive interface is the nipple.)
>
> I don't think this point can be stressed enough: BOX's design goal is to
> solve the aforementioned 4-step process.  It is tightly integrated with
> XML, XSL, SQL, and file I/O -- to the intentional exclusion of all
> else.  It has minimal facilities required to run native code via
> embedded function calls.  GUI-based applications and batch processing
> are beyond its ken: they would only serve to complicate the
> architecture.
>
> BOX inherently knows about state transitions, broken down by Stages and
> Phases.
>
> > And about the last point you brought up... how is your system any more
> > platform, language, or database neutral than Struts, Maverick, Turbine,
> > or WebWork?
>
> If the system is coupled with Java, you lose language independence.
> When I say "language" I don't mean human languages.  Just in case there
> was some confusion.  However, BOX is both programming language and human
> language neutral.
>
> STRUTS
> --
> Struts is inextricably tied to Java.  Struts also couples logic and
> presentation (or can):
>
> 
>
> What if I wanted to limit the user names to a selection list?  (Silly
> example, but the idea can cause significant ripple effects; consider
> typing in a c

RE: Business-Oriented XML

[Jeff Schnitzer]

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:
> 
> 
> 
> 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
> 
> 
>   
>   
> 
> 
> 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 the following:
> 
> 1) Present HTML to the user.
> 2) Gather inf

RE: Business-Oriented XML

[Zulq Alam]

> If you write SQL using specific database extensions (i.e., non-ANSI SQL)

Access isn't the only problem here. Oracle 8 does not support ANSI style
joins. For example,

SELECT A.column, B.column
FROM A LEFT OUTER JOIN B ON A.id = B.id

Note that the Oracle JDBC driver does not support {oj } escape sequences.

Does cocoon or BOX have any scope for a translation layer of some sort?

Cheers,
Zulq.

-Original Message-
From: jarvisd [mailto:jarvisd]On Behalf Of Dave Jarvis
Sent: 18 November 2001 00:03
To: Jakarta General List
Subject: Re: Business-Oriented XML


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

> 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):



INTO TABLE VALUES (?, 'John', 'Smith')





I will freely admit this isn't a great way (heck it isn't even a _good_
way); just showing it can be done.

I will also admit that it doesn't have all the necessary bells and
whistles to take into consideration specific implementation differences
across all databases.  But even in Cocoon (and as you said, Turbine),
you can still do your own database-specific SQL which, in turn, lowers
the portability of the system.  No matter what you do, if you give the
programmer full control over the SQL query, they'll always be able cause
system dependencies.

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!

> I still see your project as basically a Generator for cocoon + cut down
> processing engine. I would be surprised if you could reach the performance

Yes.  Simple, and quite focused.  Did I mention small and fast?  ;-)

> level of the Cocoon2 pipeline just because they have had a lot of people
> workin on it.

On a 96MB RAM, 266 MHz machine, 4GB 5400 RPM drive (I think), running
Mandrake Linux 8.1 (in low-security mode; X was not installed), Tomcat
3.2, JDK 1.3, Xalan 2.2 D6 (or so), and Xerces 2.0 beta 2, using a
remote Oracle 8i development server, it sustained a firing of more than
10 hits/sec. on the main page (using a 100MBit intranet). I could use
the site, but it was sluggish.

I tried again, using the same box, with hardware upgrades: 352MB RAM and
400MHz Pentium II.  Under the same load of 10 hits/sec. the sluggishness
disappeared.

Using IBM's 'jikes' to compile, the single supporting JAR file (without
manifest information) is exactly 48651 bytes.  The single servlet that
launches the processing engine is 6865 bytes.  I could use Hashjava to
get it maybe 15% smaller ... but 41300 bytes vs. 48600 bytes is not
worth the effort.

I've tested the architecture against an HTML-based servlet-only site
with the exact same functionality as the BOX code.  The servlets were
faster, but the difference in speed was less than a second.  Keep in
mind the servlets have no extra transformation step -- they output pure
HTML to the browser.

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?

Sincerely,
Dave Jarvis

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


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