WS-* Standards. Szolgáltatásorientált rendszerintegráció Service-Oriented System Integration. Dr. Balázs Simon BME, IIT

Transcription

1 WS-* Standards Szolgáltatásorientált rendszerintegráció Service-Oriented System Integration Dr. Balázs Simon BME, IIT

2 Outline Integration requirements WS-* standards 2

3 Integration requirements 3

4 Integration within a company SAP.NET JEE SQL Server PHP Oracle DB MySQL 4

5 e-gov integration Tax authority Linux, Oracle e-gov portal Linux, JBoss Social security Windows,.NET Insurance Linux, IBM 5

6 Requirements Integration within a company transactions e-gov integration, integration between companies: security: encryption, digital signature reliability: no messages are lost Standardized solution 6

7 WS-* standards 7

8 Web service standards Metadata Security Reliable Messaging Transactions Messaging XML encryption, digital signature Transport pl. HTTP, HTTPS, TCP, UDP, JMS, SMTP,... 8

9 Messaging Messaging MTOM WS-Addressing SOAP WS-Addressing: SOAP headers: Action To From ReplyTo FaultTo MessageId RelatesTo analogy: MTOM: efficient byte transfer as MIME attachment 9

10 Reliable messaging Reliable messaging WS- Reliability WS- Reliable Messaging WS-Reliability: original version does not live well with the other WS-* protocols WS-ReliableMessaging: analogy: TCP widely supported lives well with the other WS-* protocols e.g. transactions, security,... 10

11 WS-ReliableMessaging Endpoint A Endpoint B CreateSequence() CreateSequenceResponse(Identifier= ) Sequence(Identifier= MessageNumber=1) Sequence(Identifier= MessageNumber=2) Sequence(Identifier= MessageNumber=3, LastMessage) SequenceAcknowledgement(Identifier= AcknowledgementRange=1,3) bootstrap application-level messages 11

12 WS-ReliableMessaging Endpoint A Endpoint B Sequence(Identifier= MessageNumber=2, AckRequested) SequenceAcknowledgement(Identifier= AcknowledgementRange=1..3) CloseSequence(Identifier= ) CloseSequenceResponse(Identifier= ) application-level messages closing the sequence TerminateSequence(Identifier= ) TerminateSequenceResponse(Identifier= ) releasing resources 12

13 WS-ReliableMessaging (WS-RM) Non-persistent implementation: sequence session stored in memory problems: only relevant over an unreliable protocol (e.g. UDP) makes no sense over TCP, and hence over HTTP cannot outlive a shutdown-restart storing a lot of sessions can overload the server WCF only supports non-persistent WS-RM 13

14 WS-ReliableMessaging (WS-RM) Persistent implementation: sequence session stored in a persistent store e.g. file or database advantages: relevant over TCP, and hence over HTTP can outlive a shutdown-restart sessions don t overload the server IBM and Oracle have persistent WS-RM implementations 14

15 Transactions WS- Atomic Transaction Transactions WS-Coordination WS- Business Activity WS-Coordination: managing transactions WS-AtomicTransaction: short term transaction 2PC WS-BusinessActivity: long running transaction rollback: compensation 15

16 Transactions ACID principles: Atomicity: either the transaction as a whole succeeds or fails. Consistency: data before and after the transaction must be in a consistent state. Isolation: parallel transactions act isolated from each other; it appears as though they are running sequentially. Durability: data state after a successful transaction is persistent; survives a crash. Operations: Commit: finish the transaction successfully and persist the outcome. Rollback: discard all data manipulations performed since the transaction began. 16

17 WS-Coordination Runtime Runtime Client Message+ context Service Message+ context Service... Create context Register Register Activation Service (root) Coordinator Registration Service Protocol Service Registration Service Protocol Service (subordinate) Coordinator

18 WS-AtomicTransaction: 2PC Phase 1: prepare (Can everyone commit?) Runtime Runtime Client Service Service commit 2. prepare 3. OK 5. prepare 6. OK (root) Coordinator 4. prepare 7. OK (subordinate) Coordinator... 18

19 WS-AtomicTransaction: 2PC Phase 2: commit (Do commit.) Runtime Runtime Client Service Service commited 1. commit 2. OK 4. commit 5. OK (root) Coordinator 3. commit 6. OK (subordinate) Coordinator... 19

20 WS-BusinessActivity For long-running transactions Problem: cannot lock databases for days WS-AtomicTransaction cannot be used Solution: assume we can commit and do the operation (e.g. reserve flight) if later a rollback has to be done, undo the operation, i.e. compensate (e.g. cancel flight) But: ACID is no longer valid the system can be in an inconsistent state for a while 20

21 Security Security WS-Federation WS-Trust WS-SecureConversation WS-Security WS-Security: encryption, digital signature WS-SecureConversation: symmetric-key crypto (analogy: SSL) WS-Trust: issuing tokens (analogy: Kerberos) WS-Federation identity management between trusted domains single sign-on 21

22 WS-Security XML encryption and digital signature in the message Authentication information in the message username-password, X.509. certificate, etc. Signed parts: WS-Addressing, WS-ReliableMessaging headers SOAP body Encrypted parts: keys, username-password, etc. SOAP body Uses asymmetric key cryptography => slow Usually for a single call 22

23 WS-SecureConversation Bootstrap protocol: client and server agree in a symmetric key Application-level messages: encrypted by the symmetric key => faster Faster for multiple calls (from about 10 calls) on a single connection The bootstrap protocol is configured like a WS-Security protocol uses asymmetric keys 23

24 WS-Trust sample Driving license STS: Security-Token Service Client Client 1. Buy wine 2. Adult? Web-shop Service 24

25 Federation problem Company A Company B STS A STS B request token for user-pass token from STS A Client A how to use service B with a token from STS A??? Service B Won t work! 25

26 WS-Federation Company A Company B STS A Trust STS B request token for user-pass token from STS A Client A Service B use service with token from STS B 26

27 WS-Federation Advantages: Company B does not have to maintain a database of users from Company A Authorization rights are always up-to-date Builds on WS-Trust WS-Trust: issue, renew and cancel tokens authentication: username-password, X.509 certificates, SAML, tokens from another STS, etc. 27

28 Metadata Metadata WS-MetadataExchange WS-Policy WSDL WS-Policy: describes the capabilities of the service extends the WSDL configures the WS-* protocols e.g.: WS-Security Policy WS-ReliableMessaging Policy WS-AtomicTransaction Policy WS-MetadataExchange: retrieving WSDL exchanging Policy information dynamic protocol discovery 28

29 WS-* standards Security Reliable Messaging Transactions WS-Federation WS-Trust WS-SecureConversation WS-Security WS-Transfer WS-Enumeration WS-Reliability WS-ReliableMessaging Messaging WS-EventNotification WS-Addressing SOAP WS- Atomic Transaction WS-Coordination MTOM WS- Business Activity Metadata WS- Metadata Exchange WS-Policy WSDL XML Encryption XML XML Digitial Signature XML XML Schema XML Namespaces Transport HTTP HTTPS SMTP TCP 29

30 Configuration of WS-* standards WCF (.NET): wshttpbinding in App.config or Web.config JAX-WS does not cover WS-* standards vendors provide their own extensions Metro (GlassFish server) WS-Policy assertions in the WSDL Apache CXF (Tomcat, JBoss, WildFly) Spring configuration + WS-Policy assertions in the WSDL Oracle WebLogic custom XML files or WS-Policy assertions IBM WebSphere custom XML files and WS-Policy assertions 30

31 Interoperability of the WS-* standards 31