XML Web Services

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
• -gt _at_ Standish
• -gt _at_ Microsoft
• -gt _at_ MSN
• -gt _at_ 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
• -gt _at_ Standish
• -gt _at_ Microsoft
• -gt _at_ MSN
• -gt _at_ 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
• -gt _at_ Standish
• -gt _at_ Microsoft
• -gt _at_ MSN
• -gt _at_ 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 Im 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 Im 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 Im 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.