Archives for July 2005

Patricia Seybold Group ESB Evaluation Framework – Free!

July 30, 2005 By brenda michelson

I’ve just wrapped up creating a 20-plus page enterprise service bus (ESB) evaluation framework. The framework presents criteria with required (and suggested) capabilities in 6 areas:

Integration Scenarios. Integration scenarios represent the functional requirements for the enterprise service bus. Specifically, the types of scenarios you can deliver, the types of resources you can connect, and the building blocks (integration patterns, integration services) provided to facilitate scenario delivery.

Design, Development and Deployment. Design, development, and deployment looks at how you deliver integration scenarios. This includes tools for integration providers, integration consumers, and testers. Feeding the integrations tools is a repository.

Management and Monitoring. Management needs to occur on two levels: the integration scenario (application) level and the ESB infrastructure (systems) level. Monitoring needs to occur on three levels: the integration scenario, the ESB infrastructure, and the business level.

Architecture. The objectives of the architecture evaluation are to understand how the ESB works, its fit in the target (your) environment, and with your architecture. To do this, you need to look at the ESB’s organization, the interoperability of its parts, deployment environment requirements, enterprise infrastructure dependencies (and conflicts), and its capabilities for quality of service and quality of protection. In addition, to provide insight on architectural direction fit, look at the architectural premise of the solution––in other words, what are the ESB creator’s views on the challenges of integration and the future of services?

Product Viability. Product viability criteria consider the business aspects of enterprise service buses and their suppliers.

Company Viability. A company’s history and current financial statistics are key markers for its future viability.

Anyone who has ever evaluated and purchased software knows this is an important tool to have, but a drag to create. So, since I did the work, and it’s available free, I want other people to use it. (Re-use is good).

Feel free to download the ESB evaluation framework from the PSGroup site, pick out the criteria that are important to you, and ask vendors how their capabilities match up.

In all cases, try before you buy!

Java Business Integration (JBI) – A spec for vendors, benefits for the enterprise

July 16, 2005 By brenda michelson

This week I spent some time looking into the recently approved and industry supported Java Business Integration specification, JSR-208.

Beyond learning that the JBI/SOA session was the most attended session on Day 1 of JavaOne (listen to Tuesday 6/28 8:00-9:30), and that the blogosphere is generally unconcerned with IBM and BEA’s JBI abstentions (as am I), I learned that JBI offers some real advantages for the enterprise.

In this posting, I offer some excerpts (JBI basic architecture and enterprise advantages) from my PSGroup JBI report. For the full (currently free) report, go here.

Focus of the JBI. The JBI specification is a vendor specification directed at providers of integration software and SOA infrastructure. The specification articulates the architecture for building integration software that is actually a framework for pluggable, interactive, integration components. Essentially, the JBI outlines a service-oriented architectural blueprint for integration infrastructure.
The Java in the JBI refers to the integration software’s runtime. It runs in a JVM. The JBI is not part of the J2EE specification. This point is important for enterprises to understand for two reasons. First, your J2EE application servers will not come with JBI containers inside. Second, the use of JBI integration solutions is not limited to pure J2EE shops. JBI solutions will provide integration between Java, .Net, legacy and application package services. The Java implementation is essentially a black box, hidden from the developers and integrators using the integration software.

While JBI is a vendor specification, the establishment (and acceptance) of standards for integration infrastructure is an important (and long overdue) milestone for the enterprise. It’s akin to the ratification of the first J2EE specification that resulted in standardized application infrastructure containers.

Beyond the pure existence of the standard, the service-oriented architecture of the JBI will resonate with both infrastructure providers (large, small, commercial, OSS) and enterprise IT professionals, each of whom are increasingly focused on interoperability, partnerships/collaboration, and choice.

The Basic JBI Architecture

At the highest level, the JBI architecture centers on two concepts: pluggable components and normalized message mediation.

