Java one2010 presentation-s313909
Upcoming SlideShare
Loading in...5

Java one2010 presentation-s313909






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • 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

Java one2010 presentation-s313909 Java one2010 presentation-s313909 Presentation Transcript