OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [regrep] ebXML Registry and Workflow


<Quote>
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.
</Quote>

I'm thinking in terms of open standards: There is a great advantage in
using a standard XML vocabulary to describe access control policies,
just as there is a great advantages in using a standard XML vocabulary
to describe data that is to be aggregated from multiple systems into a
single location (ex: submission to a portal, as the federal goverment is
doing quite a bit these days). This standard XML vocabulary allows an
enterprise to aggregate access control policy information into a single
"enterprise-wide view" (or a series of sub-views), thus giving them a
complete picture of their access control settings - and allowing them to
easily identify where weaknesses may lie.

Joe

Anne Thomas Manes wrote:
> 
> 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
> >
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]