tf-34 and web services presented at esif-11 task force 34 october 26, 2004 john sines...
Post on 19-Dec-2015
214 views
TRANSCRIPT
TF-34 and Web ServicesTF-34 and Web Services
Presented at ESIF-11
Task Force 34
October 26, 2004
John Sines
© HBF Group, Inc. 2004 For ESIF Task Force 34 Use Only Page 2
What is a Web Service?
A Web Service is“A web service is a software application identified by a URI, whose interface and bindings
are capable of being identified, described and discovered by XML artifacts and supports direct interactions with other software application using XML based messages via
Internet-based protocols.”
(World Wide Web Consortium)
© HBF Group, Inc. 2004 For ESIF Task Force 34 Use Only Page 3
Intent of Web Services
A language and platform independent method to implement Service Oriented Architecture (SOA) using standard internet technologies
For application-to-application communication Has little to do with HTML Not limited to someone adding a hook into their web site. A web
service can live anywhere on the network (Inter or Intra). Entities choose to use web services for ease of implementation,
conciseness of the standard, and low cost
© HBF Group, Inc. 2004 For ESIF Task Force 34 Use Only Page 4
Examples of Web Services
Southwest Airlines accesses Budget Rent-a-Car to make car reservations after making airline reservations
Amazon allows other companies to search and purchase items via Web Services. If you are a nutritionist you can purchase nutrition books from Amazon without leaving your nutrition web site
There are stock-quote services, traffic-report services, and a weather services available
Ideal for any Service Oriented Architecture (SOA) deployment
© HBF Group, Inc. 2004 For ESIF Task Force 34 Use Only Page 5
What makes up a Web Service
All components are based on the XML standard– SOAP: Simple Object Access Protocol
– WSDL: Web Service Description Language
– UDDI: Universal Description, Discovery, Integration
© HBF Group, Inc. 2004 For ESIF Task Force 34 Use Only Page 6
SOAP
SOAP is the service messaging layer of a web service. The messages are XML based.
The protocol consists of three parts:
An envelope that defines a framework for describing what is in a message and how to process it
A set of encoding rules for expressing instances of application-defined datatypes
A convention for representing remote procedure calls and responses A transport or protocol binding
© HBF Group, Inc. 2004 For ESIF Task Force 34 Use Only Page 7
WSDL
A WSDL is an XML document that describes the functional characteristics of the services offered.
The WSDL describes:
The operations the service has available The messages the service will accept The protocol of the service
© HBF Group, Inc. 2004 For ESIF Task Force 34 Use Only Page 8
Where Web Services exist in the Standards World
W3C– XML Specifications
– WSDL Definition Specifications
– SOAP Specifications
– UDDI Specifications
– Web Services Architecture and Interoperability (WS-I) Profiles Maturity of Standard
– Introduced in 2000, and gaining momentum. Many companies are in 2nd and 3rd generation deployments
– De-facto Standard for SOA over XML
– Who uses them?• Anyone who needs interoperability between applications
Software and Hardware industry giants such as IBM, Sun, Dell, Microsoft, Intel are behind the standard
© HBF Group, Inc. 2004 For ESIF Task Force 34 Use Only Page 9
Why Web Services for ESNet?
Can be done in a faster and cheaper manner– WSDL gives widely recognized definition language to define the service
messages between the GWs and the CSCEs Platform and Technology neutral Insulates TF-34 from the intricate underlying details of defining a
protocol Ease of adding new services ComCARE messages are being defined as web services NENA 4 Generation 1 has already developed schemas for the ALI
Type Lib. The schemas are 2 weeks away from final approval http://www.nena.org/xml%5Fschemas/Current%20Release/Version%2
04.X.X.list.html
© HBF Group, Inc. 2004 For ESIF Task Force 34 Use Only Page 10
Reliability
Reliability is a concern Leverage existing technologies such Clustering and Load Balancing to
transparently manage reliability Techniques have been established to ensure that the messages get to
their endpoints Heartbeat mechanism can still be implemented
© HBF Group, Inc. 2004 For ESIF Task Force 34 Use Only Page 11
Security
Security concerns are the same as connection oriented architecture Web Service over HTTP or HTTPS – can be as secure as any website
– SSL, Basic Auth, NTLM, Passport, custom… Relies on security capabilities of the transport layer Security best practices are being recommended. People who
specialize have put an a great amount of effort in developing the best practices documents.
© HBF Group, Inc. 2004 For ESIF Task Force 34 Use Only Page 12
Pros and Cons of Web services for ESNet
Pros– Faster definition and deployment. Reduced deployment cost for PSAPs, service providers, and
ESMI intergrades– Clarity of the Standard– Ease of implementation with off the shelf technologies
• Can use Microsoft’s .NET or Java’s J2EE (IBM Web Spear, BEA Web Logic, etc.)• Leverage Application Server Technology• Leverage Load Balancer Technology
– A number of runtime management and support tools available– A number of production/development tools available (many more than SIP). In the .NET
development environment, development of web services is completely wizard driven– Allows for extensibility in protocol– Allows for a more scalable architecture– Seamless fail-over with the use of Load Balancers and Clustering- Connections are
acquiesced on every call to a service – Leverage existing NENA XML schemas – Ease of integration of ComCARE work– Allows for easy market entry for new data service providers– Affords PSAPs highest degree of flexibility for adding new services– Supports distributed Service Registry's which dynamically show which services are available
for use
© HBF Group, Inc. 2004 For ESIF Task Force 34 Use Only Page 13
Pros and Cons of Web services for ESNet (Continued)
Pros (Cont’d)– SOA supports the creation of Security Services which incorporates authentication, certification,
and encryption through std. PKI and other security practices– Supports 'Virtual Security Gateways' which model a physical security gateway, but are more
flexible to extend, consolidate, and upgrade – Each endpoint can be both a 'Client' and a 'Server' - this allows PSAPs to not only ask for
information, but to also provide information easily– Web-Services can be added as extensions to existing hub-and-spoke system design to enable
service-enabled applications to interoperate– Connectionless model only connects when data is needed - allows for messaging efficiency – Overall message overhead is reduced– Presence services can be implemented to ensure the application is available when needed
(Heartbeats can still be implemented)– Web-based connections are fast - since these are no different than any other IP-based
connection (on the order of milliseconds) Cons
– The web services standards may evolve– Overhead in initiating a connection– Matching requirements - individual customer requirements are possible but need to be
carefully managed among all customers– Availability - no architecture is perfect - many of the same dedicated 'guaranteed' data delivery
infrastructure can be leveraged to assure increased availability in a Web-Services model
© HBF Group, Inc. 2004 For ESIF Task Force 34 Use Only Page 14
Pros and Cons of Hub and Spoke/Connection Oriented Architecture
Pros– Few connection establishments means less overhead– Software exception is thrown if there is a problem with a TCP/IP socket– Hub-and-spoke Enterprise Integration Architecture (EAI) is the most popular of
traditional EAI models - been around for a while– Hub-and-spoke EAI's provide physical congestion control points to the PSAPs– Hub-and-spoke EAI's provide physical congestion control points to the PSAPs– Affords CESE client a certain amount of autonomy by virtue of RG hiding remote
data services– Allows for more responsibility to be placed on the hub provider for message
content, integrity, and performance Cons
– Complexity involved in defining the message set– Complexity involved in implementing the message set– Hub-and-spoke EAI's are built using proprietary 'middleware', as opposed to 'open'
s/w standards and protocols – Message hub is centrally located by design, rather than distributed by nature – Introduces risk due to potential for central point of failure for a large number of
automated processes (consider several hundred CESE's to one RG)
© HBF Group, Inc. 2004 For ESIF Task Force 34 Use Only Page 15
Pros and Cons of Hub and Spoke/Connection Oriented Architecture (Continued)
Cons (Cont’d)– Uses persistent TCP/IP connections which would require frequent teardown and
re-establishment (ref. TML initiative from T1 & OBF ATIS committees) – Dedicated circuits required - since Internet is a 'non-production' (inherently
unreliable) for persistent connections – Number of dedicated circuits between each CESE and RG endpoint (~7,000
PSAPs = lot of circuits) – PSAPs must then support two circuit types for IP connectivity, dedicated and
Internet-routed– A CESE is defined as a 'Client' only - though messages are defined to be intiated
both directions, this complicates the connection methodology – Requirements for persistent connections and continuous heartbeats, puts greater
load on systems and networks over that of a system that messages when it needs to
– Proprietary message exchange implementations, such as TF34 is proposing, requires specialized programming knowledge and effort to develop, maintain, and upgrade
– Introduces a TF34 'specific' messaging product between all available integrated applications
© HBF Group, Inc. 2004 For ESIF Task Force 34 Use Only Page 16
Problems with doing Connection Oriented Protocol in Parallel
Longer standards development time The technologies are very different No good migration path from one to the other
– Hardware as well as software required would be much different
© HBF Group, Inc. 2004 For ESIF Task Force 34 Use Only Page 17
Bi-directional Web Service
Connection-Oriented Web Services
ESNetRG
CESE
ESNetRG
CESE
Web Services
Web Services
Persistent Socket Does Not Persist
© HBF Group, Inc. 2004 For ESIF Task Force 34 Use Only Page 18
Possible Network Implementation
NETWORK
PSAP
PSAP
Load Balancer
DB ClusterApplication Server
Cluster
© HBF Group, Inc. 2004 For ESIF Task Force 34 Use Only Page 19
What a Solution Could Look Like
3
PSAP PSAP PSAP
IP WAN
PSAP PSAP PSAP
Reference: Optimizing Application Availability, Cisco Systems, Inc, Packet magazine (Volume 15, No. 2), 2003http://www.cisco.com/warp/public/784/packet/apr03/pdfs/ent_optimize.pdf
Load Balancer
Redundant AccessRouters and Links
Redundant WAN AccessRouters and Links
FirewallApp Server
ClusterDB Cluster
Data Center 1
Data Center 2 4
. . . .
. . . .
© HBF Group, Inc. 2004 For ESIF Task Force 34 Use Only Page 20
How to move Forward
Define a WSDL that includes all of the messages– Map messages to WSDL
© HBF Group, Inc. 2004 For ESIF Task Force 34 Use Only Page 21
Taken a step further, the entire ESNET could be a Web Service based peer network
PSAP1
(CESE1)
PSAP1
(CESE1)PSAPn
(CESEn)
PSAPn
(CESEn)
Service1Service1 Servicen
Servicen
This would allow CPE vendors to supply services as PSAP demand dictates – all using the same mechanism of discovery and invocation. ALI, ACN, VoIP, etc. all become an accessible service.
PSAPs share information on a peer basis.