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