Enterprise Computing
Wednesday, March 31, 2004
 
Welcome to my first BLOG. I am interested in seeing if these things are any good. I want to be able to add anything that I need to remember for work. Like when I have done something for the first time and think, I have to remember that, but never do. Therefore, it needs to be easy to search (keyworks would be good). Would also like to get an XML rendition of the stuff, so I can re-use it later.
 
Sunday, March 21, 2004
 
New Scientist - 20 March 2004

Smart 'bots' used to keep chatrooms safe for kids. They can look for people that are trying to meet with kids. Kind of AI that meets Turings 'when a human can talk to a computer without known it is one'.

Big bang, looking glass Universe. Everything backwards, two cones put togther.

Architect Interview - William McDonough very green and useful take on design.
 
Saturday, March 13, 2004
 
Before examining the detailed architecture of ORBs, it is important to understand the context of middleware in relation to the rest of a computer system. As mentioned before middleware is normally concerned with distributed computer systems, therefore a look at where middleware fits into the OSI conceptual protocol stack is a good place to start. As the role of middleware is to provide platform independently of data across a network it belongs at layer 6, the presentation layer. Typically layer 6 deals with how different machines represents data types, for example two UNIX stations running a C program may use a different number of bytes to represent an integer or a UNIX station may send the LSB first while an NT machine sends the MSB first . As an object encapsulates primitive data types this problem is core to the design of object-oriented middleware.
 
Saturday, March 06, 2004
 
Three tier architecture has dramatically increased the maintainability and modularity of enterprise-wide computer systems. It has given rise to component based software and fast RAD techniques for developing systems with reusable code. Some systems take the three tier principle a stage further by adding a multiple number of tiers to increase modularity, this is sometimes refereed to n-tier architecture.
 
Thursday, March 04, 2004
 
A real world example of such a system is a multi platform distributed database, maybe something like an Oracle database. At our presentation level we may have a graphical front end, produced in Visual Basic for PC machines and a interface made in Java for our Solaris machines. These applications have two requirements: obtain the users request; display the subsequent result. In our database example the request maybe an SQL (Structured Query Language) statement, the result maybe some lines of data from the Oracle database. In request will be send to the business logic level, this is likely to be on a different server, but not always. What happens at this level will depend on the complexity of the system, a simple level two will forward the data onto the database, in that case the database it properly be on the same server as the business logic or actually incorporated into the database in some cases. In more complex systems the logic will act as a router or co-ordinator for the data. Most large companies will have more than one copy of the database for security and performance reasons, this is called replication, for a query the logic layer will maybe pick the database with the least traffic on it. In the case of an update the job is not as easy, all the databases must be updated with the new data, now the logic layer must act as a ‘Transaction Monitor’, it must make sure that all the database are updated or none of them are update. Typically a Two or Three Phase Commit Protocol makes sure that this functional correctness is carried out. Another job of the logic layer is often joining together different databases, lets say our personnel data is on a client-server based Oracle system while the customer database is running on DB/2 on a mainframe. The logical layer will split and send of the relevant queries to the databases and join the response together. Assuming for simplicity that the system only uses one database the request in sent on to it, and a response is sent back. The logic layer gets the response and puts it into a readable format for both the Visual Basic client and the Java client. The advantage of this approach is a very high level of abstraction, for both the user and the developer. Lets say that for some reason we get rid of our DB/2 mainframe database and swap it for a Microsoft SQL Server database, the logic layer will need some new modification but the client interface layer should be unaware of any changes. This is very useful when we have hundreds of client machines and only a few application servers, a massive reduction in maintenance time.
 
Wednesday, March 03, 2004
 
A three tier architecture adds and extra level in the middle of the two entities in figure 1.1. This may or may not be another piece of hardware, in some systems it could be an extra software component. In most enterprise-wide systems it normally takes on the form of an application server. There will be middleware both sides of the added middle tier, the names of the different tiers tend to be variable but this description comes from Barry Nance [BYTE03] and is fairly generic. “The levels of a three-tier architecture are presentation, business logic and data storage. Middleware exists between each of the tiers, connecting the presentation layer to the business logic layer and the business logic layer to the data storage layer”. With this definition Figure 1.1 can be redefined to add the middle layer, shown in Figure 1.2.
 
Tuesday, March 02, 2004
 
This two-tier architecture worked well in general and help the boom of component based software like Visual Basic and PowerBuilder. Problems did arise when programs had to be upgraded or some type of routing was needed between different servers [BYTE02].
 
Monday, March 01, 2004
 
Another important theme of middleware is the client-server model, the distributed network model that came into heavy use in the early 1980s superseding the master-slave relationship used by mainframes. The traditional client-server model is referred to as a two-tier model, the client would attach to the server for some service, a database query for example as shown in figure 1.1.
 
 
In very simple terms middleware allows the transfer of data between devices of different architecture possible running on different operating systems and possible running applications written in different languages. The longest standing implementation of a middleware product is Sun’s RPC (Remote Procedure Call), this allows a program to call a procedure on a remote machine without changing the semantics of the program [OPSYSp569]. RPC is still used heavily in distributed systems, NFS (Network File System) in UNIX uses RPC to mount remote file systems on a local machines. This is a good example of RPC as UNIX operating systems are written in the C programming language, a procedural language, all of which integrate nicely together. However RPC is not a middleware as we know it today. In the 1990s however, objects are being used in almost every area to help the development of computing systems, object-oriented programming, analysis and design. The most widely used object-oriented middleware is an ORB (Object Request Broker), an ORB provides all the services a RPC user is used to plus more, ORBs will provide the basis of this report.
 
Alistair Thomas's 'everything to do with enterprise computing'.

Archives
03/01/2004 - 04/01/2004 / 04/01/2004 - 05/01/2004 / 05/01/2004 - 06/01/2004 / 08/01/2004 - 09/01/2004 / 03/01/2005 - 04/01/2005 / 04/01/2005 - 05/01/2005 / 06/01/2005 - 07/01/2005 / 08/01/2005 - 09/01/2005 / 09/01/2005 - 10/01/2005 / 11/01/2005 - 12/01/2005 / 02/01/2010 - 03/01/2010 / 06/01/2013 - 07/01/2013 /


Powered by Blogger

Subscribe to
Posts [Atom]