Expert Systems.
The enterprise is typically composed of expert systems that perform core business
functions and perform them well. A retail system consists of points of sale systems, e-commerce websites, inventory management systems, accounting systems, marketing systems, customer service systems, advertising systems and business analytics. Each supports a core function, and the primary business process ties them all together to execute its main use case.
In addition to these business expert systems, there are a number of process oriented expert systems that take care of security, notifications,
logging, search, exception management, monitoring, management etc.
In a distributed environment, the most common way to interact with expert systems is using webservices, file transfers, shared databases, or including references to expert components in an application. The problem with most of these methods is that they strongly couple the systems to each other. The webservice has to be available when the application needs it and if it's not there, can cause cascading failures downstream. These failures can lead to data loss or require the development of expensive, complex, redundant systems that can handle these failures and recover at later times. Managing changes to expert components that are referenced by other applications is very difficult, often requiring versioning when interfaces change, rebuilding dependent applications to accommodate changes, or having system wide downtimes to upgrade just one expert system. In an enterprise, this can get out of hand very quickly.
Ideally you want to loosely couple these expert systems. In addition to using webservices or referencing expert components directly in an application, we can add advanced messaging to our arsenal and add some stability to the system. Messaging has been around for a very long time and has a wide and varied implementation base, but it's features are limited. Advanced messaging adds several important features that change the way we use messaging, it's basically messaging re-engineered from the bottom up.In a distributed environment, the most common way to interact with expert systems is using webservices, file transfers, shared databases, or including references to expert components in an application. The problem with most of these methods is that they strongly couple the systems to each other. The webservice has to be available when the application needs it and if it's not there, can cause cascading failures downstream. These failures can lead to data loss or require the development of expensive, complex, redundant systems that can handle these failures and recover at later times. Managing changes to expert components that are referenced by other applications is very difficult, often requiring versioning when interfaces change, rebuilding dependent applications to accommodate changes, or having system wide downtimes to upgrade just one expert system. In an enterprise, this can get out of hand very quickly.
One important feature of the advanced messaging protocol is that it applies the publisher/subscriber pattern to message queues. In the typical queue architecture an application puts a message on the queue specifically for another application who picks it up and processes the work, responding perhaps on another queue. In the exchange model, an application puts a message in an exchange and provides a routing topic (publishing). An application can listen to an exchange using a specific subscription key (subscribing). The exchange acts as a broker and matches routing keys to subscription keys. When a match is made the message is moved to as many subscribers as match the routing key. This mechanism does one very important thing. It completely decouples the publisher from the subscriber. This has large implications for how the enterprise can be organized into expert systems.
Distributed Systems
No comments:
Post a Comment