[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] ebXML Registry and Workflow
Anne Thomas Manes wrote: >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. > The point is that a standard distributed content management system allow for information to be linked across implementations (e.g. ebxmlrr, YellowDragon Software) in a loosely coupled manner with no prior contracts between operators. That is what a CMS standard provides. > >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. > XACML does not require passing any token around. XACML policies stay put managed within some ebXML Registry like any other reopository item. Howver a policy in one registry may be used for one or more objects in any ebXML Registry. This distributed policy based fine grained authorization has a lot of unrealized potential. >The gnarly part is authentication, not authorization. > I beg to differ. Authentication is much simpler. Its like having a badge that says who you are. No big deal. However, deciding what Anne is allowed to do to whom is much more complex. Traditional authz prior to XACML have not even scratched the surface. >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. > We are actually having very good luck with adoption in some very significant enterprises. This with no marketing machine or large company pushing the technology. > >And this is the real crux of the problem. You ask: Why not ebXML regrep? But >that's the wrong question. > I agree. That is a bit self serving ;-) Adoption will happen because we provide compelling new value that their old tools do not. >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. > I would rather show them why ebXML Registry is the best solution instead of why interwoven is not enough. >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? > I would be very interested in your analysis of how UDDI+interwoven stack up with CMS capabilities of ebXML Registry 2.5. Thanks in advance. > >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 > > > > >You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php > > > -- Farrukh
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]