Re: [cuo-wg] Interoperability

["Adrian Walker" <adriandwalker@xxxxxxxxx>]

John --

That's a nice way of approaching interoperability.

I'd add another item at the end of your list.  

Setting aside our work on business rules in executable English (which
this group has regrettably agreed to exclude), there is other work on
specifying applications as business rules in technical
notations.   For example, in the talk abstract below, John
Field of IBM advocates interoperability via Reactors and Transactors,
and (in the actual talk) these are specified as condition-action rules
using a logic programming notation.

Here's the suggested additional item:

-- Interoperability by combining executable business rules from different sources.

There's a big potential payoff in this area, but there are also some
deep technical questions about  executing rules using rule engine
B when they were written for rule engine A.

On a more general point, I hope we can discuss the following in the
phone conference today.  The current draft of the group paper can
be read as saying  (a)  current technologies won't lead to
enterprise interop, and (b) here is a list of current
technologies.  Surely, the draft can be improved by listing some new technologies ?

Hope this helps,    -- Adrian

                   
Internet Business Logic (R)
A Wiki for Executable Open Vocabulary English
Online at www.reengineeringllc.com
                               
Shared use is free
Adrian Walker
Reengineering
Phone: USA 860 830 2085



Astract of recent talk by John Field of IBM Research

Increasingly, software is being built as loosely-coupled collections
of distributed components interacting over the internet, glued
together by systems software such as databases, messaging systems, web
servers, and browsers.  Moreover, many such applications are also
"inter-organizational", combining components written in and running in
distinct administrative domains. While the trend toward internetworked
applications is inexorable, the programming models we are using to
build such applications were largely designed for monolithic,
freestanding applications. In this talk, I will discuss some of the
reasons why programming models should evolve to better support
internetworked applications, and enumerate some of the distinguishing
features of such applications. I will then describe recent work on
Reactors and Transactors. These are simple "kernel" programming models
intended to explore key issues in programming support for building
reliable and evolvable internetworked applications. The Reactor model
is designed to explore integration of front-end "presentation logic",
back-end "business logic", and data access in a single distributed
programming model that supports both synchronous and asynchronous
component composition.  The Transactor model provides programming
constructs for maintaining consistency among the states of distributed
components in the presence of runtime errors or system failures.

On 12/20/06, John Flynn <jflynn@xxxxxxx> wrote:

The following is intended to open discussion on what is meant by computer
interoperability.

There are a variety of conditions that might relate to the term
"interoperability". In order to analyze and consider options to increase
interoperability it would be useful to more clearly define the type of
interoperability we desire to improve. The following is a list of a few
types of computer interoperability in an attempt to narrow down the specific
type(s) of interoperability we are trying to promote in the context of CDSI.
- CPU interoperability: CPU's that execute the same instruction set can run
the same machine-level code programs.
- Low-level System interoperability: Low-level system programs, such as
system communications programs, can provide computer interoperability. At
one point, about twenty years ago, Unix machines, PC's and Mac's could not
interact due to their unique system communications programs. Now almost all
computers use TCP-IP and Ethernet protocols to communicate via the Internet,
Intranets, or a classified version of the Internet such as SIPRNET.
- Applications interoperability: Many computer applications are designed to
support interoperability. Although there are many different email programs,
almost all of them read and send email messages that are interoperable with
one another. Word processing applications are mostly interoperable with
Microsoft Word (the de facto standard), although in some cases unique
formatting may be lost. Microsoft Excel supports the input and execution of
spreadsheets developed on very different computer hardware. There are a
large number of computer music players but they all support playing MP3
music files.
- Data sharing interoperability: Many computer applications share common
data sources. Sometimes the common data sources are accessed directly at the
data element level from an external data base, file or some other type of
data storage. In other cases the application can only input a complete data
file and convert it to some other internal format for further processing.
Some applications can not only passively share static data but can also
dynamically modify the common data. A very distributed version of the static
data sharing model is the World Wide Web.
- Direct application to application interoperability: In this situation the
data output from one application is provided directly to another application
as input to some process.

The few, out of many, examples of successful interoperability types
mentioned above all rely of the use of standards such as TCP-IP, Ethernet,
Web standards, email standards, computer music standards or even standards
imposed by the use of a common operating system and applications, such as
those by Microsoft. I suspect a more exhaustive compilation of successful
interoperability examples will support the contention that the use of
standards is essential. So, it would be useful for us to determine the
specific types of computer interoperability we are shooting for and then
determine the standards that are required to ensure success. The next, and
hardest step, is to enforce those standards. Enforcement is best
accomplished through market forces. If your computer music player won't play
MP3 files you probably aren't going to sell many copies of it even if your
proprietary music file format is superior.

John



_________________________________________________________________
Message Archives: http://colab.cim3.net/forum/cuo-wg/
Subscribe/Unsubscribe/Config: http://colab.cim3.net/mailman/listinfo/cuo-wg/
To Post: mailto:cuo-wg@xxxxxxxxxxxxxx
Community Portal: http://colab.cim3.net/
Shared Files: http://colab.cim3.net/file/work/SICoP/cuo-wg/
Community Wiki: http://colab.cim3.net/cgi-bin/wiki.pl?SICoP/CommonUpperOntologyWG

_________________________________________________________________
Message Archives: http://colab.cim3.net/forum/cuo-wg/  
Subscribe/Unsubscribe/Config: http://colab.cim3.net/mailman/listinfo/cuo-wg/
To Post: mailto:cuo-wg@xxxxxxxxxxxxxx
Community Portal: http://colab.cim3.net/
Shared Files: http://colab.cim3.net/file/work/SICoP/cuo-wg/
Community Wiki: 
http://colab.cim3.net/cgi-bin/wiki.pl?SICoP/CommonUpperOntologyWG    (01)