Mail Archive Home | architecture List | August 2004 Index
Re: [architecture] Fwd: greeting from XimpleWare
- Subject: Re: [architecture] Fwd: greeting from XimpleWare
- From: claus.hirth@xxxxxxxxxxxxxx
- Date: Wed, 11 Aug 2004 21:28:37 +0200
"Jimmy zhang" <jzhang@xxxxxxxxxxxxxx>
schrieb am 11.08.2004 09:58:22:
> Claus, Thanks for the comments. However, having dependency on
> interface is often regarded as not good enough.
> businesses evolves, new partners, activity, rules
will drive the schema
> to evolve along the business change. In this
regards, CORBA and
> RMI is usually considered a little brittle, not
well suited for app
I don't agree in full, though I would support your
specifically RMI is not much suited for enterprise
[ Database ] Schemas are to be managed _behind_ interfaces.
[ Request ] Schemas and the semantics of requests
are to be pinned down
by an interface contract. Whether or not the interface
contract is supported
by some means of automatic checking (eg static type
checking) or not, it
remains an interface contract.
An interface contract can include some portions that
flexible, and robust against evolution or change:
To support 'business schema evolution' you can for
example provide functions
in the interface that accept nested Name-Value-Containers
; such as a
java.util.Properties instance to name the most basic
I have designed and implemented interfaces that way
many times, some dating
back to 1998Q4, and those interfaces still work unchanged,
while the set of data fields, the 'business schema',
has changed a lot [ a whole lot ] over the years.
This is just to say that I am very well aware of the
need to allow
things to remain flexible: changing business rules,
changing partners, etc etc.
Interfaces _must_never_ be changed in COM, CORBA,
RMI, etc. -- and every
programmer is explicitly told so. No half full or
half empty philosophy
possible here. ;-)
Whenever you change an interface contract you are
breaking your system,
and more importantly, other's systems, too.
Whenever you fail to foresee a relevant possibility
for evolution or
change when designing an interface, you will be building
which is brittle relative to this specific aspect.
Member of the
> I heard cases where two RMI had trouble conversing
with each other :(.
> I think XML is a step forward from that point
of view. But every pros has
> a con, a bottle is half empty of half full...
> ----- Original Message -----
> From: claus.hirth@xxxxxxxxxxxxxx
> To: Jimmy zhang
> Cc: college@xxxxxxxxxxxxx ; architecture ; executive-committee@xxxxxxxxxxxxx
> Sent: Tuesday, August 10, 2004 11:42 PM
> Subject: Re: [architecture] Fwd: greeting from
> "Jimmy zhang" <jzhang@xxxxxxxxxxxxxx> schrieb am 11.08.2004
> > Claus,
> > Thanks for the email. Whether XML is human-readable
> > to do the very meaning of "human-readable." I think
> > makes XML unique is the combination of open, interoperable,
> > loose-coupling and (almost) human-readable.
> You just confirmed my point here. :-)
> > Loose-coupling
> > means that, similar to HTML, a Web services application
> > have the option of processing only what it intends to understand
> > and process, and disregard other parts of the contend, and not
> > break the application.
> > The same thing can't be said of RMI or
> > CORBA, which must have a schema before hand. The problem
> > is that when people changes implementation, they inevitably
> > have to the change the data itself, which breaks applications.
> No, only when they change interfaces ; -- and they know they must
> not do that...
> > For Enterprise App Integation, interoprability is the
> > important thing, XML is *ideally" suited for that.
> I think that is still a subject matter under dispute. No doubt
> XML has a lot to offer -- but *ideally* is too much of a claim.
> > Adam bosworth
> > had a very article on this,
> > http://www.fawcette.com/xmlmag/2002_04/magazine/departments/endtag/
> > Let me know what you think of it.
> I would not recommend reading that article: it's too shallow.
> I can find no proof in the above article for the claim that XML
> would be *ideally* suited to solve the interoperability problem.
> Today's XML is part of the problem (! not of the optimum solution
> because it allows for so many encoding variations, which requires
> XML processors to be more complex than inherently necessary.
> That is at the core of the suggestion I made yesterday (see
> quotation below).
> Yet, let all this aside, in my opinion:
> your approach seems to be valuable for dealing with today's XML,
> and should therefore be analyzed closer by OW for possible
> Kind regards
> Claus Hirth
> > Cheers,
> > Jimmy Zhang
> > ----- Original Message -----
> > From: claus.hirth@xxxxxxxxxxxxxx
> > To: Jimmy zhang
> > Cc: francois.letellier@xxxxxxxxxxxxx
> > Sent: Tuesday, August 10, 2004 1:37 PM
> > Subject: WG: [architecture] Fwd: greeting from XimpleWare
> > Dear Jimmy,
> > François,
> > quote from http://www.w3.org/2003/08/binary-interchange-workshop/20-
> > ximpleware-positionpaper-updated.htm :
> > "XML is, by design, human-readable [ ... ]"
> > That is not so, quite remarkably. Consider
> > (1)
> > XML does not prescribe one, and only one, standard encoding.
> > Therefore any XML Editor or XML Viewer must deal with eg character
> > encoding declarations at
> > attribute level.
> > See http://www.w3.org/TR/2000/REC-xml-20001006#charencoding
> > (2)
> > For URIs, XML requires everything that is non-ASCII to be encoded
> ineg UTF-8,
> > which is not what I would call human-readable.
> > See http://www.w3c.org/TR/xmlbase/#escaping
> > --
> > So really, XML is designed to be completely
> > * transferable through every network on the market,
> > * storeable on any storage device on the market,
> > but it is not designed to be completely following the 'view source
> > although XML in most practical cases does come close to this
> > --
> > The following are the conclusions to draw from the need for both
> > * readable source 'view the source'
> > * efficient marshaling for network and storage transfer:
> > (1) Define a standard 'view the source' form for 'XML';
> > eg: require it to be encoded as UCS-4,
> > because that is the only possible realistic choice.
> > Consequence: you can't 'view the source' if your
> > display all the characters from UCS-4.
> > (2) Compile the 'view the source' form to a networkable form
> > whenever you save the source from your editor.
> > A network byte order binary XML representation
would be one
> > possible networkable form.
> > Consequence: a standardized and portable compiler
must be made
> > available in a FOSS implementation.
> > (3) Require XML processors to understand both the binary standard
> > and the 'view the source' form, of 'XML'.
> > Reason: That let's the user choose whether he wants
> the source'
> > or whether he wants optimum marshaling performance.
> > Note: By this we also require any XML-View-The-Source-Editor
> > able to read and display 'network byte order binary
XML' as if it
> > were a 'UCS-4-encoded XML'.
> > (4) Encourage the transitional support for the current alternativeencodings
> > of XML such as UTF-8, UTF-16 in XML processors
to support existing
> > 'legacy-XML' documents and applications.
> > I would be interested to hear your opinions on this. I'd be especially
> > interested, and grateful, if you can point out any flaws that
> > slipped in.
> > Kind regards
> > Claus Hirth
> > Diplom-Informatiker Universität
> > Member of the ObjectWeb Consortium
> > ----- Forwarded by Claus 2003-05 Hirth/eMaert on 10.08.2004 21:50
> > Francois Letellier <francois.letellier@xxxxxxxxxxxxx> schrieb
> > 08.2004 11:56:45:
> > > Hi all,
> > >
> > > FYI: XimpleWare is currently considering joining OW and
> > > their project, VTD-XML, as an OW project.
> > > The email below explains it all...
> > >
> > > - Francois
> > >
> > >
> > > >From: "Jimmy zhang" <jzhang@xxxxxxxxxxxxxx>
> > > >To: <francois.letellier@xxxxxxxxxxxxx>
> > > >Subject: greeting from XimpleWare
> > > >Date: Mon, 9 Aug 2004 13:31:16 -0700
> > > >
> > > >
> > > >Hi, Francois,
> > > >
> > > > How are you? Hope all is well.
> > > >
> > > > It was nice talking with you last week in Linux
> > > >I am just glad to know that ObjectWeb is offering the
> > > >world such a great product for free.
> > > >
> > > > We (ximpleware) recently released an open source
> > > >software called VTD-XML on sourceforge
> > > >(http://vtd-xml.sf.net). The goal is simple: we want
> > > >make XML Web services applications scale. The
> > > >problem with current generation XML processing
> > > >technology is it will suck up to 90% of CPU cycles.
> > > >There has been a lot of interesting development in
> > > >W3C over the subject of binary XML. Our position
> > > >paper is available at
> > > >http://www.w3.org/2003/08/binary-interchange-workshop/20-
> > > ximpleware-positionpaper-updated.htm
> > > >which gives a pretty good overview of the technology.
> > > >
> > > > We are very interested in learning more on how
> > > >We can partner with Object web to deliver move
> > > >the XML web services initiative forward. Could you
> > > >suggest procedures or contacts within ObjectWeb?
> > > >I appreciate your suggestion of any kind.
> > > >
> > > >Best regards,
> > > >Jimmy Zhang
> > > >===========
> > >
> > >
> > >
> > >
> > > --
> > > You receive this message as a subscriber of the
> > > architecture@xxxxxxxxxxxxx mailing list.
> > > To unsubscribe: mailto:architecture-unsubscribe@xxxxxxxxxxxxx
> > > For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
> > > ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Powered by MHonArc.
Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.