Re: [regrep] ebXML Registry and Workflow

["Anne Thomas Manes" <anne@manes.net>]

So compare ebXML repository with Interwoven....

As I said, I think the traditional CMS products are a much tougher nut to
crack -- and if you look back at Peter's question, CMS comes up more
frequently than DBMS.

The fact that ebXML regrep is a standard isn't relevent until there are a
host of tools and services available that support the standard. There are
lots of tools that support SQL and XPath. There will be lots of tools that
support XQuery. Will there be lots of tools based on ebXML regrep? That is
the question.

I don't follow your comment that databases don't support SQL, XPath, and
XQuery in "a standard way". The query languages *are* the standards. But
perhaps you're talking about the envelope format? My point is that you will
have a very hard time convincing people that a standard envelope adds
significant value to a standard query facility. The database systems supply
APIs and tools that hide the mechanics of the envelope.

Although I appreciate the value of XACML as a way to pass authorization
information around, most database and content management systems implement
access control in the database, so there's no need to pass authorization
tokens around. The gnarly part is authentication, not authorization. But the
database systems are becoming more sophisticated when it comes to
authentication. They now support multiple authentication mechanisms, and as
I said before, they map the authentication credential to a known principal.
Then the database evaluates the principal and the access control policies
and makes an authorization decision. Again, I think you'll have trouble
convincing people that a new XACML-based security system is better than what
they're familiar with.

And this is the real crux of the problem. You ask: Why not ebXML regrep? But
that's the wrong question. People use the tools that they're familiar with.
You won't convince people to use ebXML unless you can show them why
Interwoven or other established CMS products are insufficient to manage Web
services metadata. Interwoven isn't just a CMS. It's a CMS that's tightly
integrated with the entire Web application development environment. And
Interwoven is extending its products to fully support Web services. How will
you compete with the combination of UDDI registry and Interwoven repository?

Anne

----- Original Message -----
From: "Farrukh Najmi" <farrukh.najmi@sun.com>
To: "Anne Thomas Manes" <anne@manes.net>
Cc: "Peter Kacandes" <pkacande@adobe.com>; "Chiusano Joseph"
<chiusano_joseph@bah.com>; <regrep@lists.oasis-open.org>
Sent: Thursday, June 26, 2003 10:31 PM
Subject: Re: [regrep] ebXML Registry and Workflow


> Anne Thomas Manes wrote:
>
> >I beg to differ.
> >- Most databases can now handle arbitary content very easily. They can
store
> >any arbitray XML as a CLOB, or they can shred an XML document and map the
> >various elements to a set of tables -- your choice.
> >
> Content Management requires more than storing something as a CLOB. It
> requires life cycle mangement
>
> >Most databases now also
> >support XPath and XQuery queries against both CLOBs and shredded data
(and
> >even against regular relational data) -- returning results as XML.
> >
> Some may do so in a proprietary way. They do not do this in a standard
way.
>
> >- Many databases now provide a Web interface that supports SQL, XPath,
and
> >XQuery queries.
> >
> Some may do so in a proprietary way. They do not do this in a standard
way.
>
> >- SQL has been a standard for much longer than XML. The SQL System tables
> >are standard metadata representations
> >
> >
> Systems tables do not define services, organizations, people, resources
> etc. They define tables, columns, indexes etc. Stuff that no one in real
> life cares about.
>
> >- Most databases allow you to expose stored procedures and table function
as
> >Web services. Table functions can also invoke Web services.
> >
> Some may do so in a proprietary way. They do not do this in a standard
way.
>
> >- All databases provide extremely rich, fine-grained authentication and
> >authorization services -- admitedly the administration process is
> >proprietary, but in all cases it just comes down to mapping an
authetication
> >token to a principal and then applying the authorization rules.
> >
> Some may do so in a proprietary way. They do not do this in a standard
way.
> Not ONE of them supports the rich capabilities of XACML. We  adopted
> XACML literally the day it was finalized!
>
> >All database
> >systems support signatures as an authentication mechanism. How the
mechanism
> >works is transparent to the user -- only the administrator has to worry
> >about setting it up.
> >
> That has not been my experience.
>
> >- All database systems support content-based notification services -- and
> >they are customizable to support a variety of notification mechanisms.
You
> >can receive your notification via IM, email, SOAP, etc.
> >
> Some may do so in a proprietary way. They do not do this in a standard
way.
>
> >
> >I agree that database systems don't provide first class support for
> >taxonomies -- although it's pretty trivial to store a taxonomy in a
> >database. I generally think of taxonomies as a feature of the registry,
> >though, not the repository.
> >
> >The big downsides to storing arbitrary data in a relational database are:
> >- performance of CLOB searches and shredding is generally horrendous
> >- A database doesn't provide version management facitlities
> >
> +1
>
> >
> >I tend to be rather conservative about data stores, so I would discourage
> >most people from storing XML metadata in a relational database. The more
> >pressing question is why not just store the metadata in a traditional
> >content management system?
> >
> What exactly is a traditional CMS? There are NO CMS standards today.
> ebXML Registry is the only CMS standard I am aware of. Please confirm or
> deny this assertion.
>
> I would venture to say that an ebXML Registry is a better CMS because it
> is built on the latest standards and has sophisticated feature set.
>
> The questions is: Why not ebXML Registry? Is there something inherently
> wrong with it?
>
> Here is my mantra for ebXML Registry V3:
>
> -ebXML Registry is to web service what databases were to enterprise
> applications
>
> -ebXML Registry is a general purpose Content Management System today.
>
> Here is my mantra for ebXML Registry V4:
>
> -ebXML Registry will be a Semantic Content Management System in version 4
>
> -ebXML Registry will be to the Semantic Web what Web Servers are to the
> Web today
>
> -ebXML Registry will be the Semantic Web Server
>
> Carl please consider above for our brochure ;-)
>
> This is a great thread for helping us articulate our niche and core
> competency. Thanks.
>
> --
> Farrukh
>
>
> >
> >Anne
> >
> >----- Original Message -----
> >From: "Farrukh Najmi" <farrukh.najmi@sun.com>
> >To: "Peter Kacandes" <pkacande@adobe.com>
> >Cc: "Chiusano Joseph" <chiusano_joseph@bah.com>;
> ><regrep@lists.oasis-open.org>
> >Sent: Thursday, June 26, 2003 4:36 PM
> >Subject: Re: [regrep] ebXML Registry and Workflow
> >
> >
> >
> >
> >>Peter Kacandes wrote:
> >>
> >>
> >>
> >>>The other question I get is why shouldn't they just use a database?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>Here is an initial listr of reasons why ebXML Registry is better:
> >>
> >>-Databases cannot handle arbitrary content very well
> >>
> >>-Databases do not provide a standards based web interface
> >>
> >>-Databases do not provide standards based distributed capabilities
> >>
> >>-Databases do not provided a standard metadata representation
> >>
> >>-Databases do not provided authentication based on digital signatures in
> >>a standard way
> >>
> >>-Databases do not provided fine grained authorization based in a
> >>standard way
> >>
> >>-Databases do not provide content based event notification in a standard
> >>
> >>
> >way
> >
> >
> >>-Databases do not provide first class support for taxonomies
> >>
> >>-Databases do not provide first class support for services
> >>
> >>-Databases do not provide first class support for content management
> >>(cataloging, validation)
> >>
> >>
> >>
> >>--
> >>Farrukh
> >>
> >>
> >>
> >>You may leave a Technical Committee at any time by visiting
> >>
> >>
>
>http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup
.
> >php
> >
> >
> >
> >
> >You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.
php
> >
> >
> >
>
>
>
>
> You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.
php
>