These characteristics are essential for developing productive and agile Web service solutions that will have the longevity and adaptability that businesses require.

Communication Mechanism- Distributed Peer-to-Peer
In order for any two software elements to communicate, they must use common communication mechanisms. There are three essential elements: universal communication transport, dialogue language, and a unique identity system (see Figure 2).

 

Universal Communication Transport - The Internet
The Internet has revolutionized communication between people in the form of e-mail (SMTP protocol) and the publication of information (HTTP protocol). It is pervasive, can be reached from anywhere on the planet, and represents the ubiquitous communication network for businesses to interact over, whether internally or externally.

Universal Dialogue Language - XML
The Internet accelerated with the use of HTML, a simple markup language to publish information for people to view. Unfortunately, machines cannot understand the data presented within HTML markup. In order for businesses to enable conversations over the Internet, they need a common language. XML allows data to be defined with a markup language that enables both humans and machines to understand the content of a page or document. It is already universally accepted as the syntax for conversations. Many industry bodies are defining standard business documents to be used for electronic business interactions.

Universal Identification - URI
In order to find information or services it is essential to have a globally unique identification mechanism. This ensures every Web page or document can be identified with a standard address mechanism.

Business Logic Implementation - Software Agents Using Business Rules
When two software elements communicate they are undertaking particular tasks on behalf of a business. Those tasks need to be implemented as a set of business services and processes. The services are the access points to a business, for example, to place a hotel reservation. The service would then call upon one or more business processes and consume or use resources to undertake the request. In the case of the hotel reservation, this may include checking the customer's status, the room availability, and recording the booking.

Each software element that delivers a service or process must be implemented with characteristics that ensure a loosely coupled, proven, and reliable implementation.

Contract of Use - Services-Oriented Architecture
If all business services are exposed through universal communication mechanisms, they can be consumed internally, externally by trusted organizations, or even publicly on the Web. Many of today's existing applications have not been constructed with this in mind.

Some traditional middleware technologies suggest that you simply need to wrap the existing applications with a service-oriented interface, and this will allow you to plug-and-play them into the universal communication network. It is often valid to wrap existing applications in this manner, but they have not been designed for external or public consumption. They tend to be internally focused, and have inappropriate data inputs/outputs, processing steps, exception handling, and security models.

Business services must be constructed by clearly defining the contract of the business processing that they expose, and the information that can be communicated via the exposed business service.

The Web Service Description Language (WSDL) standard allows the definition of service contracts, and is already accepted as a de-facto standard.

Autonomous Interactions - Role-Oriented Software Agents
The software elements need to be autonomous and loosely coupled software agents. A software agent is a piece of software that has the capacity to autonomously conduct its work. Each software agent exists for a clearly defined purpose, performing a specific role or job for a business. It is essential that the software agents themselves are not aware of the implementation details of other services. They should not know exactly where they are physically located.

The software agent would simply call upon other services when it required them as part of its business processing. A particular service may be an exposed service of another business, or a business process consuming internal resources, e.g., recording a reservation in an operational data store. This is essential to ensure that implementation details are not entangled with the primary business logic.

Infrastructure Independent - Network Enabled Agents
Another key issue is that most software elements cannot easily be redistributed because they are based on centralized enterprise models rather than a networked, role-based model.

The current dominant development approaches are object-oriented and component-based construction models, whether based on J2EE or .NET platforms. Unfortunately, these types of software elements are constructed and deployed on the basis of an application server, with procedural code tightly coupled to the infrastructure.

These approaches operate on the basis of encapsulating fixed interfaces or methods to a software element with low-level technical details mixed with business information. This results in the data input and output to a software element being rigid and very tightly coupled to the physical implementation's architecture.

Software should be constructed with autonomous software agents that have no embedded knowledge of the physical world they exist in. The definition of the physical communication mechanisms and location should be defined separately from the business processes. This allows software to be redeployed by redefining their locations to each other, independent of the business logic.

It should not be an issue if a software application needs to be deployed on a J2EE or .NET platform. The software should have no dependencies on its physical environment. The only open approach that can maintain this independence is to ensure that all the business logic is encapsulated within W3C XML architecture standards - URI, XML, XPath, XSL, and XSD.

This is critical if a business has a desire or need to be able to outsource particular business services and processes to third parties. A service-oriented solution does not require massive rewrites or integration activity to deliver this capability. It should simply be a case of redeploying the solution.

Separation of Concerns - Business Patterns of Interactions
The core principle behind the OO/ Component development approach was to enable assembly of prefabricated components or objects. Unfortunately, this hasn't lived up to expectations because most businesses are different internally with respect to the infrastructure used - hardware, operating systems, languages, application servers, and so on. Some estimates suggest that only 5-10% reuse has really been achieved with business processes in these environments. Where reuse has been achieved, it is predominantly in areas that are horizontal rather than vertical in nature, such as security or auditing.

The fundamental problem is that the business processes and the physical infrastructure details are tightly coupled. It is more powerful to ensure that the business process definitions are completely independent of the physical implementation.

The business processes should be defined by selecting proven business patterns of interaction rather than focusing on technical interface requirements (see Figure 3). These patterns come in a number of forms, based on the type of business problems that they are designed to handle. IBM has undertaken an exhaustive study of 80,000 engagements and defined an extensive range of reusable, proven patterns for e-business solutions. The business patterns fall into four primary categories:

 

