Because Ben asked "What is it for?" I have to answer: As with anything that has a purpose in this world there are a few purposes:
31:10:2007 - human aspect - why should this make a difference (part I)
This is yet another answer to a bulk of questions from Mihai :)
This system that I have called Perspective programming or Perspectives is ment to create a common ground of processing and solving the problem of systems interactions. Just as 2 people communicate with each other they do it based on the a common language - be it even bodylanguage - they have developed in time methods of bridging over initial contact communication problems this is a a common strategy all people have one if they don't they will be pushed away to the outskirts of the sociaty. Thus another syntagm should be valid "I communicate thus I exist"
I comunicate thus I exist
And I'm refering to comunication, not talk - just to set this straight from the beginning. In the documentation to come and in this blog I will try to create an effective comunication rules set that can are sufficiently generic to be able to encompas any human interaction that has a given action result that can be to some extent be measured in success and failure. A system is more and more relying on external systems for it to exist for decades electronical systems were breached by human interactions, helpdesk phonecalls is just an example. In time these interactions became more and more standardised and now we see a very fruifull and effective interactional model Service Oriented Programming. What this lacks and what the Perspectives bring in new we will discuss imnmediately.
Perspectives vs. SOA
The 2 technologies overlap in many ways and extended SOA may provide a very good replacement of the Perspectives. So... Why then perspectives? Well perspectives is rooted in the SOA model of work but provides another very important add-on to it: Transformations. While SOA relyes on a common calling method (usually SOAP inspired) using XML-calls Perspectives lets you define prototypes that are processlevel and override perspective specific ones. This is no doubtly do-able in SOA too but there is no common ground defined and does not make the subject of it. While SOA is based on interactions Perspectives are based on transformations delivering a much closer to reality model of the data being transfered plus a much greater human understanding. Perspectives are closer to human understanding the use the same terms they use in everyday life in programming theyr everyday informational syste.
While SOA makes comunication available and offers it a messaging method Perspectives do not just transmit data they transfer behaviours tructures it has an intrinsic way of transmitting not just data but actions coordination, behaviours and new structures. Thus on the prototypes known by a certain Perspective we can build a completely new system of ideas, a completely new concept or set of concepts (objects at programatic level). Thus we can explain from outside to an inside process how it should work not just the predefined structures and actions, we can alter the process flow on the fly depending on other parameters. Each perspective can change any object of the underlying perspectives as it wishes to suit his needs.
Any perspective engine has a set of drivers which bind the perspective into the local system and offers a completely new level of control of local resources. This access must be provided by the perspectives framework. Security is a matter that I will discuss extensively in a future posts, for now I will just point out that users are assimilated to access entities that can be subdivided and part of a bigger entity security will allways be asserted at each perspective level each perspective asesses if the access entity has sufficient authority to access the process. The access entity is transported as a prototype throuout the process as an object. Additionally a perspective might require backcheck of the entity meaning accessing a security checking perspective (LDAP equivalent if you want)
Will continue this answer in the next post hopefully tomorrow
30:10:2007 - crying out loud
As with any new idea this one makes no difference it has to get refined thus I will take the time of defining all the building blocks and key concepts:
  • Objects
  • Perspectives
  • Processes
Are the static entities carier of data and functionality encapsuling all behaviours representing the abstract notion of a class on a per perspective basis. Objects may have same name in different perspectives sets they are not intrinsically connected. When we refere to a single object we understand it in one and only one perspective. Data and data containers are not name specific each perspective may or may not alter change or ignore data but this depends totally on the perspective. The results of the same object interpreted by different perspectives do not rely on any predefined rule
The viewpoint of a set of objects understandable at a certain level of knowledge. Perspectives are comprised of more elements:
  • engine
  • environment
  • processor
  • serializer
  • prototypes
  • language
Part of a perspective that processess the input objects. This part of the perspective can be reduced to the concept of a language parser truelly completing this task along with the processor which may or may not be just a language parser library.
The main data container from the input (static data). Provides means of branching execution.
This is the part of the perspective used mainly to contain the actions of all the prototypes (function calls). Provides means of starting and setting up of other processess.
This is the part of a perspective that transforms the result of this process step into an output. This element is not necessarry if this perspective is only a consumer and does not produce any other object for further processing.
This is part of a perspective that describes the structure of any object using existent objects in the existent perspective. These objects are instantiated by any input to the perspective unknown prototypes management is up to the perspective(to ignore or throw an error).
This is the description way of any objects understandable by this perspective.
The view point as we have named it before the enumeration of the elements is analogue to the viewpoint of different humans on the same problem they provide a way of understanding input into valid needed/usable information to this extent the language used by the perspective should suit the language of the business branch and schould be as close to real business logics as possible.
These are the actions of transforming an initial requirement into final results that fullfill the actional requirement. A process is not unidirectional nor does it have a specific flow of action. Each process has the folowing elements:
  • perspective specific overrides (PSO)
  • environment data
  • starting points
  • ending points
Perspective specific overrides (PSO)
These provide overrides of perspective resident prototypes from the process level down.
Environment data
This is the startup data with which the process begins its work
Starting points
The perspectives that start out on resolving the specific requirements of a process
Ending points
The perspectives that require the results of this process
A process is allways started in one perspective and can be branched and managed by it using its elements. A process may need branching in subprocesses this will be managed and the knowledge of the subprocessess resides in a perspective the begin process allways knows how to interact only with the perspectives given as startpoint. If a perspective is unknown unreachable or has an unknown protocol the process must error out to the perspective marked as caller. The caller of any process is the starting point and the perspective decides wether to escalate the problem or try to solve the problem on alternative routes.
Attention! A process does not hold flow controllers these ALLWAYS reside in the objects of the perspective interpreted by the processor of the perspective.
29:10:2007 - first steps
The complexity of the task at hand is not to be overlooked and I set up this site in the hope that people will gather together in a common effort to promote and enlarge the concept in the title and url of this site: One version of the truth.
Grinding all my life on this problem step by step I learned a few things:
  1. There is allways a common ground to each 2 opposite ideas(appliccable in all areas of life)
  2. There is allways more then 1 perspective of a single thing be it anything from an atom to love
