Simple Object Access Protocol (SOAP) - Online Expert

therapistarmyΛογισμικό & κατασκευή λογ/κού

14 Δεκ 2013 (πριν από 3 χρόνια και 5 μήνες)

100 εμφανίσεις

Simple Object Access Protocol (SOAP)
Simple Object
Access Protocol
(SOAP)
Objectives
• Learn how SOAP is an XML implementation of RPC (Remote
Procedure Calls).
• Compare SOAP to other RPC solutions.
• Analyze a SOAP packet and see how they work.
XML Professional Skills Development 9-1
Copyright © by Application Developers Training Company and AppDev Products Company, LLC
All rights reserved. Reproduction is strictly prohibited.
Simple Object Access Protocol (SOAP)
9. 9.1 1 The Need for SOAP
9 9..1 1
There has been a need for client applications to call procedures on remote
servers ever since the first pair of servers was connected to form a network.
Over the decades that passed since that event, thousands of inter-process
communication schemes have been designed, hundreds have been
implemented, and dozens have become standards or at least found to be in
general use. The vast majority is completely incompatible with one another.
Even today, with the world of distributed computing coalescing around
standards such as TPC/IP, Unicode, and Java, we still fight the battle. Simply
put, the battle is long from being won and it’s entirely possible it will
never be
decided. The reasons can be summed up in three ways: complexity, symmetry,
and security.
Complexity
Connections to interesting, useful, productive applications are difficult to
distribute. It’s easy to cobble together a solution that works universally for a
tiny fraction of problems. It’s also relatively easy to create custom-designed
solutions that only work for one instance of a particular problem. It’s quite
another to do everything for everyone all of the time.
Symmetry
Most solutions assume both sides of the process are written in the same
language. It’s doubtful there will ever be a single, universal programming
language. Java could be it, but it is not universal right now and therefore any
solution will have to live with the fact that all current client applications are
not going to be written in Java.
Security
Even if you are not challenged by the complexity or bothered by the
symmetry, you will still run into the one barrier that always exists between
systems: security. Only very foolish or ignorant companies open up a server to
anyone that knows the IP address and service names. No solution can get
around this problem, either.
9-2 XML Professional Skills Development
Copyright © by Application Developers Training Company and AppDev Products Company, LLC
All rights reserved. Reproduction is strictly prohibited.
9.1 The Need for SOAP

