× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I like to think that I am a reasonably intelligent man, but I have to
admit that I still have no idea what SOA is. I know that "SOA is
Architecture. Not technology. Not hardware. Not software." And I have
also learned that "your FTP solution could be SOA." And that it seems to
make people think of web services and for whatever reason XML?

Let's say I have some sort of problem, and I say to myself "Gosh I wish
I had some SOA" what sort of problem do I have? These "Best Practices"
are the best practices for what exactly? It sounds sort of like what is
being described is either the internet, or EDI.

Thanks,
Chris

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Trevor Perry
Sent: Tuesday, May 09, 2006 9:33 AM
To: Midrange Systems Technical Discussion
Subject: Re: Application design & architecture

Rob,

The alley is a major highway. Your blindness does not make it an alley.

I find this completely ironic. You cannot understand SOA, but you have
some 
snake oil for the rest of us. You start with asking about a new 
architecture. Instead, you are proposing a coding technique? This is not

even subliminal.

We need a new group called Midrange-20th-century.

Trevor

----- Original Message ----- 
From: "Rob Dixon"
Subject: Re: Application design & architecture


> We got hijacked and taken down a blind alley.
>
> Let's try and get back on track.
>
> I asked - it seems eons ago -
>
> "Can we design an architecture that will make us more efficient?"
>
> I don't think that many people will regard present methods as
efficient
> - just the best that they know.
>
> There are many reasons for this, but I would like to concentrate here
on
> just one of these - programming.
>
> Whatever the language or the architecture, programming is a most
> inefficient process, as I said  earlier, "the most inefficient process
> ever devised by mankind in any field of human endeavour".
>
> In order to explain how we might create a better moustrap, a little
> computing history is relevant.  I have tried to keep this as short as
> possible.
>
> The first computers were conceived and constructed to do high speed
> calculations - they were built solely for computation. John von
Neumann
> and his colleagues, working in 1944 on the Manhattan project to build
> the first atomic bomb, wanted a much quicker way of solving complex
> mathematical equations.  Storing, manipulating and constantly updating
> vast quantities of data was not the problem that von Neumann was
trying
> to solve.
>
> Von Neumann, who first conceived the required logical structure of the
> computer, realised that his mathematical problems could be closely
> defined but needed to be run repeatedly on many sets of data. He
further
> conceived the concept of the stored program as a convenient way of
> defining each separate problem to the computer and allowing his
> colleagues to switch quickly between the different problems they were
> trying to solve. It is unlikely that von Neumann considered that his
> "model" would be used for all computing work for the next 60 years
> without any real change.
>
> The separation of the rules from the data may be appropriate for
> mathematical and scientific problems but has added dramatically to the
> complexity of creating and maintaining business computer systems.  At
> the same time, we may have ensured that we can never create a machine
> with an ability that might be called "intelligent", whether or not
that
> is similar to the intelligence of the brain. We may call the present
> artificial split of rules and data in computer systems "*Separatism*".
>
> It is clear that human intelligence is very dependent on our ability
to
> store, dynamically update, and navigate large numbers of connections
> between the items of data in our brain.  This ability, which may be
> considered to be non-computational, can conveniently be described as
> "*Connectionism*".
>
> If we are to move forward, the rules and processes must be defined,
not
> in the separatist manner using programs and files, but in association
> with the data to which they apply, using connections.  This means
that,
> like the brain, our computer database must be able to determine where
> and how information is stored without outside help (from program
> changes). In other words, it must be capable of defining its own
> structure and allow continual changing of the connections as it
acquires
> new data.  All of this is way beyond the capability of RDMBSs but not
so
> difficult to implement if we create a universal data structure.
>
> Applying the principle of connectionism to the building of computer
> systems can allow us to build systems with a speed and ease that is
> beyond the wildest dreams of those using separatism as their model.
> Connectionist systems can be changed dynamically whilst they are in
use
> and so continually be kept up to date with the world of their users.
> Since connectionist systems are defined using the language and
> terminology of their users, the process is one to which users are
> already accustomed. Typing their business descriptions, definitions
and
> rules into a connectionist system will be dramatically simpler to
learn
> than the present separatist processes of system design and
programming.
> As with the information stored in their brain, users will not need to
> understand the complexity of the structure of their world, since they
> can study and define it incrementally in small pieces and use the
> connections to move from one part of the definitions to another.
Months
> of detailed planning and specifying become a thing of the past.
>
> Separatist methods produce static rigid solutions whilst the
> unstructured real-world problems of their users change dynamically.
> Static solutions are totally inappropriate for any business that is
> trying to get ahead or even to stay put. The effect of separatism is
> "*isolationism*". As John Donne (1571? - 1631) wrote in his
~Devotions~,
> "No man is an island, entire of it self".
>
> I wrote the above many years ago in isolation (!!) in order to try and
> explain the connectionist system that I had built and then found that
> the concept of connectionism had been invented by Dr. Vannevar Bush in
> 1945. It may all seem very removed from the present day world of
> computing but it is an extremely simple concept.  It can be
implemented
> in about 6Mb of RPG code (any flavour will do) and the same code is
used
> for both development and also for operation.  One of the additional
> benefits of connectionism is that it ticks many important boxes - e.g.
> security, performance, scaleability, documentation, standards, object
> oriented, automatic re-use of definitions and code, contextual help,
> multi-lingual, etc. - and it allows sharing of definitions on
different
> systems so that developers don't need to spend their time reinventing
> the wheel.  Rather than having open source programs, we can have an
open
> business model to which multiple users can contribute and which they
can
> use.
>
> Connectionism actually achieves much of what SOA attempts to do,
> because, unlike SOA, connectionism is a technology that can be
> implemented. If we.are to progress, we must stop using von Neumann's
> model for a purpose for which it was not invented - running a
business.
>
> Of course, my implementation of connectionism has not solved all the
> problems of the world.  I have done it as a one man band, in isolation
> and I trained at IBM as a salesman, not as a techie.  Anyone else
might
> be able to do a better implementation of the concept of connectionism.
>
> Rob Dixon
> www.erros.co.uk


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.