1. Building a JAX-WS Web Service with JBoss Drools and Apache jUDDI Integration JavaOne 2010 Session: S313909 Monday, September 20, 2010

2. About Your Speakers Dave Read CTO CISSP, RHCE, SCJP David.Read@blueslate.net Paul Evans Chief Architect SCJD, SCWCD Paul.Evans@blueslate.net 1 Smart Approach. Extraordinary Results. www.blueslate.net

3. Why Are We Here? To walk through the architecture and design of a Java-based web service service based on a set requirements JAX-WS, JAXB, JAXR, JSR94,… To demonstrate how the architecture of a complex web service flows from object-oriented principals 2

4. Agenda The Requirements Architecture of Proposed Solution Major Components Demo Summary Q/A 3

5. Agenda The Requirements Architecture of Proposed Solution Major Components Demo Summary Q/A 4

6. Functional Requirements 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) 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 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 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) 5

7. Non-functional Requirements NFR.1: The rules governing the calculation of the sub-total should be maintainable by business analysts New rules can be added, existing rules to be modifiable without involving the application development team NFR.2: The order total processing system should be componentized and not tied to a web service context NFR.4: The sub-total processing system should be easy and convenient for consumers to utilize NFR.7: The rule engine will be limited to the execution of business rules - it should not be used for “mechanical” type purposes 6

8. Agenda The Requirements Architecture of Proposed Solution Major Components Demo Summary Q/A 7

9. Architecture of Proposed Solution (logical) 8 Service Registry Consumer Order Total Service Order Total Service Client BRE Connector Service Registry Connector EP Bind EP Bind EP Bind Business Rule Engine (BRE) Rule Definitions

10. Notables Missing from Logical Architecture Enterprise Service Bus Complex piece of system software Omitted for brevity Logging service Logging service to be used enterprise-wide A logging service would operate asynchronously for snappy performance 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 Security service Handles authentication and authorization requests Queried to ascertain encryption and integrity requirements of a service 9

11. Reconcile Requirements with Logical Architecture (1/4) 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. 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) Order Total Service Business Rule Engine (BRE) Rule Definitions 10

12. Quick Note on Rules and Rule Engines (1/2) 11 What? Execution environment for business rules Storage / housing of business rules Environment for authoring and maintaining business rules Usually leverages Rete algorithm for rule execution Think of as just another component within the architecture – RDBMS component = data persistence LDAP component = identity management (authentication / authorization) Mainframe component = legacy transaction processing BRE component = execution of business rules Workflow engine component = codification of workflow … = …

13. Quick Note on Rules and Rule Engines (2/2) 12 Why? Interprets business data data sitting in a relational database in and of itself is meaningless – SOMETHING needs to give the data MEANING business rules provide meaning to data Codification of business rules in a format that is closer to the business domain 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 BREs typically provide an environment to codify rules using a grammar that is more natural to technical-savvy business users Other reasons Easier to audit Expose as a service to enable other systems the ability to leverage common rule base …

14. Reconcile Requirements with Logical Architecture (2/4) 13 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. BRE Connector NFR.1: BREs allow rules to be codified using a language close to the business domain NFR.1: BREs typically provide a GUI to allow non-programmers the ability to manage rules Business Rule Engine (BRE) Rule Definitions

15. Reconcile Requirements with Logical Architecture (3/4) 14 Using a service registry provides a level of indirection that enables services to be loosely coupled from consumers from the dimension of location. Service Registry NFR.4: The service registry connector is used to connect to a service registry and discover the physical endpoint of some target service. Order Total Service Client Service Registry Connector

16. Quick Note on Registries 15 Publication of web services Discovery and lookup of data formats, messages, business processes, services ebXML Started by OASIS and United Nations (UN/CEFACT) in 1999 Repository of data formats, process definitions, messages across industries Enable global world to participate in electronic commerce (including developing nations) UDDI Sponsored by OASIS – 2000/2001 Enables business to publish and lookup service listings Peculiar to web services

