[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: Re: [egov] USE OF WEB SERVICES]
Decided to post Joseph's eGov post to this list. Some really good thoughts in here. Duane -------- Original Message -------- Subject: Re: [egov] USE OF WEB SERVICES Date: Wed, 23 Jun 2004 09:20:02 -0400 From: Chiusano Joseph <chiusano_joseph@bah.com> Organization: Booz Allen Hamilton To: John.Borras@cabinet-office.gsi.gov.uk CC: egov@lists.oasis-open.org References: <OF14828574.200A44F0-ON80256EBC.0037D35B-80256EBC.0038D042@e-envoy.gsi.gov.uk> Excellent document. I discussed this topic during an interview I recently gave to Government Computer News (GCN) - article is titled "Web Services Ready for Third Wave"[1]. At one point I provide an example of a logging function, and the considerations that would help one determine whether a function should be Web Services-based. As we progress through this thread, I would recommend that we also go one step further to discuss Service-Oriented Architectures (SOAs). More specifically, Web Services-based SOAs. That is, I believe that the world has been using SOAs for quite some time now - for example, back in the 80s with client/server technology. However, in the past several years (but mostly in the past year), we have seen the advent of SOAs that take advantage of the World Wide Web's HTTP infrastructure - that is, Web Services-based SOAs (I am using the W3C's most recent definition of Web Service when I refer to "Web Service" - i.e. SOAP/WSDL-based). I would offer the additional clarification that a Web Services-based SOA does not require that *all* services are Web Services-based; that is, some services may utilize message-oriented middleare (MOM) that is not Web Services-based, and some services may also involve manual processes (all or in part), such as workflow or a help desk that is reached by telephone with human interaction. As time goes on, I recommend that we refer to the work that we are doing within the OASIS ebSOA TC, specifically on patterns (what I call "integration patterns"). These patterns will - I believe - emerge as templates that government agencies can reference as (at least) starting points in solving their integration challenges. Comments on the document: (1) Syndication theme - this can be considered SOA, as it involves integration at the process layer rather than just the information layer. IMO, Web Services-based integration between 2 processes/systems that exchange information without referencing shared processes is not *true* SOA. (2) Rules Engine theme - another excellent example of SOA. In the ebSOA discussions, I have offered this type of scenario as a "calculation-based pattern" (name will change over time). (3) Joining Up Internal Architecture - this may or may not involve Web Services-based SOA. Recognizing the extemely high value that Web Services bring, there are some cases in which Web Services are not the best choice of integration strategy. That is, if one has multiple systems communicating inside a firewall that have well-known and well-supported APIs (i.e. a wide range of vendors support them), it may not make sense to leverage HTTP and "compete" with other users of the HTTP infrastructure to communicate between applications in this scenario. For example, a solution that involves MOM that is non-Web -Services-based may be perfectly adequate. Having said that, there are many other factors involved, a large one being (of course) cost. (4) Handshaking with Other Agencies - a good example where portal-oriented architecture (POA) may play a role. Technologies such as Enterprise Information Integration (EII) may support a multi-agency portal by aggregating information from multiple disparate data sources and presenting it to the portal. Kind Regards, Joe Chiusano Booz | Allen | Hamilton [1] http://www.gcn.com/23_13/interview/26093-1.html (quick find: search for "logging") John.Borras@cabinet-office.gsi.gov.uk wrote: > > Now that Web Services seem to have reached a good level of maturity we > here in the UK are considering when and how we should deploy them to > support our e-government service delivery plans. For example should > our future architecture dictate that everything be deployed as a WS or > is it a case of WS are more appropriate for different types of > services. A colleague of ours has produced the attached discussion > document which attempts to answer this question and I'd welcome your > views on this and any experience you already have of deploying WS for > Gov applications. > > There may be some value in the TC producing a guidance document on > this for wider consumption. What do you think? > > Within Europe it may be necessary to agree on this if we are to > support the concept of joined-up pan-European services so such a > document might be valuable input to deliberations in Brussels. > > Regards, > John > > The original of this email was scanned for viruses by the Government > Secure Intranet (GSi) virus scanning service supplied exclusively by > Energis in partnership with MessageLabs. > > On leaving the GSi this email was certified virus-free > > Name: web services for gov.doc > Type: WINWORD File > web services for gov.doc (application/msword) > Encoding: base64 > Download Status: Not downloaded with > message > > --------------------------------------------------------------- > To unsubscribe from this mailing list (and be removed from the roster > of the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/egov/members/leave_workgroup.php > . -- Senior Standards Strategist Adobe Systems, Inc. http://www.adobe.com
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
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/egov/members/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]