Interoperable Web Services with JAX-WS and WSIT
•Download as ODP, PDF•
14 likes•6,869 views
Interoperable SOAP Web Services, REST
![About the Speaker ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (8)
Similar to Interoperable Web Services with JAX-WS and WSIT
Similar to Interoperable Web Services with JAX-WS and WSIT (20)
More from Carol McDonald
More from Carol McDonald (20)
Recently uploaded
Recently uploaded (20)
Interoperable Web Services with JAX-WS and WSIT
- 1. WSIT Carol McDonald, Java Architect
- 4. Pharmaceutical Intranet apps ( Roche Switzerland)
- 5. Telecom Network Mgmt ( Digital France)
- 6. X.400 Email Server ( IBM Germany)
- 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
- 11. Add @ annotation to Plain Old Java Object (POJO)
- 12. SOAP 1.2 (document/literal)
- 13. Uses JAXB for data binding
- 14. Part of Java SE 6 and Java EE 5 platforms
- 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
- 17. WSDL/Schema generated at deploy time automatically
- 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. Service Description default mapping Java mapping -> WSDL: public class Catalog { public List getItems ( int i , int j ){ } } < portType name=" Catalog "> < operation name=" getItems "> < input message=" tns:getItems " /> < output message=" tns:getItemsesponse " /> < /operation > < /portType > PORT TYPE = ABSTRACT INTERFACE OPERATION = METHOD MESSAGE = PARAMETERS AND RETURN VALUES
- 20. Server Side Web Service E ndpoint Listener Soap binding @Web Service Soap request publish 1 2
- 21. SOAP Request <?xml version="1.0" encoding="UTF-8"?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Header/> <S:Body> <ns2: getItemCount xmlns:ns2="http://service/"/> </S:Body> </S:Envelope> http://localhost:8080/CatalogService/CatalogService
- 22. SOAP Response <?xml version="1.0" encoding="UTF-8"?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Body> <ns2: getItemCountResponse xmlns:ns2="http://service/"> <return>29</return> </ns2:getItemCountResponse> </S:Body> </S:Envelope>
- 23. Glassfish and MySQL Part 3 DEMO
- 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. Client-Side Programming wsimport tool @WebService Dynamic Proxy Service contract WSDL Generates You develop Client which uses proxy to call Web Service
- 26. Web Service Client public class ItemController { @WebServiceRef(wsdlLocation= "http://host/Catalog/Service?wsdl") 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. 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. 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. Glassfish and MySQL Part 3 DEMO
- 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
- 32. JAX-WS Standards
- 33. WSIT
- 34. REST
- 36. Implementation of WS-* specifications
- 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
- 43. Metro WSIT Reliable Messaging
- 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
- 48. Recover from lost/misordered messages
- 50. At most once
- 51. In order End-to-End Reliability
- 53. <?xml version="1.0" encoding="UTF-8"?> <definitions xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://mypackage/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://mypackage/" name="HelloService"> <wsp:UsingPolicy></wsp:UsingPolicy> <wsp:Policy wsu:Id="HelloPortBindingPolicy"> <wsp:ExactlyOne> <wsp:All> <ns1:RMAssertion xmlns:ns1="http://schemas.xmlsoap.org/ws/2005/02/rm/policy"></ns1:RMAssertion> <ns2:Ordered xmlns:ns2="http://sun.com/2006/03/rm"></ns2:Ordered> <ns3:UsingAddressing xmlns:ns3="http://www.w3.org/2006/05/addressing/wsdl"></ns3:UsingAddressing> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> <!-- omitted --> WSDL with Reliable Messaging
- 54. <?xml version="1.0" encoding="UTF-8"?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S :Header> <To xmlns="http://www.w3.org/2005/08/addressing">http://localhost:8080/HelloWebServiceReliable/HelloService</To> <Action xmlns="http://www.w3.org/2005/08/addressing">http://mypackage/Hello/sayHelloRequest</Action> < ReplyTo xmlns="http://www.w3.org/2005/08/addressing"> <Address>http://www.w3.org/2005/08/addressing/anonymous</Address> </ReplyTo> < MessageID xmlns="http://www.w3.org/2005/08/addressing">uuid:6bf70fdf-5b7d-4dce-874a-0ab56abc9819</MessageID> <ns2: Sequence xmlns:ns2="http://schemas.xmlsoap.org/ws/2005/02/rm" xmlns:ns3="http://schemas.microsoft.com/ws/2006/05/rm" xmlns:ns4="http://www.w3.org/2005/08/addressing"> <ns2: Identifier >uuid:b8a4fd6e-1992-4a5f-8972-3b3f2c86b1a8</ns2:Identifier> <ns2: MessageNumber >1</ns2:MessageNumber> </ns2:Sequence> <ns2: AckRequested xmlns:ns2="http://schemas.xmlsoap.org/ws/2005/02/rm" xmlns:ns3="http://schemas.microsoft.com/ws/2006/05/rm" xmlns:ns4="http://www.w3.org/2005/08/addressing"> <ns2:Identifier>uuid:b8a4fd6e-1992-4a5f-8972-3b3f2c86b1a8</ns2:Identifier> </ns2:AckRequested> </S:Header> <S:Body> <ns2:sayHello xmlns:ns2="http://mypackage/"> <arg0>SangShin</arg0> <arg1>22</arg1> </ns2:sayHello> </S:Body> </S:Envelope> SOAP Request with R.M.
- 55. <?xml version="1.0" encoding="UTF-8"?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Header> <To xmlns="http://www.w3.org/2005/08/addressing">http://www.w3.org/2005/08/addressing/anonymous</To> <Action xmlns="http://www.w3.org/2005/08/addressing">http://mypackage/Hello/sayHelloResponse</Action> < MessageID xmlns="http://www.w3.org/2005/08/addressing">uuid:46bb95a0-1ea0-47b7-b417-e19cbf652db8</MessageID> < RelatesTo xmlns="http://www.w3.org/2005/08/addressing">uuid:6bf70fdf-5b7d-4dce-874a-0ab56abc9819</RelatesTo> </S:Header> <S:Body> <ns2:sayHelloResponse xmlns:ns2="http://mypackage/"> <return>Hello SangShin!My age is 22</return> </ns2:sayHelloResponse> </S:Body> </S:Envelope> SOAP Response Message with R.M.
- 57. Metro WSIT Security
- 59. Issued and signed by Certifying Authority
- 64. Bind the sender’s identity to an XML document Private Encryption XML data Signature Public Decryption XML data Receiver
- 67. Security at transport layer
- 68. Encrypts session
- 71. SAML
- 72. Kerberos tickets SOAP Envelope SOAP Envelope Header SOAP Envelope Body WS-Security Header Security Token Business Payload
- 75. Only sign/encrypt part of msg
- 77. Security at transport layer
- 78. All or nothing granularity
- 79. Point-to-point
- 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
- 81. WS-Security <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <SOAP-ENV:Header> <wsse:Security SOAP-ENV:mustUnderstand="true" xmlns:wsse="http://docs.oasis-open.org/...-wss-wssecurity-secext-1.0.xsd"> <ds: Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds: SignedInfo > <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm ="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/> <ds:Reference URI=" #id-1281123 "> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds: DigestMethod Algorithm ="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>wLumPkKZ+X48rjao/XUUQDp0xk0=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds: SignatureValue >a56OxPcKr8LJnIFgRyMQej5/ZkUjkV9V9rmn+queMKzJ3GYpMiXpjQ==</ds:SignatureValue> <ds: KeyInfo Id="KeyId-30752603"> <wsse: SecurityTokenReference wsu:Id="STRId-2545159" xmlns:wsu="http://docs.-wss-wssecurity-utility-1.0.xsd"> <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=" id-1281123 " xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <sayHello xmlns="http://jeffhanson.com/services/helloworld"> <value xmlns="">Hello world!</value> </sayHello> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
- 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
- 84. Establish and broker trust relationships WS-Trust
- 86. Options: Username/Password,X.509, (& SAML) SSO
- 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)
- 90. Establish and broker trust relationships Trust .NET service Java client
- 92. Establish and broker trust relationships
- 93. Identity Services through OpenSSO
- 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
- 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
- 99. Message Authentication over SSL
- 100. SAML Authorization over SSL
- 102. SAML Sender Vouches with Certificates
- 103. SAML Holder of Key
- 104. STS Issued Token
- 105. STS Issued Token with Service Certificate
- 106. STS Issued Endorsing Token
- 108. Create shared symmetric session key
- 109. Optimizes processing WS-SecureConversation Optimized Security security context token Use generated symmetric session key
- 111. Metro WSIT Transactions
- 114. Mapping between Java EE transaction attributes and WS-AT policy statements
- 115. Control flow
- 118. Java™ Transaction Service Application Server Transaction Service Application UserTransaction interface Resource Manager XAResource interface Transactional operation TransactionManager Interface Resource EJB Transaction context
- 119. WS-Coordination and WS-AtomicTransaction Protocols in Two GlassFish Domains WS-Coordination : Wire protocol for distributed coordinated activity Participant registration
- 120. WS-Coordination and WS-AtomicTransaction Protocols in Two GlassFish Domains WS-Atomic Transaction : Coordinated two phase commit for web service operations
- 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
- 123. Transacted Web Service: Option 2 <wsdl:definitions> <!-- Define WS-AT policy assertion --> <wsp:Policy wsu:Id=" TransactedPolicy1 " > < wsat:ATAssertion wsp:Optional="true” /> <wsat:ATAlwaysCapability/> </wsp:Policy> <wsdl:binding name="Bank" type="tns:BankPortType" > <!-- Marked Transacted by Operation Policy Subject--> <wsdl:operation name=" transferFunds " > <wsp:PolicyReference URI="#TransactedPolicy1" wsdl:required="true" /> ... </wsdl:operation> </wsdl:binding> </wsdl:definitions>
- 125. <?xml version="1.0" encoding="UTF-8"?> <definitions xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://mypackage/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://mypackage/" name="HelloService"> <wsp:UsingPolicy></wsp:UsingPolicy> <wsp:Policy wsu:Id="HelloPortBinding_sayHello_Policy"> <wsp:ExactlyOne> <wsp:All> <ns1: ATAlwaysCapability xmlns:ns1="http://schemas.xmlsoap.org/ws/2004/10/wsat"></ns1:ATAlwaysCapability> <ns2: ATAssertion xmlns:ns2="http://schemas.xmlsoap.org/ws/2004/10/wsat" wsp:Optional="true"></ns2:ATAssertion> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> WSDL with Transaction
- 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
- 128. WSIT creates Transaction Context when ws invoked @Resource javax.transaction.UserTransaction ut; ut.begin(); bankWebService.makeWithdrawl(); ... ut.commit();. Transaction Context created Web Service Client
- 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
- 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
- 131. Metro: Bootstrapping
- 133. metadata exchange is handled by wsimport utility of WSIT
- 134. transparent to developers < wsdl …> < policy …> … </policy> … </wsdl> WSDL
- 135. WS-Policy <wsdl…> <policy…> … </policy> … </wsdl> <wsdl…> <policy…> <security-policy> … </security-policy> <transaction-policy> … </transaction-policy> <reliability-policy> … </reliability-policy> … </policy> … </wsdl>
- 136. Proxy Generation Bootstrapping Communication <wsdl…> <policy…> < security-policy > … </security-policy> < transaction-policy > … </transaction-policy> < reliability-policy > … </reliability-policy> … </policy> … </wsdl>
- 137. End-to-End Messaging
- 139. Config file produced by NetBeans enable/control WSIT
- 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
- 144. works with message security and transport security
- 147. JAX-WS Standards
- 148. WSIT
- 149. REST with JAX-RS
- 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="1.0"?> <items xmlns="…"> <item>…</item> … </items> Method Resource Representation State transfer
- 154. POJO @Path("/items/") public class ItemsResource { @Produces("application/json") @GET public ItemsConverter get() { ... } ... } responds to the URI http://host/catalog/items/ responds with JSON responds to HTTP GET
- 156. Glassfish and MySQL Part 4
- 161. PUT - update an item
- 162. DELETE – remove an item Item Catalog Example http://www.infoq.com/articles/rest-introduction
- 164. /items – URI for a list of Items
- 165. Item resource retrieves or updates one Item entity
- 166. /item/1 – URI for item 1 DB JAX-RS class Dojo client JAXB class Entity Class ItemsConverter Item ItemsResource
- 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(...) { ... } }
- 168. Get Items @Path("/items/") public class ItemsResource { @Context protected UriInfo uriInfo; @GET @Produces ("application/json") 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
- 169. XML <?xml version="1.0" encoding="UTF-8"?> <items uri="http://localhost/Web/resources/items/"> <item uri="http://localhost/Web/resources/items/1/" > <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>
- 170. JSON { "@uri":"http://host/catalog/resources/items/", " item ":[ {"@uri":"http://host/catalog/resources/items/1/", "name":"Friendly Cat", "description":"This black and white colored cat is super friendly.", "id":"1", "imageurl":"http://localhost:8080/CatalogService/images/anthony.jpg"}, {"@uri":"http://host/catalog/resources/items/2/", "name":"Fluffy Cat", "description":"A great pet for a hair stylist! "id":"2", "imageurl":"http://localhost:8080/CatalogService/images/bailey.jpg"} ] }
- 171. Ajax RESTful Catalog client
- 172. RESTful Pet Catalog Web Service http://petstore/catalog/resources/items/ HTTP GET Response JSON items {"url":"http://store/catalog/item1", {"url":"http://store/catalog/item2"} Server Client Addressable Resources Web Container
- 173. JavaFX RESTful Catalog client
- 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
- 176. Test RESTful Web Servics
- 178. Existing tools, infrastructure, know-how
- 179. Advanced security, reliability requirements
Editor's Notes
- 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 &quot;pay as you go&quot; 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 &quot;pay as you go&quot; 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 &quot;live&quot; 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.