Composite Materials

Tuesday Jun 15, 2004

The Role of Metadata in JBI

Metadata plays an important role in JBI. Metadata has two major uses:

Service description. A service describes itself, using WSDL 2.0.
Message description. Extra information about a normalized message.

Services are described using WSDL. The description includes the basic stuff of how the service is invoked (message exchanges), but can also include more esoteric data. JBI's so-called normalized message includes a message context that is a container for more (you guessed it) metadata. This includes simple things (like the address of the requester), and more interesting things, like security information and even transaction identifiers.

Both types of metadata are extensible, meaning that the JBI spec doesn't have to spell out every detail for every possible use case. Plug-in components are free to extend the basic metadata in ways that may not be understood by all other components, but which provides for extended interoperability between those components.

For example, an ebXML binding component and an ebXML BPSS service engine may use extensions to the normalized message context data to communicate ebXML-specific information, such as Service/Action names and CPA identifiers. If you don't grok ebXML, the basic point is: there are technologies needed in the integration world (and the SOA universe in general) that must share specialized, technology-specific metadata in JBI's message-passing model. JBI cannot specify all the technologies that possibly can be used in an integration solution based on JBI, and thus must allow for the unknown. Extensible metadata is the ticket to controllable, flexible extensions to the messages (and services) in JBI.

Posted at 06:56PM Jun 15, 2004 by rtenhove in Java Business Integration |

Wednesday Jun 09, 2004

Service-Oriented Architecture

Service-oriented architecture (SOA) is the latest "must have" in the competitive world of buzz-word compliance, er, enterprise software. What's it really all about? One word: decoupling.

Lessons are learned the hard way in most industries; software, particularly enterprise software, seems to compress a lot of such learning into short time spans. The big lesson reflected in SOA is that you can't treat your enterprise IT system as a big, undifferentiated wad of software , composed of dozens (even hundreds) of interconnected pieces. It may work, but it is fragile. When a single functional chance is introduced in a BUWOS system, many of the pieces comprising the system must be changed. This a Bad Thing, as experience has shown.

A better way is to split things up to avoid interdependencies, assuring that changes are confined to a managable number of components, usually just one. Good enterprise architects have been doing this for years, but now we have a trendy new acronym for this pattern: SOA. SOA has more promise than being simply the latest pattern name to add to our catalogues: it is helping shape standard software products, including EAI, and is even influencing the latest public standards.

SOA is a pretty simple concept: it is a collection of services that intercommunicate in a decoupled fashion. That is, a service can be invoked by any service consumer (including other services), but the service generally doesn't "know" (or care) who is calling [1]. The dependency is one-way (consumer depends on the service). In modern parlance, SOA implies the use of a technology-neutral messaging infrastructure linking services to consumers, such as XML over HTTP or JMS, thus eliminating a form of technological coupling that previous approaches to SOA embraced.

This decoupling makes services blind to applications that use them. This gives us the benefits listed above.

A nice collection of SOA information can be found at BEA's DEV2DEV site.

[1] Not to minimize the role of security in authenticating and authorizing service access, but this can be addressed separately from service use.

Posted at 10:52AM Jun 09, 2004 by rtenhove in Java Business Integration |

Monday Jun 07, 2004

Java Business Integration

I work in web services integration. You well might wonder what that means (WSI, that is, not working!). WSI is a Sun software product group that concentrates on solving enterprise application integration (EAI) and business-to-business electronic data interchange (B2B EDI) problems using standard products that we create, sell, and support.

EAI and EDI problems cover a broad spectrum, ranging from simple point-to-point messaging solutions (to get application A to interoperate with application B), to large collections of applications (and trading partners) being turned into business processes through using sophisticated work flow engines serving to orchestrate everything.

EAI encompasses a huge range of applications, platforms, and technologies. The main challenges we face are:

Application adaptation. Get applications that were never meant to interoperate with other applications, or perhaps interoperate in standard ways, to interoperate. This includes both packageware and home-grown applications
Scaling. Getting two applications to interoperate is a tractable problem; getting 50 to interoperate is a far different problem, due to the (N-1)^2 possible connections.
Decoupling and state management. Combining existing applications to create new business functions often leads to new points where business decisions must be made, and extra state information is created. This can lead to highly coupled applications, where new state and business logic must be added all affected applications. This can lead to a huge maintenance headache. Much of Sun's current integration technology (Forte Fusion, or Integration Service EAI Edition) is built around approaches that separate business process logic from the applications, including state information.
Managing change. The typical enterprise is a dynamic beast. Applications are added, changed, retired. Mergers bring in a flood on new systems to be integrated or phased out in a controlled fashion. New technologies are deployed that must be integrated into the existing infrastructure. Business processes are changed regularly. All of these changes must not disrupt on-going processes, applications, and the connections between them.
Reliability. The integration system becomes a key piece of the IT infrastructure, so reliability (not to mention managability) become key concerns.

So how do we control this complexity? Our main approach is embodied in a new Java standard known as Java Business Integration (JBI), or JSR 208 to its friends. We are seeking to move toward a standards-based service-oriented approach to integrating applications and EDI. The key abstraction is embodied in WSDL 2.0. Applications are modelled as WSDL services, using XML-based message exchanges. I'll elaborate on this theme in a subsequent 'blog.

Posted at 05:38PM Jun 07, 2004 by rtenhove in Java Business Integration |