Pluggable Components. The JBI authors recognize that enterprises have unique integration scenarios, but as you break down those scenarios into integration services, resource types, and connection protocols, there are commonalities. For instance, many integration scenarios involve protocol and data translation, and routing. However, the types of protocols, and the data formats to be translated (both source and target) vary greatly. Of course, data translation is just one type of integration service; others are business process execution, service orchestration, authentication/authorization, data validation, event publication and subscription, etc.

The JBI model, then, needed a way to support a (seemingly) infinite list of protocols, and integration services. The JBI solution, and cornerstone of the JBI architecture, is pluggable components. The JBI provides for a plug-in framework that
accepts software components from a variety of providers as long as the components are JBI compliant.

There are two types of JBI components:

Service Engines (SE): The service engines provide the actual integration services, such as data translation using XSLT. In that case, the service engine hosts an XSLT engine, and contains artifacts (style sheets) for particular data translations. Adhering to SOA, the integration services may be service providers or service consumers. Since almost anything could be a service engine, including a Business Process Execution Language (BPEL) engine or J2EE container, the JBI is often referred to as “a container of containers.” Given the container nature of the service engines, you may deploy business services, such as a process-oriented service, into a target container in the JBI.
Binding Components (BC): The binding components convert protocol and transport specific bound messages to a normalized XML message format (and vice versa). The service engines communicate using the normalized message
format. The JBI specification requires a WS-I binding component, but since binding components are “pluggable,” you can install JBI-compliant BCs for whatever protocols and APIs are present in your environment.
JBI Mediator. The binding components and service engines do not interact directly. Following solid architectural constructs, there is a mediator, which handles interactions between binding components and service engines, and between service engines. This mediator is the normalized message router. The normalized message router accepts normalized XML messages from the binding components (dropped into delivery channels), and invokes service engines with WSDL-based messaging. The mediator also has an outbound role, picking up messages from a service engine’s delivery channel and dropping them into the delivery channel of a binding component.

Why JBI is Good for the Enterprise

For the enterprise, the JBI, and the advent of service-oriented integration solutions, is as the saying goes, “all good.” Of course, this is only release 1.0 of the JBI, and like any specification, some areas still need fleshing out, such as best practices for in-JBI service deployment and collaboration, and specifications for distributed JBI.

However, even at this early stage, the advantages for the enterprise include:

First, the obvious. Standards bring choice. Enterprises won’t be locked in to a particular vendor or product suite.
The cost of enterprise integration technology will be more palatable, and manageable. After choosing a JBI environment, enterprises can add integration services and adapters in an a la carte fashion.
The open source JBI offerings (ServiceMix ESB, Sun’s Java ESB, FiveSight’s BPEL engine) allow enterprises to freely experiment with the technology prior to making financial outlays or commitments.
Service-oriented approach to enterprise integration technology.
Opportunity to reuse integration services, across integration scenarios, and over time, possibly application solutions. If application software vendors adopt JBI infrastructure (SAP AG and Oracle participated in the expert group), enterprises can standardize on one rules service, one BPEL engine, one workflow engine, and so on. No longer will enterprises have to deal with the added complexity of “infrastructure inside” application packages. Using JBI, enterprises would be able to install their chosen service engine in the application vendor’s software stack.
Of course, as with any technology, you need to do your own exploration, and make informed choices for your business. But, if you are pursuing a service-oriented architecture strategy and/or are tackling integration initiatives, you might want to start “playing” with some of the JBI OSS and reference implementations.

“My” SOA definitions–What I mean when I say “service-*”

July 15, 2005 By brenda michelson

I spend a lot of time in the service-oriented world. Sometimes as a practitioner, other times as an advisor, and other times still as an interested observer. Over the course of time, I’ve settled on a set of definitions for some commonly (but inconsistently) used terms. For the full deal, in a formal manner, see my PSGroup Service-Oriented World Cheat Sheet, which is being published in installments on Nextslm.org . (No guarantee how long the piece will run).

