TF-34 and Web Services

bevyquixoticSecurity

Nov 3, 2013 (3 years and 1 month ago)

95 views

TF
-
34 and Web
Services

Presented at ESIF
-
11

Task Force 34

October 26, 2004

John Sines

jsines@hbfgroup.com

© 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 2
nd

and 3
rd

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
ESNet
RG
CESE
ESNet
RG
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 Cluster
Application 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
)
,
2003
http
://
www
.
cisco
.
com
/
warp
/
public
/
784
/
packet
/
apr
03
/
pdfs
/
ent
_
optimize
.
pdf
Load Balancer
Redundant Access
Routers and Links
Redundant WAN Access
Routers and Links
Firewall
App Server
Cluster
DB 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

PSAP
1

(CESE
1
)

PSAP
n

(CESE
n
)

Service
1

Service
n

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.