Why use distributed objects? The reason is quite transparent!
Programmers must generally resort to primitive, object-disoriented communication techniques, such as sockets, to build distributed applications. However distributed object technology extends the benefits of object-oriented technology across process and machine boundaries to encompass entire networks. This means that remote objects now appear to programmers as if they were local objects (that is, simple programming-language objects in the same process). This effect is called location transparency.
A transparency occurs when some mechanism causes an obstacle to disappear. This is a software abstraction that allows programmers to cross a computing boundary without having to be aware of the boundary at all, or without performing an explicit transformation. The object's programming interface is identical in all cases.
Distributed objects glossary
This topic is full of acronyms so a short glossary of terms may be useful.
Client: In the world of distributed objects, a slight change is made to the standard client definition for this topic. A distributed object client can be any computing context that invokes operations on the object (sends it a message, invokes a
method etc.).
CORBA: An acronym for Common Object Request Broker Architecture, as set by the OMG. See http://www.omg.org. In the CORBA model, the ORB provides location transparency.
Location transparency: This occurs when an object's client invokes the object's methods in a natural manner, regardless of where the object resides on the network.
Interface: The boundary layer that separates a consumer of an object's service (a client) from the supplier of the object's service (an object implementation).
IDL: Interface Description Language is an abstract interface description
language used to create an IDL file. This is used to map abstract descriptions and to generate the stubs, skeletons, and servants that are actually used when programming.
OMG: The Object Management Group is the technical group that defines a lot of specifications for technologies such as CORBA and UML. At http://www.omg.org – 'The Object Management Group (OMG) is an open membership, not-for-profit consortium that produces and maintains computer industry specifications for interoperable enterprise applications.'
ORB: The Object Request Broker is the central technical component, or foundation, on which the other OMG specifications are built. An ORB is any mechanism that mediates between an object and one of its clients, on different computers, using some kind of network communication. The ORB can provide various types of transparency such as programming language transparency, platform transparency and representation transparency.
RMI: Remote Method Invocation.
RPC: Remote Procedure Method.
UML: Unified modelling Language for OO design.
Components and distributed objects
Distributed objects technology raises the level of abstraction for distributed application design and development. A component is a standardised and interchangeable software module that is executable, has a unique identifier and has a well-known interface. Components are important in modern software development because complex programs and applications can be constructed for small, previously developed parts. Component-based design and construction (JavaBeans) provides similar benefits to complex software products. Component developers can deliver their product as a ready-to-use executable function (CORBA and COM+). It is important to distinguish the differences between CORBA as an OMG specification for use with Java, Python and C++, and the layered RMI architecture in Java, and ActiveX controls with Microsoft's DCOM.
Developers of a software package simply plug in the component into the existing software. Interoperability among hardware and software components requires well-defined and widely adopted standards. Software components require similar standards for connections and services. Components located on different machines running different operating systems requires a standard network protocol. Recent work in this area is with using XML with SOAP – Simple Object Access Protocol.
ORB programming
ORB programming in Java or Python or C++ etc. all focus on the object's interface. The interface defines what a client can know about an object and how a client may interact with it. A neat feature is that low-level details (network protocols, programming language idiosyncrasies, physical data organisation) on one side of the boundary are hidden from the other side. (So it can be a paradox to describe interfaces as 'hiding' things and providing 'transparencies'.)
As you will see in the Web services notion of contractual agreement later in this course, an interface may also be a contract between an object's client and implementation; and is called a servant.
The servant agrees on the information that will be exchanged in a given operation - a contract to interact between client and object for proper behaviour. CORBA interfaces may be composed from other interfaces through inheritance. This is called IDL programming. The Interface Description Language is used to develop an IDL file that can be used to map abstract descriptions and to generate the stubs, skeletons, and servants that are actually used when programming. Transformation into equivalent constructs in a concrete programming language is useful; the way in which these transformations are made for a particular language is called a mapping for that language. IDL language mappings exist for Java, C, C++, Smalltalk, and Python.
In Java language mapping, as an example, a stub takes the form of a Java interface - which is the Java equivalent of the IDL interface from which it was generated. Stubs are used by clients to invoke operations on target CORBA objects.
Reading the notion of a stub, here is some more information.
Using stubs
Stubs are used by clients to invoke operations on target CORBA objects. In Java language mapping, a stub takes the form of a Java interface, which is the Java equivalent of the IDL interface from which it was generated. An instance of the stub type is used indirectly by a client of a remote object (a consumer of the remote object's service) to invoke operations on the object.
A stub is often called a proxy or surrogate, as it is not the CORBA object itself; it is a Java object that represents the CORBA object and is partly responsible for invoking requests made on itself, to the real target object.
As you can see, CORBA applications can be quite involved, expensive and mostly used by large corporations for developing distributed objects applications for small-to-medium enterprises. The boundaries get fuzzy when a client of one CORBA object may be the server for other objects, and programs are sharing each others' objects in a variety of client/server roles as peers!
Servants
Servants are a CORBA interface (package of code) used to build object implementations. It is in a concrete programming language that provides the real behaviour of the object type. A servant is an interface with methods that correspond to the operations in the IDL interface; programmers construct an implementation by deriving a new type from the servant interface, then provide method implementations for the methods inherited from the servant interface. CORBA determines matching servants and stubs from a common interface mapped to the IDL interface, thereby making certain that a given stub/servant pair have identical interfaces.
Skeletons in the closet?
Skeletons are responsible for unpacking the parameters of the request sent by a stub and delivering them to a servant to implement the CORBA operation. They are used to delegate CORBA requests to servants. When the operation is finished, the skeleton must package any results into a reply to send back to the stub.
RMI and CORBA case study: On the road to distributed systems
Tim Austin discussed Java applications with RMI, CORBA and SOAP, and provided the source code for the HelloWorld RMI and HelloWorld CORBA examples as a case study for this Study Guide.
NOTE: You can download a copy of the source code used by Tim in this RMI
and CORBA Case Study at:
http://ispg.csu.edu.au/subjects/workshops/java/rmi and http://ispg.csu.edu.au/subjects/workshops/java/corba
Why bother with distributed systems?
Provision of a new level of automation across business intranets saves money and allows:
• distributed users to work with the same application;
• distributed data sources to be used with the same application; and
• computation to best be matched with machine resources.
What are distributed component architectures all about?
Distributed Component Architectures are designed to allow many machines to work together to form a distributed application. The use of components can allow an organisation to wrap existing 'legacy' applications in forming a new application, using object-oriented principals to make the system operate over a network – therefore reaping the benefits of the OO approach. Like a heavyweight boxing tournament, the contenders are:
• Common Object Request Broker Architecture (CORBA)
• Microsoft Distributed Component Object Model (DCOM)
• Sun's Java Remote Method Invocation (RMI)
• Simple Object Access Protocol (SOAP) The newest challenger
Reference:
Charles Sturt University ITC 594 E-system infrastructure development student study guide
Tuesday, April 13, 2010
Topic 5: XML – eXtensible Markup Language
XML
Extensible Markup Language is another language used to define the syntax of markup languages. XML is a subset of SGML, and is designed to represent arbitrary structured data in a text format. SGML is the Standard Generalised Markup Language, and is an enabling technology used in publishing applications such as HTML and XML - so a working knowledge of SGML
may be handy. XSL is a style sheet language for styling XML documents.
Some sites to examine are:
• W3C's XML 1.0 Recommendation
• W3C's 'XML in 10 Points'
• W3C's XSL Specification
What's my line?
When I put forward my opinion, I am reminded of the public speakers that get up on their soapbox each Sunday morning in Hyde Park, London to push forward their thoughts to the gathering crowd. You are my audience! Last year I started sending soapbox e-mail messages to my colleagues amusement, as well-formed XML, using my root tag element:
XML was designed to describe data with tags. It is not predefined like HTML, so you must define your own tags (as XML is self-describing). Soon I had a set of child tags for issues, facts, examples, questions and thoughts – like a developing schema or document type definition (DTD). I found that XML helped to 'see' the relationship of each element with indenting. Maybe those Hyde Park speakers practiced XML in their speeches, popular in the 19th century, without us really knowing! ☺
Instead of reading about my perspective on this subject in 12 point, Times Roman, formatted text, the notes are now presented as 'well formed' XML, using 10 point Courier New font. Note how hard it is for the eye and brain to 'parse' the raw XML content:
I hold the tenet that e-commerce and indeed many e-business applications, are not about commerce at all. I suggest that an e-commerce framework provides a system for secure electronic transactions of a diverse nature.
A bank or credit card company desires a secure transaction for moving numbers and money around the Internet. Many Internet users need the same secure system for transactions without money involved at all.
a student and teacher need a secure system to exchange
assignments and marks;
a farmer and a government agency exchange water quota
figures for irrigation, also require a private, secure
transaction without money involved.
In this subject, you will use object modelling as a tool for designing a secure E-business application or Web object component, such as an E-catalogue, an interactive multimedia product for sale or a Shopping Cart.
What is the significance of the thing you do?
For each E-business component that you build and attach to Web site – the online store front, you should discuss how your component connects or relates to your UML-based model, the Online Store (Web site); its business plan for online transactions and the secure E-commerce model in the business plan.
Such thinking and decision-making by you, will assist the organization (and you) to see not only how all the bits fit together, but also how your work fits into a secure, portable, scalable, reusable and persistent (big picture) development plan for the E-systems infrastructure of the business entity.
XML is widely supported as an open technology for data exchange and is better designed to handle the task of managing information. XML was designed to describe data, where XML tags are not predefined in XML. You must define your own tags, hence XML is self-describing. XML uses a DTD (Document Type Definition) to formally describe the data.
XML is not a replacement for HTML. XML and HTML were designed with different goals: XML was designed to describe data and to focus on what data is; HTML was designed to display data and to focus on how data looks. HTML is about displaying information, XML is about describing information.
In the future development of the Web it is most likely that XML will be used to structure and describe the Web data, while HTML will be used to format and display the same data. It is strongly believed that XML will be as important to the future of the Web as HTML has been to the foundation of the Web. XML is the future for all data transmission and data manipulation over the Web, using new protocols like SOAP.
XML is extensible and portable
The tags used to markup HTML documents and the structure of HTML documents is predefined. The author of HTML documents can only use tags that are defined in the HTML standard. However, XML allows you to define your own tags and your own document structure. Since XML tags describe the data they contain, it is possible to search, sort, manipulate and render an XML document using related technologies such as XSL (Extensible Style sheet Language).
XML parser
XML docs are highly portable – any text editor can be used. XML is both human and machine-readable. When processing XML, and XML document end with a .xml extension. An XML parser is required to check doc syntax and can support the Document Object Model (DOM) and/or the Simple API for XML (SAX).
Several parsers are available free of charge for Java, Python and other languages. DOM-based parsers build a tree structure containing the XML doc's data in memory – it allows data to be programmatically manipulated. SAX-based parsers process the docs and generate events when tags, text, comments etc. are encountered – returning data from XML doc. XML parsers are kept at http://www.xml.com/.
XML DTD
An XML doc can reference an optional Document Type Definition (DTD) file – this defines how the XML doc is structured.
XML Doc + XML DTD
(optional)
XML - Parser
Application
XML can be used as 'well formed', using the rules of XML or 'validated' by use of a DTD.
How can XML be used?
XML can keep data separated from your HTML - HTML pages are used to display data. Data is often stored inside HTML pages. With XML this data can now be stored in a separate XML file. This way you can concentrate on using HTML for formatting and display, and be sure that changes in the underlying data will not force changes to any of your HTML code.
XML can be used to store data inside HTML documents - XML data can also be stored inside HTML pages as 'Data Islands'. You can still concentrate on using HTML for formatting and displaying the data. XML can be used as a format to exchange information. (In the real world, computer systems and databases contain data in incompatible formats.) One of the most time-consuming challenges for developers has been to exchange data between such systems over the Internet. Converting the data to XML can greatly reduce this complexity and create data that can be read by different types of applications. XML can be used to store data in files or in databases - XML can also be used to store data in files or in databases. Applications can be written to store and retrieve information from the store, and generic applications can be used to display the data.
XML schema design for XML data structures
Several tools and XML schema languages exist. Interesting suggestions (and hints) are provided by Kennedy (2003) and Fitzgerald, M. (2002). Kennedy (2003) recommends an XML schema tool called RelaxNG, in association with RelaxNC. The key features of RELAX NG as an XML schema development tool is that it:
• is simple
• is easy to learn
• has both an XML syntax and a compact non-XML syntax
• does not change the information set of an XML document
• supports XML namespaces
• treats attributes uniformly with elements so far as possible
• has unrestricted support for unordered content
• has unrestricted support for mixed content
• has a solid theoretical basis
• can partner with a separate data typing language (such W3C XML Schema Data types).
Kennedy (2003) also suggests using ELM tree diagrams for mapping the data and structures, in conjunction with another tool called RELAX NC - which is the human friendly form of RELAX NG. A lot of students new to XML analysis take an instance, write it up in XML and then reverse-engineer the DTD or XML schema from that instance. However, ELM tree diagrams have been found to be useful in faster and effective forward engineering of the XML schema. Here are some steps to follow:
1. Do the data analysis using an Elm tree diagram for data and structure - see http://www.w3.org/XML/1998/06/xmlspec-report.htm#AEN101
2. Write the XML schema using RNC/RNG e.g. use a recipe.
3. Write up the document in XML.
Seven (7) rules for XML analysis
1. Code only the data
2. Use collection elements
3. Use groups of 'like' elements
4. Use elements to represent multi-valued data
5. Avoid mixed content
6. Use meaningful names and a standard case
7. Note that it is an iterative process.
Further tips
• With the XML tree structure, avoid 'tall trees' or 'wide hedges'
• Elements represent the data
• Attributes used for element meta-data
• Do not use attributes for content
• Mark-up documents e.g. user manual
• Mark-up documents for data transfer e.g. invoices.
The steps of: (1) mark-up XML; (2) create DTD (reverse engineer); (3) write XSL; are replaced by steps involving (1) Elm tree; (2) RelaxNC; (3) Mark-up XML; (4) write XSL.
Information integration as the problem: Is XML the solution?
While companies starting with a 'blank piece of paper' are at an advantage because they can store data in XML from scratch (and this is of increasing importance), most existing data repositories are still managed by relational database systems. Recent XML database research has focused on extending relational database backend to handle XML data efficiently. Special algorithms need to be designed and implemented on top of existing relational databases to support efficient database queries. For large systems, the update performance of the database in addition to query execution time will be scrutinised.
Reference:
Charles Sturt University ITC 594 E-system infrastructure development student study guide
Extensible Markup Language is another language used to define the syntax of markup languages. XML is a subset of SGML, and is designed to represent arbitrary structured data in a text format. SGML is the Standard Generalised Markup Language, and is an enabling technology used in publishing applications such as HTML and XML - so a working knowledge of SGML
Some sites to examine are:
• W3C's XML 1.0 Recommendation
• W3C's 'XML in 10 Points'
• W3C's XSL Specification
What's my line?
When I put forward my opinion, I am reminded of the public speakers that get up on their soapbox each Sunday morning in Hyde Park, London to push forward their thoughts to the gathering crowd. You are my audience! Last year I started sending soapbox e-mail messages to my colleagues amusement, as well-formed XML, using my root tag element:
XML was designed to describe data with tags. It is not predefined like HTML, so you must define your own tags (as XML is self-describing). Soon I had a set of child tags for issues, facts, examples, questions and thoughts – like a developing schema or document type definition (DTD). I found that XML helped to 'see' the relationship of each element with indenting. Maybe those Hyde Park speakers practiced XML in their speeches, popular in the 19th century, without us really knowing! ☺
Instead of reading about my perspective on this subject in 12 point, Times Roman, formatted text, the notes are now presented as 'well formed' XML, using 10 point Courier New font. Note how hard it is for the eye and brain to 'parse' the raw XML content:
I hold the tenet that e-commerce and indeed many e-business applications, are not about commerce at all. I suggest that an e-commerce framework provides a system for secure electronic transactions of a diverse nature.
A bank or credit card company desires a secure transaction for moving numbers and money around the Internet. Many Internet users need the same secure system for transactions without money involved at all.
a student and teacher need a secure system to exchange
assignments and marks;
a farmer and a government agency exchange water quota
figures for irrigation, also require a private, secure
transaction without money involved.
In this subject, you will use object modelling as a tool for designing a secure E-business application or Web object component, such as an E-catalogue, an interactive multimedia product for sale or a Shopping Cart.
What is the significance of the thing you do?
For each E-business component that you build and attach to Web site – the online store front, you should discuss how your component connects or relates to your UML-based model, the Online Store (Web site); its business plan for online transactions and the secure E-commerce model in the business plan.
Such thinking and decision-making by you, will assist the organization (and you) to see not only how all the bits fit together, but also how your work fits into a secure, portable, scalable, reusable and persistent (big picture) development plan for the E-systems infrastructure of the business entity.
XML is widely supported as an open technology for data exchange and is better designed to handle the task of managing information. XML was designed to describe data, where XML tags are not predefined in XML. You must define your own tags, hence XML is self-describing. XML uses a DTD (Document Type Definition) to formally describe the data.
XML is not a replacement for HTML. XML and HTML were designed with different goals: XML was designed to describe data and to focus on what data is; HTML was designed to display data and to focus on how data looks. HTML is about displaying information, XML is about describing information.
In the future development of the Web it is most likely that XML will be used to structure and describe the Web data, while HTML will be used to format and display the same data. It is strongly believed that XML will be as important to the future of the Web as HTML has been to the foundation of the Web. XML is the future for all data transmission and data manipulation over the Web, using new protocols like SOAP.
XML is extensible and portable
The tags used to markup HTML documents and the structure of HTML documents is predefined. The author of HTML documents can only use tags that are defined in the HTML standard. However, XML allows you to define your own tags and your own document structure. Since XML tags describe the data they contain, it is possible to search, sort, manipulate and render an XML document using related technologies such as XSL (Extensible Style sheet Language).
XML parser
XML docs are highly portable – any text editor can be used. XML is both human and machine-readable. When processing XML, and XML document end with a .xml extension. An XML parser is required to check doc syntax and can support the Document Object Model (DOM) and/or the Simple API for XML (SAX).
Several parsers are available free of charge for Java, Python and other languages. DOM-based parsers build a tree structure containing the XML doc's data in memory – it allows data to be programmatically manipulated. SAX-based parsers process the docs and generate events when tags, text, comments etc. are encountered – returning data from XML doc. XML parsers are kept at http://www.xml.com/.
XML DTD
An XML doc can reference an optional Document Type Definition (DTD) file – this defines how the XML doc is structured.
XML Doc + XML DTD
(optional)
XML - Parser
Application
XML can be used as 'well formed', using the rules of XML or 'validated' by use of a DTD.
How can XML be used?
XML can keep data separated from your HTML - HTML pages are used to display data. Data is often stored inside HTML pages. With XML this data can now be stored in a separate XML file. This way you can concentrate on using HTML for formatting and display, and be sure that changes in the underlying data will not force changes to any of your HTML code.
XML can be used to store data inside HTML documents - XML data can also be stored inside HTML pages as 'Data Islands'. You can still concentrate on using HTML for formatting and displaying the data. XML can be used as a format to exchange information. (In the real world, computer systems and databases contain data in incompatible formats.) One of the most time-consuming challenges for developers has been to exchange data between such systems over the Internet. Converting the data to XML can greatly reduce this complexity and create data that can be read by different types of applications. XML can be used to store data in files or in databases - XML can also be used to store data in files or in databases. Applications can be written to store and retrieve information from the store, and generic applications can be used to display the data.
XML schema design for XML data structures
Several tools and XML schema languages exist. Interesting suggestions (and hints) are provided by Kennedy (2003) and Fitzgerald, M. (2002). Kennedy (2003) recommends an XML schema tool called RelaxNG, in association with RelaxNC. The key features of RELAX NG as an XML schema development tool is that it:
• is simple
• is easy to learn
• has both an XML syntax and a compact non-XML syntax
• does not change the information set of an XML document
• supports XML namespaces
• treats attributes uniformly with elements so far as possible
• has unrestricted support for unordered content
• has unrestricted support for mixed content
• has a solid theoretical basis
• can partner with a separate data typing language (such W3C XML Schema Data types).
Kennedy (2003) also suggests using ELM tree diagrams for mapping the data and structures, in conjunction with another tool called RELAX NC - which is the human friendly form of RELAX NG. A lot of students new to XML analysis take an instance, write it up in XML and then reverse-engineer the DTD or XML schema from that instance. However, ELM tree diagrams have been found to be useful in faster and effective forward engineering of the XML schema. Here are some steps to follow:
1. Do the data analysis using an Elm tree diagram for data and structure - see http://www.w3.org/XML/1998/06/xmlspec-report.htm#AEN101
2. Write the XML schema using RNC/RNG e.g. use a recipe.
3. Write up the document in XML.
Seven (7) rules for XML analysis
1. Code only the data
2. Use collection elements
3. Use groups of 'like' elements
4. Use elements to represent multi-valued data
5. Avoid mixed content
6. Use meaningful names and a standard case
7. Note that it is an iterative process.
Further tips
• With the XML tree structure, avoid 'tall trees' or 'wide hedges'
• Elements represent the data
• Attributes used for element meta-data
• Do not use attributes for content
• Mark-up documents e.g. user manual
• Mark-up documents for data transfer e.g. invoices.
The steps of: (1) mark-up XML; (2) create DTD (reverse engineer); (3) write XSL; are replaced by steps involving (1) Elm tree; (2) RelaxNC; (3) Mark-up XML; (4) write XSL.
Information integration as the problem: Is XML the solution?
While companies starting with a 'blank piece of paper' are at an advantage because they can store data in XML from scratch (and this is of increasing importance), most existing data repositories are still managed by relational database systems. Recent XML database research has focused on extending relational database backend to handle XML data efficiently. Special algorithms need to be designed and implemented on top of existing relational databases to support efficient database queries. For large systems, the update performance of the database in addition to query execution time will be scrutinised.
Reference:
Charles Sturt University ITC 594 E-system infrastructure development student study guide
Topic 4: Web application servers
Common Gateway Interface – CGI
CGI is a standard for the construction of completely dynamic HTML documents by use of an external script (small program) installed on the same machine as the Web server. Common CGI scripts require a local interpreter or compiler. PERL and Python are popularly used to process HTML forms, and can verify user inputs as well as control the return of messages and perform further processing of the forms data. On a secure Web site, CGI can still be used for some e-commerce transactions, such as ordering some perfume for your mother's birthday. The forms data is concatenated into a string of delimited name/value pairs as the following example reveals:
name=Evan+Burke&card=Visa&number=8443261344895544&order=French+perfume
Note how each variable (name, card, number and order) is delimited by an &, and the each value by a + sign.
For notes on How to setup CGI on athene (PythonCGI), go to:
http://ispg.csu.edu.au/subjects/itc594/resources/apachecgi
Common Gateway Interface Demonstrations
1. Flat-file system
A Python CGI script that runs the flat-file system at http://athene.csu.edu.au/~keustace/friends.html
Enter some dummy test data and see the flat file grow.
2. Environment variables: ZOPE and Apache web servers
The environment variable display exercise begins at ZOPE using a local Python script and end with a look at Cookies and the same environment variables display at the Apache Web server on athene. Go to : http://ispg.csu.edu.au/subjects/itc594/resources/zopecgi/envform to begin.
Reference:
Charles Sturt University ITC 594 E-system infrastructure development student study guide
CGI is a standard for the construction of completely dynamic HTML documents by use of an external script (small program) installed on the same machine as the Web server. Common CGI scripts require a local interpreter or compiler. PERL and Python are popularly used to process HTML forms, and can verify user inputs as well as control the return of messages and perform further processing of the forms data. On a secure Web site, CGI can still be used for some e-commerce transactions, such as ordering some perfume for your mother's birthday. The forms data is concatenated into a string of delimited name/value pairs as the following example reveals:
name=Evan+Burke&card=Visa&number=8443261344895544&order=French+perfume
Note how each variable (name, card, number and order) is delimited by an &, and the each value by a + sign.
For notes on How to setup CGI on athene (PythonCGI), go to:
http://ispg.csu.edu.au/subjects/itc594/resources/apachecgi
Common Gateway Interface Demonstrations
1. Flat-file system
A Python CGI script that runs the flat-file system at http://athene.csu.edu.au/~keustace/friends.html
Enter some dummy test data and see the flat file grow.
2. Environment variables: ZOPE and Apache web servers
The environment variable display exercise begins at ZOPE using a local Python script and end with a look at Cookies and the same environment variables display at the Apache Web server on athene. Go to : http://ispg.csu.edu.au/subjects/itc594/resources/zopecgi/envform to begin.
Reference:
Charles Sturt University ITC 594 E-system infrastructure development student study guide
Topic 3: Database servers
Types of databases
Database servers have long been the client/server arena for development.
Flatfile
The flat file database, is usually just a text file. It can suit many applications whereby the database's to function like a rolodex. The records can be delimited, non-delimited or position delimited. The delimited records can be by CSV (comma-quote) or a Tab character in the text.
Relational DBMS
The relational model has advantages of 'one to many' between tables and the use of simultaneous updates. Many are ODBC/SQL compliant, allowing communication across data sources/servers.
Object-oriented OODBMS
The object oriented model has data objects which are encapsulated by classes that have pre-defined characteristics. Such as a player, room or container classes used in virtual worlds and multi-user games. Objects added to the database automatically acquire (inherit) the characteristics of their class. These data are accessible only through messages which they recognise. The ZOPE application server from zope.org uses an OODBMS inside its core as shown in Figure 3.1.
Figure 3.1: E-systems infrastructure as an expression of an e-commerce model.
Source: zope.org/WhatIsZope/ZopeArchitecture
The CouchDB
Apache CouchDB is a distributed, schema-free document-oriented database accessible via a RESTful HTTP/JSON API with JavaScript as the main view definition language.
Figure 3.2: CouchDB architecture diagram
Source: couchdb.apache.org
Database servers can use Thick or Thin clients. In a thick client like a modern Web browser, the client does much of the work, and so is relatively large and complex. A thin client is simple and light as the server handles most of the work, but can be network intensive.
2- and 3-tier database models
The 2-tier database model is a standalone application with data tightly bound, and includes many mainframe and workgroup database systems. Microsoft Access, as an example, may have all actions take place within a single Visual Basic application and the data may be in a separate or integrated file.
The 3-tier model is more popular for business, where the database backend is an Enterprise Relational Database such as Sybase or Oracle - with generally no direct access to the database. A Middleware component (API, controls or scripts) does most of the work in controlling access, building relational database tables and tracking changes. The clients are either thin, a Web browser, or a custom application - and of more than one type. The API support usually includes Perl, C, Java and Python, as well as Web submission forms, e.g. MyCSU and the CSU E-box system.
The advantages of the 3-tier database model are load distribution; transparency (changes at one level transparent at other levels, e.g. New client or backend); the ease of building custom application, business and data rules; as well as security controlled at the middleware layer.
Database design issues
Consider the following design aspects:
The number of users
1. How will the system scale? Does it need to?
2. What's your timeline?
3. What kind of output do you need?
4. Paper forms, web, wireless devices?
5. Will your application serve all needs?
Security issues
1. Where is your security coming from?
2. Who needs access to what?
3. Need for agility in your code base.
4. Will you need to migrate? (Yes, you will!)
5. Do you need to add specialised applications?
Take a video lesson under 10 minutes
A: Microsoft SQL Server 2008: http://www.youtube.com/watch?v=gfzEZTiGNIc
or at http://www.microsoft.com/latam/sql/2008/learning/presentations.mspx
B: phpMyAdmin Tutorial at:
http://www.youtube.com/watch?v=1-81n_vuwug&feature=related
Reference:
Charles Sturt University ITC 594 E-system infrastructure development student study guide
Database servers have long been the client/server arena for development.
Flatfile
The flat file database, is usually just a text file. It can suit many applications whereby the database's to function like a rolodex. The records can be delimited, non-delimited or position delimited. The delimited records can be by CSV (comma-quote) or a Tab character in the text.
Relational DBMS
The relational model has advantages of 'one to many' between tables and the use of simultaneous updates. Many are ODBC/SQL compliant, allowing communication across data sources/servers.
Object-oriented OODBMS
The object oriented model has data objects which are encapsulated by classes that have pre-defined characteristics. Such as a player, room or container classes used in virtual worlds and multi-user games. Objects added to the database automatically acquire (inherit) the characteristics of their class. These data are accessible only through messages which they recognise. The ZOPE application server from zope.org uses an OODBMS inside its core as shown in Figure 3.1.
Figure 3.1: E-systems infrastructure as an expression of an e-commerce model.
Source: zope.org/WhatIsZope/ZopeArchitecture
The CouchDB
Apache CouchDB is a distributed, schema-free document-oriented database accessible via a RESTful HTTP/JSON API with JavaScript as the main view definition language.
Figure 3.2: CouchDB architecture diagram
Source: couchdb.apache.org
Database servers can use Thick or Thin clients. In a thick client like a modern Web browser, the client does much of the work, and so is relatively large and complex. A thin client is simple and light as the server handles most of the work, but can be network intensive.
2- and 3-tier database models
The 2-tier database model is a standalone application with data tightly bound, and includes many mainframe and workgroup database systems. Microsoft Access, as an example, may have all actions take place within a single Visual Basic application and the data may be in a separate or integrated file.
The 3-tier model is more popular for business, where the database backend is an Enterprise Relational Database such as Sybase or Oracle - with generally no direct access to the database. A Middleware component (API, controls or scripts) does most of the work in controlling access, building relational database tables and tracking changes. The clients are either thin, a Web browser, or a custom application - and of more than one type. The API support usually includes Perl, C, Java and Python, as well as Web submission forms, e.g. MyCSU and the CSU E-box system.
The advantages of the 3-tier database model are load distribution; transparency (changes at one level transparent at other levels, e.g. New client or backend); the ease of building custom application, business and data rules; as well as security controlled at the middleware layer.
Database design issues
Consider the following design aspects:
The number of users
1. How will the system scale? Does it need to?
2. What's your timeline?
3. What kind of output do you need?
4. Paper forms, web, wireless devices?
5. Will your application serve all needs?
Security issues
1. Where is your security coming from?
2. Who needs access to what?
3. Need for agility in your code base.
4. Will you need to migrate? (Yes, you will!)
5. Do you need to add specialised applications?
Take a video lesson under 10 minutes
A: Microsoft SQL Server 2008: http://www.youtube.com/watch?v=gfzEZTiGNIc
or at http://www.microsoft.com/latam/sql/2008/learning/presentations.mspx
B: phpMyAdmin Tutorial at:
http://www.youtube.com/watch?v=1-81n_vuwug&feature=related
Reference:
Charles Sturt University ITC 594 E-system infrastructure development student study guide
Topic 2: Clients, servers and distributed paradigms
What is client/server computing?
Will the real client/server please stand up? This is a question often posed due to changes in architecture and technologies over the last twenty-five years. According to Orfali (1999), several client server types exist such as:
1. File servers
2. Database servers (SQL calls)
3. Transaction servers (1-3 seconds)
4. Groupware servers (Microsoft Exchange and Sharepoint, MOO, CSU Interact, MOODLE)
5. Object servers (ORB-communicating objects)
6. Web application servers (HTML, Java, CGI, ASP).
The Orfali text also gave an excellent overview of client/server computing for over ten years and is a still good reference text. Orfali stated that 'the road to bandwidth heaven' will govern future development and migration towards wireless and mobile device networks requiring further protocol and network design. As bandwidth availability will grow with 'fibre to the premises' many changes beyond those endured by Web 2.0 will proliferate.
Various client/server systems just shuffle the location of the application logic around – from the client end to the server end of the networked relationship. See the 'see-saw' diagram below in Figure 2.1.
Figure 2.1: Which way client/server? The migration of the application logic from the client or server end.
E-business applications development: Architectures, models, methods, and methodologies
Many of the new client server development projects are related to E-Commerce and M Commerce systems - or E-Systems; so the term 'client/server', with its roots in the paradigms of distributed computer applications over a network, takes on a new image.
Burying your treasure
Several common layers, or tiers, exist in the way that a client/server application is developed. The historical development from 1, 2, 3 to 'n' tiers is shown below:
1-tier client-server architecture - all the application logic is at the server end.
2-tier client-server architecture - either client or server has application logic buried inside.
3-tier client-server architecture - the application logic is in the middle tier.
'n'-tier client-server architecture - many component services exist in the middle tier.
Communications and networking
Data communications and the underlying network architecture and operating systems largely determine and enable the type of e-commerce that can be carried out by an organisation:
• The Internet and mobile e-commerce
• Architecture of web systems
• Data interchange (mobile devices, SMS, GPS)
• Bandwidth and Bluetooth devices(access)
• Cryptographic security
• Electronic payments
• Databases
• Multimedia (videoconferencing).
As bandwidth, viewing devices and mobile connection prices improve remote devices such as mobile phones and PDAs will play an increasingly important role in the expansion of e-systems and services. Corporate solutions such as database, e-mail servers, enterprise-wide intranet and extranets are changing due to new technologies such as the availability of broadband services, and the use of new protocols and language definitions such as SOAP, XML, RSS and new API's.
Client/server architecture: Some background information
E-commerce models and e-business applications are really just current themes in the longer history of client/server applications and the architecture that supports that interaction - so some basic definitions may be handy. Distributing parts of an information system across many computer systems and locations has been called distributed computing. Client-server architecture is the dominant architectural model for distributing information system resources across a network.
Client-server architecture divides software into two parts - client and server. A server manages one or more system resources and provides access to those resources through a well-defined communication interface. A client uses the communication interface to request resources and the server responds to those requests. Modern variants of client-server architecture divide application software into the following set of client and server processes - called layers of tiers: data layer, business logic layer and presentation layer. The term middleware describes software that 'glues' together multiple components in a client-server or multi-tier application.
Connections to remote resources can be either static or dynamic. A static connection is initialised by the user or system administrator prior to accessing a remote resource. Static connections are inherently difficult to initialise and maintain. The resource locator maintains a resource registry containing the names and locations of known resources and services. The interaction between a
resource locator and a primary resource registration repository is inherently dynamic. Connections established through those interactions are dynamic connections.
A server can be stateful or stateless. When the state is maintained by a 'statefull'
server, it tracks states such as location, selections made, and user information. For a 'stateless' server like a Web server - no information is maintained on the server (e.g. HTML page in a browser - but you can use cookies to get around this if needed).
Interprocess communication
When an application is split into multiple processes, those processes must communicate with one another to share data and coordinate their activities. A variety of protocols and standards have been developed to address the problem of process coordination across networks. Peer-to-peer communication protocols and the use of sockets, named pipes and remote procedure calls assist with such coordination.
Sockets, ports, pipes and your operating system
A socket is a unique combination of an IP number and a port number. Some port numbers are permanently assigned for standard Internet or vendor-specific services, but many port numbers are available for other uses including client-server or peer-to-peer communication among application programs. A named pipe is a pipe that has a name that is permanently placed within a file system directory and has the ability to communicate among processes on different computers. The operating system at both ends of the pipe manages communications to and from the pipe. With a remote procedure call (RPC), a process on one machine can call a process on another machine.
Common port numbers
See the list of TCP and UDP port numbers at http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
From Client/Server to Web frameworks
The section on Web Application Architecture Patterns require you to determine what are the significant components of your system. The basic idea is: where do you put the business logic? On the server, in an ASP page, or in a distributed object? Conallen (2003) describes the three most common patterns as:
1. Thin client with business logic on the server.
2. Thick client with business logic executed on the client machine (Java applets, ActiveX controls etc.).
3. Web delivery with distributed objects - RMI, CORBA using IIOP, Java Beans and DCOM to support delivery by using the browser client as a delivery and container device.
Thin client means the normal desktop that sits on clients' desktop, and does not have much in the way of processing power, disk space or memory. All of the processing is performed on a central server, rather than on the clients' PCs. On the desktop appears a desktop window, though the difference between this and a normal PC is that the processing and saving of files is not happening locally. Clients use the web browser to interact with the server.
The 3-tier client/server architecture can be mapped to the newer Web application frameworks like Ruby on Rails or Django with the Model-View-Controller design approach, as shown below:
data layer (guarded by the server) … the MODEL
business logic layer (middleware) … the CONTROLLER
presentation layer (text or GUI client) … the VIEW
The client/server term middleware (CONTROLLER) describes software that 'glues' together multiple components in a client-server or multi-tier application.
Reference:
Charles Sturt University ITC 594 E-system infrastructure development student study guide
Will the real client/server please stand up? This is a question often posed due to changes in architecture and technologies over the last twenty-five years. According to Orfali (1999), several client server types exist such as:
1. File servers
2. Database servers (SQL calls)
3. Transaction servers (1-3 seconds)
4. Groupware servers (Microsoft Exchange and Sharepoint, MOO, CSU Interact, MOODLE)
5. Object servers (ORB-communicating objects)
6. Web application servers (HTML, Java, CGI, ASP).
The Orfali text also gave an excellent overview of client/server computing for over ten years and is a still good reference text. Orfali stated that 'the road to bandwidth heaven' will govern future development and migration towards wireless and mobile device networks requiring further protocol and network design. As bandwidth availability will grow with 'fibre to the premises' many changes beyond those endured by Web 2.0 will proliferate.
Various client/server systems just shuffle the location of the application logic around – from the client end to the server end of the networked relationship. See the 'see-saw' diagram below in Figure 2.1.
Figure 2.1: Which way client/server? The migration of the application logic from the client or server end.
E-business applications development: Architectures, models, methods, and methodologies
Many of the new client server development projects are related to E-Commerce and M Commerce systems - or E-Systems; so the term 'client/server', with its roots in the paradigms of distributed computer applications over a network, takes on a new image.
Burying your treasure
Several common layers, or tiers, exist in the way that a client/server application is developed. The historical development from 1, 2, 3 to 'n' tiers is shown below:
1-tier client-server architecture - all the application logic is at the server end.
2-tier client-server architecture - either client or server has application logic buried inside.
3-tier client-server architecture - the application logic is in the middle tier.
'n'-tier client-server architecture - many component services exist in the middle tier.
Communications and networking
Data communications and the underlying network architecture and operating systems largely determine and enable the type of e-commerce that can be carried out by an organisation:
• The Internet and mobile e-commerce
• Architecture of web systems
• Data interchange (mobile devices, SMS, GPS)
• Bandwidth and Bluetooth devices(access)
• Cryptographic security
• Electronic payments
• Databases
• Multimedia (videoconferencing).
As bandwidth, viewing devices and mobile connection prices improve remote devices such as mobile phones and PDAs will play an increasingly important role in the expansion of e-systems and services. Corporate solutions such as database, e-mail servers, enterprise-wide intranet and extranets are changing due to new technologies such as the availability of broadband services, and the use of new protocols and language definitions such as SOAP, XML, RSS and new API's.
Client/server architecture: Some background information
E-commerce models and e-business applications are really just current themes in the longer history of client/server applications and the architecture that supports that interaction - so some basic definitions may be handy. Distributing parts of an information system across many computer systems and locations has been called distributed computing. Client-server architecture is the dominant architectural model for distributing information system resources across a network.
Client-server architecture divides software into two parts - client and server. A server manages one or more system resources and provides access to those resources through a well-defined communication interface. A client uses the communication interface to request resources and the server responds to those requests. Modern variants of client-server architecture divide application software into the following set of client and server processes - called layers of tiers: data layer, business logic layer and presentation layer. The term middleware describes software that 'glues' together multiple components in a client-server or multi-tier application.
Connections to remote resources can be either static or dynamic. A static connection is initialised by the user or system administrator prior to accessing a remote resource. Static connections are inherently difficult to initialise and maintain. The resource locator maintains a resource registry containing the names and locations of known resources and services. The interaction between a
resource locator and a primary resource registration repository is inherently dynamic. Connections established through those interactions are dynamic connections.
A server can be stateful or stateless. When the state is maintained by a 'statefull'
server, it tracks states such as location, selections made, and user information. For a 'stateless' server like a Web server - no information is maintained on the server (e.g. HTML page in a browser - but you can use cookies to get around this if needed).
Interprocess communication
When an application is split into multiple processes, those processes must communicate with one another to share data and coordinate their activities. A variety of protocols and standards have been developed to address the problem of process coordination across networks. Peer-to-peer communication protocols and the use of sockets, named pipes and remote procedure calls assist with such coordination.
Sockets, ports, pipes and your operating system
A socket is a unique combination of an IP number and a port number. Some port numbers are permanently assigned for standard Internet or vendor-specific services, but many port numbers are available for other uses including client-server or peer-to-peer communication among application programs. A named pipe is a pipe that has a name that is permanently placed within a file system directory and has the ability to communicate among processes on different computers. The operating system at both ends of the pipe manages communications to and from the pipe. With a remote procedure call (RPC), a process on one machine can call a process on another machine.
Common port numbers
See the list of TCP and UDP port numbers at http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
From Client/Server to Web frameworks
The section on Web Application Architecture Patterns require you to determine what are the significant components of your system. The basic idea is: where do you put the business logic? On the server, in an ASP page, or in a distributed object? Conallen (2003) describes the three most common patterns as:
1. Thin client with business logic on the server.
2. Thick client with business logic executed on the client machine (Java applets, ActiveX controls etc.).
3. Web delivery with distributed objects - RMI, CORBA using IIOP, Java Beans and DCOM to support delivery by using the browser client as a delivery and container device.
Thin client means the normal desktop that sits on clients' desktop, and does not have much in the way of processing power, disk space or memory. All of the processing is performed on a central server, rather than on the clients' PCs. On the desktop appears a desktop window, though the difference between this and a normal PC is that the processing and saving of files is not happening locally. Clients use the web browser to interact with the server.
The 3-tier client/server architecture can be mapped to the newer Web application frameworks like Ruby on Rails or Django with the Model-View-Controller design approach, as shown below:
data layer (guarded by the server) … the MODEL
business logic layer (middleware) … the CONTROLLER
presentation layer (text or GUI client) … the VIEW
The client/server term middleware (CONTROLLER) describes software that 'glues' together multiple components in a client-server or multi-tier application.
Reference:
Charles Sturt University ITC 594 E-system infrastructure development student study guide
Topic 1: E-commerce, distributed applications and the Internet
Introduction
The aim of this subject is to provide guidance for you to address the architectures, models, methods, methodologies and technologies that can be used for all types of business application development. Many of the e-commerce models like B2B, B2C, C2C, E2C, E2B, and social networking require an underlying infrastructure including technologies such as:
• Broadband Communications and Networking
• Internet and mobile E-commerce via wireless data communications
• Client/server or MVC architecture of web framework systems
• Data interchange
• Access and cryptographic security
• Electronic payments, databases and multimedia
Some of the core e-business services that can then be provided by an organisation's e-systems architecture include:
• Online merchant account facilities
• Secure credit card processing and electronic payment systems
• Custom order processing to meet your organisation's specific needs
• Catalogue management
• Shopping cart facilities
• Daily site traffic and ordering statistics
• Instant updates early
• Ease for consumers to browse and collect prices
• Convenient for the consumer
• No face to face communication.
As increased broadband bandwidth helps build online business services, other influences such as the development of 10 Gigabit Ethernet and the release of Web 2.0 tools since 2005 and Web application frameworks have led to the emergence of social networks as a new business model and marketplace.
What is the big push behind E-commerce?
The list of advantages below may help answer this question:
• Efficiency gains.
• User friendly.
• Open 24 hours a day, 7 days a week. Unlike real stores, staff need not be employed 24 hours a day for a business to receive orders and process payments.
• Orders can be processed online in real time, or offline in batch processing.
• Globalisation – shops are not geography constrained and can compete with national and multinational companies for consumers located anywhere in the world. It is much cheaper than opening a shop and advertising in numerous countries.
• Provides flexibility.
• Reduction in processing costs - especially when large volume of business occurs between certain companies.
• Speed.
• Market freedom.
• New ways to fundraising activities.
• Competitive.
However your feelings towards doing business online may be moderated when we look at some of the issues or risks involved:
• Security.
• Vandalism.
• Sabotage.
• Theft and fraud.
• Breach of privacy or confidentiality.
• Violations of data integrity.
Reference:
Charles Sturt University ITC 594 E-system infrastructure development student study guide
The aim of this subject is to provide guidance for you to address the architectures, models, methods, methodologies and technologies that can be used for all types of business application development. Many of the e-commerce models like B2B, B2C, C2C, E2C, E2B, and social networking require an underlying infrastructure including technologies such as:
• Broadband Communications and Networking
• Internet and mobile E-commerce via wireless data communications
• Client/server or MVC architecture of web framework systems
• Data interchange
• Access and cryptographic security
• Electronic payments, databases and multimedia
Some of the core e-business services that can then be provided by an organisation's e-systems architecture include:
• Online merchant account facilities
• Secure credit card processing and electronic payment systems
• Custom order processing to meet your organisation's specific needs
• Catalogue management
• Shopping cart facilities
• Daily site traffic and ordering statistics
• Instant updates early
• Ease for consumers to browse and collect prices
• Convenient for the consumer
• No face to face communication.
As increased broadband bandwidth helps build online business services, other influences such as the development of 10 Gigabit Ethernet and the release of Web 2.0 tools since 2005 and Web application frameworks have led to the emergence of social networks as a new business model and marketplace.
What is the big push behind E-commerce?
The list of advantages below may help answer this question:
• Efficiency gains.
• User friendly.
• Open 24 hours a day, 7 days a week. Unlike real stores, staff need not be employed 24 hours a day for a business to receive orders and process payments.
• Orders can be processed online in real time, or offline in batch processing.
• Globalisation – shops are not geography constrained and can compete with national and multinational companies for consumers located anywhere in the world. It is much cheaper than opening a shop and advertising in numerous countries.
• Provides flexibility.
• Reduction in processing costs - especially when large volume of business occurs between certain companies.
• Speed.
• Market freedom.
• New ways to fundraising activities.
• Competitive.
However your feelings towards doing business online may be moderated when we look at some of the issues or risks involved:
• Security.
• Vandalism.
• Sabotage.
• Theft and fraud.
• Breach of privacy or confidentiality.
• Violations of data integrity.
Reference:
Charles Sturt University ITC 594 E-system infrastructure development student study guide
Subscribe to:
Posts (Atom)
