Open For Business - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
IoT
Software // Information Management

Open For Business

Preparing for a complex, event-driven future, leading-edge businesses are pushing the software community to focus application development on a vision of business-driven, integrated processes. The conclusion of our series focuses on key components.

Preparing for a fast, complex, event-driven future, leading-edge businesses are pushing the software community to focus application development on a vision of business-driven, integrated processes. The conclusion of our series addresses key components of the solution.

The goal of a service-oriented architecture (SOA) is to create a loosely coupled IT infrastructure. Ensuring that it adheres to this goal is of paramount importance. In the first two parts of this article, I set the scene for SOA and described three of its five major components: the integration framework, synthesized computing, and the abstracted service taxonomy (AST). I'll pick up the discussion here with some remarks on technical considerations and then finish up with a description of the major aspects of the final two components: business activity monitoring (BAM) and events and the full life-cycle process.

Technical Matters

What's the chief constraint in trying to realize the SOA vision? Primarily, it's that current applications are tightly coupled while the underlying SOA technology is still evolving. Therefore, it may not be possible — at least not in a cost-effective manner — to achieve loosely coupled perfection given the existing environment of tightly coupled, business-critical applications.

I believe SOA technology is worth the potentially Herculean efforts required to create loosely coupled, reusable services. Simple interfaces, exposed at the right level to transmit and receive functionality, are the key to SOA. While exposing the right level of detail, it's vital that the interfaces not be too complex, which will limit their use and reuse. Services exposed as tiny, incomprehensible units will be too hard to understand: On the other hand, not enough detail could limit the usefulness of the services.

Current technology enables connectivity, but it doesn't automatically produce good architecture. Only by following key design principles will a loosely coupled architecture succeed in increasing business functionality, reducing software costs and development time, and improving maintenance. The following are some pointers to help you create a well-architected SOA:

  • Services must be loosely coupled. They must be self-sustaining so that they can interoperate with other services without unnecessary internal dependencies.
  • Services must perform discrete tasks and provide simple interfaces to access their functionality to encourage reuse and loose coupling.
  • Message exchange between services must be coarsely grained, descriptive, and utilize documents and schemas - which are more extensible than traditional remote procedure code interfaces.
  • Extensibility and versioning must ensure backward compatibility with service consumers who may be spread all over the world. Otherwise, it will be nearly impossible to update consumers with service changes.
  • When appropriate, services must support asynchronous messaging to decrease time dependence and, thus, tight coupling.
  • Services must utilize metadata to identify service semantics, capabilities, and constraints.

Security, including authentication and authorization, should adhere to a federated model. This approach is in step with the loosely coupled style of an SOA.

BAM and Events

Like SOA, event-based computing relies heavily on asynchrony and a loosely coupled architecture. An event-based architecture enables the services and systems within an SOA to listen for events and then send these events to interested parties. Moving forward, organizations will need this ability to cope with the multiple trading partners, diverse and distributed employees, applications, and hardware devices that need information dispatched to and transmitted from them in near real time. Indeed, technologies such as RFID will make having an event-based architecture for sending, receiving, filtering, and collaborating on events increasingly necessary. Event-based architectures will help organizations avoid information overload by filtering out noise that would prevent them from detecting early warning signs.

An event-based architecture must contain and/or enable several important capabilities. A mechanism to publish and subscribe to messages should be at the heart of an event system. This technology has been available for many years within the confinement of proprietary enterprise application integration (EAI) packages. Publish-and-subscribe messaging systems are used heavily on Wall Street: An SOA will help make such systems possible for a fuller range of business contexts.

Events must have real-time access to a large portion of the enterprise's information, including data warehouses, business rules, and preferably the entire abstract service taxonomy (AST, described in Part II) to enable people to make intelligent decisions in real time. Business applications, networks, PBX systems, and other devices are also valid event sources or targets when their performance affects business processes and operations. Along with access, events need to be able to invoke either automated processes or call for human intervention.

An event-based architecture must support long-running transactions that might aggregate, correlate, and analyze multiple events during processing. For example, imagine an order process that receives an out-of-stock event on a key order on Monday and a notification from Fed Ex that it's running behind schedule on Friday — the day the revised order was scheduled to ship. The system must correlate these events and dispatch the necessary notifications.

Appropriate systems must store the increasing amounts of contextually aware data that's flowing around events, raising enterprise awareness and enabling improved decision-making down the road.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Previous
1 of 3
Next
Comment  | 
Print  | 
More Insights
Commentary
2021 Outlook: Tackling Cloud Transformation Choices
Joao-Pierre S. Ruth, Senior Writer,  1/4/2021
News
Enterprise IT Leaders Face Two Paths to AI
Jessica Davis, Senior Editor, Enterprise Apps,  12/23/2020
Slideshows
10 IT Trends to Watch for in 2021
Cynthia Harvey, Freelance Journalist, InformationWeek,  12/22/2020
White Papers
Register for InformationWeek Newsletters
Video
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you.
Slideshows
Flash Poll