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


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

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

Subject: RE: [emergency] Whatever Happened to the Public UDDI? Web Service s Registries Fad e

That works.  The agencies can then work out what information 
they wish to share.  I note also the Microsoft work on Regional 
Area Information Networks (RAIN).  I am not familiar with the 
details.  This has to be done on a case by case basis given 
the fairly substantial differences among agencies in given 
communities.  Standards for statistical data reporting (say 
UCR or NIBRS) are quite good.  Standards for interagency 
information sharing content are nascent in some cases and 
well developed in others (say agency to state requests for 
names and vehicle information through state message switches 
and NCIC). 

The shared report requirements are pretty good but vary by 
state and then, one has to hope the local agency is using 
the state standards.

Just FYI:  most permissions over files are role and group based 
within an agency.  I would expect the portal to reflect that.


From: Rex Brooks [mailto:rexb@starbourne.com]

This is all true and about to change, hopefully for the better, very 
soon. Karl Best made several announcements yesterday of 
specifications now submitted for voting upon as OASIS-wide standards, 
and one of them is WSRP, Web Services for Remote Portlets. While this 
deals mainly with Portals per se, it seems likely that most web 
services will employed within such a structure for just these access 
control and security reasons, and for achieving the ability to define 
permissions within producer, consumer and user contexts 
appropriately. This spec was designed in conjunction with JSR168, the 
Java Portlet spec, to ensure a wider applicability and has been 
tested with J2EE and .Net.

It should be noted that registries are going to be quite useful, but 
need only be starting points for more complete negotiations and 
contracts. Some will, some won't. UDDI and ebXML are there now and 
can be added to.

CAP will be ready sooner rather than later. That sets the stage for 
some fairly important developments.


At 12:41 PM -0500 7/29/03, Bullard, Claude L (Len) wrote:
>Right.  In industry, the keiretsu phenomenon dominates.
>One needs not just partners, but credible partners.
>And rules are very different given the process, say
>a procurement offer vs a services offer, and so on.
>UDDI doesn't help much here and it can actually make
>it much tougher to negotiate a good deal.
>The same can be said of public safety agencies, but one
>questions if that can be maintained in the face of current
>events and requirements.  However, what the public safety
>groups as a whole should be discussing are the services
>that can be exposed more or less across agencies of
>different types because this cannot be based on the
>data they create or share.  As you know, the Internal
>Affairs group cannot expose name or incident information
>to other internal agencies.  Dissemination Management
>is required to ensure redaction of information shared
>to the public given a juvenile, for example, and so
>forth.  So the business rules for standard services
>have to be worked out.  A registry is fairly easy
>given that.
>From: Aerts, John F. [mailto:jfaerts@lasd.org]
>Yvonne L. Lee and David Rubinstein, Software Development Times
>A few years ago, when Web services were envisioned as creating
>interconnected applications that spanned across businesses, public
>Universal Description, Discovery and Integration (UDDI) registries
>were seen as a tree on which to find the fruit -- or external Web
>services. Now that Web services are used almost exclusively for
>internal development and integration, not only has the hype
>surrounding the public UDDI registries subsided, but the
>information in them hasn't grown either.
>You may leave a Technical Committee at any time by visiting
>You may leave a Technical Committee at any time by visiting 

Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request

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