|
Papers, articles and presentations Read what the team and others have to say about Swordfish |
|
|
Read about the folks behind Swordfish |
|
|
Find everything you need to get started with Swordfish |
|
The Enterprise Service Bus (ESB) has always been the cornerstone of any vendor's SOA strategy. In the past, however, ESBs have often failed to help leverage the full value of SOA because of their large footprint, the centralized architecture and the considerable effort required to properly integrate them into an existing application landscape.
Swordfish — the next-generation ESB
This is why Swordfish takes a different approach. Built upon proven open source components such as Apache ServiceMix and Apache CXF, Swordfish provides an extensible framework that allows application developers and system integrators alike to build their own ESB — taylor-made to their requirements. But Swordfish is more than just a framework: following the Eclipse tradition of providing 'both extensible frameworks and exemplary plugins', the Swordfish project also aims at delivering Enterprise-grade plugins, turning it into a full-fledged open source ESB that takes the 'E' seriously. In order to illustrate the advantages of Swordfish over other open source ESBs, we'll highlight some of the features that have grown out of years of SOA experience gained in real-world enterprise settings.
The first feature that we're going to take a closer look at is the possibility to integrate a Service Registry and dynamically bind services at runtime. What this basically means is that in Swordfish, contrary to many other ESBs, there doesn't have to be a static relationship between components using a service (consumers) and components providing a service (providers). In fact, a consumer refers to a provider by means of a logical identifier that clearly signifies the service's interface together with a statement on the consumer's non-functional capabilities and requirements which is called a Policy. Given these two pieces of information and its own database of existing service providers along with their respective Policies, the Service Registry selects a matching provider and calculates an effective Policy that governs all future communication between consumer and provider. The advantages of this approach are quite obvious: consumers and providers are even more loosely coupled and their non-functional characteristics can be easily changed without touching a single line of business application code.
Another notable point about Swordfish is that it's based on an architectural pattern that is often called 'Distributed ESB' or 'Federated ESB'. What it basically means is that in order for two service participants to communicate with each other, no central components are needed after the initial communication set up. The advantage of this approach over 'classical' Hub-and-Spoke integration architectures is quite obvious: There are no central components that are likely to become a performance bottleneck over time, so the whole system is much more scalable and grows with the users' requirements without forcing them into more and more hardware investments as they progress on their SOA adoption path.
The potential downsides of a federated approach — increased administration and management complexity — are compensated for by a remote configuration mechanism that allows administrators to configure a large number of distributed Swordfish instances conveniently an efficiently and extensive monitoring capabilities. Monitoring is especially important in the context of Business Process Management (BPM), since fine-grained monitoring events are a prerequisite for a comprehensive Business Activity Monitoring (BAM), often based on a Complex Event Processing (CEP) approach.
OSGi and JBI inside
The Swordfish framework is based on standards that are relevant in the SOA space today. On the lowest level there's OSGi, or more specifically, Equinox, the Eclipse Foundation's OSGi implementation. OSGi provides among other things the component model, a deployment mechanism for modules and a clean class loading system. On a higher level, Swordfish is using a subset of the JBI standard for messaging abstraction and message routing between components. Originally, JBI 1.0 included its own component model and deployment mechanism, but this was dropped this in favour of OSGi. This is pretty much in line with what used to be consensus in the JBI 2.0 working group and what‘s already implemented in version 4 of Apache ServiceMix, Apache's JBI container which serves as the core message routing engine for Swordfish. But ServiceMix doesn't only provide routing, it also includes a large number of ready-made components that can be used out of the box to interface to business logic or transport channels and protocols.
So, in a nutshell, Swordfish is a framework that builds on ServiceMix and extends it with features that are required for Enterprise SOA. The Swordfish core uses public extension points in ServiceMix in order to hook into the message flows inside the Normalized Message Router (or NMR).
The central concept of hooking into the NMR is the Interceptor, which is a piece of code that intercepts message exchanges as they go through the NMR and operates on them in some way. The Java interface that represents an Interceptor is part of the Swordfish API and can be implemented by Plugins that contribute Interceptors for special purposes, for example message validation, transformation and so on. The order in which the available interceptors are actually applied to a message exchange is defined by a processing plan which gets calculated by a component of the swordfish framework core called the Planner. The exact way how planning is performed is again something that should be user extensible, so there's an interface in the API called PlannerStrategy that Plugins can implement. One example of such a strategy could be one that knows how to evaluate a Policy that is included inside the message exchange. In addition to custom interceptors there are some cases of special purpose interceptors, for example an interceptor that takes care of looking up a service in a service registry and re-routing the exchange accordingly. The basic (JBI-related) behaviour of this interceptor is part of the core implementation, but the details of how exactly the lookup is being performed can be supplied by a plugin that implements the ServiceResolver interface in the framework API. The same pattern is applied all over the public APIs.
Registry & Repository for Application Developers
We've already touched on the merits of using a Service Registry to resolve service endpoints at runtime briefly above. But a Service Registry is more than just that: It essentially provides a comprehensive overview of the services existing within a Service-oriented Architecture and plays a key role in fostering service reuse, one of the main benefits of the SOA paradigm. The real power of a Service Registry becomes obvious when services are composed into more complex services by means of a process orchestration facility: If the service interfaces have been carefully defined with reuse in mind, creating a complex composite service can ideally be merely a matter of moving and connecting boxes in a graphical editing environment.
In the future, the Service Registry will be complemented by a Service Repository that allows all SOA-related artifacts that are created as part of the SOA artifact workflow (such as service interface descriptions, policies etc.) to be stored in reliable and traceable manner. Features like versioning, the possibility to define approval workflows and analysis and reporting capabilities enable Enterprises to set up and enforce the governance processes that are often deemed crucial for successful SOA adoption.
If you're interested in the actual fish and the story behind the project name and the logo, read this.
