UltraESB provides advanced mediation capabilities including mediation of messages within sequences. Sequences can be defined inline as Java or script fragments and support features like error handling. The mediation API is the same for Java and script sequences and provides methods for sending messages to endpoints, reading payloads, and more. Endpoints can specify load balancing and failover behaviors.

1. UltraESB
Advanced Services

2. Mediation of messages
● Mediation of messages takes place within Sequences
●
Sequences maybe written as
●
In-line Java fragments
● Classes – (allows step-through debugging)
● Script fragments (JSR 223)
● Java source files or Script files
●
Spring beans - (allows step-through debugging)
●
All sequences run at the speed of byte-code, irrespective of how they were
defined (e.g. scripts are not slow, as they use JDK compilation)
●
Mediation API is same for Java and Script sequences

3. To any sequence
● “msg” and “mediation” are always available and
refers to the current message and the mediation
support handle
● For sequence fragments “logger” is also available
● Custom class sequences can define own loggers
● Logger refers to a SLF4J/Log4J logger for the sequence

4. Mediation within Sequences
● Can use the “mediation” API of the ESB
● e.g.
– mediation.sendToEndpoint(msg, “some-endpoint”)
– mediation.readPayloadAsString(msg) etc
● Can invoke Spring framework utilities
● For Database operations etc
●
Can invoke existing libraries or third party libraries
● e.g.
– LogB → XML or CSV conversion librariy
– Smooks, XMLSpy etc
●
Error handling
● Via error handler sequences
● Or try – catch blocks within sequences

5. What is the UltraESB “api” JAR?
● A suggestion from a real customer
● Forces user code to only depend on the UltraESB
“API” and not its implementation
● Prevent binding to ESB internals
● AdroitLogic can safely assure backwards compatibility of
API methods
● Available as a separate Maven artifact for customers

6. In-line Sequence definition
Also shows an Error handler for a sequence

7. Sequence Error Handling
● One sequence can define another as its “error
handling sequence”
● Any un-handled exception causes the error handler
sequence to get invoked
● An error handler sequence should be carefully written,
and should take any recovery/log steps
● Example shows the specification of the error
sequence by its “id”

8. Re-usable Sequence definition
Also shows a “Groovy” script / JSR 223 fragment Sequence

9. The default configuration

10. Re-writing using re-usable
sequences

11. Re-Usable Sequences
● Does not belong to any proxy service
● Can be invoked by one or more proxy services
● But only within the same deployment unit
● Else, un-deploying one deployment unit could cause
problems to another
● If you want to define re-usable sequences to be
shared across multiple deployment units, define them
in the ultra-custom.xml

12. Re-Usable Endpoints?
● Of course!
● Similar to re-using sequences

13. More on reuse

14. Mediation Support Interfaces
● GetAuditSupport()
●
GetCachingSupport()
●
GetDateSupport()
● GetHTTPSupport()
●
GetJAXBSupport()
●
GetJSONSupport()
● GetMetricsSupport()
●
getSOAPSupport()
●
GetThrottleSupport()
● getXACMLSupport()
● GetProtocolBufferSupport()
●
getHL7Support()
● ..

15. Core Mediation methods
●
sendToEndpoint(msg, “ep-id”)
●
sendResponse(msg, responseStatusCode)
● setPayloadFromFile(msg, “/path/to/file”)
● getDataSource(“data-source-id”)
● getSpringBean(“bean-id”)
● getWSSecurityManager()
● invokeSequence(msg, sequenceName)
● invokeSequenceAsynchronously(msg, sequenceName)
● invokeSequences(msg, List<String> sequenceIDs..)

16. More..
● readPayloadAsByteArray(msg)
●
readPayloadAsMap(msg)
● readPayloadAsString(msg)
●
readPayloadAsXMLDocument(msg)
●
savePayloadToFile(msg, “/path/to/file”)
● setPayloadFromByteArray(m, byte[])
●
SetPayloadFromFile(..)
●
SetPayloadFromMap(..)
● SetPayloadFromString(..)
●
SetPayloadFromXMLDocument(..)
●
SetPayloadFromObject(...)