For example, an Information Aggregation business pattern defines how data should be acquired from another source. An example is a "Multi-Step Population" pattern, which uses a number of software agents to perform the following steps: extract, transform, and load data.

It is essential that software agents be defined based on reliable business patterns of interaction.

Separation of Logical and Physical Aspects
Many software development advances can be characterized as making the software code look more like the design specification.

It is essential to separate the business aspects of development from the implementation environment aspects. For example, the business aspect may be focused on the recording of a hotel reservation. The business requirement is to store the reservation (business document) into an Operational Data Store for processing at a later time.

The implementation environment should be able to use an SQL database, XML data store, or a local file system without requiring a change in the business logic. The processing of this logic should be completely independent of the physical infrastructure.

For example, a generic SQL software engine would save, update, or get business documents from the particular type of operational store. The engines don't need to know anything about the specific business documents they are processing. The business logic could then call on the engine using a standard interface.

We then define transformations to convert the reservation business document dialogue to the application integration dialogue required by the operational data store. For example, the engine could transform the XML document into a SQL statement, and transform the results of the SQL query into an XML document.

Of course, if the operational data store is changed, it is only the transformation that needs to change, along with the selection of the relevant software engine. The business process and logic remain unaltered. This can significantly reduce development effort, and drastically reduce the cost of change, which is the most expensive element of a project life cycle.

Business Logic Visibility - Declarative Business Rules
Traditional software design and development methodologies have inherent weaknesses because knowledge leakage occurs when translating requirements and design specifications to software code. The primary reason for this is that most requirements for gathering and design methodologies are based on declarative techniques, whereas software code is generally written in a procedural manner. Because there is no direct alignment between the business user's requirement definition and the software developer's implementation, it is very difficult to ensure accuracy and completeness.

The business logic should be defined with declarative business rules based on the content of the business document being processed. The rules should follow a simple structure that is intuitive for both business users and developers: <event>-<condition>-<action>. The rules are only fired if the <condition> is satisfied by the incoming <event> content of the business document. If the business rules change the data content, which is checked by other rules, then further rules will be fired. This is known as a forward-chaining business rules engine (see Figure 4).

 

This approach to business logic is inherently more maintainable as further declarative definitions can be added easily, particularly when compared to more complex nested procedural logic. It also allows a business user and a developer to work in collaboration by viewing the same business logic definition because it is not buried within the software code.

Information/Data Representation - XML Document Centric
Having considered the communication mechanisms and business logic implementation, we must finally examine the representation of data and information within applications.

Earlier, we established that Web services process XML messages based on XML standards. If most interactions are performed in this manner, it is simply logical that the business rules should be defined based on the XML business documents rather than on traditional software code method properties.

Flexibility of the Dialogue - Dynamic Data-Driven Interfaces
Traditional OO/component development approaches require a mapping of the hierarchical content to methods and properties to process XML documents. There are many issues associated with this approach, including accurate mapping and marshalling of the data. The business logic is fixed internally within the methods of the OO classes based on the class properties.

The advent of Web services presents enormous challenges. If information is exchanged in the form of XML messages with multiple parties, it is increasingly likely that the information will take many forms. If the existing software development approaches are utilized, there will be a proliferation of software classes and interfaces for each business document. If we consider how many different documents and versions each business process will require across an organization, it will simply become unmanageable. The software code will become impossible to maintain.

Software agents need the ability to receive multiple business documents, and then decide the appropriate processing that should be performed based on content within the business document.

Document Metaphor - Content Activated Business Rules
What becomes even more powerful is when the business rules can natively process the XML business documents and react to the content directly.

The W3C has defined the XPath language for querying and processing content within XML documents. If we combine this rules syntax with a "Document Metaphor" type of action operation to be applied to XML documents, it is a very intuitive way to define the business logic.

The processing actions should take the form of business document manipulation, for example, operations such as read, write, store, forward, and so on. In fact, business rules of this nature are similar to decisions people make when manually processing paper documents.

Conclusion
The three main considerations of any software development approach are the communication mechanism, the business logic, and the representation of information and data. The ubiquitous nature of the Internet and its related specifications make it the obvious choice for a communication mechanism. In order to make effective use of these standards (which include SOAP, WSDL, XML, and HTTP), they should be incorporated directly into the development process.

By using XML over HTTP as a standard communication mechanism, business can take advantage of peer-to-peer architecture. This peer-to-peer approach requires autonomous, intelligent software agents, and these agents will in turn need to be able to react to the content of the incoming messages to be able to function efficiently.

The most effective way for the agents to do this would be to make use of XML-based rules using open standards such as XPath. By making these business rules declarative, we also gain business logic visibility. If we also ensure that the rules are directly activated by the incoming XML document content, we also gain a human- and machine-readable representation of information and data.

This article has examined what we believe to be the key characteristics required for a service-oriented development approach, and highlighted why this approach delivers a dramatic reduction of the cost and timescales for business integration. E-business projects should be driven by business needs and not by the coding capability of technical specialists. In fact, as more and more software elements are Web services- enabled, the cost of business integration will decrease further.

Traditional software development and middleware approaches adopted by the majority today simply cannot deliver effective, intelligent service-oriented architectures. A Web service-oriented architecture must be document-based, loosely coupled collaborations of autonomous intelligent software agents. A single development and runtime platform that supports all the above characteristics in a cohesive architecture is inherently more agile and productive. As business needs change and grow, this platform must also be able to evolve with them, making the software development approach outlined in this article the only suitable choice to take software development into the future.

References