17. Reconcile Requirements with Logical Architecture (4/4) 16 NFR.4: The service client shields the consumer from the details and mechanics of invoking the web service. Consumer Order Total Service Client Service Registry Connector Bind Bind Bind

19. Following a contract-first approach

20. Connectors to provide access to web services, rule engine, and service registry

21. Usage of service registry insulates consumers from service endpoint locations

23. Java domain model created by hand (is not auto-generated by JAXB compiler from canonical XSDs)

25. Physical Architecture of ProcessSubTotal Web Service 20 ProcessTotal Web Service JAX-WS Runtime (+) Dispatcher Servlet Book Order / ProcessTotal SEI Implementation @WebServiceProvider annotation Book Order / ProcessTotal WSDL Book Order Marshaler / Un-marshalerComponent (JAXB) Book Order Commands canonical (XSD) Context Neutral Order Rule Access Object (RAO)Component Book Order Entities canonical (XSD) Rule Engine ConnectorComponent (JSR-94) Book Order CommandsComponent Context Neutral Context Neutral Context Neutral Context Neutral Book Order Domain ModelComponent (POJOs) Business Rule Engine JBoss Rules (Drools) Context Neutral

26. Physical Architecture of Client Application JAX-WS Runtime (+) Dispatcher Servlet ProcessTotalWeb Service ProcessTotal SEI Implementation @WebServiceProvider annotation Book Order - ProcessTotal WSDL ProcessTotalService Component (Java SE) Book Order Marshaler / Un-marshalerComponent (JAXB) Book Order Commands canonical (XSD) SOAP/HTTP CONTEXT NEUTRAL CONTEXT NEUTRAL Rule Engine ConnectorComponent (JSR-94) Book Order Entities canonical (XSD) Book Order Domain ModelComponent (POJOs) CONTEXT NEUTRAL CONTEXT NEUTRAL CONTEXT NEUTRAL Business Rule Engine JBoss Rules (Drools) Client Application Service Registry Connector (JAXR) ProcessTotal Service Client Component Context Neutral JAX-WS Dispatch mechanism UDDI Registry Apache jUDDI Book Order Marshaler / Un-marshalerComponent (JAXB) Book Order CommandsComponent Context Neutral Context Neutral Service Registry (returns endpoint URL of ProcessTotal service) Book Order Commands canonical (XSD) Book Order Domain ModelComponent (POJOs) Book Order Entities canonical (XSD) Book Order Domain ModelComponent (POJOs) Context Neutral Context Neutral 21 Context Neutral 21

27. High-level Sequence (component view) 22

29. Regardless of endpoint used, the exact same downstream-components are used to handle requests

30. A service can expose multiple endpoints; some examples:

31. HTTP binding, verb=GET, input=URL encoded, output=MIME

32. HTTP binding, verb=GET, input=URL replacement, output=MIME

33. HTTP binding, verb=POST, input=MIME, output=MIME

34. SOAP binding, transport=(HTTP | JMS | SMTP), input=soap:body, output=soap:body

35. SOAP binding, transport=(HTTP | JMS | SMTP), input=MIME, output=MIME Order Total Service Order Total Service Client EP Bind EP Bind EP Bind

37. Messages

43. Services24

44. Abstract Definitions 25 <types> <import> <message> <portType>

45. Concrete Definitions 26 <import> <binding> <service>

46. JAX-WS (Java API for XML Web Services) Evolution from JAX-RPC Supports the development of both bottom-up and top-down (contract first) services Data binding is delegated to JAXB Provides WSDL / Java mapping Makes extensive use of annotations Provides service-side and client-side APIs Handler framework 27

47. JAX-WS Service Endpoint Implementation (SEI) Java class to process requests to web service endpoint Must carry javax.jws.WebService annotation Maps to a wsdl:portType container element Methods of this class may carry javax.jws.WebMethod annotation JAX-WS runtime will leverage JAXB to handle un-marshalling and marshalling of inbound request and response Very simple! 28