17. What is the “payload”?
● Defined by possible MessageFormats
● RawFileMessage – e.g. HTTP/S
● ByteArrayMessage – e.g. JMS
● DOMMessage – When XML manipulations are performed over a message
● DataHandlerMessage – e.g. Email
● MapMessage – e.g. JMS
● HAPIMessage – e.g. MLLP/S
● String – e.g. JMS
● Stream - e.g. JMS
● Object - e.g. JMS

18. MessageFormat conversions
● Takes place on demand
● Where required / implicit
– e.g. XML DOM manipulation
● Explicitly converted
– By user action e.g. a HTTP JSON message from a file to an untyped
Map
● Xpath evaluation can be performed without DOM parsing
when using VTD XML
● User just drops the VTD XML JAR into lib/custom

19. Message format Optimizations
● If a message is not modified, a non-effective changes with a
conversion maybe ignored by the ESB for performance
● e.g. a HTTP JSON message is parsed as an untyped Map, and
used for routing
– If the original message is not updated, the original raw file will be used to
write the message to the backend service
● Same applies for Xpath evaluation creating DOM from a raw file
●

20. Using Spring / Spring Security / 3rd
party libraries
● JDBC Insert - #105
● Local transactions - #105
● Authentication – LDAP, Database, Custom etc

21. The “Message” (i.e. “msg”)
● addMessageProperty(“key”, value)
● GetMessageProperties()
● RemoveMessageProperty(..)
● addResponseCorrelation(“key”, value)
● addTransportHeader(“key”, “value”)
● RemoveTransportHeader(...)
● getFirstTransportHeader(“key”)
● getTransportHeaders()
● createDefaultResponseMessage()
● beginTransaction()
● commitTransaction()
● rollbackTransaction()
● suspendTransaction()
● resumeTransaction()
● isMarkedAsFailed()

22. ● getContentType()
●
getCurrentPayload()
●
getOriginalPayload()
●
GetAttachments()
●
getAttachment(“id”)
● getDestinationURL()
●
getExceptions()
●
isRequest() / isResponse()
● setDestinationURL()
●

23. Endpoints/Destinations and
Addresses
● An Endpoint can specify one or more Addresses
● Addresses could specify the destination as:
● A Full URL
– <u:address>http://localhost:9000/service/EchoService</u:address>
– <u:address>jms:/Q.jmsPending</u:address>
– <u:address>file:///tmp/AS2/received</u:address>
– <u:address>mailto:fwd@localhost</u:address>
●
A URL Prefix (e.g. for REST)
– <u:address type="prefix">http://localhost:9000/rest-services</u:address>
● As a “response” (e.g. for HTTP/S over same socket)
– <u:address type="response"/>
●
As “default” - i.e. pick actual address set during mediation (e.g. by looking at a Database etc)
– <u:address type="default"/>

24. Load balancing and Fail-Over
● Single (address) Endpoints
● Are never suspended on errors
– better try the only one available
● Group endpoints
● Failing addresses are given grace periods or are suspended from use
● Round-Robin with/without Fail-Over
● Weighted with/without Fail-Over
● Random with/without Fail-Over
● Fail-Over only
● More Endpoints in later versions

25. Synchronous / Asynchronous
Transports and Endpoints
● An Endpoint send could be synchronous or asynchronous
depending on the transport sender implementation
● At present
● HTTP/S, MLLP/S, TCP/S are asynchronous senders
● All others are synchronous
– e.g. JMS post, SFTP upload etc..
● Error handling could detect synchronous (e.g. invalid/unsupported
transport) as well as asynchronous (e.g. invalid hostname) errors

26. Error Handling Configuration

27. Errors and Codes
● Errors are indicated by Error codes
● Some signal serious errors(e.g. connection refused)
● Some signal temporary errors (e.g. socket timeout)
● Serious errors lead to suspension of failed address
● Duration of suspension is computed as
Current Duration = Last Duration == null ?
Initial Duration :
max( (Last Duration * Progression Factor), Maximum Duration)

28. Suspension on continuous
occurrence of temporary failures
● If the grace period expires without any
successful responses

29. Fail-Over behavior
● Not all failures maybe safe for retry
● User may override and specify which error conditions are safe for
retry with another address
● Default safe conditions are the following, and can be specified per
endpoint
– 101508 - Sender connect timeout (TCP level connection establishment
failure within specified (default 10) number of seconds
– 101503 - Connect failed (connection refused by remote party over the
specified port)
– 101510 - Rejection by response validator as a temporary error

30. Common Endpoint Errors
● Suspension
● 101503 - Connect failed (connection refused by remote party over the specified port)
● 101511 - Rejection by response validator as a suspension error
● Temporary
● 101508 - Sender connect timeout (TCP level connection establishment failure within specified (default 10) number of seconds
● 101504 - Sender connection Timeout (expiration of the specified, or default connection timeout from the ESB side sender)
● 101500 - Sender IO error during sending
● 101506 - Sender detection of a HTTP/S protocol violation during send
● 101505 - Sender detection of a connection close by remote party during send
● 101510 - Rejection by response validator as a temporary error
● 101006 - Listener detection that a response cannot be submitted (e.g. Connection already closed)
● 101000 - Listener side IO error during send
● 101003 - Listener connection timeout (expiration of the specified, or default connection timeout from the ESB side listener)
● 101005 - Listener detection of a connection close by remote party

31. Response Validation and
Location Header re-writing
● Validate response “body” instead of transport or response
header/status code
● e.g. “Service Not Found” HTML page returned with 200 status code
● Location headers used with REST must be re-written against
the proxy service to hide backend service
● e.g. <u:property name="ultra.endpoint.switch_location_headers_to"
value="http://localhost:8280/service/rest-proxy"/>

32. Transports
● Listeners
● Gets messages and pushes them to the ESB
● HTTP/S, JMS, File, FTP, SFTP, FTPS, POP3/IAMP/SMTP,
MLLP/S, TCP/S
● Senders
● Registers a protocol to the ESB and is invoked by the ESB
depending on the out URL

33. Other ways of getting Stuff in/out
● Transport Listers
● Polling transports (Email, FTP etc)
●
Fired on event (JMS, HTTP/S, etc)
●
Can configure more than one Listener per Service
– Services exposed over multiple transports (http/JMS/File etc)
– Multiple incoming ports, security configurations (auth, SSL etc)
●
Transport Senders
● Are selected by the outgoing URL for a message
● More than one instance can exist for same protocol
– e.g. Proxy Servers, Authentication, 2-way SSL etc

34. HTTP/S Transport Listeners
● Context Path customization
● Zero-Copy
● Bind Address
● No-Compression
● Connection Debugging
● Advanced properties (SO Timeout, Nagle, Buffer size)
● Maximum Payload Size
● Maximum connections before new connection acceptance pause
● Request Filters
● Service Resources (WSDL, XSD etc)
● Authentication (Basic and Digest)
● SSL – 2-way SSL and remote certificate validation disable for testing

35. HTTP/S Transport Senders
● Proxy server
● Proxy by-pass for hosts
● Zero-copy
● Unzip response entities
● Connection debug
●
Keep-alive time and safety threshold
● Advanced properties (SO Timeout, etc)
● SSL – Host name verification (Strict, Default..), remote certificate
validation disable for testing

36. e.g. Multiple HTTP Senders
- Though a Proxy Server and Direct connection
●
Sample # 207
<bean id="http-sender-1" class="org.adroitlogic.ultraesb.transport.http.HttpNIOSender">
<constructor-arg ref="fileCache"/>
</bean>
<bean id="http-sender-2" class="org.adroitlogic.ultraesb.transport.http.HttpNIOSender">
<constructor-arg ref="fileCache"/>
<property name="proxyHost" value="localhost"/>
<property name="proxyPort" value="3128"/>
<property name="proxyBypassList" value="asankha,127.0.0.1"/> </bean>

37. Specifying out Sender configuration
<u:proxy id="soap-proxy-1">
...
<u:target>
<u:inDestination>
<u:address>{http-sender-
1}http://localhost:9000/service/SimpleStockQuoteService</u:address>
</u:inDestination>
...
</u:target>
</u:proxy>

38. HTTP/S Connection Debugging
● Helps find out root cause
● e.g. Client to the ESB timed out, but actual cause was multiple
backend service timeouts after fail-over
● Can be disabled, or tuned to dump only a subset of headers
● Records error codes, times and connection socket/s, keep-
alive establishment times etc
2011-11-28 02:16:05,228 [-] [L-I/O dispatcher 8] WARN ServerConnectionDebug UUID=2846e762-58c8-4a9e-af60-68a32c1dc3f5, C2E-
Connection=10.194.142.84:49875->10.37.22.82:8281, C2E-Req-StartTime=02:16:05.033, C2E-Req-EndTime=02:16:05.033, C2E-Req-
ConnCreateTime=02:16:04.996, C2E-Req-URL=/services/sample-service-xfire, C2E-Req-Protocol=HTTP/1.1, C2E-Req-Method=POST, C2E-Req-IP=10.194.142.84,
C2E-Req-Info={Host=ec2-50-19-56-197.compute-1.amazonaws.com:8281, SOA_CALL_ID=543bbd22-56ec-43ac-bde0-2dabde756a44, Content-Length=947,
SOAPAction=urn:runForTime, User-Agent=SOA-Toolbox/1.5.0, Content-Type=text/xml; charset=UTF-8, Connection=Keep-Alive}, E2C-Resp-Start=02:16:05.169,
E2C-Resp-Status=HTTP/1.1 200 OK, E-C-IOSession-Start=02:16:04.996, E-C-IOSession-Last-Read=02:16:05.032, E-C-IOSession-Last-Write=02:16:05.224, E-C-
Error-Time=02:16:05.225, E-C-Error-Code=101000, C-Xfer-Time=55.583, C-Req-Xfer-Time=0.039, C-Res-Xfer-Time=55.544

39. More clearly examined
C2E-Req-StartTime=16:50:52.420,
C2E-Req-EndTime=16:50:52.422,
C2E-Req-ConnCreateTime=16:50:52.419,
C2E-Req-URL=/service/echo-proxy,
C2E-Req-Protocol=HTTP/1.0,
C2E-Req-Method=POST,
C2E-Req-IP=127.0.0.1,
C2E-Req-Info={SOAPAction=urn:getQuote,
User-Agent=AdroitLogic (http://adroitlogic.org) - UltraESB/1.1.0
(GA),
Host=localhost:8280,
Content-Type=text/xml; charset=UTF-8,
Connection=close,
Content-Length=295},
E2C-Resp-Start=16:50:56.459,
E2C-Resp-Status=HTTP/1.0 200 OK,
E-C-Error-Code=101001,
E-C-Error-Time=16:50:56.461,
E2S-Req-Start=16:50:54.437,
E2S-Req-EndTime=16:50:54.446,
E2S-Req-ConnCreateTime=16:50:54.442,
E2S-Req-URL=http://localhost:9000/service/EchoService,
E2S-Req-Protocol=HTTP/1.1,
E2S-Req-Method=POST,
E2S-Previous-Attempts=Attempt-Info={
E2S-Req-Start=16:50:52.426,
E2S-Req-EndTime=16:50:52.433,
E2S-Req-ConnCreateTime=16:50:52.429,
E2S-Req-URL=http://localhost:9001/service/EchoService,
E2S-Req-Protocol=HTTP/1.1,
E2S-Req-Method=POST,
E-S-Error-Code=101504,
E-S-Error-Time=16:50:54.434},
S2E-Resp-Start=16:50:54.449,
S2E-Resp-End=16:50:54.454,
S2E-Resp-Status=HTTP/1.1 200 OK,
S2E-Resp-Info={
port=9000,
Content-Length=295}

40. Publicly exposed HTTP/S
Listener protection
● Limits connections allowed
● Limit maximum payload size
● Dump attacking IP when suspected, for
fail2ban blocking from the firewall

41. HTTP/S support for
'Maintenance Mode'
● When HTTP/S Listeners are put into Maintenance
(i.e. for a restart or temporary pause) new
connections will not be accepted
● However, established connections will be able to
respond without hindrance
● If an attack is detected, the HTTP/S listener would
automatically limit connections to the user specified
threshold and reject others

42. JMS Transport
● Based on Spring Framework
● Can map one or more request/response destinations to a service
● Supports local and JTA XA transactions
● Supports API 1.1/1.0.2b via Spring DefaultMessageListenerContainer
● Based on Polling, with automatic caching of resources
● All Spring tuneable properties are valid – e.g. concurrentConsumers,
maxConcurrentConsumers, messageSelector etc

43. JMS Transport (more)
● Text, Map, Stream, Bytes and Object messages
supported
● JMS Queues and Topics Supported
● Durable Subscriptions supported
● Message headers and properties supported
● Spring JMSTemplates and Connection Factory
tuning is re-used

44. Email Transport
●
Support for POP3/IMAP polling
● SMTP Sending
● Java Mail supported Authentication
● Parallel download and processing from one Inbox
● Delete or move after processing/failure
● Simplified support to manage email headers, and attachments
●
Support for text and multipart messages with content type based priority to
select “main” part and attachments
● Can quickly debug detailed mail server communication through integration
with javax.mail debugging

45. Scheduled Tasks
● Based on a simple polling specification or CRON
● Can be used to poll a Database, file system, remote
HTTP/S URL or Service etc
● Support for use of transactions when Databases are
used
● Simplified DB access with Spring JDBC Templates
● Ability to specify steps via any supported mediation
technology / language

46. File Transports
● Supports Files, FTP, SFTP and FTPS
● Delete or move [+rename] after processing
● File locking to prevent multiple threads from processing
the same file
● Safe mode support in Windows
but not recommended for production use
● Raw “file” access as a “file” is always kept as a “file”
without any wrapping

47. TCP/S and MLLP/S Transports
● TCP/S is an abstract transport
● Must specify the “protocol”
● e.g. MLLP/S is a concrete implementation for HL7
messaging
● Can develop support for legacy / proprietary
protocols easily with non-blocking TCP/S base
framework

48. Custom Transports
● Custom transports maybe implemented over
● The polling transport framework
● The abstract transport framework

49. Proxy Services & Work Managers
● Could be associated with a custom work manager
● By default each service binds to the default work manager
of the configuration
● Work managers defines the thread pools (usually
primary/secondary) and optional message persistence
● Default work manager is the SimpleQueue WorkManager

50. Proxy Service & Transports
● A Proxy Service attaches to one or more transport
listener configuration
● Depending on the transport, the service will specify
transport specific properties for the service
● e.g. URL or URL pattern for a HTTP/S service
● JMS destination and Response destination
● File/SFTP/FTPS locations and file patterns

51. File Caches
● Are a very efficient way to store messages in memory, without
an overhead to the CPU using Direct Memory Access (DMA)
where supported
● i.e. Zero-Copy proxying
● HTTP/S, MLLP/S, TCP/S transports use this
● Also used when messages are converted within the ESB at
some points
● Reduces GC overhead considerably due to fixed size
allocation outside of the heap

52. HTTP/S messages on Files
● Allows support for absolutely any type of payload
● SOAP, JSON, Hessian, Text, FI, Binary etc
● Unless mediation attempts to read payload content is left
intact as raw bytes
● Allows optimal fail-over – as an Object message would be
serialized multiple times for fail-over
– File messages messages are repeatable, and the size pre-known