Transcript XML Web Services

XML Web Services
(or what going to HPTS has
taught me about web services)
Jim Johnson
XML Web Services
(or what going to HPTS has
taught me about web services)
Jim Johnson
The Basics

Shared transport, schema, & representation

Email and plain text seemed to cover it
Message Exchange Pattern

Registration follows many best practices





Well documented and mutually understood
Asynchronous
No leaked internal state
Individual steps are atomic
Compensation paths available
Atomicity



Lower level actions should be atomic
Overall contract may not be
Message delivery will be asynchronous


May be best effort
Duplicate or out of order messages are possible
Naming & Addressing

Name uniqueness is important



Bound by scope
Problems arise if the address becomes fragmented
Uniqueness problems may result in surprises
 Especially if the two addresses implement the same MEP.
Jim Johnson
-> @ Standish
-> @ Microsoft
-> @ MSN
-> @ XML Web Services
Naming & Addressing

Name uniqueness is important



Bound by scope
Problems arise if the address becomes fragmented
Uniqueness problems may result in surprises
 Especially if the two addresses implement the same MEP.
Jim Johnson
-> @ Standish
-> @ Microsoft
-> @ MSN
-> @ XML Web Services
Naming & Addressing

Name uniqueness is important



Bound by scope
Problems arise if the address becomes fragmented
Uniqueness problems may result in surprises
 Especially if the two addresses implement the same MEP.
Jim Johnson
-> @ Standish
-> @ Microsoft
-> @ MSN
-> @ XML Web Services
Compensation Models



Real world does not always undo
Frequently it adapts, and moves forward some other way
… but should build from underlying atomic actions

For instance:
 Submit abstract on one topic (STM & databases)
 Get agenda that lists a different talk (this one)

Options:
 Rollback…
 Compensate, by moving forward using a new path…
 So I’m here, and you get this talk instead 
Compensation Models



Real world does not always undo
Frequently it adapts, and moves forward some other way
… but should build from underlying atomic actions

For instance:
 Submit abstract on one topic (STM & databases)
 Get agenda that lists a different talk (this one)

Options:
 Rollback…
 Compensate, by moving forward using a new path…
 So I’m here, and you get this talk instead 
Compensation Models



Real world does not always undo
Frequently it adapts, and moves forward some other way
… but should build from underlying atomic actions

For instance:
 Submit abstract on one topic (STM & databases)
 Get agenda that lists a different talk (this one)

Options:
 Rollback…
 Compensate, by moving forward using a new path…
 So I’m here, and you get this talk instead 
STM, Databases, and Services

Neither turtles nor elephants


How to simplify building atomic actions?


Compensations built from atomic steps
Use transactions, but
 Simplify the programming model
 Incorporate the full application state
(memory, database, message queues, etc)
 Only use within a limited range
(same process, same system, maybe neighboring blades)
STM can be a big help, iff it also works with the
other resources out there.