Matt RaibleMatt Raible is a Java Champion and Developer Advocate at Okta.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

[CSS 2006] To ESB or not to ESB?

Do you have to have an ESB to have a SOA? I'm sitting in Denise Hatzidakis's talk titled "To ESB or not to ESB" as requested by Mick Huisking. Dinese is the Chief Technologist at Perficient, Inc.. It's interesting, on her opening slide she has a e-mail address, as well as an address.

"SOA stands for Same Old Architecture"

This talk focuses on using an ESB and how to build it. There's a lot of ESB products out there. An ESB is not about a product - it's about what kind of connectivity you need between your systems.

An ESB is an "Architectural Pattern". In fact, it's possible to construct service buses from a variety of different underlying integration technologies.... The architecture pattern remains valid and is a guiding priciple to enable the integration and federation of mulitpler service bus instantiations

--Rob High, SOA Foundation Chief Architect

An ESB enables standards-based integration between loosely-coupled apps and services within and across:

  • services oriented architectures - where distributed applications are composed of granular re-usable services with well-defined, published and standards-compliant interfaces
  • message driven architectures - where applications send messgaes through the ESB to receiving apps
  • event driven architectures - where applications generate and consume messages anonymously

"SOA - it was EJBs a couple of years ago"

When implementing a "Virtual Provider", who is responsible for building that?

  • The Service Consumer?
  • The Prospective Service Provider?
  • The Service Broker?
  • The Internal Enterprise-wide Governance Body on SOA?

The Service Consumer may have to foot the bill or agree to split it with the prospective provider. The provider may not be ready or willing (no funding or not a priority) to build a service interface for the consumer.

The biggest barrier to ESB implementation success is often political - it rarely has anything to do with technology.

There's 3 core layers in an ESB:

  • Micro Composition/Decomposition & Customized Routing: Protocol mapping, pattern recognition (where you deal with the messages), message validation, service brokering
  • Enterprise Service Bus - Core Layer
  • Bus Connections: HTTP, JDBC, etc.

The key USB purpose is Routing Service Requests. The ESB proxies the means to manage the service infrastructure and the capability to operate in today's distributed, heterogeneous environment. Denise said she told IBM not to build an ESB, because it's not about the product, it's about the architecture. However, apparently one CEO wouldn't buy the IBM Stack because "ESB" wasn't on the purchase order.

ESB Capabilities: Communications, Service Interaction, Integration (databases, legacy, etc.), Quality of Service, etc.

An ESB leverages underlying communication fabrics of SOA infrastructure - providing on-ramps and off-ramps. Typical requirements are: HTTP (SAOP/HTTP, XML/HTTP), MQ (SOAP/JMS/MQ, XML/MQ, text/MQ), Adapters, WS-I, WS-Security, RAMP. Web services are a key enabler of SOA, but they certainly aren't a requirement.

Message Models

  • Describe messages exchanged with requesters and providers
  • Based on Meta-models
  • An ESB supports one or more message meta-models
  • An ESB supports multiple message content models
    • Can include industry standard model as well as enterprise specific models
    • Can include weakly-typed models

Canonicalize on the message format itself (using something like SOAP or JMS, just agree on which one). Let the business logic reside in the message itself. You will want an ESB that supports multiple content models.

Mediation Flows: process messages exchanged between requester and provider via ESB (large grained, moderately reusable, constructed from Mediation Patterns.

Mediation Patterns and Message Processing: Allow manipulation of messages during a message flow (provided by a mediation framework).

Mediation enables Service Virtualization of identity via routing, interaction vi conversion and interface via transformation.

Mediation enabled Aspect Oriented Connectivity - Security & Management, Logging Auditing, Dynamic Routing, etc.

Example Mediation Patterns: request/response, request/multi-response, event propagation, distribute, correlate, monitor, gateway, transform - log - route.

Connectivity, Message Model and Message Flows are the 3 main components in an ESB. What's not in the ESB? Everything else!

Do you have to have an ESB to do an SOA? No.

Do get a good ROI from your SOA, you need to have a loose coupling in your implementation. Tighter coupling tends to cost more over time, but looser coupling requires greater investment up front. There's more design work and more implementation work that happens in the beginning. You might not need a full-blown ESB (is this starting to sound like EJB containers), you can probably do an SOA architecture with your current tools and technologies. When I was at Xcel Energy last year, a bunch of good friends built an ESB on top of JBoss - using Quartz, JMS, EJB, Spring and Hibernate.

What does "loosely coupled" mean? It's not a well defined term. We now what "coupled" and "decoupled" means, but there's a lot of grey in between.

At this point, my battery began to die. Denise was a good speaker, but she had a lot of information on her slides - makes a real-time blogger's fingers hurt. ;-)

Tonight, I'll be attending the Q & A, followed by a Spring BOF. Should be fun.

Posted in Java at Oct 24 2006, 06:08:48 PM MDT 1 Comment

Thanks for checking this one out for me too.

Posted by Mick Huisking on October 24, 2006 at 08:38 PM MDT #

Post a Comment:
Comments are closed for this entry.