[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]