Ontologies are the Esperanto for the Babel Fish of the 21st Century (part 07)

010203040506070809101112

Architecture Patterns


TODO: This whole section needs to flow better between sub sections where the flow must be based on the patterns applicability to ontological IS and TI solutions.

Event Driven Architecture (EDA), Service Oriented Architecture (SOA), Enterprise Application Integration (EAI), all these various efforts are attempts at solving a similar problem namely integration of distributed systems – even though EDA, SOA and EAI all attempt to solve the problem by different, but complementary, means – and can be grouped under the umbrella term, Enterprise Integration Architecture (EIA).

The following image shows the OMGs SOA SIG mission and high level technical view/scope in relation to EIA.

OMG SOA Sig Mission Technical Views[28]

ED-SOA – EIA Patterns

The main contention made in this section is that SOA, EDA, BPM and CEP are all Complementary[53] and all therefore require ontological specifications and contracts not dissimilar to those, for services, expounded in UPMS [48] to interact successfully. Further that Complex Event Processing (CEP) will be one of the component elements that shall tie them together. And they shall be used for ontological realization in the enterprise by Master Data Management (MDM). And all shall be implemented on Event Driven Architecture (EDA) provided by an Enterprise Service Bus (ESB) by event aware/enabled Services Oriented Architecture (SOA).

”SOA and EDA are complementary. EDA is the paradigm for communications in SOA’s, and SOA is the design methodology for EDA’s. In the future we would like to able to define EDA as follows

An event driven architecture (EDA) is a SOA in which all communication is by events and all services are reactive event processes (i.e., react to input events and produce output events).”[53]

EAI

Enterprise Application Integration (EAI) has been a mechanism used to manage the routing and transformation of data between systems and enterprises.

One of the key elements of a formal ontological approach is the ability incorporate logical statements into the ontological structures. The use of logical statements with ontologies can be achieved in several different ways. Ontological logic statements have in the past been implemented in as bespoke solutions in Business (Rules & Process) Engines. These engines have often been packaged as elements of an EAI solution or EAI COTS product set.

TODO: More on EAI in relation to Canonical Data Models and Ontologies.

EDA

Two IT initiatives reliant to ontologies, which support logical statement execution based on events, [22] are; BPM and Rules Engines. The static structure nature of BPM is a significantly different approach from the more agile EDA. However they are complimentary particularly when the BPM approach is used to orchestrate SOA services and where both are running on an ESB backbone. EDA is the nervous system for the ESB backbone. The traditional BPM has a long association with integration with rules engines. It is notable that in Sun’s Business Integration (ESB) initiative JSR 208 there is an interface slot for both rules engines, and BPM (via WS-BEPL engines). BPM was also a part of the SeeBeyond EAI product purchased by Sun, some of which is being refactored along with JBI JSR 208 into Sun’s Open ESB [23].

IBM have produced a definition for a canonical event set of definitions in the “Canonical Situation Data Format: The Common Base Event – ACAB.BO0301.2.0” in line with their Autonomic – self healing – systems initiative. The specification was submitted to the OASIS Web Services Distributed Management TC. The requirement for a joined up taxonomic view – a base event ontology if you will – across enterprises and systems is show by an extract from this document.

”The event, which encapsulates message data sent as the result of an occurrence, or situation, represents the very foundation on which these complex systems communicate. Events passed between and among applications in complex information technology systems represent the very “nervous system” that allows these various facets of the system to interoperate, and coordinate their activities. Fundamental aspects of enterprise management and e-business communication, such as performance monitoring, security and reliability, as well as fundamental portions of e-business communications, such as order tracking, are grounded in the viability and fidelity of these events, Quality event data leads to accurate, deterministic and proper management of the enterprise. Poor fidelity can lead to misguided, potentially harmful results, or even results that are fatal to the system. Even simple things such as the formatting of the date and time specified within an event can render the remaining data in the event useless the format used by the sender is not understood by the receiver beforehand. Clearly, efforts to ensure the accuracy, improve the detail and standardize the format of these fundamental enterprise building blocks is an imperative towards designing robust, manageable and deterministic systems. Hence, the “Common Base Event” is defined as a new standard for events used by enterprise management and business applications.”[33]

Brenda Michelson writes about the need for ontologies in her excellent primer on EDA;

”For an event to be meaningful to downstream subscribers (human and automated) it is imperative that the event (name and body) is specified in business terms, not data or application terms. … To ensure events are understood by all consumers, a clear business lexicon or ontology should be used.”[34]
An interesting implementation of an EDA is SEDA an acronym for staged event-driven architecture.

”… the EDA field is expanding. New event-driven communication protocols are being developed all the time to support new applications such as Mobile Adhoc Wireless Networking to enable Mesh computing (e.g., the OLPC project). These technology developments are all event driven.”[53]
 
TODO: More on EDA in relation to Canonical Data Models and Ontologies.

CEP

Complex Event Processing (CEP) will increasingly leveraged through out the enterprise according to Gartner [24]. EDA and SOA solutions particularly when implemented on top of a nervous system that implements ESB architecture pattern are likely contenders in increasing use of CEP and reporting tools. CEP will rely on well defined ontologies to work successfully across systems and enterprises. As the trend toward autonomic self managing systems increases machine and human readable ontologies at all levels throughout the technology stack shall be needed.

