Interoperable Web Services with JAX-WS and WSIT

13,463 views

Published on

Interoperable SOAP Web Services, REST

Published in: Technology
0 Comments
12 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
13,463
On SlideShare
0
From Embeds
0
Number of Embeds
180
Actions
Shares
0
Downloads
721
Comments
0
Likes
12
Embeds 0
No embeds

No notes for slide
  • 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.
  • Interoperable Web Services with JAX-WS and WSIT

    1. 1. WSIT Carol McDonald, Java Architect
    2. 2. About the Speaker <ul><li>Carol cDonald: </li><ul><li>Java Architect at Sun Microsystems
    3. 3. Before Sun, worked on software development of: </li><ul><li>Application to manage Bank Loans
    4. 4. Pharmaceutical Intranet apps ( Roche Switzerland)
    5. 5. Telecom Network Mgmt ( Digital France)
    6. 6. X.400 Email Server ( IBM Germany) </li></ul></ul></ul>
    7. 7. Agenda <ul><li>Metro </li><ul><li>JAX-WS
    8. 8. WSIT </li></ul><li>REST: </li><ul><li>JAX-RS </li></ul></ul>
    9. 9. 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
    10. 10. JAX-WS <ul><li>J ava A PI for X ML W eb S ervices
    11. 11. Add @ annotation to Plain Old Java Object (POJO)
    12. 12. SOAP 1.2 (document/literal)
    13. 13. Uses JAXB for data binding
    14. 14. Part of Java SE 6 and Java EE 5 platforms </li></ul>
    15. 15. Web Service Client Pet Catalog Sample JAX-WS Application DB Registration Application Managed Bean JSF Components Web Service Entity Class Catalog Item ManagedBean SOAP
    16. 16. Catalog Web Service @WebService public class Catalog public List<Item> getItems { ... } } <ul><li>public methods become web service operations
    17. 17. WSDL/Schema generated at deploy time automatically </li></ul>
    18. 18. 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
    19. 19. 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
    20. 20. Server Side Web Service E ndpoint Listener Soap binding @Web Service Soap request publish 1 2
    21. 21. 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
    22. 22. 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>
    23. 23. Glassfish and MySQL Part 3 DEMO
    24. 24. Web Service Client Pet Catalog Sample JAX-WS Application DB Registration Application Managed Bean JSF Components Web Service Entity Class Catalog Item ManagedBean SOAP
    25. 25. Client-Side Programming wsimport tool @WebService Dynamic Proxy Service contract WSDL Generates You develop Client which uses proxy to call Web Service
    26. 26. 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
    27. 27. 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
    28. 28. 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
    29. 29. Glassfish and MySQL Part 3 DEMO
    30. 30. 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
    31. 31. Agenda <ul><li>Metro
    32. 32. JAX-WS Standards
    33. 33. WSIT
    34. 34. REST </li></ul>
    35. 35. WSIT: Web Services Interoperability Technology <ul><li>Goal </li><ul><li>Interoperability with Microsoft Windows Communication Foundation
    36. 36. Implementation of WS-* specifications </li></ul></ul>
    37. 37. 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
    38. 38. (Web Services Interoperability Technology) WSIT Features <ul><li>End-to-end reliability
    39. 39. Secure communication
    40. 40. Atomic transaction
    41. 41. Optimized communication
    42. 42. Bootstrapping communication </li></ul>
    43. 43. Metro WSIT Reliable Messaging
    44. 44. <ul><li>messages may get lost or mishandled </li></ul>Communication Without Reliable Messaging
    45. 45. Communication With Reliable Messaging Application Message Ack Protocol Message buffer buffer RMSource handles sending and re-sending RMDestination handles reconstructing the stream of messages
    46. 46. WS-Reliable Messaging <ul><li>Brings reliability to SOAP (protocol) layer
    47. 47. Transparent to application
    48. 48. Recover from lost/misordered messages
    49. 49. Delivery assurance </li><ul><li>At least once
    50. 50. At most once
    51. 51. In order </li></ul></ul>End-to-End Reliability
    52. 52. Configuration with NetBeans
    53. 53. <?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
    54. 54. <?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.
    55. 55. <?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.
    56. 57. Metro WSIT Security
    57. 58. 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 <ul><li>Electronic Proof of Identity
    58. 59. Issued and signed by Certifying Authority
    59. 60. Public, Private keys
    60. 61. Makes security protocols work </li><ul><li>SSL </li></ul></ul>CA Authorized
    61. 62. Encryption Receiver Public Key Receiver Private Key <ul><ul><li>XML Encryption (data confidentiality ) </li></ul></ul><ul><ul><ul><li>Only the private key can decrypt </li></ul></ul></ul>Asymmetric keys Public Encryption Original Document Encrypted Document Private Decryption Original Document Sender Receiver
    62. 63. Digital Signature Transform Transform Sender Sender's Private Key Sender's Public Key <ul><ul><li>XML Signature (data integrity )
    63. 64. Bind the sender’s identity to an XML document </li></ul></ul>Private Encryption XML data Signature Public Decryption XML data Receiver
    64. 65. SSL Key Exchange Server Client connects Browser generates symetric session key Use session key to Encrypt data <ul><li>Browser and Server use Session Key B to encrypt all data exchanged over the Internet </li></ul>Client obtains server's certificate; verifies with trusted CA
    65. 66. Transport Security (SSL) Use case: client with no relationship with service <ul><li>Point-to-point
    66. 67. Security at transport layer
    67. 68. Encrypts session </li></ul>
    68. 69. WS-Security: SOAP Message Security WS-Security defines: <ul><li>Encrypting and signing message parts: </li><ul><li>XML Signature and XML Encryption in SOAP Header </li></ul><li>How to pass security tokens </li><ul><li>(token=identifies the msg sender ) </li><ul><li>UserName/Password token
    69. 70. X.509 certificate
    70. 71. SAML
    71. 72. Kerberos tickets </li></ul></ul></ul>SOAP Envelope SOAP Envelope Header SOAP Envelope Body WS-Security Header Security Token Business Payload
    72. 73. Security Before WS-Security WS-Security <ul><li>Security at SOAP message layer
    73. 74. XML Signature/Encryption
    74. 75. Only sign/encrypt part of msg
    75. 76. Work with intermediaries </li></ul><ul><li>SSL/HTTPS
    76. 77. Security at transport layer
    77. 78. All or nothing granularity
    78. 79. Point-to-point </li></ul>
    79. 80. 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
    80. 81. 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>
    81. 82. <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
    82. 83. <ul><li>framework for: </li><ul><li>Issue, Validate, Exchange security tokens used by WS-Security
    83. 84. Establish and broker trust relationships </li></ul></ul>WS-Trust
    84. 85. Message Authentication over SSL Use case: client/service ID/Auth token relationship <ul><li>Use token to plug into service's ID/Authentication infrastructure
    85. 86. Options: Username/Password,X.509, (& SAML) </li></ul>SSO
    86. 87. 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)
    87. 88. <ul><li>WS-Trust </li><ul><li>Exchange </li></ul></ul>Trust
    88. 89. <ul><li>WS-Trust </li><ul><li>Validate
    89. 90. Establish and broker trust relationships </li></ul></ul>Trust .NET service Java client
    90. 91. 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) <ul><ul><li>Issue, Validate, Exchange
    91. 92. Establish and broker trust relationships </li></ul></ul>
    92. 93. Identity Services through OpenSSO
    93. 94. 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
    94. 95. 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
    95. 96. Security Mechanisms <ul><li>Username Authentication with Symmetric Keys
    96. 97. Mutual Certificates Security
    97. 98. Transport Security (SSL)
    98. 99. Message Authentication over SSL
    99. 100. SAML Authorization over SSL
    100. 101. Endorsing Certificate
    101. 102. SAML Sender Vouches with Certificates
    102. 103. SAML Holder of Key
    103. 104. STS Issued Token
    104. 105. STS Issued Token with Service Certificate
    105. 106. STS Issued Endorsing Token </li></ul>
    106. 107. <ul><li>How to Establish a Secure SESSION </li><ul><li>For multiple message exchanges
    107. 108. Create shared symmetric session key
    108. 109. Optimizes processing </li></ul></ul>WS-SecureConversation Optimized Security security context token Use generated symmetric session key
    109. 111. Metro WSIT Transactions
    110. 112. Sub-Topics of Web Services Transaction <ul><li>Transaction support for Web services
    111. 113. Server programming models
    112. 114. Mapping between Java EE transaction attributes and WS-AT policy statements
    113. 115. Control flow
    114. 116. Client programming model
    115. 117. Atomic transaction policy </li></ul>
    116. 118. Java™ Transaction Service Application Server Transaction Service Application UserTransaction interface Resource Manager XAResource interface Transactional operation TransactionManager Interface Resource EJB Transaction context
    117. 119. WS-Coordination and WS-AtomicTransaction Protocols in Two GlassFish Domains WS-Coordination : Wire protocol for distributed coordinated activity Participant registration
    118. 120. WS-Coordination and WS-AtomicTransaction Protocols in Two GlassFish Domains WS-Atomic Transaction : Coordinated two phase commit for web service operations
    119. 121. <ul><li>Option 1: Start from Java source using Annotations </li><ul><li>Stateless EJB ™ using Container Managed Transaction (CMT) using Annotations </li><ul><li>WSDL with WS-AT Policy gets created </li></ul></ul><li>Option 2: Start from WSDL </li><ul><li>Transacted operations denoted with WS-AT Policy Assertion </li></ul></ul>How to Created Transacted Web Service: 2 Options
    120. 122. Transacted Web Service: Option 1 @WebService @Stateless public class Bank { @TransactionAttribute(REQUIRED ) void transferFunds(...) throws ... ; } [1] stateless EJB default, annotation added to be explicit
    121. 123. 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>
    122. 124. Configuration with NetBeans
    123. 125. <?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
    124. 126. 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
    125. 127. <ul><li>Start a transaction in Web Service Client
    126. 128. WSIT creates Transaction Context when ws invoked </li></ul>@Resource javax.transaction.UserTransaction ut; ut.begin(); bankWebService.makeWithdrawl(); ... ut.commit();. Transaction Context created Web Service Client
    127. 129. 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
    128. 130. 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
    129. 131. Metro: Bootstrapping
    130. 132. Bootstrapping Communication JAX-WS wsimport WCF or WSIT Web Service Creates Client Proxy WS-Transfer/MEX WSDL WS-MetadataExchange WS-MetadataExchange protocol supports: <ul><ul><ul><ul><li>discovery of WSDL documents
    131. 133. metadata exchange is handled by wsimport utility of WSIT
    132. 134. transparent to developers </li></ul></ul></ul></ul>< wsdl …> < policy …> … </policy> … </wsdl> WSDL
    133. 135. WS-Policy <wsdl…> <policy…> … </policy> … </wsdl> <wsdl…> <policy…> <security-policy> … </security-policy> <transaction-policy> … </transaction-policy> <reliability-policy> … </reliability-policy> … </policy> … </wsdl>
    134. 136. Proxy Generation Bootstrapping Communication <wsdl…> <policy…> < security-policy > … </security-policy> < transaction-policy > … </transaction-policy> < reliability-policy > … </reliability-policy> … </policy> … </wsdl>
    135. 137. End-to-End Messaging
    136. 138. 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 <ul><li>No runtime APIs for WSIT
    137. 139. Config file produced by NetBeans enable/control WSIT </li></ul>
    138. 141. 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
    139. 142. Metro SOAP/TCP and FastInfoset Smaller and faster <ul><li>Fast Infoset message encoding </li><ul><li>ITU-T and ISO/IEC standard encoding of XML
    140. 143. more compact than text, MTOM and .NET Binary </li></ul><li>SOAP/TCP transport </li><ul><li>WS messages over TCP
    141. 144. works with message security and transport security
    142. 145. FastInfoset </li><ul><li>even better performance when used together </li></ul></ul><li>Built into Metro </li></ul>
    143. 146. Agenda <ul><li>Metro
    144. 147. JAX-WS Standards
    145. 148. WSIT
    146. 149. REST with JAX-RS </li></ul>
    147. 150. REpresentational State Transfer Get http://petcatalog/items Response data = REpresentational State Transfer REST Tenets <ul><li>Resources ( nouns ) </li><ul><li>Identified and exposed through web URIs , For example: </li><ul><li>http://www.petstore.com/catalog/items </li></ul></ul><li>Methods ( verbs ) small fixed set </li><ul><li>HTTP methods POST, GET, PUT, DELETE: </li><ul><li>to create, retrieve, update, and delete resources </li></ul></ul><li>Representation of the Resource </li><ul><li>XML, JSON.. data state exchanged between client and Service </li></ul></ul>
    148. 151. 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
    149. 152. JAX-RS: Clear mapping to REST concepts <ul><li>High level, Declarative </li><ul><li>Uses @ annotation in POJOs </li></ul><li>Resources : what are the URIs ? </li></ul><ul><ul><li>@Path(&quot;/items/{id}&quot;) </li></ul></ul><ul><li>Methods : what are the HTTP methods ? </li></ul>@GET public XXX find() <ul><li>Representations : what are the formats ? </li></ul><ul><ul><li>@Consumes(&quot;application/xml&quot;)
    150. 153. @Produces(&quot;application/json&quot;) </li></ul></ul>
    151. 154. 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
    152. 155. Example RESTful Catalog
    153. 156. Glassfish and MySQL Part 4
    154. 158. RESTful Catalog <ul><ul><ul><li>Dojo client, JAX-RS, JAXB, JPA </li></ul></ul></ul>DB Registration Application JAX-RS class Dojo client JAXB class Entity Class ItemsConverter Item ItemsResource
    155. 159. URIs and Methods: <ul><li>/items </li></ul><ul><ul><li>GET - list all items
    156. 160. POST – add item to catalog </li></ul><li>/items/{id} </li></ul><ul><ul><li>GET - get an item representation
    157. 161. PUT - update an item
    158. 162. DELETE – remove an item </li></ul></ul>Item Catalog Example http://www.infoq.com/articles/rest-introduction
    159. 163. Resource Classes <ul><ul><li>Items Resource retrieves updates a collection of Item entities
    160. 164. /items – URI for a list of Items
    161. 165. Item resource retrieves or updates one Item entity
    162. 166. /item/1 – URI for item 1 </li></ul></ul>DB JAX-RS class Dojo client JAXB class Entity Class ItemsConverter Item ItemsResource
    163. 167. 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(...) { ... } }
    164. 168. 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
    165. 169. 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>
    166. 170. 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;} ] }
    167. 171. Ajax RESTful Catalog client
    168. 172. 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
    169. 173. JavaFX RESTful Catalog client
    170. 174. 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
    171. 175. Demo <ul><li>Create RESTful Web Services from Entity Classes
    172. 176. Test RESTful Web Servics </li></ul>
    173. 177. Why SOAP? <ul><li>Web Service WSDL already defined
    174. 178. Existing tools, infrastructure, know-how
    175. 179. Advanced security, reliability requirements </li></ul>
    176. 180. Why REST ? <ul><li>Simplicity
    177. 181. Takes advantage of HTTP: </li><ul><li>Scalability: stateless, caching </li></ul><li>Ajax , HTTP clients </li></ul>
    178. 182. Summary <ul><li>Metro with GlassFish Application Server: </li><ul><li>JAX-WS </li><ul><li>easy to use </li></ul><li>WSIT </li><ul><li>Makes Metro interoperable with other WS-* stacks
    179. 183. No new APIs , easy with NetBeans plugin </li></ul></ul><li>JAX-RS </li><ul><li>easy declarative programming model for REST </li></ul></ul>
    180. 184. For More Information <ul><li>METRO </li><ul><li>http://metro.dev.java.net </li></ul><li>REST </li><ul><li>http://jersey.dev.java.net </li></ul><li>Glassfish </li><ul><li>http://glassfish.dev.java.net </li></ul></ul><ul><li>Carol's Blog </li><ul><li>http://weblogs.java.net/blog/caroljmcdonald/ </li></ul><li>http://www.javapassion.com/webservices/index.html </li></ul>

    ×