Java one2010 presentation-s313909

© Blue Slate Solutions 2010

Building a JAX-WS Web Service with JBoss Drools and Apache jUDDI Integration

JavaOne 2010

Session: S313909

Monday, September 20, 2010


About Your Speakers

• Dave Read– CTO– CISSP, RHCE, SCJP– [email protected]

• Paul Evans– Chief Architect– SCJD, SCWCD– [email protected]

2

Smart Approach. Extraordinary Results.www.blueslate.net

mailto:[email protected]

mailto:[email protected]


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

3


Agenda

• The Requirements• Architecture of Proposed Solution• Major Components• Demo• Summary• Q/A

4


Agenda


5


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)

6


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

7


Agenda


8


Architecture of Proposed Solution (logical)

9

Order Total ServiceConsumer

Business Rule Engine (BRE)

Rule Definitions

EPEP

EP

BindBind

Bind

BREConnector

Order Total ServiceClient

ServiceRegistry

ServiceRegistryConnector


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

10


Reconcile Requirements with Logical Architecture (1/4)

Order Total Service


Rule Definitions

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)

11


Quick Note on Rules and Rule Engines (1/2)

12

• 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• … = …


Quick Note on Rules and Rule Engines (2/2)

13

• 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


Rule Definitions

BREConnector

NFR.1: BREs allow rules to be codified using a language close to the business domainNFR.1: BREs typically provide a GUI to allow non-programmers the ability to manage rules

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.



15


ServiceRegistry


NFR.4: The service registry connector is used to connect to a service registry and discover the physical endpoint of some target service.

Using a service registry provides a level of indirection that enables services to be loosely coupled from consumers from the dimension of location.


Quick Note on Registries

16

• 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

ConsumerBind

BindBindOrder Total

ServiceClient


NFR.4: The service client shields the consumer from the details and mechanics of invoking the web service.


Web Service – Summary of Major Design Decisions (1/2)

18

• Design to interfaces, not technologies• 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• Usage of rules engine externalizes business

rules from low-level Java code


Web Service – Summary of Major Design Decisions (2/2)

19

• Types are externalized from WSDL - command and entity canonical definitions (XSD) stand alone

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

• Marshaler/Un-marshaler component translates between canonical definitions and domain model (uses JAXB as default implementation)


Quick Note on Canonicals

• Authoritative format definitions for entities and commands (aka operations)

• AKA: Canonical Data Model design pattern from Enterprise Integration Patterns text

• Ties into an organization’s data dictionary• Context agnostic; potential uses:

– Format definition of message (when using a messaging system)

– Format definition of WSDL messages

20


Physical Architecture of ProcessSubTotal Web Service

21

ProcessTotal Web Service

Book Order / ProcessTotal SEI Implementation

@WebServiceProvider annotation

Book Order Marshaler / Un-marshalerComponent (JAXB)

Context Neutral

Book Order / ProcessTotalWSDL

Book OrderCommands canonical (XSD)

Book OrderEntities canonical (XSD)

Context Neutral

JAX-WS Runtime(+) Dispatcher Servlet

Book Order CommandsComponent

Context Neutral

Order Rule Access Object (RAO)Component

Context Neutral

Business Rule EngineJBoss Rules (Drools)

Book Order Domain ModelComponent (POJOs)

Context Neutral

Rule Engine ConnectorComponent (JSR-94)

Context Neutral


Physical Architecture of Client Application

22

Client ApplicationProcessTotal Service ClientComponent

JAX-WS Dispatch mechanism


Context Neutral

SOAP/HTTP

ProcessTotal Web Service

Service Registry(returns endpoint URL of ProcessTotal service)

Service Registry Connector (JAXR)

Context Neutral

UDDI RegistryApache jUDDI

ProcessTotalService Component (Java SE)

ProcessTotal SEI Implementation

@WebServiceProvider annotation

CONTEXT NEUTRAL


CONTEXT NEUTRAL

Book Order - ProcessTotalWSDL



CONTEXT NEUTRAL

JAX-WS Runtime(+) Dispatcher Servlet


CONTEXT NEUTRAL

Rule Engine ConnectorComponent (JSR-94)

CONTEXT NEUTRAL

Business Rule EngineJBoss Rules (Drools)



Context Neutral


Context Neutral

Book Order CommandsComponent

Context Neutral


Context Neutral

22


High-level Sequence (component view)

23


1 Service, Many Channels (and staying DRY)

24

• The ProcessOrderTotal service may publish multiple endpoints (as are needed - driven by the requirements)

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

• A service can expose multiple endpoints; some examples:o HTTP binding, verb=GET, input=URL encoded, output=MIMEo HTTP binding, verb=GET, input=URL replacement, output=MIME o HTTP binding, verb=POST, input=MIME, output=MIMEo SOAP binding, transport=(HTTP | JMS | SMTP), input=soap:body,

output=soap:bodyo SOAP binding, transport=(HTTP | JMS | SMTP), input=MIME,

output=MIME

Order Total Service

EPEP

EP

BindBind

Bind



Organizing WSDL Descriptors (concrete WSDLs implement abstract service definition)

25

Abstract Service Definition:• Types• Messages• Port Types

Concrete Definition [SOAP/HTTP]

• Bindings• Services

Concrete Definition [HTTP GET]


Concrete Definition [HTTP POST]


Concrete Definition [SOAP, using MIME / JMS]• Bindings• Services

Concrete Definition[. . .]


<wsdl:import>