To date event processing has mainly been restricted to the TI layer in particular the network and system management (NSM) capabilities of the TI layer. However the CEP initiatives being developed although currently not very mature are increasingly beginning to be integrated throughout the IS layers of the technology stack. One area where this is evident is in the BAM event processing in BPM tools. For effective enterprise system management CEP ontologies will play a central role. They shall also be used with the enterprises reporting facility. Business intelligence on key business process will be beneficiary supported by well defined ontologies encouraging the movement of CEP from low level to higher level system business information management.

The following is part of the abstract from the paper “Complex Even Processing in Distributed Systems” (a decade or more old now) by David C. Luckman etal.

”Complex event processing is a new technology for extracting information from distributed message-based systems. This technology allows users of a system to specify the information that is of interest to them. It can be low level network processing data or high level enterprise management intelligence, depending upon the role and viewpoint of individual users. And it can be changed from moment to moment while the target system is in operation.”[27]
 
A further example where CEP and ontologies are beginning to be increasingly important is the semantic web. [20]

Luckman also states in a recent article[45] the need for standards for CEP and EDA as a whole:

”Obviously in the course of developing event processing as a field in information technology we will need standards. … Here are some standards that I think will be needed early in the game: (1) basic terminology, (2) measures of event processing performance, (3) definitions of event driven architecture (EDA). Without the first two it is hard to have any precise sharing of information about tools and applications. The third has been pushed into prominence by the groundswell in Services and SOAs. ”
In  What is Complex Event Processing? (Part 1) of his eight part series Tim Bass provides a journeyman’s guide to CEP and provide the following graphic to depict the main abstracted view and top level processes that are part of the standard CEP architecture, the Joint Directors of Labratories (JDL) multisensor data fusion architecture.

 jdl[49]

The graphic above shows the 5 levels of processing in a CEP; Level 0 Event Pre Processing, Level 1 Event Refinement, Level 2 Situation Refinement , Level 3 Impact Assessment, Level 4 Process Refinement.

The abstraction is from the paper which presented JDL mark II and from which the more finely grained architectural view is taken.
 

 jdlmkII[50]

In the JDL MkII paper [50] the requirement for ontologies in the EDA and CEP domains is described thus.

”One main benefit typically cited for basing the development of an information process on an ontological footing is: interoperability with other local and also external processes, which leads also to shared understanding.”[50]

Further (for the reference [33] in the quote below please see reference [51] in this document);

”What needs to be further developed is a deeper insight into the spectrum of relationship-types that are typical of those for any given fusion application. In particular, we see ontology as aiding the fusion community in moving ahead with Level 2 and 3 capability development because it will provide adequate specificity in defining the L2, L3 states and the relationships within and among those states, e.g. exploiting the range of relationships described in [33]. That is, we feel that a major constraint to moving forward in L2, L3 development has been a lack of specificity in state definition, e.g. not adequately analyzing and partitioning notions of “situations” into specific forms for which theories, models and, eventually, algorithms can be formulated.”[50]

ESP

Event Stream Processing (ESP). See CEP. ESP is a sub set of CEP.

These two historically separate efforts (both emanating from Stanford) are converging. ESP (Stanford STREAM) was originally just concerned with synchronous ”streams” of events. CEP (Stanford CEP) is concerned with ”clouds” of events. A stream of events is linear and is concerned with a sequence of events. A cloud of events is a non linear and is concerned with sequences of events, unconnected independent events, asynchronous events and causal events, a cloud of events is partially ordered set of events (poset).

In his article What’s the Difference Between ESP and CEP[45] David Luckman – one of the originators of the concept of CEP – states:

”So ESP and CEP are both approaches to event processing. At first sight ESP is a subset of CEP and the difference boils down to special purpose event processing versus general purpose ─ but that is not as true now as it used to be … the answer to the title of this article is: there are some differences now, and there will likely be none in the future. And that’s a good thing!”

ESP and CEP footprints are similar but with historically different views of the event process. At the inaugural international conference 2007 on  Distributed Event Base Systems (DEBS) Tim Bass  why ESP and CEP so similar as to be indistinguishable.

ESB

Enterprise Service Bus (ESB) architectural pattern is one way to address the issues of ontology, message and data, transaction and interpretation, mediation [17]. However current COTS offerings are not necessarily a good fit and tend to be older mature products used for other architectural patterns to implement the ESB pattern, e.g. the use of J2EE Application Servers as ESB[28]. These products do not fit the criteria for products that would integrate well into the TI layer of the enterprise architecture. Furthermore ESB is a logical architecture not a single physical IS or TI application. Rather it may be manifest in many different forms through the collaboration of existing heterogeneous applications. The ESB pattern is a usage pattern, i.e. how to employ techniques and standards to leverage existing IS and TI assets into an ESB.

An ESB may also provide the backbone for the EDA and SOA nervous system.

Some of the technology components of a logical ESB follow. Listed under then the area where they will provide touch points (services) to other technologies. The lists and associations are indicative and not meant to be considered in any way exhaustive.

