Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

3RD YEAR - SECOND SEM > Web Services 3 > Flashcards

Web Services 3 Flashcards

1
Q

simple, lightweight XML protocol for exchanging structured and typed information on the Web

A

SOAP

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Overall design goal: KISS

A
  • Can be implemented in a weekend
  • Stick to absolutely minimum of functionality
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Make it Modular and Extensible

A
  • No application semantics and no transport semantics
  • Think “XML datagram”
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

SOAP Contains Four Parts

A
  1. An extensible envelope expressing (mandatory)
  2. A set of encoding rules for data (optional)
  3. A Convention for representation RPC (optional)
  4. A protocol binding to HTTP and HTTP-EF (optional)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

An extensible envelope expressing (mandatory)

A
  • what features and services are represented in a message;
  • who should deal with them,
  • whether they are optional or mandatory.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

A set of encoding rules for data (optional)

A
  • Exchange instances of application-defined data types and directed graphs
  • Uniform model for serializing abstract data models that can not directly be expressed in XML schema
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

A Convention for representation RPC (optional)

A

How to make calls and responses

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

SOAP Example in HTTP

A

SOAP - HTTP BINDING
HTTP REQUEST
SOAP BODY
SOAP HEADER
SOAP ENVELOPE

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

SOAP Example in SIP

A

SOAP - SIP Binding
SIP Request
SOAP Body
SOAP Envelope

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Session Initiation Protocol

A

a signaling protocol that enables the Voice Over Internet Protocol (VoIP) by defining the messages sent between endpoints and managing the actual elements of a call.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

HTTP

A

Used for transferring web content like HTML pages.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

TCP

A

Ensures reliable, ordered delivery of data packets.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

UDP

A

Provides fast but unreliable data transmission, commonly used for real-time applications like streaming and gaming.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q
  • Connection-oriented, ensuring reliable, ordered data transmission.
  • Performs error-checking and retransmission.
  • Higher overhead, suitable for applications requiring reliability like web browsing and file transfer.
A

TCP

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q
  • Connectionless, offering faster but less reliable transmission.
  • Does not guarantee packet order or error recovery.
  • Lower overhead, preferred for real-time applications like streaming, gaming, and VoIP.
A

UDP

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Note Again: SOAP is a Protocol!

A

a. What does this mean?
* It is not a distributed object system
* It is not an RPC system
* It is not even a Web application

b. Your application decides what your application is!
* You can build a tightly coupled system
…or…
* You can build a loosely coupled system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Evolvability

A

ability of a system to adapt and change easily over time to meet new needs or challenges

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

How are features and services deployed in the Web?

A
  • Often by extending existing applications
  • Spreading from in the small to the large over time
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

This means that SOAP is Designed for Evolvability:

A
  • Applications have different capabilities at all times
  • We have to support this
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

This requires that SOAP is Designed for Evolvability:

A
  • Applications supporting a particular feature or service should be able to employ this with no prior agreement;
  • Applications can require that the other party either understand and abide by the new feature or service or abort the operation
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Why Not Roll My Own XML Protocol?

A
  • SOAP allows you to define your particular feature or service in such a way that it can co-exist with other features and services within a SOAP message
  • What is a feature or a service?
    a. What is a feature or a service?
    b. Authentication service
    c. Payment service
    d. Security service
    e. Transaction management service
    f. Privacy service
  • Not owning the message means easier deployment and better interoperability
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

What is a feature or a service?

A
  1. Authentication service
  2. Payment service
  3. Security service
  4. Transaction management service
  5. Privacy service
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Interoperability

A

refers to the ability of different systems, devices, or components to seamlessly work together, exchange data, and communicate effectively, regardless of their differences in technology, platforms, or protocols.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

is the intersection of features and service supported by two or more communicating peers

A

Interoperability

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

refers to the capability of a system to easily add new features, functionalities, or capabilities without significantly altering its existing structure or core functionality.

A

Extensibility

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

Extensibility

A

Cost per new feature/service increases over time

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

Evolvability

A

Cost per new feature/service is flat

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

Composability

A

refers to the ability of individual components or elements within a system to be combined or arranged in various ways to create new, larger systems or applications. It emphasizes modularity and flexibility, allowing for the construction of complex systems from simpler, interchangeable parts.

29
Q

XML meaning

A

Extensible Markup Language

30
Q
  • multiple features and services can exist simultaneously within the same message
  • Allows for independent features to co-exist
A

Vertical Composability

31
Q
  • features and services within a message can be intended for different recipients.
  • Allows for intermediaries
A

Horizontal

32
Q

intermediaries in horizontal composability

A
  1. authentication
  2. actor
  3. transaction
  4. payment
33
Q

Modularity through XML Namespaces

A
  1. The SOAP envelope namespace
  2. The SOAP encoding namespace
  3. Separate namespaces help enforce modularity
  4. SOAP Envelope Schema provides formal definition of Envelope
34
Q

RPC meaning

A

Remote Procedure Call

35
Q

SOAP Envelope

A
  1. A SOAP envelope defines a SOAP message
  2. messages are one-way transmissions
  3. Messages are routed along a “message path”
  4. Envelopes can be nested