• Each concrete WSDL provides <binding> and <service> elements• Each concrete WSDL uses <wsdl:import> to reference abstract

service definition


Abstract Definitions

26

<types>

<message>

<portType>

<import>


Concrete Definitions

27

<import>

<binding>

<service>


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

28


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!

29


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

30

Marshaller / Un-marshaller

XML message

POJO domain model

Canonical XSDsContext

neutral ecosystem

Web Services Messaging EJB EDIContext usage scenarios

…

Commands


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

31


Each concrete Provider-based endpoint references concrete WSDL

32

Concrete Definition [SOAP/HTTP]


Concrete Definition [HTTP GET]


Concrete Definition [HTTP POST]


Concrete Definition [SOAP, using MIME / JMS]• Bindings• Services

Concrete Definition[. . .]


Abstract Service Definition:

• Types

• Messages

• Port Types

<wsdl:import>

Provider-based Endpoint

@WebServiceProvider


@WebServiceProvider


@WebServiceProvider


@WebServiceProvider


@WebServiceProvider

wsdlLocation

<< Abstract >>Endpoint Support Class

Each Provider object to extend endpoint support base class


Each concrete Provider-based endpoint to extend from common abstract “endpoint support” class

33


@WebServiceProvider


@WebServiceProvider


@WebServiceProvider


@WebServiceProvider


@WebServiceProvider

<< Abstract >>Endpoint Support Class

- marshaler- processOrderTotalService

+ invoke (Source pSrc): Source

<< Interface >>javax.xml.ws.Provider


Concrete endpoints extend support class

34

@WebServiceProvider(wsdlLocation=/SOAP_HTTP-Service.wsdl)public class OrderService extends OrderServiceProviderSupport {

// no need to implement or override any methods...}

public abstract class OrderServiceProviderSupport implements Provider<Source> {

@Override public Source invoke(Source pRequest) { // un-marshal request XML into command object... OrderTotalCommand cmd = marshaler.unmarshal(pRequest);

// inject rule access object (RAO)... cmd.setOrderRao(OrderRaoFactory.newOrderRao());

// execute the command… new CommandExecutor().executeCommand(cmd);

// return the marshaled order object... return marshaler.marshal(cmd.getOrder()); }}

• Only exists to contain @WebServiceProvider annotation (with wsdlLocation attribute)


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

35


WSDL Design (2/3)

36


WSDL Design (3/3)

37


Agenda


38


Component: Command and Entity Canonical Definitions

39

• Unambiguous, authoritative definition of business entities and operations

• Formulated using XML Schema (XSD) • 2 types of elements:

o Entity - canonical definitions of business entities (nouns)o 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 • Canonical definitions can be versioned (related to "Format

Indicator" EI pattern)


Entities Canonical (types)

40


Commands Canonical

41


Component: POJO Domain Model

42

• Java-based object model representing both entities and commands

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


Domain Model - UML Class Diagram

43


Component: Marshaller/Un-marshaller (1/4)

44

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

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

• Publishes Java interface; multiple implementations can be createdo Default implementation will be based on JAXB

• 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


Component: Marshaller/Un-marshaller (2/4)

45


Relationship between canonicals, marshaller, domain model (3/4)

46

Web Services Messaging EJB EDI …

Marshaller / Un-marshaller

XML message

POJO domain model

Canonical XSDs

Commands


JAXB-based Implementation of Marshaller Interface

47


Component: Business Rule Engine (BRE) (1/3)

48

• JBoss rules (Drools)• 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• Accessed using BRE connector component


Component: Business Rule Engine (BRE) (2/3)

49

• 2005: Drools was incorporated into JBoss and rebranded as “JBoss Rules”

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

• 2007: Renamed back to Drools• 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…


Example Rule Definition

50

Rule Name

Effective Date

Condition (if)

Action (then)


Component: Rule Engine Connector (1/4)

51

• Like JDBC, JSR-94 API is verbose and cumbersome to work with directly

• Connector component provides layer of abstraction• Exposed 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



• 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

52



53

// 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);



54


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

55


Component: Order Rule Access Object (RAO) (2/2)

56


Component: Service Registry

57

• Apache jUDDI (UDDI-based)• Unambiguous, authoritative system of

record of web service endpoint locations

• Provides JAXR adapter• Accessed using service registry

connector component


Quick Note on UDDI

• Created in 2000/2001 timeframe– ebXML too general / complex– All about services

• Hierarchical data representation– Business– Business services– Concrete service bindings

• Compliant registries REQUIRED to offer node that publishes web service-based inquiry API

• Compliant registries SHOULD offer node that publishes web service-based API for:– publication, security, custody and ownership transfer

58


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

59


Publishing entries to UDDI Registry (1/3)

• Leveraging soapUI to access jUDDI web service-based API• Publishing a business:

60



• Publishing a business service:

61



• Publishing a service binding:

62


Browsing contents of jUDDI Registry

63


Component: Service Registry Connector (1/3)

64

• Like JDBC and JSR-94 API, JAXR is verbose and cumbersome to work with directly

• Connector component provides layer of abstraction• Exposed 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



65



66


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

67


Component: Commands Abstraction (2/2)

68

From our JAX-WS Provider-based SEI…


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

69


Agenda


70


Agenda


71


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

72


Agenda


73


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-javaone201074

Date post:	18-Nov-2014
Category:	Documents
Upload:	blue-slate-solutions
View:	794 times
Download:	0 times

Java one2010 presentation-s313909

Documents