SOA tools--virtually bridging the legacy divide Part I

Whatever method is used to create or develop them (Web services and so on), services--the integration interfaces between apps--are the smallest components of SOA environments. Those can be information-centric--pulling data to and from applications--or functional--linking or exposing functionality in one or more apps. Discrete services can be combined into what are called composite apps or services, which can in turn be combined into whole business processes, combined services governed by business process logic invoked at runtime.

In that way, services comprise a layer of functionality that links and controls but simplifies the complex functionality in legacy systems. Bloomberg says they are like a fixed set of buttons on the remote control whose interface controls the activities you'd otherwise have to invoke manually by opening up the back of the television and fiddling with complex wiring and the like.

One of the great benefits of services is that they can be reused, which eliminates development and integration time and cost in the long run, says Sandra Rogers, program director of SOA, Web services and integration at IDC (idc.com), and when they are changed, changes are automatically reflected wherever the service is reused. Popular early types of services are for information sharing between systems, she continues, such as order management, distribution and logistics--the kinds of services most implemented when Web services debuted.

SOA creation tools let developers create and combine services but not manage them at runtime. What's more, says Rogers, many automatically create services adhering to Web service protocols and such to make the process easier.

Deployment and management tools deal with more complex and dynamic activities. An SOA infrastructure is both the traditional IT infrastructure with legacy and new applications, servers, storage devices, network, etc., and the intermediary services linking and exposing functionality therein. Generally, deployment and management tools perform functions like interacting with services stored and advertised in registries (a common repository of services from which IT can check out services and reuse them--they expedite the search for services like a card catalog does for books in a library). The registries might advertise via metadata what each service does.

Other deployment tools, says Plummer, are integration brokers, which allow standards-based interoperability across applications for a subset of systems in the entire global enterprise infrastructure. Those are usually limited to one product set and perform functions like message routing and communication protocol and data format translation and transformation. Enterprise service busses (ESB), he adds, are similar tools that are more comprehensive but also more lightweight and enable standards-based interoperability across the enterprise. For instance, he explains, "You can plug middleware into the bus, and it translates messages into the proper protocols and formats, etc."

Services must also be managed--maintained as static code and managed as code behaving with code from other services. For example, there's a set of tools--which may be services in themselves--that manage the life cycle of services from creation through production, maintenance and retirement.

There are also tools for versioning services. "The service may change," Rogers explains, "and then you need to broadcast out to whatever parties are using it that there's been a change, or there may be varying configurations where you may not want to use that changed version, so you have to indicate to users whether it's a new service or just a new version."

Then there are tools that excel at monitoring and managing the dynamic behavior of services while just in production. Those deal with the interaction of services, for instance, and tell you such things as whether the message the service transmitted got to its destination across connected services.

Exactly because services are interdependent (a change in one service can change the behavior of the composite service or process of which it's a part), Rogers says that change management is an increasingly important, but not yet automated, operation in an SOA environment, and tools are bound to evolve that better handle this activity too. Rogers says tools also exist for managing processes--both their state (how far a transaction has progressed through a process) and life cycle--as if they were services. Process "orchestration" tools are first required to provide workflow definitions (the logic) that connect pre-existing services. That can get especially tricky because the process is comprised of multiple services and can span multiple applications, other processes comprised of services, and extend out to other organizations with yet other disparate apps and processes.