For those interested in a quick take, I’m posting the terms here, because it will make my subsequent postings (of which I hope there are many) more understandable.

What is a Service? Simply stated, a service is a thing that fulfills a purpose. A service is, in essence, a “worker,” employed to achieve a specific end goal for a requester. The end goal may be small in scope, such as retrieving information, or large in scope, such as executing a business process. Most services are in the middle, completing a function. The scope of a service is referred to as its grain, or level of granularity.

What kind of thing is a service? A service is an abstract resource that has a name, a job, job tasks, contact information and policies regarding security and service levels. To use (request) a service, you send a message—in accordance to the contact information and policies—and then (if appropriate), receive a reply message.

A service’s job. The job of a service is limited to a single distinct business concept, function, or process. This characteristic is referred to as the bounds of a service. Finding the correct bounds is a key factor in service definition. A service may call upon other services if it needs assistance to complete its job. This service-to-service relationship is called collaboration.

Service Collaboration. Services collaborate through orchestration, business interaction, or interception:

Orchestration is a type of collaboration in which the primary service directly invokes other services. The primary service knows the sequence of actions and the interfaces, responses, and return states of the called services.

Business Interaction is a type of collaboration in which some coordination mechanism knows the sequence of actions, possible states, and paths of interaction among one or more services. The business interaction is usually long-lived involving requests/messages from multiple parties. The coordination mechanism may be a business process execution engine, a workflow engine, an event handler, or an enterprise service bus.

Interception is a type of collaboration in which an intermediary service receives and acts on a request (or reply) and then forwards the request (or reply) to the original target. Interception is used to perform common functions such as security, policy, audit, and translation. In many interception scenarios, the requesting and providing parties are unaware of the intermediary service.

Service Types. Not all services are simple information-oriented requests/replies. Beyond request/reply, a service may be a worker, a monitor, an agent, an aggregator, or even a process.

Service-Orientation. Service orientation is an architectural concept that refers to the loose coupling of a service (an abstract resource with a defined job) and its provider (the physical asset(s) that perform the job tasks). A requestor only knows what the service’s job is and how to request it. The service is the only one that knows its implementation.

Service-Oriented Architecture. SOA is an IT architecture strategy for business solution (and infrastructure solution) delivery based on the concept of service-orientation.

SOA Styles for Business Solutions. The two primary styles of SOA used in business solution development are composite application development and flow.

Composite Application Development. In composite applications, the user interaction drives a request for one or many services. Most of the service invocations are synchronous in nature. A composite application typically serves
one business domain. Composite applications are often delivered in a portal.

Flow. In flow, business process and/or events drive the service invocations. The service invocations are a mix of asynchronous and synchronous; however, the overall flow is usually long running and asynchronous. A flow typically crosscuts business domains and often extends outside of the enterprise.

Business Process-Driven. In business process-driven architecture, the flow of work, as a series of activities, drives the requisite application and human behavior to complete a business transaction or process. The process is typically long running in nature, involving multiple parties and/or applications within an enterprise or across enterprises. In business process-driven SOA, a business process may implement as a service, and/or a business process step (activity) may invoke one or more services.

Event-Driven. In an event-driven architecture, a notable thing happens inside or outside your business, which disseminates immediately to all interested parties (human or automated). The interested parties then take action. The event-driven action may include the invocation of a service (thus event-driven SOA) or the triggering of a business process or workflow.

SOA Environment. Refers to the collective environment that allows services to be defined, developed and used by other services, and to be assembled into solutions by adding process, interaction mechanisms, user interface, and/or rules. In addition to service development and solution assembly, the SOA environment provides runtime and management functions such as service discovery, policy definition and enforcement, quality of service (performance, availability, reliability and load), transaction management, audit, and usage metering.

Archives for July 2005

Brenda M. Michelson

Recent Posts

Recent Tweets