A Possible Solution
Simple Object Access Protocol (SOAP) was not created to solve all of these
problems. SOAP’s attitude is that they are unsolvable by a single,
comprehensive specification. The S in SOAP stands for SIMPLICITY. SOAP
says:
• Interesting, useful, productive applications are very complex, so we’ll
ignore things like memory management, garbage collection,
versioning, cache management, and so on. These are all vitally
important, but are already addressed very well by any number of
software development tools and environments.
• Widely distributed applications need to connect any client to any
sever. Nobody will ever be able to dictate the configuration of every
client or even every server involved in complex transactions. SOAP
says, let everyone remain how they are.
• The security problem is impossible to solve generically. Let the
servers do what they need to do to authenticate and otherwise trust the
actions of clients. SOAP says, we’ll ride along with whatever the
clients and servers want to use.
The net effect of this attitude is that for the first time, everyone can agree on an
inter-process communication protocol because all of the things that make it
difficult or impossible to agree on have been removed from the equation.
SOAP in a Sentence
Simply put: SOAP is RPC over HTTP using XML as the payload.
Let’s look at each of these terms in more detail.
RPC
This is all about a client making a request for service from a server, and then
getting a response back. Nothing fancier than that.
HTTP
The request is made using HTTP, exactly as happens whenever you click the
Submit button on a Web page. The response from the server comes back
exactly like any other HTTP response.
XML
The payload is marked up using XML elements and attributes that conform to
a very simple schema. The method name, parameters, and parameter values are
XML Professional Skills Development 9-3
Copyright © by Application Developers Training Company and AppDev Products Company, LLC
All rights reserved. Reproduction is strictly prohibited.
Simple Object Access Protocol (SOAP)
marked up in a standard way. The response from the sever uses the same
message format.
SOAP Advantages
The main reasons SOAP is gaining such momentum are:
• Simplicity: SOAP doesn’t try to solve much. It’s very focused on
making remote procedure calls between clients and servers.
Consequently it’s efficient and easy to implement on multiple
platforms and in multiple languages. SOAP implementations exist on
all major Web servers and in all modern programming languages.
• Ubiquity: SOAP rides around on HTTP, which is as close to a
universal protocol as the world may ever have, at least for the
foreseeable future.
• Firewall-Friendliness: HTTP coming through port 80 is considered to
be benign and acceptable for all servers everywhere. The design of
SOAP is such that every packet can be easily examined and filtered if
necessary.
• Security: There’s nothing dangerous about a string of XML being
posted to a Web server. The Web server has to understand the message
and be explicitly configured to act upon it. Any security mechanism
currently in place to impose security on a Web site (for example,
HTTPS or SSL) will work just as well with SOAP message traffic.
• Extendibility: Using XML for the payload means it’s trivial to extend
SOAP to meet all of your needs.
What SOAP Is Not
SOAP is not itself an object model. SOAP is a way to encode the properties
and methods of any object model, or even the RPC structures of services that
are not object-oriented! SOAP has no knowledge of, or affinity for, the object
model that the SOAP packet represents.
SOAP is not a language. It has no understanding of who or what created the
SOAP packet and why. It has no understanding of what will be done with the
packet when processed by the server. SOAP has no knowledge of, or affinity
for, a particular programming language.
SOAP is not an implementation. SOAP is just a specification for how SOAP
packets are constructed. It’s up to vendors to step in and create the
infrastructure that create, send, receive, and process SOAP packets. SOAP is
designed to be simple enough that a knowledgeable programmer can
implement SOAP on a particular platform for a particular language in a few
weeks.
9-4 XML Professional Skills Development
Copyright © by Application Developers Training Company and AppDev Products Company, LLC
All rights reserved. Reproduction is strictly prohibited.
9.1 The Need for SOAP

SOAP is not a general solution. SOAP rides atop HTTP and that is all, for
now anyway. If you need to use SMTP or messaging systems like MSMQ or
MQSeries you’ll have to look for another solution. With that said, there’s
nothing about a SOAP packet that could not be picked up and re-packed as
something else. The point is, SOAP deliberately does not address more than
HTTP so it stays simple and cheap to implement.
XML Professional Skills Development 9-5
Copyright © by Application Developers Training Company and AppDev Products Company, LLC
All rights reserved. Reproduction is strictly prohibited.
Simple Object Access Protocol (SOAP)
9. 9.2 2 Alternatives to SOAP
9 9..2 2
SOAP is not a radical new concept. Like nearly everything here in the mature
era of computing, SOAP is very derivative. It was built upon a large body of
prior work going back several decades.
There are many alternatives to SOAP. Each has advantages that make the
alternative much better than SOAP for a particular need. Each, however, has
flaws or disadvantages that make it difficult or even impossible for it to
achieve the same potential as SOAP.
First, we’ll enumerate the disadvantages in a general way. Then we’ll look at
each alternative and indicate which disadvantage(s) are present.
• Operating system dependency: If the mechanism requires, for
example, Windows NT on the server, it is too limited. SOAP does not
have any ties to the operating system.
• Programming language dependency: If the mechanism requires, for
example, Java on one or both sides of the connection, it is too limited.
SOAP is programming language independent.
• Security configuration hassles: If the mechanism depends, for
example, on specific ports being opened in the firewall, it is too
complex. SOAP rides on HTTP over port 80 and is as close to being
universally accepted as you can get.
• Filtering hassles: If the mechanism prevents, for example, standard
firewall filtering from being able to reject any call on sight, it is either
too complex or too dangerous for wide-spread utilization. SOAP
headers can be examined by standard firewall filtering tools.
• Custom message format: If the mechanism defines its own message
format, custom software has to be written to convert the format on
both ends of the connection. SOAP uses XML and messages can
therefore be parsed and understood everywhere there is an XML
parser.
Here are 10 alternatives to SOAP, with a very brief description followed by the
deficiencies or limitations that make it less attractive than SOAP. These are
listed alphabetically so don’t read it as a ranking.
• Coins: A Java Beans interoperability and persistence technique. It
uses XML but depends on Java.
• DCOM: Stands for Distributed COM and extends COM inter-
component communication over networks. DCOM is a security
nightmare and tied to Microsoft operating systems (in theory it’s open,
but in practice it’s not).
9-6 XML Professional Skills Development
Copyright © by Application Developers Training Company and AppDev Products Company, LLC
All rights reserved. Reproduction is strictly prohibited.
9.2 Alternatives to SOAP

