TF-34 and Web Services

1. TF-34 and Web Services Presented at ESIF-11 Task Force 34 October 26, 2004 John Sines jsines@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/xml%5Fschemas/Current%20Release/Version%204.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 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

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

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 (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

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.