1. XML Web Services (or what going to HPTS has taught me about web services) Jim Johnson

2. XML Web Services (or what going to HPTS has taught me about web services) Jim Johnson

3. The Basics Shared transport, schema, & representation Email and plain text seemed to cover it

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. STM, Databases, and Services Neither turtles nor elephants Compensations built from atomic steps How to simplify building atomic actions? 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.