48. However…we need more control We have requirements that stipulate the components we build should be reusable; and be reusable outside the context of web service 29 Context usage scenarios Web Services Messaging EJB EDI … XML message Canonical XSDs Context neutral ecosystem Marshaller / Un-marshaller POJO domain model Commands

49. JAX-WS Provider API javax.xml.ws.Provider is a lower-level generic API for processing requests to web service endpoint @WebServiceProvider annotation Enables the endpoint class to work directly with message payloads Allows us to use our own marshalling/un-marshalling component 30

51. Messages

57. Services<wsdl:import> wsdlLocation Provider-based Endpoint Provider-based Endpoint Provider-based Endpoint Provider-based Endpoint Provider-based Endpoint @WebServiceProvider @WebServiceProvider @WebServiceProvider @WebServiceProvider @WebServiceProvider << Abstract >> Endpoint Support Class Each Provider object to extend endpoint support base class 31

60. WSDL Design (1/3) Leverage the document/literal “wrapped” convention Semantically very similar to RPC/literal Internal dispatching/processing of requests is simplified Root element of message payload indicates the operation / command Entire message payload can be schema validated Not so with RPC/literal Not without its disadvantages Requires trickery within the WSDL 34

61. WSDL Design (2/3) 35

62. WSDL Design (3/3) 36

63. Agenda The Requirements Architecture of Proposed Solution Major Components Demo Summary Q/A 37

65. Formulated using XML Schema (XSD)

66. 2 types of elements:

67. Entity - canonical definitions of business entities (nouns)

68. Command - canonical definitions of operations which act upon entities (verbs)

69. Exist on their own and are context-independent

70. XML instances of entity canonical un-marshal into Java POJOs

71. XML instances of command canonical un-marshal into command objects (based-on GoF command design pattern)

72. Related to "Canonical Data Model" EI pattern

74. Commands Canonical 40

76. Hand-authored; not created by a tool

77. Influenced by associated entity and command canonical definitions

78. Entities modeled as simple POJOs

79. Commands modeled as command objects - conforming to the GoF command design pattern

82. Responsible for marshaling POJOs into associated XML instances (conformant to a specific version of entity canonical)

83. Publishes Java interface; multiple implementations can be created

84. Default implementation will be based on JAXB

86. Relationship between canonicals, marshaller, domain model (3/4) 45 Web Services Messaging EJB EDI … XML message Canonical XSDs Marshaller / Un-marshaller Commands POJO domain model

87. JAXB-based Implementation of Marshaller Interface 46

89. Rete-based forward chaining environment

90. Unambiguous, authoritative system of record of business rules

91. Interprets business data

92. Business rules encoded using a grammar that is closer to the business domain (closer than what a traditional 3GL could achieve)

93. Provides JSR-94 adapter

95. 2006: JBoss acquired by RedHat - rewrite / enhanced implementation funded

96. 2007: Renamed back to Drools

97. Drools is currently a suite of systems:Drools Expert – rule engine Rule language Domain specific languages Rules and decision tables ReteOO – enhanced version of Rete for OO systems Drools Guvnor – business rule management system Web-based Rule authoring and storage Rule management Rule deployment Drools Flow – process and workflow system Others…

98. Example Rule Definition 49 Rule Name Effective Date Condition (if) Action (then)

100. Connector component provides layer of abstractionExposed as a Java interface Convenient; easy to work with Implementations can be changed/swapped-out without impacting callers; implementation options: JSR-94 Vendor-specific API other

101. Component: Rule Engine Connector (2/4) JSR-94 concepts: Rule Engine Environment to house and execute rules Rule Session Stateless or stateful Associated with a single rule execution set Rule Execution Set Collection of rules Rule If/Then Pluggable provider 51