* Rules Engine will supply services to:
** Business Process Management
** CEP
** COTS
** IS bespoke builds
** MDM
*** Ontologies as CDM & ECDM
** Ontologies

* Business Process Management will supply services to:
** COTS
** IS bespoke builds
** MDM

* Registries will supply services to:
** COTS
** MDM
** SOA

* CEP will supply services to:
** Business Process Management
** COTS
** ESB
** EDA
** IS bespoke builds
** MDM
** Network and System Management (NSM)
** Registries
** Rules Engine
** SOA

The ESB provides the touch point (backbone) for the technologies listed above, through MOM and connector architecture (for example J2EE Connector Architecture (JCA)) via internet protocols and service standards, to (web enabled) services. These technologies in turn provide services to other high level services, but are also the result of the combination of finer grained lower level IS & TI services. The relationship is to some degree recursive and fractal in nature

SOA Fractal Model[46]

”The same service specification may be realized many different ways over time. Some runtime architectures even allow pluggable implementations that replace existing service providers with new, compatible implementations having additional capabilities or different qualities of service. Service realizations have to be consistent with all of the service specifications they realize and the service contracts they fulfill. UPMS can model complete service implementations, including services that are implemented through the recursive composition and choreography of other services.”[48]

This degree of complexity or recursive and fractal relationships and the events that encompass the entire set of a single transaction will require a capability to process and analyse the event interrelationship. This Complex Event Processing (CEP) shall be required at all levels of the 7 layer model that supports these complex event interactions.

TODO: MOM as part of ESB.

TODO: More on ESB in relation to Canonical Data Models and Ontologies.

SOA

Service Oriented Architecture (SOA). It is likely that ontological agents and ontological transformations shall be manifested as coarsely grained SOA services. Where the ontology services might be available to many different EI architectures over an ESB and provide what has been termed an interception type of service collaboration [32]. So that an ontological SOA service might be made available to the enterprise via the ESB (to event driven aspects of the enterprise system) and the businesses extended value chain.

TODO: Services as event generators. Services as event consumers. Services as event collaboration managers (choreography & orchestration).

EDA and SOA provide the architecture to implement MDM and make manifest the business and data ontologies and marry them to the event driven worlds and event based ontologies inherent therein.

”While SOA enables integration and data exchange through services, such integration is useless without a common vocabulary of data content and data structure. MDM defines how the enterprise establishes and maintains such a vocabulary.”[38]

SOA and event processing through EDA are brought together in the implementations of the seemingly disconnected domains of the MDM and CEP.

”You would expect that data management issues are far removed from the real-time excitement of CEP applications. But this is not necessarily the case. … Master data records may well be required during complex event processing, for example to augment event based information. So data processed in a CEP application may be managed in MDM.”[40]
 
Further event driven services are complementary and the association is not new.

”Event driven architecture (EDA) and SOA are related in two ways. First, event driven access to services is an”’ implementation paradigm ”’for SOA – not a competing technology. ED-SOA is a very good way to organize distributed services over any kind of IT infrastructure. … Secondly, SOA is a”’ design paradigm ”’for event driven applications. In software systems we’ve seen this happening, first in the middleware products, and more recently in the enterprise service bus. But SOA designs of event driven systems have been around for nearly 50 years in hardware designs – long before SOA in fact!!”[53]

TODO: More on SOA in relation to Canonical Data Models and Ontologies.

Other – EIA Patterns

TODO: Find ontological references to these patterns. Tie them into patterns above; firstly through ontologies, secondly through EDA/CEP/SOA/MDM.

TODO: Futher subdivide these patterns (and those for ED-SOA) and place them all in relation to layered architecture.

TODO: Patterns and EA governance over layered architecture.

GRID

TODO: Canonical Data Models & Ontologies and GRID.

Defintion of  GRID distributed computing from wikipedia

TODO: GRID & EDA/SOA.

Mesh

TODO: Canonical Data Models & Ontologies and Mesh computing.

Definition of Wireless mesh network computing from wikipedia

REST

Representational State Transfer (REST). For a given domain, or url, where the url represents a specific thing, different content wants to be served to different sources, browsers, users, geographic locations, ISPs, Carriers, etc, expressing the same information about the thing but in different types/formats. [42] For example human readable (text & audio – in the localized language of the user – & images, video, etc ) to a human user but machine readable ( XML, bits, etc ) to a machine subscriber/requester. The information about the thing is returned in the type/format that is either determined by default by the subscriber/requester type or specifically requested by them.

TODO: Canonical Data Models & Ontologies and REST [43]
 
TODO: URL canonicalization.

TODO: REST & EDA/SOA

SBA

Definition of Space-based architecture (SBA) from wikipedia

Jini Network Technology

Jini Network Technology

JavaSpaces resources

TODO: More on SBA in relation to Canonical Data Models and Ontologies.

SNA

Definition of Shared nothing architecture (SNA) from wikipedia, made popular with Google and Amazon.

JCACHE JSR 107

Java Caching System (JCS)

Latencey 


010203040506070809101112

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: