System Engineering & Design Architecture - Sander R.B.E. Beals (books to get back into reading txt) 📗

program, based on the domain object model that the parser created. By then the values for all variables are already within programmed boundaries, or have resulted in an error which will be reported back to the calling system. The same goes for any condition that caused the Integrity check to fail.

After processing, the system has determined which parts of the code form the answer that needs to be sent back to the client. The XQL Composer turns these into valid XQL code, and sends the reply back.

Finally, the system heavily depends on a database that is set up to serve all the other components with the various document streams they need. This database serves all the types of documents needed in this approach, that are on the same system. In essence, this database might also hold proxy entries for documents which it actually retrieves from other servers if need be.

In order to run such software, we will require a piece of hardware that is somewhat more suited for the task requested of it by the system. Although right now we can probably go with traditional processors and PC architecture, the move to multi-Gigabit Ethernet connections may well require an architecture that is more up to the task of streaming bits at billions per second, and probably more in a few years.... Clusters of QL Systems may well be the way to go here.

QL usage by Example

In order to make the use of this QL system a bit more accessible, we are going to dedicate this chapter to an example of a QL program execution, as the user would experience it. This is different from the development of a QL Application, which will be tackled in the next chapter.

QL should be accessible via any browser, which basically takes care of the interface we humans require to interact with the system. The entry point the user needs to access the application is an XQL file, for which he or she only needs to have the URL. It will look like 'ql://www.qualingo_based_system.nl/qualingo_application_name'. Sometimes even added parameters may be attached to it, but this will make things more difficult for now. Let's just consider this an example where we start a program without parameters, and then proceed to tell it what to do.

The QL Base System (on either server or client, depending on the settings) will load that XQL file into a session for the user who just requested it. It will also look up the XSD, XSL and XSQ files, which respectively bring in the datatypes, layout info and program code aspects.

Let's assume the server does the execution of the Application for now. This implies it will basically run through the cycle in the diagram above, and will send a reply XQL document back to the client. Since this is also containing XSD, XSL and no XSQ references, the browser will know how to present the next screen in the browser. But since the server already did all the computing, it will just perform a display effort. Any system could do this, because then the XQL document is nothing more than an XML document by another name.

If the server retrieves the needed XQL file and sees it is client side programming, it simply sends the file back to the client. The client then has to be a QL Based System as well, and will do just what the server did in the previous step....

Either way, we end up with a response XQL document, which the browser knows how to display.

Of course this approach uncovers just the top layer, where especially the execution stage has been given way too little appreciation. In order to rectify this, we will bring in an example of an XQL file, and make ourselves a simple programming example:

<?XQL version="1.0" encoding="ISO-8859-1"?>

<application type="client side process">
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsq:sourcecode version="1.0"
xmlns:xsl="http://www.ql_one.org/2012/hello_world">

 

<xs:element name="screen 1">

<xs:element name="message" type="xs:string" value="Hello World!!!"/>

</xs:element>

</xs:schema>

</XQL>

 

Simple enough, ain't it? A client would for instance call this at "ql://localhost/hello.xql". Since it is client side programming, the server will just return the above document to the client, so it can execute it. Based on this, the client can then retrieve the XSD, XSL and XSQ documents, in order to perform the processing in accordance with these documents. Of course, when server side programming is the case, the server will process, and will only return XSD and XSL in its response, since the client obviously doesn't need the more verbose XSQ file with all the information in it. Now the XSD and XSL documents are quite well-known in structure, and there are enough examples on the Web, the most official definitions being hosted at www.w3schools.com.

But now we get to the crucial part: what would the XSQ document look like? We've seen the satellite concepts it must cover, so the top level isn't all that difficult:

<XSQ>

<code>

<version versionNumber="1.1.1.1"/>

<!-- config defined at XQL level by the included XSD and XSL document -->

<sourceCode>

 

</sourceCode>

<testMethods>

 

</testMethods>

</code>

<data>

<!-- data may come from XQL file or be included here -->

<designSpecs>

 

</designSpecs>

<programData>

 

</programData>

</data>

</XSQ>

 

Yes, you've seen it right: even within the XSQ file, we discern between code and data, just to make sure no one messes them up! This just serves to make the Integrity check a viable target. Now I could work on this some more, but most of you readers out there will not be happy to be talked through programming issues by a guy whose passion isn't programming... I'm more into architecture, the kind that makes systems like us work: where Andrew just talked Portia into dumping her soon-to-be groom in favor of him, where the boundaries between us and our creations blur. Does it matter whether we become more like technological wonders, or our machines become more like us? Do we need to make it a legal proceeding to determine where and when we will be comfortable with our mechanical friends as every bit the free-willed and well-designed beings they will eventually become?

 

In that sense I absolutely identify with Andrew in Bicentennial Man (I even carry his name, since mine is André in our reality): like he wants to become more human in order to reach the goal in his life of becoming accepted as a human, I foresee myself becoming more machine-like: I do not know the details of how this will happen, but my donor card already showed me fit for research purposes years ago, long before I realized this to be one of the pieces of truth I know absolutely: I will reach the age of 94 in 2057, at which time some sort of transition will take place. But at this moment I have strong feelings that it will not be an event which people usually call dying....

 

And no,, this is not about fear of death: it is far more the understanding that death or any other transformation is merely the arrival in a still larger playground!

Appendix A: the Simple Solutions

See subchapters....

Keep It Simple Sir...

Any action that leads to too much complications needs to be rethought: rather than settling for a complication, try some of the other rules written down here to arrive at something simpler .

80 / 20 % rule

Popularly said: "Screw the other 20, 80% is plenty!" Or in more decent wording: it takes you about 20% of your available time to come up with 80% of the solution, and the remaining 80% of your budget and time, to finish remaining 20 percent or worse....

Divide and Conquer

If the problem is too complex, chop it up into more easily digestible pieces. The SevenSphere is a nice tool for this, because it keeps in mind the rule that you shouldn't chop it into too many pieces. And if you do find you have too many aspects, try dividing them over several SevenSpheres, like two or three. Try and keep your balance where the weight of the various chunks is concerned.