102. Component: Rule Engine Connector (3/4) 52 // load the provider class... Class.forName("org.drools.jsr94.rules.RuleServiceProviderImpl“); // obtain provider object... RuleServiceProvider provider = RuleServiceProviderManager.getRuleServiceProvider(“http://drools.org”); // create rule administrator object (needed to create execution set)... RuleAdministrator ruleAdmin = provider.getRuleAdministrator(); // create local rule execution set provider... LocalRuleExecutionSetProvider ruleExecSetProvider = ruleAdministrator.getLocalRuleExecutionSetProvider(null); // create the rule execution set... RuleExecutionSet executionSet = ruleExecSetProvider.createRuleExecutionSet( new InputStreamReader(new FileInputStream(“/BusinessRuleDefs.drl”)), null); // register the rule execution set with the rule administrator... ruleAdmin.registerRuleExecutionSet(executionSet.getName(), executionSet, null); // get handle to rule runtime... RuleRuntime ruleRuntime = provider.getRuleRuntime(); // create stateless rule session... StatelessRuleSession session = ruleRuntime.createRuleSession(executionSet.getName(), null, RuleRuntime.STATELESS_SESSION_TYPE); // execute the rules and get back the results... List results = session.executeRules(inputObjectsList);

103. Component: Rule Engine Connector (4/4) 53

104. Component: Order Rule Access Object (RAO) (1/2) Similar in concept to DAO pattern Clients will interact with rule engine via this component; not the BREConnector Just as a client would interface with a DAO interface and not some O/R or JDBC-based integration component Provides domain-specific interface to access the rule engine 54

105. Component: Order Rule Access Object (RAO) (2/2) 55

107. Unambiguous, authoritative system of record of web service endpoint locations

108. Provides JAXR adapter

110. Apache jUDDI and Apache Scout Demo application leverages Apache jUDDI and Apache Scout Apache jUDDI UDDI registry Compliant with UDDI 3 specification (level-0) Provides web service and Java-based API to query and manage the registry Apache Scout JAXR implementation UDDI version 2 and 3 compliant 58

111. Publishing entries to UDDI Registry (1/3) Leveraging soapUI to access jUDDI web service-based API Publishing a business: 59

112. Publishing entries to UDDI Registry (2/3) Publishing a business service: 60

113. Publishing entries to UDDI Registry (3/3) Publishing a service binding: 61

114. Browsing contents of jUDDI Registry 62

116. Connector component provides layer of abstractionExposed as a Java interface Convenient; easy to work with Implementations can be changed/swapped-out without impacting callers; implementation options: JAXR Vendor-specific API other

117. Component: Service Registry Connector (2/3) 64

118. Component: Service Registry Connector (3/3) 65

119. Component: Commands Abstraction (1/2) Inbound request is un-marshalled into a command object Command executor executes command Business logic encapsulated within command Clean programming model New command objects can be created to accommodate new <portType> operations No need to modify JAX-WS SEI; just create new command classes Similar to “EJB Command” design pattern 66

120. Component: Commands Abstraction (2/2) 67 From our JAX-WS Provider-based SEI…

121. Component: Service Client Business delegate-style object to allow easy access to web service Methods in service client interface match-up to <portType> operations from web service As usual, interface-based Today’s implementation talks to a web service Tomorrow’s implementation could talk to remote EJBs Day after tomorrow’s implementation could be local method calls within the same JVM 68

122. Agenda The Requirements Architecture of Proposed Solution Major Components Demo Summary Q/A 69

123. Agenda The Requirements Architecture of Proposed Solution Major Components Demo Summary Q/A 70

124. Summary Demo app makes very rudimentary usage of Drools Expert No central rule engine server to house and execute rules Rule files are loaded and executed locally (same JVM) within the BREConnector implementation Simple design, but not naïve Design can accommodate changes in requirements and technology Technology usage == implementation details Interface-based design allows solution stacks to be swapped out without affecting callers Not the only way to design a service Architecture and design are informed by requirements; not technology Good architecture flows from loose coupling and sound object-oriented principals 71

125. Agenda The Requirements Architecture of Proposed Solution Major Components Demo Summary Q/A 72

126. QA Thank You for Attending! Please remember to full out the session survey available under the “Survey” tab of the online schedule builder (Session: S313909) The source code for this presentation can be found at: http://bit.ly/blueslate-javaone2010 73