Java one2010 presentation-s313909


Published on

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • The functional requirements call for a service that can compute the sub-total of an order for some books. The sub-totalling should be broken-down by line item and business should be in place for determining things like discounts (such as free shipping).
  • We also have some non-functional requirements as well. The business rules should be maintainable by tech-savvy business analysts.The service should be designed in such a way that it is componentized
  • There’s a distinction between the service itself, and the service endpoint. Our service is designed such that multiple endpoints can expose the service, yet, there is still only 1 service implementation “behind” the endpoints. This is something that WSDL supports. A single port type (a grouping of operations) can have multiple bindings. Each binding can then have multiple permutations.We’re going to see how JAX-WS makes it pretty simple to implement these ideas…
  • In furtherance of this, we divide our WSDL into 2 partitions – the first partition contains the logical definitions: types, messages, port types. The 2nd partition defines the concrete portion of the WSDL – the bindings and services. With this structure, we have a separate concrete WSDL file for each type of endpoint we want to support.
  • high level Java-centric abstraction that hides the details of converting between Javaobjects and their XML representations for use in XML-based messages
  • Remember we were talking about the separation of logical service definition and concrete bindings. This pictorial attempts to show the relationship between a Provider-annotated Java class and a concrete WSDL definition. The reality of how the Provider annotation works presents a challenge to us in remaining DRY. Regardless of endpoint, we want to process messages in a uniform way. To accomplish this, we’ll create an abstract ‘endpoint service support’ class that each concrete Provider-annotated class can extend from.
  • This allows us to place our common processing-logic into a single class, and, each concrete provider class will just inherit the functionality.
  • Thus, our concrete Provider-annotated service class only really exists to:(+) inherit from our endpoint support classess and(+) to contain the Provider annotation tying it to the associated concrete WSDL definitionNotice the class itself is empty…
  • So we’ve talked about how to “break-up” the WSDL into “the logical” and “the concrete”, however we haven’t touched upon yet the content of the WSDL; the *design* of our web service from the perspective of its contract.
  • So we’ve talked about how to “break-up” the WSDL into “the logical” and “the concrete”, however we haven’t touched upon yet the content of the WSDL; the *design* of our web service from the perspective of its contract.
  • And so here’s the wire format
  • Again, we just want to stress the notion that there is a pretty tight relationship between our POJO domain model and our canonicals. It’s important to point out that the canonicals only partially help inform the design of the domain model. It is OO principals and the requirements that ultimately drive the design of the domain model. Similarly, it is good hierarchical data-modeling that informs the design and creation of the canonicals. It is the job of the marshaller model to translate XML instances of the canonicals to and from objects from our domain model. The last thing to restate is, we’re not tied to a web service or web or another other sort of computing-context.
  • Although our implementation is quite naïve, we’re remaining true to our axiom that we should be designing to interfaces, and not technologies. Today our marshaller interface is implemented using JAXB, tomorrow, could be something different…Our design is “future proof” to the extent that our interface is robust.
  • Notables: eclipse plug-in
  • So as you can see here JSR-94 is a pretty verbose API, and obviously we want to provide a more convenient API for clients to work with. What’s not shown here is resource cleanup-code surrounded by try/catch/finally, so in reality, the code would even be more cluttered in this in a real system.
  • So instead of working with JSR-94 directly, clients can use this interface. We’ll have a JSR-94-based implementation that just default to creating a stateless rule session with the rule service.
  • One method per rule execution set – potential strategy for designing RAOs
  • As per usual we create a generalized interface that is tied to the domain of A REGISTRY, and not JAXR.
  • Just trying to show here that like JDBC, JSR-94, etc, JAXR is a relatively verbose API, and thus we have our interface in front of it for clients to interact with.
  • DSR takes 1st 3 bullets; Paul takes last 2 bullets
  • Display this slide during the Q and A
  • ×