Extending the SOAP speci?¬?cation with security features was a
risky path. After having observed the issues with comprehensive
but bloated solutions such as CORBA, SOAP was intentionally
kept simple so as to keep its size and scope to a manageable
level.
The industry broke the impasse by creating additional web services
speci?¬?cations, each designed to solve a single aspect of the
advanced communication problem. All those speci?¬?cations
built their new functionalities on top of SOAP and sometimes on
top of other web services speci?¬?cations. The idea was that implementers
were not forced to deal with the full range of possible
capabilities, but they could have chosen which
speci?¬?cations to implement according to the requirements of
their systems. The speci?¬?cations were all designed to work with
each other gracefully, without imposing any unnecessary dependency.
The speci?¬?cations were named according to a consistent pattern:
WS-Security describes how to add security capabilities to
Interoperating is not
enough in the enterprise
world. You
want security,
transactions,
reliability??¦
Modularity was the
stratagem for keeping
the web services
speci?¬?cations
in a manageable
format
WS-* Web Services Speci?¬?cations: The Rei?¬?cation of the Identity Metasystem 141
SOAP messages, WS-ReliableMessaging establishes a protocol
for adding reliability assurances to web services communications,
and so on.
Pages:
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246