Successfully reported this slideshow.

More Related Content

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Java one2010 presentation-s313909

  1. 1. Building a JAX-WS Web Service with JBoss Drools and Apache jUDDI Integration<br />JavaOne 2010<br />Session: S313909<br />Monday, September 20, 2010<br />
  2. 2. About Your Speakers   <br />Dave Read<br />CTO<br />CISSP, RHCE, SCJP<br />David.Read@blueslate.net<br />Paul Evans<br />Chief Architect<br />SCJD, SCWCD<br />Paul.Evans@blueslate.net<br />1<br />Smart Approach. Extraordinary Results.<br />www.blueslate.net<br />
  3. 3. Why Are We Here?<br />To walk through the architecture and design of a Java-based web service service based on a set requirements<br />JAX-WS, JAXB, JAXR, JSR94,…<br />To demonstrate how the architecture of a complex web service flows from object-oriented principals<br />2<br />
  4. 4. Agenda<br />The Requirements<br />Architecture of Proposed Solution<br />Major Components<br />Demo<br />Summary<br />Q/A <br />3<br />
  5. 5. Agenda<br />The Requirements<br />Architecture of Proposed Solution<br />Major Components<br />Demo<br />Summary<br />Q/A <br />4<br />
  6. 6. Functional Requirements<br />FR.1: Require the ability to calculate the sub-total price of a book order (in support of the to-be developed book order web portal)<br />FR.2: Require the order sub-total to be broken-down by line item - the order sub-total is simply the summation of the line item sub-totals<br />FR.3: The sub-total of each line item is calculated by multiplying the price of the book with the quantity, then factoring-in sales tax and factoring-in shipping costs<br />FR.4: Discounts may be applied to the order sub-total based on the customer's loyalty level (other rules may be crafted in the future that will impact the sub-total calculation)<br />5<br />
  7. 7. Non-functional Requirements<br />NFR.1: The rules governing the calculation of the sub-total should be maintainable by business analysts<br />New rules can be added, existing rules to be modifiable without involving the application development team<br />NFR.2: The order total processing system should be componentized and not tied to a web service context<br />NFR.4: The sub-total processing system should be easy and convenient for consumers to utilize<br />NFR.7: The rule engine will be limited to the execution of business rules - it should not be used for “mechanical” type purposes<br />6<br />
  8. 8. Agenda<br />The Requirements<br />Architecture of Proposed Solution<br />Major Components<br />Demo<br />Summary<br />Q/A <br />7<br />
  9. 9. Architecture of Proposed Solution (logical)<br />8<br />Service<br />Registry<br />Consumer<br />Order Total Service<br />Order Total Service<br />Client<br />BRE<br />Connector<br />Service<br />Registry<br />Connector<br />EP<br />Bind<br />EP<br />Bind<br />EP<br />Bind<br />Business Rule Engine (BRE)<br />Rule Definitions<br />
  10. 10. Notables Missing from Logical Architecture<br />Enterprise Service Bus<br />Complex piece of system software<br />Omitted for brevity<br />Logging service<br />Logging service to be used enterprise-wide <br />A logging service would operate asynchronously for snappy performance <br />Regardless of the number of tiers or clustering, log messages would be recorded by the logging service to a single system for ease of auditing and monitoring<br />Security service<br />Handles authentication and authorization requests<br />Queried to ascertain encryption and integrity requirements of a service <br />9<br />
  11. 11. Reconcile Requirements with Logical Architecture (1/4)<br />FR.1, FR.4: The service implementation will handle the mechanics of totaling the individual line items and other costs to produce the order total. This includes adding shipping cost, adding total tax and applying discounts produced by the BRE.<br />FR.1, FR.2,FR.4: The rule engine houses and executes the core business rules in support of calculating the order total. The BRE houses rules associated with the calculation of sales tax, discounts, shipping cost, etc. (it is the service implementation that is responsible for performing the raw mathematics to calculate the total)<br />Order Total Service<br />Business Rule Engine (BRE)<br />Rule Definitions<br />10<br />
  12. 12. Quick Note on Rules and Rule Engines (1/2)<br />11<br />What?<br />Execution environment for business rules<br />Storage / housing of business rules<br />Environment for authoring and maintaining business rules<br />Usually leverages Rete algorithm for rule execution<br />Think of as just another component within the architecture – <br />RDBMS component = data persistence<br />LDAP component = identity management (authentication / authorization)<br />Mainframe component = legacy transaction processing<br />BRE component = execution of business rules<br />Workflow engine component = codification of workflow<br />… = …<br />
  13. 13. Quick Note on Rules and Rule Engines (2/2)<br />12<br />Why?<br />Interprets business data<br />data sitting in a relational database in and of itself is meaningless – SOMETHING needs to give the data MEANING<br />business rules provide meaning to data<br />Codification of business rules in a format that is closer to the business domain<br />Rules codified in low-level programming languages (e.g. 3GLs such as Java, C++, etc) are expensive to maintain and difficult/impossible for business users to validate<br />BREs typically provide an environment to codify rules using a grammar that is more natural to technical-savvy business users<br />Other reasons<br />Easier to audit<br />Expose as a service to enable other systems the ability to leverage common rule base<br />…<br />
  14. 14. Reconcile Requirements with Logical Architecture (2/4)<br />13<br />NFR.2: Providing a connector to the BRE simplifies integration – the connector increases the accessibility of the BRE to other consumers. Multiple connectors can be created to support a diverse ecosystem of heterogeneous potential consumers.<br />BRE<br />Connector<br />NFR.1: BREs allow rules to be codified using a language close to the business domain<br />NFR.1: BREs typically provide a GUI to allow non-programmers the ability to manage rules<br />Business Rule Engine (BRE)<br />Rule Definitions<br />
  15. 15. Reconcile Requirements with Logical Architecture (3/4)<br />14<br />Using a service registry provides a level of indirection that enables services to be loosely coupled from consumers from the dimension of location.<br />Service<br />Registry<br />NFR.4: The service registry connector is used to connect to a service registry and discover the physical endpoint of some target service. <br />Order Total Service<br />Client<br />Service<br />Registry<br />Connector<br />
  16. 16. Quick Note on Registries<br />15<br />Publication of web services<br />Discovery and lookup of data formats, messages, business processes, services<br />ebXML<br />Started by OASIS and United Nations (UN/CEFACT) in 1999<br />Repository of data formats, process definitions, messages across industries<br />Enable global world to participate in electronic commerce (including developing nations)<br />UDDI<br />Sponsored by OASIS – 2000/2001 <br />Enables business to publish and lookup service listings<br />Peculiar to web services<br />
  17. 17. Reconcile Requirements with Logical Architecture (4/4)<br />16<br />NFR.4: The service client shields the consumer from the details and mechanics of invoking the web service.<br />Consumer<br />Order Total Service<br />Client<br />Service<br />Registry<br />Connector<br />Bind<br />Bind<br />Bind<br />
  18. 18. Web Service – Summary of Major Design Decisions (1/2)<br />17<br /><ul><li>Design to interfaces, not technologies
  19. 19. Following a contract-first approach
  20. 20. Connectors to provide access to web services, rule engine, and service registry
  21. 21. Usage of service registry insulates consumers from service endpoint locations
  22. 22. Usage of rules engine externalizes business rules from low-level Java code</li></li></ul><li>Web Service – Summary of Major Design Decisions (2/2)<br />18<br /><ul><li>Types are externalized from WSDL - command and entity canonical definitions (XSD) stand alone
  23. 23. Java domain model created by hand (is not auto-generated by JAXB compiler from canonical XSDs)
  24. 24. Marshaler/Un-marshaler component translates between canonical definitions and domain model (uses JAXB as default implementation)</li></li></ul><li>Quick Note on Canonicals<br />Authoritative format definitions for entities and commands (aka operations)<br />AKA: Canonical Data Model design pattern from Enterprise Integration Patterns text<br />Ties into an organization’s data dictionary<br />Context agnostic; potential uses:<br />Format definition of message (when using a messaging system)<br />Format definition of WSDL messages<br />19<br />
  25. 25. Physical Architecture of ProcessSubTotal Web Service<br />20<br />ProcessTotal Web Service<br />JAX-WS Runtime<br />(+) Dispatcher Servlet<br />Book Order / ProcessTotal<br />SEI Implementation<br />@WebServiceProvider annotation<br />Book Order / ProcessTotal<br />WSDL <br />Book Order Marshaler / <br />Un-marshalerComponent (JAXB)<br />Book Order<br />Commands canonical (XSD)<br />Context Neutral<br />Order Rule Access Object (RAO)Component<br />Book Order<br />Entities canonical (XSD)<br />Rule Engine ConnectorComponent (JSR-94)<br />Book Order CommandsComponent<br />Context Neutral<br />Context Neutral<br />Context Neutral<br />Context Neutral<br />Book Order Domain ModelComponent (POJOs)<br />Business Rule Engine<br />JBoss Rules (Drools)<br />Context Neutral<br />
  26. 26. Physical Architecture of Client Application<br />JAX-WS Runtime<br />(+) Dispatcher Servlet<br />ProcessTotalWeb Service<br />ProcessTotal SEI Implementation<br />@WebServiceProvider annotation<br />Book Order - ProcessTotal<br />WSDL <br />ProcessTotalService Component (Java SE)<br />Book Order Marshaler / <br />Un-marshalerComponent (JAXB)<br />Book Order<br />Commands canonical (XSD)<br />SOAP/HTTP<br />CONTEXT NEUTRAL<br />CONTEXT NEUTRAL<br />Rule Engine ConnectorComponent (JSR-94)<br />Book Order<br />Entities canonical (XSD)<br />Book Order Domain ModelComponent (POJOs)<br />CONTEXT NEUTRAL<br />CONTEXT NEUTRAL<br />CONTEXT NEUTRAL<br />Business Rule Engine<br />JBoss Rules (Drools)<br />Client Application<br />Service Registry Connector (JAXR)<br />ProcessTotal Service Client<br />Component<br />Context Neutral<br />JAX-WS Dispatch mechanism<br />UDDI Registry<br />Apache jUDDI<br />Book Order Marshaler / <br />Un-marshalerComponent (JAXB)<br />Book Order CommandsComponent<br />Context Neutral<br />Context Neutral<br />Service Registry<br />(returns endpoint URL of ProcessTotal service)<br />Book Order<br />Commands canonical (XSD)<br />Book Order Domain ModelComponent (POJOs)<br />Book Order<br />Entities canonical (XSD)<br />Book Order Domain ModelComponent (POJOs)<br />Context Neutral<br />Context Neutral<br />21<br />Context Neutral<br />21<br />
  27. 27. High-level Sequence (component view)<br />22<br />
  28. 28. 1 Service, Many Channels (and staying DRY)<br />23<br /><ul><li>The ProcessOrderTotal service may publish multiple endpoints (as are needed - driven by the requirements)
  29. 29. Regardless of endpoint used, the exact same downstream-components are used to handle requests
  30. 30. A service can expose multiple endpoints; some examples:
  31. 31. HTTP binding, verb=GET, input=URL encoded, output=MIME
  32. 32. HTTP binding, verb=GET, input=URL replacement, output=MIME
  33. 33. HTTP binding, verb=POST, input=MIME, output=MIME
  34. 34. SOAP binding, transport=(HTTP | JMS | SMTP), input=soap:body, output=soap:body
  35. 35. SOAP binding, transport=(HTTP | JMS | SMTP), input=MIME, output=MIME </li></ul>Order Total Service<br />Order Total Service<br />Client<br />EP<br />Bind<br />EP<br />Bind<br />EP<br />Bind<br />
  36. 36. Organizing WSDL Descriptors (concrete WSDLs implement abstract service definition)<br />Each concrete WSDL provides <binding> and <service> elements<br />Each concrete WSDL uses <wsdl:import> to reference abstract service definition<br />Abstract Service Definition:<br /><ul><li> Types
  37. 37. Messages
  38. 38. Port Types</li></ul><wsdl:import><br />Concrete Definition [SOAP/HTTP]<br /><ul><li> Bindings
  39. 39. Services</li></ul>Concrete Definition [HTTP GET]<br /><ul><li> Bindings
  40. 40. Services</li></ul>Concrete Definition [HTTP POST]<br /><ul><li> Bindings
  41. 41. Services</li></ul>Concrete Definition [SOAP, using MIME / JMS]<br /><ul><li> Bindings
  42. 42. Services</li></ul>Concrete Definition<br />[. . .]<br /><ul><li> Bindings
  43. 43. Services</li></ul>24<br />
  44. 44. Abstract Definitions<br />25<br /><types><br /><import><br /><message><br /><portType><br />
  45. 45. Concrete Definitions<br />26<br /><import><br /><binding><br /><service><br />
  46. 46. JAX-WS (Java API for XML Web Services)<br />Evolution from JAX-RPC<br />Supports the development of both bottom-up and top-down (contract first) services<br />Data binding is delegated to JAXB<br />Provides WSDL / Java mapping<br />Makes extensive use of annotations<br />Provides service-side and client-side APIs<br />Handler framework <br />27<br />
  47. 47. JAX-WS Service Endpoint Implementation (SEI)<br />Java class to process requests to web service endpoint<br />Must carry javax.jws.WebService annotation<br />Maps to a wsdl:portType container element<br />Methods of this class may carry javax.jws.WebMethod annotation<br />JAX-WS runtime will leverage JAXB to handle un-marshalling and marshalling of inbound request and response<br />Very simple!<br />28<br />
  48. 48. However…we need more control<br />We have requirements that stipulate the components we build should be reusable; and be reusable outside the context of web service<br />29<br />Context usage scenarios<br />Web Services<br />Messaging<br />EJB<br />EDI<br />…<br />XML message<br />Canonical XSDs<br />Context neutral ecosystem<br />Marshaller / Un-marshaller<br />POJO domain model<br />Commands<br />
  49. 49. JAX-WS Provider API<br />javax.xml.ws.Provider is a lower-level generic API for processing requests to web service endpoint<br />@WebServiceProvider annotation<br />Enables the endpoint class to work directly with message payloads<br />Allows us to use our own marshalling/un-marshalling component<br />30<br />
  50. 50. Each concrete Provider-based endpoint references concrete WSDL <br />Abstract Service Definition:<br /><ul><li> Types
  51. 51. Messages
  52. 52. Port Types</li></ul>Concrete Definition [SOAP/HTTP]<br /><ul><li> Bindings
  53. 53. Services</li></ul>Concrete Definition [HTTP GET]<br /><ul><li> Bindings
  54. 54. Services</li></ul>Concrete Definition [HTTP POST]<br /><ul><li> Bindings
  55. 55. Services</li></ul>Concrete Definition [SOAP, using MIME / JMS]<br /><ul><li> Bindings
  56. 56. Services</li></ul>Concrete Definition<br />[. . .]<br /><ul><li> Bindings
  57. 57. Services</li></ul><wsdl:import><br />wsdlLocation<br />Provider-based Endpoint<br />Provider-based Endpoint<br />Provider-based Endpoint<br />Provider-based Endpoint<br />Provider-based Endpoint<br />@WebServiceProvider<br />@WebServiceProvider<br />@WebServiceProvider<br />@WebServiceProvider<br />@WebServiceProvider<br /><< Abstract >><br />Endpoint Support Class<br />Each Provider object to extend endpoint support base class<br />31<br />
  58. 58. Each concrete Provider-based endpoint to extend from common abstract “endpoint support” class<br />32<br /><< Interface >><br />javax.xml.ws.Provider<br /><< Abstract >><br />Endpoint Support Class<br /><ul><li> marshaler</li></ul>- processOrderTotalService<br />+ invoke (Source pSrc): Source<br />Provider-based Endpoint<br />Provider-based Endpoint<br />Provider-based Endpoint<br />Provider-based Endpoint<br />Provider-based Endpoint<br />@WebServiceProvider<br />@WebServiceProvider<br />@WebServiceProvider<br />@WebServiceProvider<br />@WebServiceProvider<br />
  59. 59. Concrete endpoints extend support class<br />33<br /><ul><li>Only exists to contain @WebServiceProvider annotation (with wsdlLocation attribute)</li></ul>public abstract class OrderServiceProviderSupport implements Provider<Source> {<br /> @Override<br /> public Source invoke(Source pRequest) {<br />// un-marshal request XML into command object...<br />OrderTotalCommandcmd = marshaler.unmarshal(pRequest);<br />// inject rule access object (RAO)...<br />cmd.setOrderRao(OrderRaoFactory.newOrderRao());<br />// execute the command…<br /> new CommandExecutor().executeCommand(cmd);<br />// return the marshaled order object...<br /> return marshaler.marshal(cmd.getOrder());<br /> }<br />} <br />@WebServiceProvider(wsdlLocation=/SOAP_HTTP-Service.wsdl)<br />public class OrderService extends OrderServiceProviderSupport {<br /> // no need to implement or override any methods...<br />} <br />
  60. 60. WSDL Design (1/3)<br />Leverage the document/literal “wrapped” convention<br />Semantically very similar to RPC/literal<br />Internal dispatching/processing of requests is simplified<br />Root element of message payload indicates the operation / command<br />Entire message payload can be schema validated<br />Not so with RPC/literal<br />Not without its disadvantages<br />Requires trickery within the WSDL<br />34<br />
  61. 61. WSDL Design (2/3)<br />35<br />
  62. 62. WSDL Design (3/3)<br />36<br />
  63. 63. Agenda<br />The Requirements<br />Architecture of Proposed Solution<br />Major Components<br />Demo<br />Summary<br />Q/A <br />37<br />
  64. 64. Component: Command and Entity Canonical Definitions<br />38<br /><ul><li>Unambiguous, authoritative definition of business entities and operations
  65. 65. Formulated using XML Schema (XSD)
  66. 66. 2 types of elements:
  67. 67. Entity - canonical definitions of business entities (nouns)
  68. 68. Command - canonical definitions of operations which act upon entities (verbs)
  69. 69. Exist on their own and are context-independent
  70. 70. XML instances of entity canonical un-marshal into Java POJOs
  71. 71. XML instances of command canonical un-marshal into command objects (based-on GoF command design pattern)
  72. 72. Related to "Canonical Data Model" EI pattern
  73. 73. Canonical definitions can be versioned (related to "Format Indicator" EI pattern)</li></li></ul><li>Entities Canonical (types)<br />39<br />
  74. 74. Commands Canonical<br />40<br />
  75. 75. Component: POJO Domain Model<br />41<br /><ul><li>Java-based object model representing both entities and commands
  76. 76. Hand-authored; not created by a tool
  77. 77. Influenced by associated entity and command canonical definitions
  78. 78. Entities modeled as simple POJOs
  79. 79. Commands modeled as command objects - conforming to the GoF command design pattern
  80. 80. Reusable</li></li></ul><li>Domain Model - UML Class Diagram<br />42<br />
  81. 81. Component: Marshaller/Un-marshaller (1/4)<br />43<br /><ul><li>Responsible for un-marshaling XML instances (conformant to a specific version of a canonical) into associated Java objects (from POJO data model and command model)
  82. 82. Responsible for marshaling POJOs into associated XML instances (conformant to a specific version of entity canonical)
  83. 83. Publishes Java interface; multiple implementations can be created
  84. 84. Default implementation will be based on JAXB
  85. 85. Also not tied to web service paradigm; this module is used anytime in which XML instances need to be translated back-and-forth between Java objects</li></li></ul><li>Component: Marshaller/Un-marshaller (2/4)<br />44<br />
  86. 86. Relationship between canonicals, marshaller, domain model (3/4)<br />45<br />Web Services<br />Messaging<br />EJB<br />EDI<br />…<br />XML message<br />Canonical XSDs<br />Marshaller / Un-marshaller<br />Commands<br />POJO domain model<br />
  87. 87. JAXB-based Implementation of Marshaller Interface<br />46<br />
  88. 88. Component: Business Rule Engine (BRE) (1/3)<br />47<br /><ul><li>JBoss rules (Drools)
  89. 89. Rete-based forward chaining environment
  90. 90. Unambiguous, authoritative system of record of business rules
  91. 91. Interprets business data
  92. 92. Business rules encoded using a grammar that is closer to the business domain (closer than what a traditional 3GL could achieve)
  93. 93. Provides JSR-94 adapter
  94. 94. Accessed using BRE connector component </li></li></ul><li>Component: Business Rule Engine (BRE) (2/3)<br />48<br /><ul><li>2005: Drools was incorporated into JBoss and rebranded as “JBoss Rules”
  95. 95. 2006: JBoss acquired by RedHat - rewrite / enhanced implementation funded
  96. 96. 2007: Renamed back to Drools
  97. 97. Drools is currently a suite of systems:</li></ul>Drools Expert – rule engine<br />Rule language<br />Domain specific languages<br />Rules and decision tables<br />ReteOO – enhanced version of Rete for OO systems<br />Drools Guvnor – business rule management system<br />Web-based<br />Rule authoring and storage<br />Rule management<br />Rule deployment<br />Drools Flow – process and workflow system<br />Others…<br />
  98. 98. Example Rule Definition<br />49<br />Rule Name<br />Effective Date<br />Condition (if)<br />Action (then)<br />
  99. 99. Component: Rule Engine Connector (1/4)<br />50<br /><ul><li>Like JDBC, JSR-94 API is verbose and cumbersome to work with directly
  100. 100. Connector component provides layer of abstraction</li></ul>Exposed as a Java interface<br />Convenient; easy to work with<br />Implementations can be changed/swapped-out without impacting callers; implementation options:<br />JSR-94<br />Vendor-specific API<br />other<br />
  101. 101. Component: Rule Engine Connector (2/4)<br />JSR-94 concepts:<br />Rule Engine<br />Environment to house and execute rules<br />Rule Session<br />Stateless or stateful<br />Associated with a single rule execution set<br />Rule Execution Set<br />Collection of rules<br />Rule<br />If/Then<br />Pluggable provider<br />51<br />
  102. 102. Component: Rule Engine Connector (3/4)<br />52<br />// load the provider class...<br />Class.forName("org.drools.jsr94.rules.RuleServiceProviderImpl“);<br />// obtain provider object...<br />RuleServiceProvider provider = RuleServiceProviderManager.getRuleServiceProvider(“http://drools.org”);<br />// create rule administrator object (needed to create execution set)...<br />RuleAdministrator ruleAdmin = provider.getRuleAdministrator();<br />// create local rule execution set provider...<br />LocalRuleExecutionSetProvider ruleExecSetProvider = ruleAdministrator.getLocalRuleExecutionSetProvider(null);<br />// create the rule execution set...<br />RuleExecutionSet executionSet = ruleExecSetProvider.createRuleExecutionSet(<br /> new InputStreamReader(new FileInputStream(“/BusinessRuleDefs.drl”)), null);<br />// register the rule execution set with the rule administrator...<br />ruleAdmin.registerRuleExecutionSet(executionSet.getName(), executionSet, null);<br />// get handle to rule runtime...<br />RuleRuntime ruleRuntime = provider.getRuleRuntime();<br />// create stateless rule session...<br />StatelessRuleSession session = ruleRuntime.createRuleSession(executionSet.getName(), null,<br /> RuleRuntime.STATELESS_SESSION_TYPE);<br />// execute the rules and get back the results...<br />List results = session.executeRules(inputObjectsList);<br />
  103. 103. Component: Rule Engine Connector (4/4)<br />53<br />
  104. 104. Component: Order Rule Access Object (RAO) (1/2)<br />Similar in concept to DAO pattern<br />Clients will interact with rule engine via this component; not the BREConnector<br />Just as a client would interface with a DAO interface and not some O/R or JDBC-based integration component<br />Provides domain-specific interface to access the rule engine <br />54<br />
  105. 105. Component: Order Rule Access Object (RAO) (2/2)<br />55<br />
  106. 106. Component: Service Registry<br />56<br /><ul><li>Apache jUDDI (UDDI-based)
  107. 107. Unambiguous, authoritative system of record of web service endpoint locations
  108. 108. Provides JAXR adapter
  109. 109. Accessed using service registry connector component </li></li></ul><li>Quick Note on UDDI<br />Created in 2000/2001 timeframe<br />ebXML too general / complex<br />All about services<br />Hierarchical data representation<br />Business<br />Business services<br />Concrete service bindings<br />Compliant registries REQUIRED to offer node that publishes web service-based inquiry API<br />Compliant registries SHOULD offer node that publishes web service-based API for:<br />publication, security, custody and ownership transfer<br />57<br />
  110. 110. Apache jUDDI and Apache Scout<br />Demo application leverages Apache jUDDI and Apache Scout<br />Apache jUDDI<br />UDDI registry<br />Compliant with UDDI 3 specification (level-0)<br />Provides web service and Java-based API to query and manage the registry<br />Apache Scout<br />JAXR implementation<br />UDDI version 2 and 3 compliant<br />58<br />
  111. 111. Publishing entries to UDDI Registry (1/3)<br />Leveraging soapUI to access jUDDI web service-based API<br />Publishing a business:<br />59<br />
  112. 112. Publishing entries to UDDI Registry (2/3)<br />Publishing a business service:<br />60<br />
  113. 113. Publishing entries to UDDI Registry (3/3)<br />Publishing a service binding:<br />61<br />
  114. 114. Browsing contents of jUDDI Registry<br />62<br />
  115. 115. Component: Service Registry Connector (1/3)<br />63<br /><ul><li>Like JDBC and JSR-94 API, JAXR is verbose and cumbersome to work with directly
  116. 116. Connector component provides layer of abstraction</li></ul>Exposed as a Java interface<br />Convenient; easy to work with<br />Implementations can be changed/swapped-out without impacting callers; implementation options:<br />JAXR<br />Vendor-specific API<br />other<br />
  117. 117. Component: Service Registry Connector (2/3)<br />64<br />
  118. 118. Component: Service Registry Connector (3/3)<br />65<br />
  119. 119. Component: Commands Abstraction (1/2)<br />Inbound request is un-marshalled into a command object<br />Command executor executes command<br />Business logic encapsulated within command<br />Clean programming model<br />New command objects can be created to accommodate new <portType> operations<br />No need to modify JAX-WS SEI; just create new command classes<br />Similar to “EJB Command” design pattern<br />66<br />
  120. 120. Component: Commands Abstraction (2/2)<br />67<br />From our JAX-WS Provider-based SEI…<br />
  121. 121. Component: Service Client<br />Business delegate-style object to allow easy access to web service<br />Methods in service client interface match-up to <portType> operations from web service<br />As usual, interface-based<br />Today’s implementation talks to a web service<br />Tomorrow’s implementation could talk to remote EJBs<br />Day after tomorrow’s implementation could be local method calls within the same JVM<br />68<br />
  122. 122. Agenda<br />The Requirements<br />Architecture of Proposed Solution<br />Major Components<br />Demo<br />Summary<br />Q/A <br />69<br />
  123. 123. Agenda<br />The Requirements<br />Architecture of Proposed Solution<br />Major Components<br />Demo<br />Summary<br />Q/A <br />70<br />
  124. 124. Summary<br />Demo app makes very rudimentary usage of Drools Expert<br />No central rule engine server to house and execute rules<br />Rule files are loaded and executed locally (same JVM) within the BREConnector implementation<br />Simple design, but not naïve<br />Design can accommodate changes in requirements and technology<br />Technology usage == implementation details<br />Interface-based design allows solution stacks to be swapped out without affecting callers<br />Not the only way to design a service<br />Architecture and design are informed by requirements; not technology<br />Good architecture flows from loose coupling and sound object-oriented principals<br />71<br />
  125. 125. Agenda<br />The Requirements<br />Architecture of Proposed Solution<br />Major Components<br />Demo<br />Summary<br />Q/A <br />72<br />
  126. 126. QA<br />Thank You for Attending!<br />Please remember to full out the session survey available under the “Survey” tab of the online schedule builder (Session: S313909)<br />The source code for this presentation can be found at: http://bit.ly/blueslate-javaone2010<br />73<br />

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
  • ×