36
Q

Allows for processing at one or more intermediate nodes in addition to the ultimate destination node.
(True or False)

A

True

37
Q

a SOAP processor and is identified by a URI

A

node

38
Q

SOAP Headers

A
  • Allows for modular addition of features and services
  • Open-ended set of headers
  • Authentication, privacy, security etc. etc.
  • Can address any SOAP processor using the “actor” attribute
  • Can be optional/mandatory using the “mustUnderstand” attribute
39
Q

Semantics of SOAP Headers

A
  1. Contract between sender and recipient/actor
  2. allows differengt types of negotiation (take it or leave it; lets talk about it can be built on top)
  3. And for different settings (server dictated, peer-to-peer, dictated by third party)
40
Q

has a special URI assigned to it

A

next hop

41
Q

is the default destination for a header

A

end

42
Q

is the destination for the body

A

end

43
Q

attribute is a generalization of the HTTP Connection header field

A

actor

44
Q

The SOAP actor Attribute

A

Instead of hop-by-hop vs. end-to-end, the actor attribute can address any SOAP processor because it is a URI

45
Q

URI meaning

A

Uniform Resource Identifier

46
Q
  • ” is the same as “mandatory” in the HTTP Extension Framework
  • This allows old applications to gracefully fail on services that they do not understand
A

mustUnderstand

47
Q
  • Special case of header
  • Default contract between sender and ultimate recipient
  • Different from HTTP’s header/body separation
  • Defined as a header with attributes set to:
  • Implicit mustUnderstand attribute is always “yes”
  • Implicit actor attribute is always “the end”
A

SOAP Body

