Java one2010 presentation-s313909
Report
Blue Slate SolutionsFollow
Sep. 29, 2010•0 likes•648 views
2 likes
Be the first to like this
Show More
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Check these out next
Java one2010 presentation-s313909
Sep. 29, 2010•0 likes•648 views
2 likes
Be the first to like this
Show More
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Download to read offline
Report
Blue Slate SolutionsFollow
Recommended
SOA (hands-on exercise w.r.t Oracle included)santosh_c_s
Service Oriented Architecture Design PatternShanto Rahman
Soa design patternLap Doan
Basf roadmap-2-global-st852ChrisVdJ
Migrating SOACoi Xay
Building Service Oriented Architecture based applicationsRamco Institute of Technology, Rajapalayam, Tamilnadu, India
Java one2010 presentation-s313909
- Following a contract-first approach
- Connectors to provide access to web services, rule engine, and service registry
- Usage of service registry insulates consumers from service endpoint locations
- Java domain model created by hand (is not auto-generated by JAXB compiler from canonical XSDs)
- Regardless of endpoint used, the exact same downstream-components are used to handle requests
- A service can expose multiple endpoints; some examples:
- HTTP binding, verb=GET, input=URL encoded, output=MIME
- HTTP binding, verb=GET, input=URL replacement, output=MIME
- HTTP binding, verb=POST, input=MIME, output=MIME
- SOAP binding, transport=(HTTP | JMS | SMTP), input=soap:body, output=soap:body
- Messages
- Messages
- Formulated using XML Schema (XSD)
- 2 types of elements:
- Entity - canonical definitions of business entities (nouns)
- Command - canonical definitions of operations which act upon entities (verbs)
- Exist on their own and are context-independent
- XML instances of entity canonical un-marshal into Java POJOs
- XML instances of command canonical un-marshal into command objects (based-on GoF command design pattern)
- Related to "Canonical Data Model" EI pattern
- Hand-authored; not created by a tool
- Influenced by associated entity and command canonical definitions
- Entities modeled as simple POJOs
- Commands modeled as command objects - conforming to the GoF command design pattern
- Responsible for marshaling POJOs into associated XML instances (conformant to a specific version of entity canonical)
- Publishes Java interface; multiple implementations can be created
- Default implementation will be based on JAXB
- Rete-based forward chaining environment
- Unambiguous, authoritative system of record of business rules
- Interprets business data
- Business rules encoded using a grammar that is closer to the business domain (closer than what a traditional 3GL could achieve)
- Provides JSR-94 adapter
- 2006: JBoss acquired by RedHat - rewrite / enhanced implementation funded
- 2007: Renamed back to Drools
- Unambiguous, authoritative system of record of web service endpoint locations
- Provides JAXR adapter
Editor's Notes
- 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