1 / 41

Red Hat JBoss Fuse Service Works - A Common Framework

Red Hat JBoss Fuse Service Works - A Common Framework. Wayne Toh SENIOR CONSULTANT RED HAT ASEAN. What you can expect. We will be talking about a real world implementation of FSW. Some experience with Enterprise Service Bus will make the session more digestible.

vragland
Download Presentation

Red Hat JBoss Fuse Service Works - A Common Framework

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Red Hat JBoss Fuse Service Works - A Common Framework Wayne TohSENIOR CONSULTANTRED HAT ASEAN

  2. What you can expect • We will be talking about a real world implementation of FSW. Some experience with Enterprise Service Bus will make the session more digestible. • More than just a quickstartEnable practitioners to adopt best practices for customers • Based on web servicesApache Camel code will be shared to assist practitioners

  3. Fuse Service Works • JBoss Fuse Service Works is Red Hat’s middleware ESB solution for application integration, messaging, SOA, and service governance requirements.

  4. Service ComponentArchitecture (SCA) • Service Component Architecture (SCA) is a software technology created by major software vendors, including IBM, Oracle and TIBCO. SCA provides a model for composing applications that follows service oriented architecture principles.

  5. Apache Camel • Apache Camel is a rule-based routing and mediation engine that provides a Java object-based implementation of the Enterprise Integration Patterns using an API (or declarative Java Domain Specific Language) to configure routing and mediation rules. • Enterprise Integration Patterns include the following: Message RouterRequest-ReplyMessage SequencingContent-Based RouterSplitterAggregatorWire Tap

  6. Definition of Framework • Framework - An architecture that implements a set of specific design elements. Enforces adherence to a consistent design approach • Also an asset which can be leveraged • Benefits – avoid common implementation pitfalls, adopts best practices, promotes reusability of components, serves as implementation guideline for developers

  7. A Little Bit of Background • The customer is a Telco that leverages an ESB to decouple service consumers and providers. • A mediation application that serves as a proxy to expose a web service that would act as a facade to allow consumers to retrieve information from the backend service provider. The intent is to achieve a loose coupling of the web service consumer and producer via an enterprise service bus to achieve Service Oriented Architecture. • They selected SOA Platform • Engaged Red Hat JBoss services to overcome implementation issues

  8. Challenges • Lack of implementation guidelines and a common framework. • Performance issues due to single threaded ESB. Maxthreads property is not set. By default it is 1. • Using Log4j to print message body to server.log. It increases the size of the log. Performance impact due to synchronous invocation. • Inconsistencies in programming, sometimes use staticRouter, sometimes ContentBasedRouter

  9. Exception Handling Issue • When a backend service times out due to a long query, HTML code is returned instead of a proper SOAP exception • Exception handling implemented in multiple places

  10. Improper Exception Handling • Exceptions in HTTP gateway not caught and handled by Fault Service

  11. Common Framework in FSW • Red Hat migrated the existing SOA-P service to FSW 6.0.0.GA • Designed, developed and documented a common framework that serves as guidelines to developers • Incorporates exception handling, logging, audit and security.

  12. Principles behind the Common Framework • Servicing all elements of exception management (ie. Logging, exception resolution, notification)

  13. Modeling Business Faults • The SOAP <Fault> element is used to transmit error and status information with a SOAP message. • A modeled fault is one that one that is thrown explicitly due to the business logic of the code. It is different from a technical fault. • <soap:Body><soap: Fault><faultcode>soap:Server</faultcode><faultstring>no account id found</faultstring><detail> <BackendSystem> <ErrorCode>ER00012</ErrorCode> </BackendSystem></detail></soap:Body></soap: Fault>

  14. The Framework

  15. Design Decisions

  16. SwitchYard Project Structure

  17. Project Dependencies • jboss-deployment-structure.xml in the ProxyService project

  18. ProxyServiceCanvas

  19. Soap Binding Export

  20. SOAPFaultMessageComposer • Custom class that extends SOAPMessageComposer and overrides the decompose method. A MessageComposer can compose or decompose a native binding message into/from SwitchYard canonical message. • Necessary as SwitchYard will wrap the exception and a custom SOAP message could not be returned to the client. • Snippet of SOAPFaultMessageComposer.java

  21. Environment properties • The “Endpoint Address” field is used to indicate the backend address. As this value is environment specific, it needs to be filled with an environment property. SwitchYard supports environment properties. Environment properties allow one to replace any attribute or element value in switchyard.xml with a property from the runtime environment. • This allows code promotion through various environments without necessitating changes in the code

  22. Backend Service Reference

  23. Backend Service Reference

  24. Queue Service Reference • Take note that the concurrent consumers limit is 1 by default. This can be changed when more MDB threads are required to consume from the queue.

  25. Queue Service Reference • Maps the Camel headers as additional properties to outbound JMS messages. This is achieved by SwitchYardContextMapper, which moves native binding message headers to/from SwitchYardcononical context.

  26. Queue Service Reference • Key in the “disableReplyTo” as true. When true, a producer will behave like a InOnly exchange. Like InOnly the producer will not wait for a reply.

  27. Fault Service Reference • Key in the target namespace. This namespace is that of the fault-handling-service project and should be unique within the SwitchYard runtime.

  28. Camel Route • All processing should be done in the Try section.This allows all exceptions to be caught and handled by the Fault Handler Service.

  29. Camel Route • Camel Route in XML

  30. Camel Route (cont’d) • Camel Route in XML

  31. Fault Service Canvas • Invocation is via SCA binding

  32. Camel Canvas Properties • “Handle Fault” is true. This turns SOAP faults into exceptions, allowing Camel to catch the exceptions.

  33. Fault Handling in Details

  34. HTTP Basic Authentication • Enables authentication to protect the serviceCreate a new application user and role in EAPGo to the Switchyard Canvas, domain tab. Add the role under “Roles Allowed”

  35. HTTP Basic Authentication • Enable Client Authentication in Security Policy

  36. Log4J configuration Table below was created in POSTGRESQL CREATE TABLE Log ( date           timestamp NULL DEFAULT NULL,category      varchar(45) DEFAULT NULL,threadid      varchar(512) DEFAULT NULL,priority      varchar(10) DEFAULT NULL,message      varchar(4096) DEFAULT NULL ); 

  37. Create POSTGRESQL driver as a module • Content of module.xml <?xml version="1.0" encoding="UTF-8"?><module xmlns="urn:jboss:module:1.1" name="org.postgresql”><resources> <resource-root path="postgresql-9.3-1101.jdbc4.jar"/></resources><dependencies> <module name="javax.api"/></dependencies></module>

  38. Add database module as a dependency to log4j • Go to jboss-eap-6.1/modules/system/layers/base/org/jboss/log4j/logmanager/main. In the module.xml, add postgresql as one of the dependency. <module xmlns="urn:jboss:module:1.1” name="org.jboss.log4j.logmanager”> <resources> <resource-root path="log4j-jboss-logmanager-1.0.2.Final-redhat-1.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="org.dom4j" optional="true"/> <module name="org.jboss.logmanager"/> <module name="org.jboss.modules"/> <module name="org.postgresql"/></dependencies></module>

  39. Custom handler and asynchandler • Add custom handler and async handler<async-handler name="ASYNC”><queue-length value=”1024"/><overflow-action value=”block"/><subhandlers><handler name="DB"/></subhandlers></async-handler><custom-handler name="DB” class="org.apache.log4j.jdbc.JDBCAppender" module="org.apache.log4j”><level name="INFO"/><formatter><pattern-formatter pattern="insert into log values (current_timestamp,'%c', '%t','%p','%m')"/> </formatter><properties><property name="Driver" value="org.postgresql.Driver"/><property name="URL" value="jdbc:postgresql://localhost:5432/logdb"/><property name="User" value=”admin"/><property name="Password" value="P@ssw0rd"/></properties></custom-handler>

  40. Logging Category • Add a new logger category<logger category="Integration" use-parent-handlers="false”> <level name="INFO"/><handlers> <handler name="DB"/></handlers></logger>

More Related