Interoperable Web Services with JAX-WS and WSIT

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Notes on slide 1

    Metro builds on top of libraries that are independently reusable outside the context of web services. Those includes: JAXB RI for the databinding layer SAAJ for raw DOM access to SOAP messages Woodstox for efficient XML parsing XML stream buffer for efficient infoset buffering The core of Metro implements the JAX-WS API and serves as the foundation where all the higher-level features plugs in. The extensibility in this layer enables "pay as you go" model, where you'll only pay the performance/complexity price for features that you use. The core also provides the basic interoperability features, such as WS-I Basic Profile, WS-I Attachments Profile, and WS-Addressing.

    JAX-WS stands for Java API for XML Web Services. JAX-WS is a technology for building web services and clients that communicate using XML. In JAX-WS, a remote procedure call is represented by an XML-based protocol such as SOAP.

    In this example, the implementation class, CalculatorWS, is annotated as a web service endpoint using the @WebService annotation. CalculatorWS declares a single method named add. add returns a sum to the client, using the input parameter passed to add to calculate the sum. All the interfaces, remote exceptions needed for jax-rpc are gone. All the values for the service in the wsdl, port...have meaningful defaults which are derived from the name of the class method...So you can get a good contract with the defaults

    getItems() method wraps a List of items, returned from the CatalogFacade Stateless Session EJB, in a DataModel. dataTable, supports data binding to a collection of data objects represented by a DataModel instance, which is the current value of this component itself. The data collection underlying a DataModel instance is modeled as a collection of row objects that can be accessed by a row index. The APIs provide mechanisms to position to a specified row index, and to retrieve an object that represents the data that corresponds to the current row index.

    Tango provides an implementation of the key enterprise Web services technologies, commonly known as WS-*, with a focus to provide interoperability with Windows Communication Foundation, which is a component of .the NET 3.0 framework

    Metro builds on top of libraries that are independently reusable outside the context of web services. Those includes: JAXB RI for the databinding layer SAAJ for raw DOM access to SOAP messages Woodstox for efficient XML parsing XML stream buffer for efficient infoset buffering The core of Metro implements the JAX-WS API and serves as the foundation where all the higher-level features plugs in. The extensibility in this layer enables "pay as you go" model, where you'll only pay the performance/complexity price for features that you use. The core also provides the basic interoperability features, such as WS-I Basic Profile, WS-I Attachments Profile, and WS-Addressing.

    A quick introduction on SOA.

    Interoperable reliability is achieved by implementing the WS-ReliableMessaging specification. Turning on reliability, in Metro, when developing a web service, is simply a checkbox in a reliability panel in NetBeans as shown in the following screenshot.

    A quick introduction on SOA.

    Once the client is authenticated, it must have permissions to perform restricted operations. The server determines if the user whose identity is captured in the credential is authorized to access the resource. The web server performs the authorization decision by consulting the security policy derived from the deployment descriptor associated with the resource to determine the security roles that are permitted access to the resource. The container then tests the user’s credentials against each role to determine if it can map the user to the role. The evaluation stops with an “is authorized” outcome on the first role that the web container is able to map the user to. A “not authorized” outcome is reached if the container is unable to map the user to any of the permitted roles.

    Until now, web services have relied on transport-based security such as SSL to provide point-to-point security. By comparison, message security passes credentials in the SOAP envelope and applies OASIS SOAP Message Security to sign and encrypt message parts. since message security protects the message independent of transport it is possible to protect messages all the way through to the ultimate message receiver (or, target application) providing end-to-end security. This makes it possible to pass messages through a content-based router, or management intermediary (for example) without exposing sensitive information. WSIT implements WS-Security so as to provide interoperable message content integrity and confidentiality, even when messages pass through intermediary nodes before reaching their destination endpoint. WS-Security as provided by WSIT is in addition to existing transport-level security, which may still be used.

    Web Services Trust--Enables web service applications to use SOAP messages to request security tokens that can then be used to establish trusted communications between a client and a web service. WS-Trust is an interoperable protocol that supports the issuance, renewal, and exchange of security tokens. The protocol is used to issue security context tokens, as described by the WS-SecureConversation protocol, but it is also the key to a federated security model. In a federated security model WS-Trust supports the delegation of authentication or authorization activities such that a centralized service, called a token issuer or a Security Token Service (STS), is responsible for issuing a security token that will be accepted by application services.

    Web Services Trust--Enables web service applications to use SOAP messages to request security tokens that can then be used to establish trusted communications between a client and a web service. WS-Trust is an interoperable protocol that supports the issuance, renewal, and exchange of security tokens. The protocol is used to issue security context tokens, as described by the WS-SecureConversation protocol, but it is also the key to a federated security model. In a federated security model WS-Trust supports the delegation of authentication or authorization activities such that a centralized service, called a token issuer or a Security Token Service (STS), is responsible for issuing a security token that will be accepted by application services.

    Web Services Trust--Enables web service applications to use SOAP messages to request security tokens that can then be used to establish trusted communications between a client and a web service. WS-Trust is an interoperable protocol that supports the issuance, renewal, and exchange of security tokens. The protocol is used to issue security context tokens, as described by the WS-SecureConversation protocol, but it is also the key to a federated security model. In a federated security model WS-Trust supports the delegation of authentication or authorization activities such that a centralized service, called a token issuer or a Security Token Service (STS), is responsible for issuing a security token that will be accepted by application services.

    Username authentication with symm key: Protects your application for integrity and confidentiality. Symmetric key relies on single, shared key used for both sign and encrypt a message. They are faster than public key cryptography Client does not possess any certificate or key of his own, but sends username and password for authentication. At runtime server generates a secret key, encrypted with server certificate that it shares with client. Client would need to specify the alias in the truststore identifying the server's certificate alias. - Mutual Certificates Security: Both client and server exchange certificates. Adds security via authentication to ensure integrity and confidentiality. Both keystore and truststore needs to be configurerd at both client and server - Transort security (SSL) : Its a transport layer security. Protects for authentication integrity and confidentiality from point to point. Security is "live" from the time it leaves the consumer until it arrives at the provider, or vice versa. The problem is that it is not protected once it gets to its destination. For protection of data after it reaches its destination, use one of the security mechanisms that uses SSL and also secures data at the message level. - Message authentication over SSL: Attaches a cryptographically secured identity or authentication token with the message and use SSL for confidentiality protection. So, it leverages the best of SSL and adds additional layer for security at message level. By default username suporting token is used. Can also configure x509 supporting token aswell. - SAML Authorization over SSL: Attaches an authorization token with the message and uses SSL for confidentiality protection. In this mechanism, the SAML token is expected to carry some authorization information about an end user. The sender of the token is actually vouching for the credentials in the SAML token. You would need to configure SAML token handler on the client side. - Endorsing Certificate: This one Uses secure messages using symmetric key for integrity and confidentiality protection, and uses an endorsing client certificate to augment the claims provided by the token associated with the message signature. For this mechanism, the client knows the service's certificate, and requests need to be endorsed/authorized by a special identity. For example, all requests to a vendor must be endorsed by a purchase manager, so the certificate of the purchase manager should be used to endorse (or counter sign) the original request. - SAML Sender Vouches with Certificates: Protects msgs with mutual certs for integrity and confidentiality. and with sender vouches SAML token for authorization. For this mechanism, the SAML token is included as part of the message signature as an authorization token and is sent only to the recipient. The message payload needs to be signed and encrypted. The requestor is vouching for the credentials (present in the SAML assertion) of the entity on behalf of which the requestor is acting.The initiator token, which is an X.509 token, is used for signature. The recipient token, which is also an X.509 token, is used for encryption. For the server, this is reversed, the recipient token is the signature token and the initiator token is the encryption token. A SAML token is used for authorization. - SAML Holder of Key: Protects msgs with signed SAML assertions (issued by trusted authority) carrying client client public key and authorization info with integrity and confidentiality protection using mutual certs. The Holder-of-Key (HOK) method establishes the correspondence between a SOAP message and the SAML assertions added to the SOAP message. The attesting entity includes a signature that can be verified with the key information. Under this scenario, the service does not trust the client directly, but requires the client to send a SAML assertion issued by a particular SAML authority. The client knows the recipient's public key, but does not share a direct trust relationship with the recipient. The recipient has a trust relationship with the authority that issues the SAML token. The request is signed with the client's private key and encrypted with the server certificate. The response is signed using the server's private key and encrypted using the key provided within the HOK SAML assertion. - STS Issued Token: Protects msgs using a token issued by secure token service for msg integrity and confidentiality. STS implements WS-Trust. Service providers and consumers are in potentially different managed environments but use a single STS to establish a chain of trust. The service does not trust the client directly, but instead trusts tokens issued by a designated STS. In other words, the STS is taking on the role of a second service with which the client has to securely authenticate. The issued tokens contain a key, which is encrypted for the server and which is used for deriving new keys for signing and encrypting. - STS issued token with service cert: Same as STS issued token with the difference being that the client authenticates using a SAML token that is issued by a designated STS, confidentiality protection is achieved using a service certificate. A service certificate is used by a client to authenticate the service and provide message protection. For GlassFish, a default certificate of s1as is installed. - STS issued endorsing token: Same as STS issued token, with the difference being that the client authenticates using a SAML token that is issued by a designated STS. An endorsing token is used to sign the message signature. n this mechanism, message integrity and confidentiality are protected using ephemeral keys encrypted for the service. Ephemeral keys use an algorithm where the exchange key value is purged from the cryptographic service provider (CSP) when the key handle is destroyed. The service requires messages to be endorsed by a SAML token issued by a designated STS.For this mechanism, authentication of the client is achieved in this way: * The client authenticates with the STS and obtains the necessary token with credentials. * The client's request is signed and encrypted using ephemeral key K. * The server's response is signed and encrypted using the same K. * The primary signature of the request is endorsed using the issued token.

    WS-SecureConversation is a specification that describes the concept of a secure session that reduces the overhead of multiple call exchanges. A security context token (SCT) is generated through an initial exchange between caller and service using the WS-SecureConversation protocol, and this token is used to authenticate subsequent message exchanges (similar to an SSL handshake). A secure session identifier generated during this exchange is also used to correlate messages within the session. This protocol is very important standard for improving the performance of one-shot message security, where credentials are passed with each call, and authenticated for each call. By creating a shared session key through negotiation, the key size used to sign and encrypt messages becomes smaller (using a symmetric key instead of an asymmetric key), which also reduces processing overhead

    A quick introduction on SOA.

    Gross over simplification, but one can think of this as exposing the Transaction Manager as a web service that works outside of firewall. WS-Coordination defines a protocol for registering participants in a coordination context, and passing that coordination context across boundaries. WS-AtomicTransaction represents an implementation of such a coordination context. WS-AtomicTransaction facilitates message-based two-phase commit (2PC) protocol The atomic transaction 2PC protocol coordinates registered services to reach a commit or abort decision, and informs all services of the final result. The decision is the same for all the services in the transaction. Making this group decision uses two phases: · Prepare phase: All participants are asked to get ready to either commit or abort, and then vote on the overall outcome. The vote is propagated up to the root coordinator to make the overall group decision. · Commit phase: If all participants vote to commit, the decision will be to commit. Otherwise, it will be to abort. I

    Gross over simplification, but one can think of this as exposing the Transaction Manager as a web service that works outside of firewall. WS-Coordination defines a protocol for registering participants in a coordination context, and passing that coordination context across boundaries. WS-AtomicTransaction represents an implementation of such a coordination context. WS-AtomicTransaction facilitates message-based two-phase commit (2PC) protocol The atomic transaction 2PC protocol coordinates registered services to reach a commit or abort decision, and informs all services of the final result. The decision is the same for all the services in the transaction. Making this group decision uses two phases: · Prepare phase: All participants are asked to get ready to either commit or abort, and then vote on the overall outcome. The vote is propagated up to the root coordinator to make the overall group decision. · Commit phase: If all participants vote to commit, the decision will be to commit. Otherwise, it will be to abort. I

    REQUIRED is mapping of ws-at policy assertions from previous WSDL.

    Development options : Start from WSDL Start form Java. Sample shows both WS-AT policy assertions. Semantically means: WS consumer MAY flow transaction context. If txn context not dlowed with request message, then service creates a transaction to execute the operation within WSDL is only way to denote transaction characteristic for a webs services implemented as a servlet.

    This table shows how the Java EE transaction annotations and WS-AT policy assertions are related When starting from Java, placing the EE annotations on the service code (or in the deployment descriptors) will cause the related AT policy assertions to be generated in the wSDL file When starting from WSDL, placing the AT policy assertions on the wsdl will cause the EE annotations to be placed on the service code These associations were illustrated in the sample code on the previous slides

    This slide shows some of the system architecture – most of this content is invisible to clients. The client interacts with the system in steps 1, 2a, and 3. Transaction Initator – MS client that creates transaction and invokes transacted @webmethods MS WSAT Coordinator coordinates MS participants AND Java WSAT subordinate coordinator (looks like a participant to MS WS-AT Coordinator). All participants are committed or rolled back by the MS WS-AT coordinator. Coordinator to coordinator communications are secure and pre-negotiated with certificates.

    This slide shows some of the system architecture – most of this content is invisible to clients. The client interacts with the system in steps 1, 2a, and 3. Transaction Initator – MS client that creates transaction and invokes transacted @webmethods MS WSAT Coordinator coordinates MS participants AND Java WSAT subordinate coordinator (looks like a participant to MS WS-AT Coordinator). All participants are committed or rolled back by the MS WS-AT coordinator. Coordinator to coordinator communications are secure and pre-negotiated with certificates.

    A quick introduction on SOA.

    WS-MetadataExchange protocol supports discovery of WSDL documents, WS-Policy settings and message and type schema associated with a particular service. With jax-ws if you want to talk to an endpoint , you give the endpoint address to wsimport. It will use the MEX protocol get the WSDL and generate the client proxy for you automatically Web Services Metadata Exchange: This specification defines a protocol to enable a consumer to obtain a web service's metadata, that is, its WSDL and policies. It can be thought of as a bootstrap mechanism for communication. When the type of metadata desired is clearly known (for example, WS-Policy), a request may indicate that only that type should be returned. To bootstrap communication with web services, this specification defines two request/response interactions. When additional types of metadata are being used or expected, or when a requester needs to retrieve all the metadata relevant to subsequent interactions with an endpoint, a request may indicate that all the available metadata, regardless of type, should be returned.

    Representational State Transfer (REST) is a style of software architecture for distributed systems such as the World Wide Web. The term was introduced in the doctoral dissertation of Roy Fielding in 2000, and has since come into widespread use in the networking community. An important concept in REST is the existence of resources, each of which can be referred to using a global identifier, that is, a URI. In order to manipulate these resources, components of the network, clients and servers, communicate using a standardized interface such as HTTP and exchange representations of these resources.

    Use an annotation to mark the methods that you want the runtime to to call to service the http request. Can either put http method in the annotation or in the method

    The uniform interface also enables every component that understands the HTTP application protocol to interact with your application. Examples of components that benefit from this are generic clients such as curl and wget, proxies, caches, HTTP servers, gateways, even Google/Yahoo!/MSN, and many more. To summarize: For clients to be able to interact with your resources, they should implement the default application protocol (HTTP) correctly, i.e. make use of the standard methods GET, PUT, POST, DELETE.

    To obtain an container managed EntityManager instance, inject the entity manager into the application component: @PersistenceContext EntityManager em; you don't need any cm lifecycle methods With a container-managed entity manager, an EntityManager instance's persistence context is automatically propagated by the container to all application components that use the EntityManager instance within a single Java Transaction Architecture (JTA) transaction. JTA transactions usually involve calls across application components. To complete a JTA transaction, these components usually need access to a single persistence context. This occurs when an EntityManager is injected into the application components via the javax.persistence.PersistenceContext annotation. The persistence context is automatically propagated with the current JTA transaction, and EntityManager references that are mapped to the same persistence unit provide access to the persistence context within that transaction. By automatically propagating the persistence context, application components don't need to pass references to EntityManager instances to each other in order to make changes within a single transaction. The Java EE container manages the lifecycle of container-managed entity managers.

    1 Favorite

    Interoperable Web Services with JAX-WS and WSIT - Presentation Transcript

    1. WSIT Carol McDonald, Java Architect
    2. About the Speaker
      • Carol cDonald:
        • Java Architect at Sun Microsystems
        • Before Sun, worked on software development of:
          • Application to manage Bank Loans
          • Pharmaceutical Intranet apps ( Roche Switzerland)
          • Telecom Network Mgmt ( Digital France)
          • X.400 Email Server ( IBM Germany)
    3. Agenda
      • Metro
        • JAX-WS
        • WSIT
      • REST:
        • JAX-RS
    4. Sun’s Web Services Stack Metro: JAX-WS , WSIT JAXB = Java Architecture for XML Binding | JAX-WS = Java APIs for XML Web Services NetBeans JAX-WS Tooling Transactions Reliable- Messaging Security Metadata WSDL Policy Core Web Services HTTP TCP SMTP JAXB, JAXP, StaX JAX-WS WSIT tools transport xml http://metro.dev.java.net
    5. JAX-WS
      • J ava A PI for X ML W eb S ervices
      • Add @ annotation to Plain Old Java Object (POJO)
      • SOAP 1.2 (document/literal)
      • Uses JAXB for data binding
      • Part of Java SE 6 and Java EE 5 platforms
    6. Web Service Client Pet Catalog Sample JAX-WS Application DB Registration Application Managed Bean JSF Components Web Service Entity Class Catalog Item ManagedBean SOAP
    7. Catalog Web Service @WebService public class Catalog public List<Item> getItems { ... } }
      • public methods become web service operations
      • WSDL/Schema generated at deploy time automatically
    8. Developing a Web Service war or ear @WebService POJO class Servlet-based or Stateless Session EJB Packaged application (war/ear file) You develop Service contract WSDL Deployment creates JAXB and JAX-WS files needed for the service
    9. Service Description default mapping Java mapping -> WSDL: public class Catalog { public List getItems ( int i , int j ){ } } < portType name=&quot; Catalog &quot;> < operation name=&quot; getItems &quot;> < input message=&quot; tns:getItems &quot; /> < output message=&quot; tns:getItemsesponse &quot; /> < /operation > < /portType > PORT TYPE = ABSTRACT INTERFACE OPERATION = METHOD MESSAGE = PARAMETERS AND RETURN VALUES
    10. Server Side Web Service E ndpoint Listener Soap binding @Web Service Soap request publish 1 2
    11. SOAP Request <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?> <S:Envelope xmlns:S=&quot;http://schemas.xmlsoap.org/soap/envelope/&quot;> <S:Header/> <S:Body> <ns2: getItemCount xmlns:ns2=&quot;http://service/&quot;/> </S:Body> </S:Envelope> http://localhost:8080/CatalogService/CatalogService
    12. SOAP Response <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?> <S:Envelope xmlns:S=&quot;http://schemas.xmlsoap.org/soap/envelope/&quot;> <S:Body> <ns2: getItemCountResponse xmlns:ns2=&quot;http://service/&quot;> <return>29</return> </ns2:getItemCountResponse> </S:Body> </S:Envelope>
    13. Glassfish and MySQL Part 3 DEMO
    14. Web Service Client Pet Catalog Sample JAX-WS Application DB Registration Application Managed Bean JSF Components Web Service Entity Class Catalog Item ManagedBean SOAP
    15. Client-Side Programming wsimport tool @WebService Dynamic Proxy Service contract WSDL Generates You develop Client which uses proxy to call Web Service
    16. Web Service Client public class ItemController { @WebServiceRef(wsdlLocation= &quot;http://host/Catalog/Service?wsdl&quot;) private CatalogService service ; public DataModel getItems() { // Call Web Service Operation Catalog port = service .getCatalogPort(); List<Item> result = port.getItems (first, size); return new ListDataModel(result); } } Factory Class Get Proxy Class Business Interface
    17. WSDL to Dynamic Proxy mapping Service Port PortType Binding 1..n 1 1 1..n 1..n CatalogPort Catalog Class CatalogService Add Method Parameters Business Interface Factory Class Proxy Class Operation Message
    18. Client Side CalculatorWS Web Service extends Dynamic Proxy S ervice E ndpoint I nterface Invocation Handler JAXB JAXB return value parameters getPort 1 2 3 6 Soap request Soap response 4 5
    19. Glassfish and MySQL Part 3 DEMO
    20. JAX-WS Layered Architecture Calls Into Implemented on Top of Messaging Layer: Dispatch/Provider Application Code Strongly-Typed Layer: @ Annotated Classes Upper layer Easy to use with annotations Lower layer, API-based, more control For advanced scenarios
    21. Agenda
      • Metro
      • JAX-WS Standards
      • WSIT
      • REST
    22. WSIT: Web Services Interoperability Technology
      • Goal
        • Interoperability with Microsoft Windows Communication Foundation
        • Implementation of WS-* specifications
    23. Sun’s Web Services Stack Metro: JAX-WS , WSIT JAXB = Java Architecture for XML Binding | JAX-WS = Java APIs for XML Web Services NetBeans JAX-WS Tooling Transactions Reliable- Messaging Security Metadata WSDL Policy Core Web Services HTTP TCP SMTP JAXB, JAXP, StaX JAX-WS WSIT tools transport xml
    24. (Web Services Interoperability Technology) WSIT Features
      • End-to-end reliability
      • Secure communication
      • Atomic transaction
      • Optimized communication
      • Bootstrapping communication
    25. Metro WSIT Reliable Messaging
      • messages may get lost or mishandled
      Communication Without Reliable Messaging
    27. Communication With Reliable Messaging Application Message Ack Protocol Message buffer buffer RMSource handles sending and re-sending RMDestination handles reconstructing the stream of messages
    28. WS-Reliable Messaging
      • Brings reliability to SOAP (protocol) layer
      • Transparent to application
      • Recover from lost/misordered messages
      • Delivery assurance
        • At least once
        • At most once
        • In order
      End-to-End Reliability
    29. Configuration with NetBeans
    30. <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?> <definitions xmlns:wsu=&quot;http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd&quot; xmlns:wsp=&quot;http://schemas.xmlsoap.org/ws/2004/09/policy&quot; xmlns:soap=&quot;http://schemas.xmlsoap.org/wsdl/soap/&quot; xmlns:tns=&quot;http://mypackage/&quot; xmlns:xsd=&quot;http://www.w3.org/2001/XMLSchema&quot; xmlns=&quot;http://schemas.xmlsoap.org/wsdl/&quot; targetNamespace=&quot;http://mypackage/&quot; name=&quot;HelloService&quot;> <wsp:UsingPolicy></wsp:UsingPolicy> <wsp:Policy wsu:Id=&quot;HelloPortBindingPolicy&quot;> <wsp:ExactlyOne> <wsp:All> <ns1:RMAssertion xmlns:ns1=&quot;http://schemas.xmlsoap.org/ws/2005/02/rm/policy&quot;></ns1:RMAssertion> <ns2:Ordered xmlns:ns2=&quot;http://sun.com/2006/03/rm&quot;></ns2:Ordered> <ns3:UsingAddressing xmlns:ns3=&quot;http://www.w3.org/2006/05/addressing/wsdl&quot;></ns3:UsingAddressing> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> <!-- omitted --> WSDL with Reliable Messaging
    31. <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?> <S:Envelope xmlns:S=&quot;http://schemas.xmlsoap.org/soap/envelope/&quot;> <S :Header> <To xmlns=&quot;http://www.w3.org/2005/08/addressing&quot;>http://localhost:8080/HelloWebServiceReliable/HelloService</To> <Action xmlns=&quot;http://www.w3.org/2005/08/addressing&quot;>http://mypackage/Hello/sayHelloRequest</Action> < ReplyTo xmlns=&quot;http://www.w3.org/2005/08/addressing&quot;> <Address>http://www.w3.org/2005/08/addressing/anonymous</Address> </ReplyTo> < MessageID xmlns=&quot;http://www.w3.org/2005/08/addressing&quot;>uuid:6bf70fdf-5b7d-4dce-874a-0ab56abc9819</MessageID> <ns2: Sequence xmlns:ns2=&quot;http://schemas.xmlsoap.org/ws/2005/02/rm&quot; xmlns:ns3=&quot;http://schemas.microsoft.com/ws/2006/05/rm&quot; xmlns:ns4=&quot;http://www.w3.org/2005/08/addressing&quot;> <ns2: Identifier >uuid:b8a4fd6e-1992-4a5f-8972-3b3f2c86b1a8</ns2:Identifier> <ns2: MessageNumber >1</ns2:MessageNumber> </ns2:Sequence> <ns2: AckRequested xmlns:ns2=&quot;http://schemas.xmlsoap.org/ws/2005/02/rm&quot; xmlns:ns3=&quot;http://schemas.microsoft.com/ws/2006/05/rm&quot; xmlns:ns4=&quot;http://www.w3.org/2005/08/addressing&quot;> <ns2:Identifier>uuid:b8a4fd6e-1992-4a5f-8972-3b3f2c86b1a8</ns2:Identifier> </ns2:AckRequested> </S:Header> <S:Body> <ns2:sayHello xmlns:ns2=&quot;http://mypackage/&quot;> <arg0>SangShin</arg0> <arg1>22</arg1> </ns2:sayHello> </S:Body> </S:Envelope> SOAP Request with R.M.
    32. <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?> <S:Envelope xmlns:S=&quot;http://schemas.xmlsoap.org/soap/envelope/&quot;> <S:Header> <To xmlns=&quot;http://www.w3.org/2005/08/addressing&quot;>http://www.w3.org/2005/08/addressing/anonymous</To> <Action xmlns=&quot;http://www.w3.org/2005/08/addressing&quot;>http://mypackage/Hello/sayHelloResponse</Action> < MessageID xmlns=&quot;http://www.w3.org/2005/08/addressing&quot;>uuid:46bb95a0-1ea0-47b7-b417-e19cbf652db8</MessageID> < RelatesTo xmlns=&quot;http://www.w3.org/2005/08/addressing&quot;>uuid:6bf70fdf-5b7d-4dce-874a-0ab56abc9819</RelatesTo> </S:Header> <S:Body> <ns2:sayHelloResponse xmlns:ns2=&quot;http://mypackage/&quot;> <return>Hello SangShin!My age is 22</return> </ns2:sayHelloResponse> </S:Body> </S:Envelope> SOAP Response Message with R.M.
    33.  
    34. Metro WSIT Security
    35. Digital Certificate Identity data signed by a Certification Authority. Provides a Trusted source of identification. Version # Serial # Signature Algorithm Issuer Name Validity Period Subject Name Subject Public Key Issuer Unique ID Subject Unique ID Extensions Digital Signature X.509 Certificate Digital ID
      • Electronic Proof of Identity
      • Issued and signed by Certifying Authority
      • Public, Private keys
      • Makes security protocols work
        • SSL
      CA Authorized
    36. Encryption Receiver Public Key Receiver Private Key
        • XML Encryption (data confidentiality )
          • Only the private key can decrypt
      Asymmetric keys Public Encryption Original Document Encrypted Document Private Decryption Original Document Sender Receiver
    37. Digital Signature Transform Transform Sender Sender's Private Key Sender's Public Key
        • XML Signature (data integrity )
        • Bind the sender’s identity to an XML document
      Private Encryption XML data Signature Public Decryption XML data Receiver
    38. SSL Key Exchange Server Client connects Browser generates symetric session key Use session key to Encrypt data
      • Browser and Server use Session Key B to encrypt all data exchanged over the Internet
      Client obtains server's certificate; verifies with trusted CA
    39. Transport Security (SSL) Use case: client with no relationship with service
      • Point-to-point
      • Security at transport layer
      • Encrypts session
    40. WS-Security: SOAP Message Security WS-Security defines:
      • Encrypting and signing message parts:
        • XML Signature and XML Encryption in SOAP Header
      • How to pass security tokens
        • (token=identifies the msg sender )
          • UserName/Password token
          • X.509 certificate
          • SAML
          • Kerberos tickets
      SOAP Envelope SOAP Envelope Header SOAP Envelope Body WS-Security Header Security Token Business Payload
    41. Security Before WS-Security WS-Security
      • Security at SOAP message layer
      • XML Signature/Encryption
      • Only sign/encrypt part of msg
      • Work with intermediaries
      • SSL/HTTPS
      • Security at transport layer
      • All or nothing granularity
      • Point-to-point
    42. request data response data authentication data SAML assertions https/ssl (optional) digital certificate Security Architecture Message Level Security (signature and encryption) web services client SOAP client signed & encrypted data web services server SOAP server SOAP service security server authentication authorization signature validation data encryption digital certificate request data data decryption/ encryption signature validation
    43. WS-Security <SOAP-ENV:Envelope xmlns:SOAP-ENV=&quot;http://www.w3.org/2003/05/soap-envelope&quot; xmlns:xsd=&quot;http://www.w3.org/2001/XMLSchema&quot; xmlns:xsi=&quot;http://www.w3.org/2001/XMLSchema-instance&quot;> <SOAP-ENV:Header> <wsse:Security SOAP-ENV:mustUnderstand=&quot;true&quot; xmlns:wsse=&quot;http://docs.oasis-open.org/...-wss-wssecurity-secext-1.0.xsd&quot;> <ds: Signature xmlns:ds=&quot;http://www.w3.org/2000/09/xmldsig#&quot;> <ds: SignedInfo > <ds:CanonicalizationMethod Algorithm=&quot;http://www.w3.org/2001/10/xml-exc-c14n#&quot;/> <ds:SignatureMethod Algorithm =&quot;http://www.w3.org/2000/09/xmldsig#dsa-sha1&quot;/> <ds:Reference URI=&quot; #id-1281123 &quot;> <ds:Transforms> <ds:Transform Algorithm=&quot;http://www.w3.org/2001/10/xml-exc-c14n#&quot;/> </ds:Transforms> <ds: DigestMethod Algorithm =&quot;http://www.w3.org/2000/09/xmldsig#sha1&quot;/> <ds:DigestValue>wLumPkKZ+X48rjao/XUUQDp0xk0=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds: SignatureValue >a56OxPcKr8LJnIFgRyMQej5/ZkUjkV9V9rmn+queMKzJ3GYpMiXpjQ==</ds:SignatureValue> <ds: KeyInfo Id=&quot;KeyId-30752603&quot;> <wsse: SecurityTokenReference wsu:Id=&quot;STRId-2545159&quot; xmlns:wsu=&quot;http://docs.-wss-wssecurity-utility-1.0.xsd&quot;> <ds: X509IssuerSerial > <ds:X509IssuerName>CN=pubcert</ds:X509IssuerName> <ds:X509SerialNumber>1140726843</ds:X509SerialNumber> </ds:X509IssuerSerial> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </SOAP-ENV:Header> <SOAP-ENV:Body wsu:Id=&quot; id-1281123 &quot; xmlns:wsu=&quot;http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd&quot;> <sayHello xmlns=&quot;http://jeffhanson.com/services/helloworld&quot;> <value xmlns=&quot;&quot;>Hello world!</value> </sayHello> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
    44. <S: Envelope xmlns:S=“http://…” xmlns:wsse=“http://…” xmlns:xenc=“http://…” <S:Header> <wsse:Security> <wsse:BinarySecurityToken> ID=“MyToken” … </wsse:BinarySecurityToken> <xenc:EncryptedKey> … <xenc:ReferenceList> <xenc:DataReference URI=“#enc”/> </xenc:ReferenceList> </xenc:EncryptedKey> <ds:Signature> … </ds:Signature> </wsse:Security> </S:Header> Security Message Key used for the signature Key used to encrypt message Signature algorithm key info, signature value
      • framework for:
        • Issue, Validate, Exchange security tokens used by WS-Security
        • Establish and broker trust relationships
      WS-Trust
    46. Message Authentication over SSL Use case: client/service ID/Auth token relationship
      • Use token to plug into service's ID/Authentication infrastructure
      • Options: Username/Password,X.509, (& SAML)
      SSO
    47. WS-Trust Using an STS STS 1. User calls WS operation. 2. STS interaction, token returned 3. Pass token with web service Use token attributes to determine user role Client (Metro) Web Service (Metro) (e.g. OpenSSO)
      • WS-Trust
        • Exchange
      Trust
      • WS-Trust
        • Validate
        • Establish and broker trust relationships
      Trust .NET service Java client
    50. Federated Trust STS A Client (browser) Web Service (Metro) AuditWS (Metro) RecordsDB AuditDB STS B (e.g. OpenSSO) (e.g., MS Geneva) Web App (using OpenSSO)
        • Issue, Validate, Exchange
        • Establish and broker trust relationships
    51. Identity Services through OpenSSO
    52. OpenSSO Architecture Policy Service Authentication Service SAML Service Identity Repository Service Realms Delegation Service Authentication Authorization Single Sign-on Integrated Console CLI Liberty Service Authentication Management Policy Management Federation Management Access Manager Server Admin Utilities Session Service Logging Services AM Information Tree Identity Repository Data Store Web Policy Agents Client SDK J2EE Policy Agents WS Security Agents
    53. Loan Processing Use Case Scenario Policy Service Authentication Service SAML Service Identity Repository Service Realms Delegation Service Liberty Service Access Manager Server Session Service Logging Services WSDL WSDL WSDL WSDL Web Policy Agents Client SDK J2EE Policy Agents WS Security Agents Integrated Console Jane requesting for Loan
    54. Security Mechanisms
      • Username Authentication with Symmetric Keys
      • Mutual Certificates Security
      • Transport Security (SSL)
      • Message Authentication over SSL
      • SAML Authorization over SSL
      • Endorsing Certificate
      • SAML Sender Vouches with Certificates
      • SAML Holder of Key
      • STS Issued Token
      • STS Issued Token with Service Certificate
      • STS Issued Endorsing Token
      • How to Establish a Secure SESSION
        • For multiple message exchanges
        • Create shared symmetric session key
        • Optimizes processing
      WS-SecureConversation Optimized Security security context token Use generated symmetric session key
    56.  
    57. Metro WSIT Transactions
    58. Sub-Topics of Web Services Transaction
      • Transaction support for Web services
      • Server programming models
      • Mapping between Java EE transaction attributes and WS-AT policy statements
      • Control flow
      • Client programming model
      • Atomic transaction policy
    59. Java™ Transaction Service Application Server Transaction Service Application UserTransaction interface Resource Manager XAResource interface Transactional operation TransactionManager Interface Resource EJB Transaction context
    60. WS-Coordination and WS-AtomicTransaction Protocols in Two GlassFish Domains WS-Coordination : Wire protocol for distributed coordinated activity Participant registration
    61. WS-Coordination and WS-AtomicTransaction Protocols in Two GlassFish Domains WS-Atomic Transaction : Coordinated two phase commit for web service operations
      • Option 1: Start from Java source using Annotations
        • Stateless EJB ™ using Container Managed Transaction (CMT) using Annotations
          • WSDL with WS-AT Policy gets created
      • Option 2: Start from WSDL
        • Transacted operations denoted with WS-AT Policy Assertion
      How to Created Transacted Web Service: 2 Options
    63. Transacted Web Service: Option 1 @WebService @Stateless public class Bank { @TransactionAttribute(REQUIRED ) void transferFunds(...) throws ... ; } [1] stateless EJB default, annotation added to be explicit
    64. Transacted Web Service: Option 2 <wsdl:definitions> <!-- Define WS-AT policy assertion --> <wsp:Policy wsu:Id=&quot; TransactedPolicy1 &quot; > < wsat:ATAssertion wsp:Optional=&quot;true” /> <wsat:ATAlwaysCapability/> </wsp:Policy> <wsdl:binding name=&quot;Bank&quot; type=&quot;tns:BankPortType&quot; > <!-- Marked Transacted by Operation Policy Subject--> <wsdl:operation name=&quot; transferFunds &quot; > <wsp:PolicyReference URI=&quot;#TransactedPolicy1&quot; wsdl:required=&quot;true&quot; /> ... </wsdl:operation> </wsdl:binding> </wsdl:definitions>
    65. Configuration with NetBeans
    66. <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?> <definitions xmlns:wsu=&quot;http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd&quot; xmlns:wsp=&quot;http://schemas.xmlsoap.org/ws/2004/09/policy&quot; xmlns:soap=&quot;http://schemas.xmlsoap.org/wsdl/soap/&quot; xmlns:tns=&quot;http://mypackage/&quot; xmlns:xsd=&quot;http://www.w3.org/2001/XMLSchema&quot; xmlns=&quot;http://schemas.xmlsoap.org/wsdl/&quot; targetNamespace=&quot;http://mypackage/&quot; name=&quot;HelloService&quot;> <wsp:UsingPolicy></wsp:UsingPolicy> <wsp:Policy wsu:Id=&quot;HelloPortBinding_sayHello_Policy&quot;> <wsp:ExactlyOne> <wsp:All> <ns1: ATAlwaysCapability xmlns:ns1=&quot;http://schemas.xmlsoap.org/ws/2004/10/wsat&quot;></ns1:ATAlwaysCapability> <ns2: ATAssertion xmlns:ns2=&quot;http://schemas.xmlsoap.org/ws/2004/10/wsat&quot; wsp:Optional=&quot;true&quot;></ns2:ATAssertion> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> WSDL with Transaction
    67. Mapping Between Java EE Transaction and WS-Atomic Transaction (1) Also specifiable in deployment descriptor (2) Default for Container Managed Transaction (CMT) EJB architecture (3) Closest mapping for WSDL to Java binding
      • Start a transaction in Web Service Client
      • WSIT creates Transaction Context when ws invoked
      @Resource javax.transaction.UserTransaction ut; ut.begin(); bankWebService.makeWithdrawl(); ... ut.commit();. Transaction Context created Web Service Client
    69. MS Client Coordinated Transaction 4a: WS-AT Protocol 3: TxnCommit 2c: WS-Coor Protocol 2b: Register 4b: XA Protocol 4b: MSDTC Protocol 2a: Invoke 1: TxnCreate
    70. Java Client Coordinated Transaction 4a: WS-AT Protocol 3: TxnCommit 2c: WS-Coor Protocol 2b: Register 4b: MSDTC Protocol 4b: XA Protocol 2a: Invoke 1: TxnBegin
    71. Metro: Bootstrapping
    72. Bootstrapping Communication JAX-WS wsimport WCF or WSIT Web Service Creates Client Proxy WS-Transfer/MEX WSDL WS-MetadataExchange WS-MetadataExchange protocol supports:
            • discovery of WSDL documents
            • metadata exchange is handled by wsimport utility of WSIT
            • transparent to developers
      < wsdl …> < policy …> … </policy> … </wsdl> WSDL
    73. WS-Policy <wsdl…> <policy…> … </policy> … </wsdl> <wsdl…> <policy…> <security-policy> … </security-policy> <transaction-policy> … </transaction-policy> <reliability-policy> … </reliability-policy> … </policy> … </wsdl>
    74. Proxy Generation Bootstrapping Communication <wsdl…> <policy…> < security-policy > … </security-policy> < transaction-policy > … </transaction-policy> < reliability-policy > … </reliability-policy> … </policy> … </wsdl>
    75. End-to-End Messaging
    76. WSIT NetBeans Module By Hand Other IDEs 109 Deployment META-INF/wsit-*.xml Service Servlet Deployment WEB-INF/wsit-*.xml WSIT Server-Side Programming Model WSIT Config File wsit-*.xml
      • No runtime APIs for WSIT
      • Config file produced by NetBeans enable/control WSIT
    77.  
    78. WSIT Client Programming Model 109 Service Wsimport Client Artifacts WSIT Config File wsit-*.xml WSIT NetBean Module By Hand Other IDEs MEX/ GET WDSL MEX/ GET
    79. Metro SOAP/TCP and FastInfoset Smaller and faster
      • Fast Infoset message encoding
        • ITU-T and ISO/IEC standard encoding of XML
        • more compact than text, MTOM and .NET Binary
      • SOAP/TCP transport
        • WS messages over TCP
        • works with message security and transport security
        • FastInfoset
          • even better performance when used together
      • Built into Metro
    80. Agenda
      • Metro
      • JAX-WS Standards
      • WSIT
      • REST with JAX-RS
    81. REpresentational State Transfer Get http://petcatalog/items Response data = REpresentational State Transfer REST Tenets
      • Resources ( nouns )
        • Identified and exposed through web URIs , For example:
          • http://www.petstore.com/catalog/items
      • Methods ( verbs ) small fixed set
        • HTTP methods POST, GET, PUT, DELETE:
          • to create, retrieve, update, and delete resources
      • Representation of the Resource
        • XML, JSON.. data state exchanged between client and Service
    82. HTTP Example Request GET /catalog/items HTTP/1.1 Host: petstore.com Accept: application/xml Response HTTP/1.1 200 OK Date: Tue, 08 May 2007 16:41:58 GMT Server: Apache/1.3.6 Content-Type: application/xml; charset=UTF-8 <?xml version=&quot;1.0&quot;?> <items xmlns=&quot;…&quot;> <item>…</item> … </items> Method Resource Representation State transfer
    83. JAX-RS: Clear mapping to REST concepts
      • High level, Declarative
        • Uses @ annotation in POJOs
      • Resources : what are the URIs ?
        • @Path(&quot;/items/{id}&quot;)
      • Methods : what are the HTTP methods ?
      @GET public XXX find()
      • Representations : what are the formats ?
        • @Consumes(&quot;application/xml&quot;)
        • @Produces(&quot;application/json&quot;)
    84. POJO @Path(&quot;/items/&quot;) public class ItemsResource { @Produces(&quot;application/json&quot;) @GET public ItemsConverter get() { ... } ... } responds to the URI http://host/catalog/items/ responds with JSON responds to HTTP GET
    85. Example RESTful Catalog
    86. Glassfish and MySQL Part 4
    87.  
    88. RESTful Catalog
          • Dojo client, JAX-RS, JAXB, JPA
      DB Registration Application JAX-RS class Dojo client JAXB class Entity Class ItemsConverter Item ItemsResource
    89. URIs and Methods:
      • /items
        • GET - list all items
        • POST – add item to catalog
      • /items/{id}
        • GET - get an item representation
        • PUT - update an item
        • DELETE – remove an item
      Item Catalog Example http://www.infoq.com/articles/rest-introduction
    90. Resource Classes
        • Items Resource retrieves updates a collection of Item entities
        • /items – URI for a list of Items
        • Item resource retrieves or updates one Item entity
        • /item/1 – URI for item 1
      DB JAX-RS class Dojo client JAXB class Entity Class ItemsConverter Item ItemsResource
    91. Methods Java method name is not significant The @HTTP method is the method @Path(“/items”) class ItemsResource { @GET Items get() { ... } @POST Response create(Item) { ... } } class ItemResource { @GET Item get(...) { ... } @PUT void update(...) { ... } @DELETE void delete(...) { ... } }
    92. Get Items @Path(&quot;/items/&quot;) public class ItemsResource { @Context protected UriInfo uriInfo; @GET @Produces (&quot;application/json&quot;) public ItemsConverter get(){ return new ItemsConverter( getEntities(), uriInfo.getAbsolutePath()); } Performs JPA Query, returns list of entities JAXB class responds with JSON responds to the URI http://host/catalog/items/ responds to HTTP GET
    93. XML <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?> <items uri=&quot;http://localhost/Web/resources/items/&quot;> <item uri=&quot;http://localhost/Web/resources/items/1/&quot; > <description> black cat is nice</description> <id>1</id> <imagethumburl>/images/anth.jpg</imagethumburl> <name>not Friendly Cat</name> <price>307.10</price> <productid>feline01</productid> </item> <item . . . </item> </items>
    94. JSON { &quot;@uri&quot;:&quot;http://host/catalog/resources/items/&quot;, &quot; item &quot;:[ {&quot;@uri&quot;:&quot;http://host/catalog/resources/items/1/&quot;, &quot;name&quot;:&quot;Friendly Cat&quot;, &quot;description&quot;:&quot;This black and white colored cat is super friendly.&quot;, &quot;id&quot;:&quot;1&quot;, &quot;imageurl&quot;:&quot;http://localhost:8080/CatalogService/images/anthony.jpg&quot;}, {&quot;@uri&quot;:&quot;http://host/catalog/resources/items/2/&quot;, &quot;name&quot;:&quot;Fluffy Cat&quot;, &quot;description&quot;:&quot;A great pet for a hair stylist! &quot;id&quot;:&quot;2&quot;, &quot;imageurl&quot;:&quot;http://localhost:8080/CatalogService/images/bailey.jpg&quot;} ] }
    95. Ajax RESTful Catalog client
    96. RESTful Pet Catalog Web Service http://petstore/catalog/resources/items/ HTTP GET Response JSON items {&quot;url&quot;:&quot;http://store/catalog/item1&quot;, {&quot;url&quot;:&quot;http://store/catalog/item2&quot;} Server Client Addressable Resources Web Container
    97. JavaFX RESTful Catalog client
    98. RESTful Pet Catalog Web Service http://petstore/catalog/resources/items/ HTTP GET Response XML items <item> <imageurl>http://host/catalog/images/anthony.jpg</imageurl> <name>Friendly Cat</name> <price>307.10</price> <productid>feline01</productid> </item> Server Client Addressable Resources Web Container
    99. Demo
      • Create RESTful Web Services from Entity Classes
      • Test RESTful Web Servics
    100. Why SOAP?
      • Web Service WSDL already defined
      • Existing tools, infrastructure, know-how
      • Advanced security, reliability requirements
    101. Why REST ?
      • Simplicity
      • Takes advantage of HTTP:
        • Scalability: stateless, caching
      • Ajax , HTTP clients
    102. Summary
      • Metro with GlassFish Application Server:
        • JAX-WS
          • easy to use
        • WSIT
          • Makes Metro interoperable with other WS-* stacks
          • No new APIs , easy with NetBeans plugin
      • JAX-RS
        • easy declarative programming model for REST
    103. For More Information
      • METRO
        • http://metro.dev.java.net
      • REST
        • http://jersey.dev.java.net
      • Glassfish
        • http://glassfish.dev.java.net
      • Carol's Blog
        • http://weblogs.java.net/blog/caroljmcdonald/
      • http://www.javapassion.com/webservices/index.html
    SlideShare Zeitgeist 2009

    + Carol McDonaldCarol McDonald Nominate

    custom

    1198 views, 1 favs, 0 embeds more stats

    Interoperable SOAP Web Services, REST

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 1198
      • 1198 on SlideShare
      • 0 from embeds
    • Comments 0
    • Favorites 1
    • Downloads 36
    Most viewed embeds

    more

    All embeds

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories

    Tags

    -->
    What's New

    © 2009 SlideShare Inc. All rights reserved.