• IIOP: Stands for Internet Inter-ORB Protocol, which is a well-
established standard used by CORBA components. It’s too closely tied
to CORBA and requires substantial security and firewall
configuration.
• Java RMI: Stands for Remote Method Invocation, has all of the
disadvantages listed above except that it’s operating system
independent.
• KOML: Stands for Koala Object Markup language and uses XML to
serialize Java objects. It’s too closely tied to Java.
• SODL: Stands for Simple Object Definition Language and is used as
the document type definition for XMOP. See XMOP below for details.
• WDDX: Stands for Web Distributed Data Exchange. Like SODL this
is another document type definition for expressing application data
structures in XML. WDDX is not as widely supported as SOAP, other
than that it has all the same advantages as SOAP.
• WIDL: Stands for Web Interface Definition Language and adds a
server-based architecture to the otherwise document-oriented
environment of the Web. WIDL is a W3C technical note and might
someday be a contender for SOAP, but SOAP is already here and
solves pressing problems that need resolution now. Also, WIDL is
attempting to solve all forms of application integration problems and
does not focus on the simplicity of an RPC via HTTP with XML.
• XML-RPC: SOAP is essentially XML-RPC with improvements. If it
were not for SOAP this chapter would probably be about XML-RPC.
SOAP is a better spec so we’re using it.
• XMOP: Stands for XML Metadata Object Persistence. It has all of the
benefits of SOAP with none of the disadvantages except a Java object
serialization strategy rather than an RPC strategy, making it too
dependent on Java.
There are undoubtedly more alternatives to SOAP than those listed above. And
it’s also very likely (strike that: it’s guaranteed) that people will take issue
with the characterizations of the alternatives, especially as they relate to
perceived disadvantages.
SOAP is easy to use yet sufficiently powerful and it’s already gaining a critical
mass of support from the big players like Microsoft. If you work with
Microsoft tools on the Web you’ll be using SOAP in the next generation of all
of your tools.
XML Professional Skills Development 9-7
Copyright © by Application Developers Training Company and AppDev Products Company, LLC
All rights reserved. Reproduction is strictly prohibited.
Simple Object Access Protocol (SOAP)
9. 9.3 3 Designing for SOAP
9 9..3 3
Make no mistake; SOAP will not automatically solve existing client/server
application problems. You will need to design with SOAP in mind. To design
effectively you have to understand how SOAP works.
How SOAP Works
Figure 1 provides a high-level view of the SOAP communication process. This
description is more complex than is technically necessary, but it is realistic
from the standpoint that most developers will not want to be dealing with raw
XML requests and responses, but will instead utilize some kind of intelligent
proxy that handles it for them.
1. Client application creates an instance of what appears to be a local
object. The client sets object property values and makes method calls,
as it would normally do.
2. A local intelligent proxy takes the requests and packages them as a
SOAP request with XML encoding the method name and parameters
name/value pairs. The requests are directed to a URL hosted by the
target server.
3. The SOAP packets travel the Internet as HTTP, passing through both
client-side and server-side firewalls without difficulty.
4. When the SOAP packets (which are actually HTTP requests) hit the
target server the reverse process occurs: The XML is parsed and
converted into an object suitable for use by the remote service.
5. To the remote service application, the method request looks exactly
like a local instance of the object making the call.
6. The process is reversed for the return trip (not diagramed) using HTTP
response.
9-8 XML Professional Skills Development
Copyright © by Application Developers Training Company and AppDev Products Company, LLC
All rights reserved. Reproduction is strictly prohibited.
Firewall
9.3 Designing for SOAP

