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

 


Help: OASIS Mailing Lists Help | MarkMail Help

egov message

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


Subject: Re: [egov] ebXML and web services


Paul,

Excellent points. Please see comments below.

<Quote1>
It seems logical (to me at least) that the transactions would use ebXML
and the services would use SOAP/WSDL.
</Quote1>

Citing your "file a tax return" example: Although one does not require
any aspect of the ebXML framework to carry out such a transaction (it
has often been done with an HTML page using ASP and an HTTP POST to
submit the tax return form), such a transaction *could* be part of an
ebXML framework. It all depends on what the overall business/system
objective is.

Regarding SOAP/WSDL: These are, of course, major component of an XML Web
Services capability. 

<Quote2>
Treating each separately, the ebXML part
</Quote2>

I'd like to add a gentle clarification regarding the thought of ebXML
and Web services being separately treated. An OASIS/ebXML registry has
the capability to store and maintain Web services descriptions in
addition to XML artifacts such as schemas (and more). I recently
co-authored a Technical Note on this subject [1]. So one can think of
ebXML and Web Services as "existing together" rather than separately.

<Quote3>
the ebXML part would need an ebXML registry in which would be stored
business process specifications and CPPs (among other things). 
</Quote3>

There is no requirement in the ebXML framework that these items be
stored in an ebXML registry - but it is certainly a valid scenario, and
the OASIS/ebXML registry certainly accomodates these (as it does any
content, due to the registry architecture's abstract nature).

<Quote4>
Typically, the services would use a UDDI registry.
</Quote4>

...or an OASIS/ebXML registry (please reference "An OASIS/ebXML registry
has the capability to store and maintain Web services descriptions..."
above). I have been speaking/writing about this very topic quite a bit
lately - please see my March 2003 WebServices.org article titled "UDDI
and ebXML Registry: A Co-Existence Paradigm" [2]. What I am essentially
saying in the article is:

UDDI --> For discovery (of business information and Web services
descriptions)

ebXML registry --> For discovery (of business information and Web
services descriptions), PLUS collaboration (using XML artifacts that are
stored and maintained in an ebXML registry)

I am also conducting a pilot within the Federal CIO Council XML Web
Services Working Group titled "Web Services and Registries" [3], whose
main objective is "to demonstrate the capability of UDDI and ebXML
registries to interoperate during Web Services-based collaborations". In
this presentation I also describe my "Three-Tier Vision" for
interoperability between UDDI and ebXML registry, which I anticipate
will be the subject of a near-future article.

<Quote5>
And what about combining SAML into this?
</Quote5>

That's a great point - as you know, SAML is on the "authentication" side
of things, and also provides Single Sign-On (SSO) capabilities. So SAML
would be used to authenticate a user to a Web Service, and/or in
conjunction with an authorization mechanism (i.e. a request to access a
resource such as a file system). 

In the latter aspect, SAML could be used in conjunction with OASIS
eXtensible Access Control Markup Language (XACML) to (from SAML 1.0
spec[4], p.8) "convey information about authentication acts performed by
subjects, attributes of subjects, and authorization decisions about
whether subjects are allowed to access certain resources.". And there's
also Liberty Alliance [5], whose version 1.0 specification leverages
SAML. In April, Liberty Alliance contributed their Phase 1 Network
Identity specifications to OASIS for consideration in SAML 2.0 [6].

Also: In the U.S. federal government, there is an initiative called
E-Authentication [7] that hosts an "E-Authentication Gateway" that
agencies can use to authenticate users of their online services.

I hope you find all of this information helpful.

Kind Regards,
Joe Chiusano
Booz | Allen | Hamilton

[1] http://xml.coverpages.org/RegisteringWebServices.pdf
[2] http://www.webservices.org/index.php/article/articleview/984/1/24/
[3]
http://www.web-services.gov/Web%20Services%20and%20Registries%20Pilot%20Proposal%20-%2007-22-03.ppt
[4] http://xml.coverpages.org/ni2002-11-12-b.html
[5] http://www.projectliberty.org/
[6] http://www.projectliberty.org/press/releases/2003-04-11.html
[7] http://www.cio.gov/eauthentication/

Paul Spencer wrote:
> 
> I have recently been thinking more about overall architectures for
> e-Government. Most architectures need a combination of transactions (such as
> the ability to file a tax return) and simple services that will be used by
> interoperating systems. An example of the latter might be the need to
> transform a name from the Extensible Name Language to/from a local format or
> to look up a postal address based on a unique property reference. It seems
> logical (to me at least) that the transactions would use ebXML and the
> services would use SOAP/WSDL.
> 
> Treating each separately, the ebXML part would need an ebXML registry in
> which would be stored business process specifications and CPPs (among other
> things). Typically, the services would use a UDDI registry. Does anyone have
> experience of having these working together or of combining them? And what
> about combining SAML into this? I see this as totally independent, but
> others might have different views.
> 
> Regards
> 
> Paul Spencer
> Director
> Boynings Consulting Ltd
> http://www.boynings.co.uk
> 
> You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/egov/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]