You will be asking now how the 2 things actually go together. Well in time I hope to deliver this answer because as any new idea as any new concept it needs a fertile ground in which it can grow and I hope to provide it but I can not say how fast it will grow nor can I promise it will grow to anybodys or my expectation. I can only hope that with the help you will be providing by instigating people of all the different cultures, rases, ages, educational backgrounds, sexes, area of business, levels of achievement etc. I might provide (with all necessary credits given) a unified context in which this idea can grow.
Well down to business. the scope of this site is to define, refine and grow into a valid theory my idea of the one version of the truth:
Starting point:
Object: The reflection of an observable thing in our mind.
Perspective: The viewpoint of an object
Process: The object that correlates any other objects including but not neccessary itself or any other process class objects.
I wanted to include only the first 2 definitions I felt the need of including the process object just to drive away the hot-tempered which would have said there is no activity in my system.
So it's teoretically simple: We have any business model that operates with different objects seen in different perspecives and bound into more generic process objects directing the activity. Simple as it may sound this splits any process as simple as it might be into a miriad of perspectives objects and processess.
Simple example: Meeting announcement in a complany:
  • Objects:
    • Meeting
    • Participants
    • Information dispatcher
    • Meeting caller
  • Perspectives:
    • Meeting:
      • Location
      • Email
      • Electronic representation of the invitation
      • hard copy
      • subject
    • Participants
      • director
      • secretary
      • invitees
    • Information dispatcher
      • electronical
      • human
I didnt even exposed all the sub perspectives of each object and any other possible proceses like: match schedules, check room availability, check resources availability etc... So you see of a very simple human activity like calling in a meeding. Plus we didn't take into considerration that some might not speek englisch or would not be available via email or special precation regarding food suplyes or any other special cases that might appear in this very simple business process.
As people speak different languages there are also differences in understanding the precise same word in a given language by different busienss areas or even just the differences between the perception of wemen and men of the same text. This is why people are trained and undergo different teambuilding and corporate compliances procedures to learn the standards rules and regulations of the group. Between 2 different business areas might appear completeley different ways of understanding the same things. These bridges are usually breached by highly skilled and highly experienced people in both areas which are able to translate the concepts from one group for the other group he addapts the concepts to the ones the others understands so the 2 groups can communicate efficiently. If this process is not intermediated like this the 2 groups will have huge difficulties in understanding eachother and it will take a while untill a common ground of concepts and operators are found by wich each individual of the 2 groups can communicate with an individual of the other group. As such a new launguage is born a functional language that transports concepts from one understanding to antother without friction. This process is tidious and might have also bad outconmes, the 2 corporations might not be able to work together in which case they have some solltions like creating joint teams and teambuildings or experts exchange etc... All these methods have usually a great outcome and people learn to effectively communicate with each other.
Well as you see the one version of the truth is a concept that touches any and all areas of activity without any exception: Thus: Any business model can be sliced up in pieces that are then processable in allways smaller pieces.
You'd say that there isn't any difference to the object oriented theory, well there is: The perspectives (aspect oriented if you want).
Thus the model that I propose does not rely on any language whatsoever but uses specialized languages for each perspective (remember the specialized and transition language in the 2 corporations example). Thus processing anything implies more then one language and an abstract set of objects. These objects are self contained and can be written in any language be anywhere in the system or in any system (the perspective knows where they are and has access to them). Thus in our 2 corporation examples we will have 3 perspecives, each corporation one and one intermediar perspecive. And 4 processess: Requirement->corp 1 language->transition lang->corp 2 languagte->resolution
Thus there is a common engine architecture but each time different settings to processess each object in another object. This means that we have a soa based architecture spliced up on many different bussess interacting with eachother in a non-standard but negociated language. The advantages of this way of defining objects is that the objects themselves are totally portable and do not rely on a highly static standard but on a common building model that both sides understand (producer and reader) it doesn't īmake a difference if the reader is written in .net on a windows machine and read by a c++ reader on a linux machine or by an $§$" lanuage written for the alien trading vessel main processing unit of the aliens at the other end of the universe. The 2 perspectives negociate a common language that is translatable in both ways to a 100% building an effective common working ground for everybody.
Now the quest is simple to abberationally complex: breaching SOA, OO, AO into one single(hopefully simple) model introducing the morphation any to any objects as long as there is an perspective that knows how to do it. This new aproach can also be used in the next generation databases: I call it active data. Working brainlike the database is a buss or a series of busses perspectives and data storages. The DB engine needs a particular dataset for a particular caller who understands the input only from a specific list of perspectives, the DB engine works like a successive filtering engine filters the data stored in one or more places to bring the data in the understandable form for the caller to the caller.
I know this all sounds extremely bold and extremely farfetched that something this big can be encompassed in one single project. Well the engine is a quite simple thing to do and that is the key to it all because it is being applyed a perspecive(which should be very easily understandable for the business logics holder of that perspective).
It's quite abstract but the finality of it is that anybody will be able to write his interface of understanding of external requirements and that should be enough for anybody else from outside to bind in with his own understanding of writing requirements and so on inter individual corporational etc.
In a next post hopefully very soon I will split up a business process into pieces and try to define them later on I will try to define and limit the extent of each concept