Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The bottom line is that you should be able to deploy standards-based services, using standards-based ESB functionality, exchanging standards-based messages. This means your code and configurations should be portable across products, it should be easy to integrate with other environments, and it should be easy to find tools to support development, testing, monitoring, and tuning.

Are there proprietary protocols in ServiceMix?

Depends on what you mean, I guess. There are a lot of Spring-related features, and Spring is clearly not an OASIS standard, but we hardly think of it as proprietary. You can simply ignore these features and choose not to, for example, use Spring Beans as services if you'd prefer not to.

Different JBI service engines included with ServiceMix may let you develop services, routing logic, transformation logic, etc. in a variety of formats. Just to give a few examples: Drools rules, XSLT transformations, OSWorkflow workflows, Groovy scripts, or JavaBeans (POJOs). While you might not normally be able to deploy say a Groovy script in another ESB, you could always deploy the servicemix-script JBI component to another JBI-compliant ESB and then your Groovy script would be deployable there too.

Basic Architecture

JBI: Normalized Messages, Service Engines, Binding Components, oh my!

...

Spec

Purpose

Support

WS-Security

Authentication, Encryption, Digital Signature

Yes, for HTTP and CXF binding components and subsequent authentication/authorization

WS-RM

Reliable Messaging

Yes, for CXF binding component

WS-Addressing

Addressing

Yes, for HTTP, JMS, and CXF binding components

WS-Policy

Policy Management

Yes, for CXF binding component

WS-Notification

Events

Yes, see the WS-Notification documentation

WS-TX

Transactions

No, though WS-TX headers can be passed through as normalized message headers for services to handle

WSDM

Management

No, JMX is used instead

WS-Management

Management

No, JMX is used instead

...

  1. Standard JBI routing, for example, a binding component specifies a particular service engine to dispatch to, or the bus matches the Normalized Message XML content to a service's WSDL
  2. Content-based routing using XPath expressions on the Normalized Message XML content
  3. Rules-driven routing using the Drools servicemix-drools service engine
  4. Script-driven routing using the Scripting servicemix-script service engine
  5. Java code can perform routing using the ServiceMix POJO Support servicemix-bean service engine
  6. You can drop in a JBI-compliant BPEL service engine (such as Ode to perform routing (among other things)

...

Many of the same options as in the routing answer above. For example, messages can be transformed with XPath/XSLT, or via a script like Groovy, or via a Java class, or BPEL, etc.

Which options allow a declarative approach for routing/transformation?

...

Other options include using Scripting languages such as Groovy, which in addition to routing and transformation, can save state across requests and therefore perform at least some orchestration (though the state is not maintained across server restarts).

You could also write custom Java code to perform orchestration.

...