48
Q
  • Bad experiences with version numbers in decentralized environments
  • Extremely confusing in HTTP – whole RFC on the topic
  • Typical uses of number based “versioning”
  • Backwards compatible (minor version number)
  • Backwards incompatible (major version number
  • SOAP supports “minor” versioning within the envelope using header and body elements
  • The SOAP composability model (“WYSIWYG on the wire”)
  • The SOAP Envelope Namespace URI defines the “major” of the SOAP envelope
  • Changing Namespace URI is equivalent to change major version number
  • Possible to negotiate major versioning change using SOAP header
  • Equivalent to the HTTP Upgrade header field

manages changes in communication protocols.

It’s like making sure everyone’s speaking the same language, even as that language evolves. Version numbers help keep track of these changes, ensuring compatibility between different systems.

A

SOAP Versioning Model

49
Q
  • “Binary” can in fact mean any data that is to be tunneled through SOAP
  • Encrypted data, images, XML documents, SOAP envelopes as data
  • Can be carried in two ways
  • Within the envelope as binary blob
  • Referenced from within the SOAP envelope
  • References can point to anything including
  • MIME multipart, HTTP accessible resources etc.
  • Integrity can be obtained through manifest

“binary” data in SOAP, we mean any non-textual information.

This data can be included directly in the SOAP message or referenced from elsewhere. To make sure everything is secure and intact, we can use a manifest to verify the integrity of the data.

A

SOAP and “Binary” Data

50
Q
  • The purpose of the HTTP protocol binding is two-fold
  • To ensure that SOAP is carried in a way that is consistent with HTTP’s message model
  • Intent is not to break HTTP
  • To indicate to HTTP servers that this is a SOAP message
  • Allows HTTP servers to act on a SOAP message without knowing SOAP
  • Binding only works for HTTP POST requests
  • SOAP intermediary is not the same as HTTP intermediary
  • Only HTTP origin server can be SOAP intermediary

binding SOAP to HTTP means ensures that SOAP messages play in the rules

It helps HTTP servers recognize and handle SOAP messages appropriately, particularly when they’re sent as HTTP POST requests. However, it’s important to distinguish between SOAP and HTTP intermediaries, as their roles and capabilities differ.

A

Binding to HTTP

51
Q
  • Use HTTP POST request method name
  • Use the SOAPAction HTTP header field
  • It cannot be computed – the sender must know
  • It should indicate the intent – not the destination
  • SOAP request doesn’t require SOAP response

  • You use the POST method.
  • You include a SOAPAction header to specify what action the SOAP service should perform.
  • The sender needs to know what action to request.
  • The SOAPAction field indicates the intended action, not necessarily where the message should go.
  • And finally, while you’re asking the SOAP service to do something, you might not always get a response back.
A

HTTP Request

52
Q
  • Successful responses can 2xx status codes (It’s like getting a thumbs-up or a green light.)
  • All 3xx, 4xx, and 5xx status codes work as normal
  • SOAP faults must use 500 status code
  • SOAP response doesn’t require SOAP request
  • Response can in fact be empty

  • If everything’s okay, you get a status code starting with “2.”
  • If there’s a problem with the request, you might get a status code starting with “3,” “4,” or “5.”
  • If there’s a SOAP-specific issue, like a fault, you’ll likely get a 500 status code.
  • You might receive a SOAP response even without sending a SOAP request.
  • Sometimes, the server might not have anything to say, and the response can be empty.
A

HTTP Response

53
Q

Purpose of SOAP Encoding (1)

A

Given a schema in any notation consistent with the data model defined by SOAP, a schema for an XML grammar may be constructed

SOAP encoding provides a way to structure data in XML format, ensuring consistency and making it easier for different systems to understand and exchange information effectively. It’s like having a set of rules for organizing information so that everyone is on the same page.

54
Q

Purpose of SOAP Encoding (2)

A

Given a type-system schema and a particular graph of values conforming to that schema, an XML instance may be constructed.

SOAP encoding helps us take different types of data, organize them according to a set of rules (schema), and convert them into a structured XML format that follows those rules.

55
Q

Basic Rules

A
  1. All values are represented as element content
  2. An element may be “independent” (top level of serialization) or “embedded” (everything else)
  3. Values can be single-reference or multi-reference
  4. A multi-reference value is represented as the content of an independent element. It has an unqualified attribute named “id” and of type “ID”.
  5. An accessor can point to a multi-reference value with a local, unqualified attribute named “href” and of type “uri-reference“
  6. The root attribute can be used to indicate roots that are not true roots in a graph
56
Q

Purpose of SOAP Encoding (3)

A

Given an XML instance produced in accordance with these rules, and given also the original schema, a copy of the original value graph may be constructed.

SOAP encoding ensures that data is structured correctly in XML format according to specific rules (schema). This structured XML data can then be used to reconstruct the original data graph, providing a way to represent and exchange complex information in a standardized manner.

57
Q

Indicating the Type

A
  • For each element containing a value, the type of the value is represented by at least one of the following conditions:
  • The containing element instance contains an xsi:type attribute,
  • The containing element instance is itself contained within an element containing a (possibly defaulted) SOAP-ENC:arrayType attribute or
  • The name of the element bears a definite relation to the type, that type then determinable from a schema.
58
Q
  • A “simple type” is a class of simple values
  • SOAP uses all the types found in the section “Built-in data types” of “XML Schema Part 2: Datatypes”
  • A simple value is represented as character data, that is, without any sub-elements

  • simple type refers to basic values, like numbers or words, which are represented directly as text in SOAP messages.
  • These values are straightforward and don’t have any internal structure or sub-elements.
A

Simple Types

59
Q
  • A “compound” type is a class of compound values
  • Each related value is potentially distinguished by a role name, ordinal or both (accessor)
  • Supports traditional types like structs and arrays
  • Supports nodes with with many distinct accessors, some of which occur more than once
  • Preserves order but doesn’t require ordering distinction in the underlying data model
A

Compund Type

  • compound types represent more complex values that consist of multiple related parts.
  • These parts can be identified by names or positions, and they support familiar data structures like structs and arrays.
  • Compound types allow for organizing data in a structured way while preserving the order of the information.
60
Q

in which accessor name is the only distinction among member values, and no accessor has the same name as any other

A

Struct Compound Type

struct compound type is like a set of labeled boxes, where each box holds a different piece of information, and each label is unique. You can think of it as a way of organizing data into distinct categories based on their names.

61
Q

A compound value in which ordinal position serves as the only distinction among member values

A

Array Compound Type

array compound type is like a list of items where each item is identified by its position in the list. You can think of it as a way of organizing data into a sequential order, where each piece is numbered according to its place in the sequence.

62
Q

A compound value with a mixture of accessors distinguished by name and accessors distinguished by both name and ordinal position

A

General Compound Type

general compound type is like a mixture of labeled boxes and numbered boxes. Some pieces of information have unique names, while others are simply numbered based on their position. It’s a flexible way of organizing data, allowing for different ways to identify and access the information within the compound value.

63
Q

Serializing Relationships

A
  • The root element of the serialization serves only as lexical container.
  • Elements can reflect arcs or nodes
  • Independent elements always reflect nodes
  • Embedded elements always reflect arcs
  • Element names correspond to node or arc labels
  • Arcs are always encoded as embedded elements

  • The main element is like a box holding everything.
  • Elements can represent either individual data points (nodes) or the connections between them (arcs).
  • Node elements stand alone, while arc elements are nested within node elements.
  • The names of elements correspond to the labels or identifiers of the data points they represent.
  • Arcs, representing connections, are always shown as part of the data points they connect.
64
Q

relationship is expressed by simple containment. For example, if a student attends a course, the canonical XML looks like

A

1:1 Relationships

65
Q
A
66
Q

A 1:many relationship is expressed by multiple elements for the 1:many direction or single element for the many:1 direction.

A

1:n and n:1 Relationships

67
Q

is expressed by using references in both directions.

A

m:n Relationships

68
Q

SOAP and RPC

A
  • A method invocation is modeled as a struct
  • A method response is modeled as a struct
  • Struct contains an accessor for each [in] or [in/out] or [out] parameter.
  • The request struct is both named and typed identically to the method name.
  • The response struct name is not important
  • The first accessor is the return value followed by the parameters in the same order as in the method signature

SOAP and RPC use structured data (structs) to represent method invocations and responses. These structs contain accessors for each parameter of the method, following a specific naming convention for the request struct and maintaining the order of parameters as in the method signature.

3RD YEAR - SECOND SEM (25 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions