A Talk with Two Titles Well, actually three including this one

advertisement
A Talk with Two Titles
Well, actually three including this one
What's in an ESB
Not unlike:
William A. Woods: What's in a Link (1971)
Ronald J. Brachman: What's in a Concept (1977)
Note, there's no question mark in either title!
What an ostentatious
title!
Main Entry: os·ten·ta·tious [Merriam-Webster]
marked by or fond of conspicuous or vainglorious and
sometimes pretentious display
Three Letters:
263 = 17576 Possibilities
MOM, EAI, EIP, JMS, JBI, JCA,
SOA, SCA, SOI, MEP, ORM,
CMP, CMT, DSL, JMX, TLA,
NMR, ESB...
Content
1. Confusion (subjective!)
2. Escapism into technology
3. Catharsis and finding ways to blame
others
1. Confusion (subjective!)
My Semantic Network
Link Semantics: "is somehow related to, but I have no idea how and I'm not in the mood to figure it out"
Views on the Issue of SOA
(1) "Democratic/chaotic" message flow over TCP/IP, http, smtp/pop,
bicycle courier or whatever is available? Charming idea - but how
does this all work without
- "authority"/"trust" concepts as in URLs, DNS, SSL/TLS, ..
- transactions, security, ...
(2) "Regulated/dictatorial" flow in a standardised "communication
framework"? Uncharming idea - at first
- why not an asynchronous message-based structure on top of
a "wire", like w3?
- message passing "patterns", routing
- message format transformation
- connectors: TCP, RMI, HTTP, in-Container, bicycle courier, ...
- the usual: security, (failure) management, protocols/APIs, ...
http://i.msdn.microsoft.com/Cc487894.bddfbe7f-6ee2-4072-91f1-402c87ee92ad(en-us,MSDN.10).png
As we all know:
If there's one thing
you can trust,
it's imagery!
Yeah! Right!
Especially in the context of
ESB, imagery can be
misleading!
2. Escapism into technology
(A)Synchronous
Message Passing
MOM (JMS)
Business Integration
JBI
Adapter
Architectures
JCA
MOM (Message-Oriented Middleware)
David A. Chappell: Enterprise Service Bus, O'Reilly, 2004
Examples:
JMS/OpenMQ/ActiveMQ
MSMQ (MS Message Queue)
JMS (Java Message Service)
- Underlying EJB (Message Driven Beans)
- point-to-point (message queues)
- publish/subscribe ("bulletin board")
- guaranteed delivery
- synchronous/asynchronous
message
"patterns"
•JMS "on the wire"?
Use MDBs or the JMS API directly
Use a J2EE compliant container,
like GlassFish ("in-container" transport)
MQ (Message Queue) Systems
Apache ActiveMQ
JMS
+ "OpenWire" socket wrapper API
+ JCA compliance
Routing over Apache Camel --> EIP
Sun OpenMQ (aka Sun Java System MQ)
JMS provider in GlassFish 2.x
+ Clustering
+ JCA compliance
EIP?
Extension of WSDL MEPs (?)
Watch the title permutations!
EIP [http://www.enterpriseintegrationpatterns.com/]
Transactional
Clients
Guaranteed Delivery
Normalizer
Java Business Integration (JBI)
"JBI does not define a traditional application programming model.
Instead, it embraces a service-oriented approach to structuring
enterprise functions, where JBI plug-in components function as service
providers and consumers." [Java™ Business Integration (JBI) 1.0,
2005]
JBI Components
Implemented: https://open-jbi-components.dev.java.net/
Service Engines implement a service
Binding Components connect to external service
providers/consumers
Shared Libraries are what we think they are
all connected over the NMR
Sun OpenESB
JBI Container
+ Community-provided modules
+ open for EIP implementation (???)
Sun GlassFishESB
OpenESB dropped into GlassFish
Apache ServiceMix
JBI Container
+ JMX Container Management
+ JDBC
+ jetty (Servlet container)
Now add
Apache ActiveMQ
Apache Camel (Routing) [http://camel.apache.org/]
Apache CXF (Services) [http://cxf.apache.org/]
(Apache) Fuse [http://fusesource.com/]
Mule
3. Catharsis and finding ways to blame others
So, what's in an ESB?
Notice the question mark?
Hub to "virtualize" Message Passing
JBI +
wiring
EIP (ESB "mantra") for
Context-based Routing
Orchestration/Choreography (?)
I mean...
Right?
Wrong!
That's what's in an ESB Container!
ESB Container
ESB
ESB = (?)
A distributed architecture of ESB/JBI containers in
an enterprise (group) connected by
•
•
•
•
•
a reliable messaging infrastructure
smart but consistent routing
central (?) administration
in-place security protocols (WS-x)
anything else you can think of to make this
happen
ESB/JBI containers are just the operational
"backbones" of an ESB architecture!
Understanding ESB by looking at
OpenESB/Fuse/Mule/...
is like understanding the WWW
by looking at Apache httpd
Things you want to "google" today:
ESB and SCA
ESB Interoperability
OSGI
Things you want to "google" in 2010:
ESB Intermediation
ESB Protocol Bridging
ESB Data Transformation Service
A Word of Encouragement?
Bobby Woolf: ESB-oriented architecture: The wrong
approach to adopting SOA
"The problem is this: An ESB by itself produces no business value. An ESB
is a means to an end, not the end itself. An ESB is like the electrical wiring or
plumbing of an SOA. [...] An ESB without an SOA is like a road from
someplace nobody is located going to other places nobody wants to be."
"Don't build it until you need it."
http://www.ibm.com/developerworks/library/ws-soa-esbarch/index.html
A Word of Defiance?
"The recent buzz around ESBs is rivaled only by the ambiguity with
which the term is defined. While Sonic Software and Gartner
originally used the term to refer to the XML-enabled SonicXQ MOM
product (which was later renamed "SonicESB"), ESB has also been
used to refer to the message bus architectural integration pattern [...].
However, as a growing number of companies began marketing their
EAI and MOM products as ESBs, the term has generally been
associated with a class of product, rather than an architectural
pattern."
"Once WS-ReliableMessaging and other key Web services
framework standards are universally implemented, the need for
vendor-proprietary ESB protocol stacks will wither away."
http://uwf.edu/bowsnickiklewe/3letters.html
Download