Application Service
Client
Stub
Proxy
XML
Component
Parser
URL serving as
connecting point
XML
Parser
HTTP
SOAP Packets
Internet
Web Server

Figure 1. How a SOAP packet works.
Design Implementations
Several key design points should jump right out at you.
• Messages are expensive. Do not assign 16 individual property values
and then invoke a method with no parameters, because it’s not going
to work. Instead, make a single method call with 16 parameters.
• Use stateless component designs. Your solution will never scale if the
client holds a single object reference that remains fully realized and
committed on the server for the life of the object.
• Don’t hold your breath waiting for the return response. It might never
come, or it might come much later than you expect. It could even
come out of order if you’ve made several calls. A message-based,
event-event driven design is the right way to go.
An Analogy
If you are familiar with OLE DB and ADO, design as if you’re making
asynchronous remote procedure calls to stored procedures.
• You don’t pass parameters one at a time to a stored procedure, you
package everything the procedure needs into a single call, even if that
means 16 individual parameters.
• You need to loop or poll or do something while waiting for the
response, and you’d better have some recovery code ready to roll if
you time out.
XML Professional Skills Development 9-9
Copyright © by Application Developers Training Company and AppDev Products Company, LLC
All rights reserved. Reproduction is strictly prohibited.

FirewallSimple Object Access Protocol (SOAP)
• Lastly, if you make several procedure calls in parallel you know you
have to examine the return response before acting on it because
different procedures execute at different speeds and even calls to the
same procedure can get re-sequenced by a busy server and/or a busy
network with lots of traffic.
9-10 XML Professional Skills Development
Copyright © by Application Developers Training Company and AppDev Products Company, LLC
All rights reserved. Reproduction is strictly prohibited.
9.4 Implementing SOAP

9. 9.4 4 Implementing SOAP
9 9..4 4
We’re way overdue for an example of a SOAP request and response in action.
In practice some kind of intelligent proxy will stand between the logical
elegance of the object model being used and the brutish physical realities of
HTTP packets and XML streams, so we’ll jump from source code to HTTP
packet in one step.
Below, a Visual Basic client application makes a request for the current
balance for a customer from a distributed customer service application. This
code might sit behind a command button on a form.

Dim customer As New Example.CustomerService
Dim nCustomerID As Long
Dim curBalance as Currency

nCustomerID = 23653 '// frmCustomer.txtCustomerID

curBalance = customer.GetBalance(nCustomerID)

MsgBox "Customer's balance is: " & curBalance

Client Post
The following code shows an HTTP POST that contains the SOAP encoded
method call for the above. Keep in mind that the general form of this POST is
identical to what would be generated by a Web browser when you submit a
form to the same server.
The line numbers in the following code are for clarity only.

