TF-34 and Web Services

1
TF-34 and Web Services

• Presented at ESIF-11
• Task Force 34
• October 26, 2004
• John Sines
• jsines_at_hbfgroup.com

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)

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

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

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

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

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

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

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/xml5Fschemas/Current20Releas
  e/Version204.X.X.list.html

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

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.

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 Microsofts .NET or Javas 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

13
Pros and Cons of Web services for ESNet
(Continued)

• Pros (Contd)
• 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

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)

15
Pros and Cons of Hub and Spoke/Connection
Oriented Architecture (Continued)

• Cons (Contd)
• Uses persistent TCP/IP connections which would
  require frequent teardown and re-establishment (re
  f. 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

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

17
Bi-directional Web Service
18
Possible Network Implementation
19
What a Solution Could Look Like
20
How to move Forward

• Define a WSDL that includes all of the messages
• Map messages to WSDL

21
Taken a step further, the entire ESNET could be a
Web Service based peer network
Service1
Servicen
PSAP1(CESE1)
PSAPn(CESEn)
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.