Closely integrated mix of Java, XML gives nonprogrammers a leg up on service creation

The basic goal of an SOA is to make resources available on a network in such a way that the resources are accessible by client applications without the applications having to resort to low-level (language- or platform-specific) APIs. The resources often have processing capabilities and are therefore referred to as services. In that sense, accessing a service looks a lot like making a very elaborate remote procedure call.

Enterprisewide, broadly available, and easily extensible services — the Holy Grail of SOA — is the goal to which Software AG’s crossvision suite aspires. The suite is a collection of services, tools, and components held lightly together by CentraSite, a sort of combination application server, management system, and repository.

The crossvision suite is an ESB suite, and its XML language is BPEL (Business Process Execution Language). As do some ESBs previously reviewed by InfoWorld, crossvision can talk to JMS, but it can also receive documents from other sources (HTTP, e-mail, even a file).

The suite is “complete” in that you don’t have to have your own Web server or database. CentraSite provides the persistence back end, and Apache/Tomcat is built in — at least, I didn’t have to install them separately. The Service Orchestrator IDE also has simulation capabilities, so you can test a service before deploying it.

Crossvision's Information Integrator provides the means for gathering data from disparate sources and organizing that data in such a way that its consumers can translate the data into contexts appropriate for their needs. In other words, Information Integrator helps consumers go beyond simply rearranging data, Information Integrator helps them draw inferences from it.

The duty of the Legacy Integrator can be largely deduced from its name. It makes the data (e.g., VSAM) and applications (e.g., those written in PL/1 and COBOL) of yesterday available to the applications of today. It also provides wrappers that allow those legacy applications to access modern resources such as Web services.

With Business Process Manager, you can describe the data involved, resources required, role-responsibilities granted, and other characteristics that define a business task. What makes the Business Process Manager actually useful is that it participates in the execution of the tasks so defined -- for example, it will see to it that information is routed to the appropriate recipient.

Components include Information Integrator, Legacy Integrator, Business Process Manager, Service Orchestrator, and Orchestrator Studio. For my review, I focused on the parts of crossvision that a creator of new services will interact with the most: CentraSite 2.1, Service Orchestrator 3.1, and Service Orchestrator Studio 3.1.1.0.

CentraSiteand Orchestrator

CentraSite and Service Orchestrator are the two essential chambers of crossvision’s heart. All roads lead to CentraSite, which serves as the management and control center for SOA efforts. Orchestrator is the runtime engine of crossvision services, and Orchestrator Studio is the IDE that allows you to create, debug, and deploy those services.

A combination registry and repository with a bit of application server thrown in, CentraSite acts as both broker — managing a directory of available services — and a kind of database for those services. In addition, when you create a project, CentraSite manages storage of all the resources that comprise your service. (Fujitsu and Software AG jointly developed CentraSite.)

Viewed from the outside, Service Orchestrator appears as a bicameral engine that responds to the arrival of messages (documents) at a crossvision installation by activating the applications to process those documents. One half is the Orchestrator runtime engine, a component factory for the executable elements of a service. The other part is a Web application, which manages document routing and provides the portals to the outside world through which documents enter and leave.

Click for larger view.

Orchestrator acts like a kind of document digestive system. A document arrives, delivered via e-mail, JMS, a SOAP message, or HTTP; its arrival triggers the execution of code that examines characteristics such as the document’s name, extension, origin, and specific contents to determine how it is to be processed.

After Orchestrator establishes the “how” of the processing, it then summons the appropriate code to do the actual work. This work could be as simple as shuttling the document to its destination or as complex as extracting disparate data from various portions of the document, forming a brand-new doc with it and depositing the result into an e-mail inbox.

Orchestrator’s documentation refers to the source code as a “sequence,” which is a mixture of Java components and XML. The flow of control is specified in the XML, and the Java components — dubbed “Orchestrator Components” — perform the actual heavy lifting. Orchestrator’s runtime is itself an Orchestrator Component called a Sequencer Component, and a source-code file is called a Sequence Document. A Sequence Document is a collection of processing elements that you can call on in a manner similar to the way you would call methods in an API.

In Orchestrator, the “methods” are the Java components, and messages are the documents. The XML acts as executable glue that binds the processing elements, and orchestrates their behavior into a usable program. This glue includes fundamental sequence control (execute statement A, then execute statement B) and decision making (that is, if/then statements).

Orchestrator comes with approximately 30 built-in components that cover just about every aspect of document processing and transmission protocols. Ordinarily, you never need to “go inside” a Java component; all the dirty work has been done for you. However, Software AG does provide development tools if you want to create your own components.

Sequence creation

To create a service — that is, to write the XML code for a Sequence Document, debug, and deploy the result — you must visit the Orchestrator Studio. You can build a project’s source graphically or, if you prefer old-school text-based source code, as a series of XML statements.

The Studio’s graphical designer is what really makes crossvision accessible to less-experienced programmers. It can represent a sequence document’s XML as either a flow diagram or a tree diagram. You edit statements by clicking on the nodes of the tree and altering properties; add new statements by clicking on predefined “insertion points” that appear in the graph as red, highlighted nodes placed on the arcs between statement blocks.

I found Studio very easy to use. It has a project-based paradigm; typically, a project translates to a single service that will ultimately be deployed to a crossvision site. After you get the hang of Software AG’s XML language, the rest of the learning curve is pretty much the same as any large-scale system. You have to explore that API — sort of like exploring a garage full of tools — to figure out what’s available to you.

When your sequence document is ready to test, you can run it through the Studio’s debugger. The debugger moves easily between the text and graphical representations of the application. You can set break points, single-step, view component properties, examine the effects on the document at each step, and so on.

After you’ve decided your new service passes muster, another few clicks in the Orchestrator Studio will deploy your new service to the crossvision installation, and it’s ready to be used.

At your service

Software AG’s crossvision is, if anything, extensive. This is simultaneously a strength and a weakness. On one hand, the odds are very good that whatever your specific SOA-related needs are, some constituent of crossvision will meet them. Aside from its impressive integration, crossvision’s graphical UI and pre-built components combine to make the construction of an SOA site something even less-experienced programmers can do.

Click for larger view. On the other hand, it is easy to get lost inside crossvision. That problem is exacerbated by the fact that the names of the component products recently changed, but the documentation — and even some file names haven’t caught up. For example, if you come across the name Mediator — Service Orchestrator’s previous name — it’s difficult to know whether you’ve stumbled onto the description of a behavior that no longer exists or simply a spot in the documentation that a copy editor missed.

These are easily corrected problems, however. And despite its somewhat complex setup, crossvision’s payoff comes in its ease of use. Working with Orchestrator Studio was straightforward; I had no difficulty modifying example sequences and deploying them to the crossvision Web site on my system.

Any organization with large volumes of information sequestered in disparate apps, or documents whose lifetimes do not reach past their trajectories from source to destination, would do well to examine Software AG’s crossvision. Based on the exercises I put a portion of it through, I’d say it provides the whip you need to corral your documents, as well as all the morphing tools necessary to transform data from those documents into the formats your enterprise requires.