XML Professional Skills Development 9-11
Copyright © by Application Developers Training Company and AppDev Products Company, LLC
All rights reserved. Reproduction is strictly prohibited.
Simple Object Access Protocol (SOAP)
1 POST /CustomerService/GetBalance HTTP/1.1
2 Host: www.Example.com
3 Content-Type: text/xml
4 Content-Length: 311
5 SOAPMethodName: www.Example.com/CustomerService#GetBalance
6 <SOAP:Envelope xmlns:SOAP="urn:schemas-xmlsoap-org:soap.v1">
7 <SOAP:Body>
8 <m:GetBalance xmlns:m="urn:www.example.com-custserv">
9 <CustomerID>23653</CustomerID>
10 </m:GetBalance>
11 </SOAP:Body>
12 </SOAP:Envelope>

Let’s dissect this POST and see exactly what makes a SOAP POST.
1. This is, as we keep saying, the HTTP verb POST.
2. This specifies the target server, as is required of all HTTP messages.
3. This calms the fears of administrators everywhere: it’s just text marked
with XML. This line is required of all HTTP messages with a payload.
4. Standard, required info: How big is this thing?
5. This is a header that provides a more explicit declaration that we’re
going to use SOAP to call the specified method. This declaration must
match the method referenced in line 8 or the packet is rejected by the
server-side SOAP interpreter. This is done so firewalls don’t have to
know how to parse XML to determine what the packet wants to do.
6. For example, line 5 cannot say GetBalance while line 8 says
TransferFunds. Consequently any firewall can read line 5 and
accept/reject the request without any special knowledge about SOAP
and/or XML.
7. Now we’re in the body of the POST and it’s time to become SOAP-
specific. This section follows the SOAP schema that dictates that the
root element is Envelope. This line declares the SOAP namespace:

urn:schemas-xmlsoap-org:soap.v1

and as such can stay clear of conflicts with names used in the
application’s environment.
8. Next we introduce the body of the method we’re constructing. SOAP
provides for an optional HEADER section that would precede BODY.
Headers are not used in this example.
9-12 XML Professional Skills Development
Copyright © by Application Developers Training Company and AppDev Products Company, LLC
All rights reserved. Reproduction is strictly prohibited.
9.4 Implementing SOAP

9. Now we indicate the name of the method, and declare the namespace
that defines method and parameter names.
10. Only a single parameter is passed so only a single parameter element
is enclosed within the body.
11. This is the standard XML closing tag.
12. This is the standard XML closing tag.
Server Response
The target server receives this POST and reverses the process by parsing the
XML to uncover the name of the method and the parameters. A response is
generated and sent back to the client using something like the following:

1 HTTP/1.1 200 OK
2 Content-Type: text/xml
3 Content-Length: 176
4 <SOAP:Envelope xmlns:SOAP="urn:schemas-xmlsoap-org:soap.v1">
5 <SOAP:Body>
6 <m:GetBalance xmlns:m="urn:www.example.com-custserv">
7 <return>7637.59</return>
8 </m:GetBalance>
9 </SOAP:Body>
10 </SOAP:Envelope>

