oct, 26 th, 2010 ogf 30, nsi-wg: network service interface working group web services overview web...
TRANSCRIPT
Oct, 26th, 2010OGF 30, NSI-WG: Network Service Interface working group
Web Services Overview
Web Services for NSI protocol implementation
OGF 30, NSI-WG:Network Service Interface working group
Advantages of Web Services
• Provides interoperability between various software applications running on disparate platforms
• Self-describing software modules that encapsulates discrete functionality.
• Utilize open standards and protocols• Protocols and data formats are text-based where possible, making
it easy for developers to comprehend.
• Issues such as byte level compatibility, framing, and internationalization are removed so implementers can focus on the protocol contents.
• Allows reuse of services and components within an infrastructure• Discrete interfaces allow for greater reuse than having to participate
in a complete protocol implementation.
2
OGF 30, NSI-WG:Network Service Interface working group
Ease of Development
• Web Services development supported in all popular programming languages
• Java has native support while other languages utilized add-on libraries (C/C++, Ruby, .NET, PHP, Perl, etc.).
• Eclipse and NetBeans IDE support integrated Web Services development
• Provides rapid prototyping and test environment.
• Dynamic web/application server deployment makes development even easier.
• Runtime supported on all major OS versions
3
OGF 30, NSI-WG:Network Service Interface working group
Web Service Profile
• Web services support both request/response and notification type interaction models.
• A standard application profile for Web Services would be deployed using existing standards such as:• Transport - Hypertext Transfer Protocol (HTTP).• Encoding - Extensible Markup Language (XML).• Messaging – SOAP.• Schema - Web Services Description Language (WSDL).• Discovery - Universal Description, Discovery, and Integration
(UDDI).
4
OGF 30, NSI-WG:Network Service Interface working group
Standardized Communication
• HTTP currently permits a large number of systems to communicate with one another
• HTTP is a well defined and widely implemented messaging protocol with the key attributes needed out of a base transport protocol.
• Using SOAP over HTTP allows for easier communication through proxies and firewalls than previous remote execution technology.
• SOAP (built on XML) is an RPC-style messaging specification • A platform and language independent protocol for exchanging information in a
decentralized and distributed environment. • SOAP is versatile enough to allow for the use of different transport protocols, with
binding to a specific transport a deployment time decision.• Many implementations utilize HTTP as a transport protocol, but other protocols such as
JMS are very popular.
• WSDL standardizes the description of Web Services• Acts as a formal interface contract between providers and requestors within the
system.
• UDDI standardizes the publishing and finding of Web Services.
5
OGF 30, NSI-WG:Network Service Interface working group
Performance
• All major vendors have invested considerable resources optimizing their SOAP and XML parsing and formatting engines.
• In the majority of implementations the overhead incurred handling XML message parsing is minor when compared to typical service logic implementation.
• Bandwidth consumed per message is dependent on the defined application data model
• Fenius reservation requests were, on average, 1.5 KBytes per message.
• Standard off the shelf quad core server technology can easily handle thousands of messages a second (of course this is application specific)
• All potential NRM platforms are running on server class machines with high-speed Internet connections and not embedded processors with 56 Kb/s data channels.
OGF 30, NSI-WG:Network Service Interface working group
WSDL – The Contract
7
Namespace definition withversion for this service
Import XML typesfor use in messagedefinition
Define request messages
Response messages
Associated parameter types
OGF 30, NSI-WG:Network Service Interface working group
WSDL – The Operations
8
Define the service port type
Operation nameInput message (request)
Output message (response)
Fault messages (errors)
Define service name
Connection service SOAP endpoint
OGF 30, NSI-WG:Network Service Interface working group
SOAP Message Structure
9
…
…
HTTP Header – All SOAP operations are POST
UTF-8 encoding for internationalization support
SOAP content envelopeSOAP header (WS-Addressing, WSS)SOAP body – contains WSDL defined operations
OperationSchema namespace
Parameter
OGF 30, NSI-WG:Network Service Interface working group 10
OGF 30, NSI-WG:Network Service Interface working group
Request/Response Operations
• NSI protocol will support two types of request interactions:• Request/response mechanism where the response contains the results of the
request.• Request/acknowledgement/response message interaction where the request is first
acknowledged, then followed sometime later by a formal response.
• Request/response mechanism• HTTP POST carries the request operation.• HTTP response to POST carries result of the operation.• HTTP socket blocks until result it returned.• Standard design pattern utilizes multiple threads to issue concurrent operations.
• Request/acknowledgement/response mechanism• HTTP POST carries the request operation.• HTTP response to POST carries the acknowledgement of the request with the
appropriate correlation Id (messTransID or specific operation TransID).• Provider NSA will POST operation result to the Requestor NSA using their
notification SOAP endpoint.
11
OGF 30, NSI-WG:Network Service Interface working group
Asynchronous Messaging
12
OGF 30, NSI-WG:Network Service Interface working group
Notifications
• There are two primary notification patterns used for SOAP• Notification “push” interface that delivers events asynchronously to
a client’s registered SOAP endpoint.• Notification “pull” interface that will queue notifications for the client
to poll via the publisher’s SOAP endpoint.
• There are two options for notification service definitions• Application specific notifications defined through application specific
schema allowing for custom notification solutions• 3GPP Parlay X standards follow this model having integrated notifications into
their messaging definitions.
• Standards based notification frameworks (WS-BaseNotification) following the publish/subscribe pattern with topics
• Subscribe, Renew, Unsubscribe, PauseSubscription, ResumeSubscription, Notify, GetCurrentMessage, GetMessages.
13