1. Like the POST, this response is friendly, safe HTTP.
2. This packet contains text formatted as XML.
3. This is pretty small.
4. It’s XML marked up per the SOAP namespace.
5. Here’s the body, as dictated by the specification. (No SOAP header
was used, though it could have been if necessary.)
6. The name of the method returning the results is GetBalance, as
defined for the specified namespace.
7. The return value is marked in any manner the server might decide.
This particular method call returns a single value, but any arbitrary set
of return values can be sent back in this manner.
8. Standard XML closing tags.
XML Professional Skills Development 9-13
Copyright © by Application Developers Training Company and AppDev Products Company, LLC
All rights reserved. Reproduction is strictly prohibited.
Simple Object Access Protocol (SOAP)
SOAP Extensions
Serialization? Transactions?
If you need your method calls to be serialized and/or be involved in
transactions, this is something the client and server will need to figure out on
their own. SOAP neither helps nor hinders this process. The general idea is
that you add parameters on both ends that provide serialization. Troublesome?
Yes, but that’s what intelligent proxies are for.
SOAP anticipates the need for behaviors like serialization, transactions,
extended security, and so on through the use of SOAP:Header elements that
precede the body. Since serialization and transactions, for example, would be
outside of the domain of a simple method call like GetBalance, the
SOAP:Header is used to isolate the higher-level configuration from lower-
level method calls.
Security?
Ignore SOAP for a moment. What can you do (or, are you doing) for security
in a pure Web forms environment? SOAP is no different from a security
standpoint. For example, if you are already using HTTPS you can simply route
all SOAP traffic in the same manner. Utilize precisely the same security
mechanisms with SOAP as you can do with standard Web applications.
Data Types and Structures?
SOAP utilizes XML Schemas for data types and has extensive support for
structures, arrays, and even object cross-references within your data. We will
not get into that level of detail in this chapter, but rest assured a lot of attention
has been paid to this subject.
Errors?
SOAP assures that all messages are understood, all server applications are
always available, and all Web servers are up and running properly.
Yeah, right!
SOAP is realistic about the many things that can go wrong in a distributed,
asynchronous environment like HTTP over the Internet. SOAP itself does
nothing to help or hinder, but it does specify behaviors and error message
numbers that are to be returned under various situations.
Clients are not assured that everything will work properly all the time, but they
are assured that faults and failure will be communicated in a consistent
manner.
9-14 XML Professional Skills Development
Copyright © by Application Developers Training Company and AppDev Products Company, LLC
All rights reserved. Reproduction is strictly prohibited.
9.4 Implementing SOAP


XML Professional Skills Development 9-15
Copyright © by Application Developers Training Company and AppDev Products Company, LLC
All rights reserved. Reproduction is strictly prohibited.
Simple Object Access Protocol (SOAP)
Summary
This chapter:
• Established the need for the Simple Object Access Protocol (SOAP) or
something like it.
• Examined some of the alternatives to SOAP and why SOAP is
arguably the best way to go.
• Discussed how to design applications to use SOAP.
• Explained how SOAP is implemented.
9-16 XML Professional Skills Development
Copyright © by Application Developers Training Company and AppDev Products Company, LLC
All rights reserved. Reproduction is strictly prohibited.
9.4 Implementing SOAP

Questions
1. True/False: Because SOAP travels over HTTP and port 80, it is very
firewall friendly.
2. When developing server-based components that utilize SOAP, is it more
beneficial to create a majority of properties or a majority of methods?
3. Name two shortcomings of SOAP competitors that SOAP tries to
overcome.
4. True/False: SOAP, like DOM, is an object model.
XML Professional Skills Development 9-17
Copyright © by Application Developers Training Company and AppDev Products Company, LLC
All rights reserved. Reproduction is strictly prohibited.
Simple Object Access Protocol (SOAP)
Answers
1. True/False: Because SOAP travels over HTTP and port 80, it is very
firewall friendly.
True
2. When developing server-based components that utilize SOAP, is it more
beneficial to create a majority of properties or a majority of methods?
A majority of methods. This keeps the conversation of the
Internet to an absolute minimum.
3. Name two shortcomings of SOAP competitors that SOAP tries to
overcome.
Operating System dependencies, programming language
dependencies, security configuration hassles, filtering hassles,
and incompatible message formats
4. True/False: SOAP, like DOM, is an object model.
False, SOAP is not an object model, it is an implementation of
XML.

9-18 XML Professional Skills Development
Copyright © by Application Developers Training Company and AppDev Products Company, LLC
All rights reserved. Reproduction is strictly prohibited.
9.4 Implementing SOAP

There is no lab for this chapter.
XML Professional Skills Development 9-19
Copyright © by Application Developers Training Company and AppDev Products Company, LLC
All rights reserved. Reproduction is strictly prohibited.
Simple Object Access Protocol (SOAP)
9-20 XML Professional Skills Development
Copyright © by Application Developers Training Company and AppDev Products Company, LLC
All rights reserved. Reproduction is strictly prohibited.