Marata
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
471
On Slideshare
471
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. DESIGN ISSUES * Assumed syntax - a simpler RDF syntax used in the following. (1999). This proposedaltervative to RDF/XMl was never adopted, RDF/XML prevailing as a standard and in practicealso Notation3.Original design issues1990 archives These documents date from the original design of the web, dating from 1990 whenthe first HTML editor was available to write them. When reading them please bear this in mind.Some have been updated later. Although the design is for a global general hypertext system, thejustification for the initial project was the CERN environment and this may be evident in someplaces.This lists decisions to be made in the design or selection of a hypermedia information system. Itassumes familiarity with the concept of hypertext. A summary of the uses of hypertext systems isfollowed by a list of features which may or may not be available. Some of the points appear in theComms ACM July 88 articles on various hypertext systems. Some points were discussed also atECHT90 . Tentative answers to some design decisions from the CERN perspective are included.Here are the criteria and features to be considered: * Intended uses of the system. * Availability on which platforms? * Navigational techniques and tools: browsing, indexing, maps, resource discovery, etc * Keeping track of previous versions of nodes and their relationships * Multiuser access: protection, editing and locking, annotation. * Notifying readers of new material available * The topology of the web of links * The types of links which can express different relationships between nodesThese are the three important issues which require agreement between systems which can worktogether * Naming and Addressing of documents * Protocols * The format in which node content is stored and transferred * Implementation and optimization - Caching , smart browsers, knowbots etc., formatconversion, gateways.Introduction In the web-application server domain, Java servlets are fast replacing the CGI. By year 2000,most of the Java based application servers are expected to be based on Java servlets forconnecting the middle-tier components with the HTML content (or templates). This article is an extract of an internal development effort, during which the author happened toexamine some of the development issues associated with developing small-to-medium scale webapplications using Java Servlets.
  • 2. This article does not intend to be a tutorial on how to program with Java servlets, although itcovers the principal concepts associated with servlets. This article examines some of the designissues, and offers some guidelines on the applicability of Java servlets for web based applicationdevelopment. For a detailed tutorial on Java servlets, see the Tutorial on Servlet Essentials athttp://www.novocode.com/doc/servlet-essentials.Java Servlets Java servlets are small, platform independent server-side programs that programmaticallyextend the functionality of the web server. The Java servlet API provides a simple framework forbuilding applications on web servers. This API is described in the Java Servlet API Specification(currently version 2.1) by the Java Software Division of Sun Microsystems Inc. Java servlets are not user-invocable applications. Servlets interact with a servlet engine (animplementation of the Java Servlet API specification) through requests and responses. Theservlet engine in-turn interacts with the web server by delegating requests to servlets andtransmitting responses to the web server. When compared to the Common Gateway Interface (CGI) and proprietary server extensionssuch as Netscape Server API (NSAPI) or Microsofts Internet Services API (ISAPI), servletsprovide a better abstraction of the Hypertext Transfer Protocol (HTTP) request-responseparadigm. In addition, servlets have all the advantages of the Java programming language,including platform independence. Java servlet based applications can be deployed on any webserver with built-in (in-process) or connector-based (out-of-process) servlet engines, irrespectiveof the operating system and the hardware platform. This is one of the reasons for servlets gainingwide acceptance over the past one year.Java Servlet Framework In the HTTP based request-response paradigm, a client user agent (a web browser or anysuch application that can make HTTP requests and receive HTTP responses) establishes aconnection with a web server and sends a request to the server. If the web server has a mappingto a servlet for the specified URL in the request, the web server delegates the request to thespecified servlet. The servlet in turn processes the request and generates a HTTP response. Fora description of the HTTP protocol and the request-response paradigm, see RFC-2068. For web application development, the servlet API provides three primary abstractions: HTTPrequests, request processing based on some application logic, and HTTP responses. Theseabstractions simplify the application development as far as the requests and responses areconcerned. In addition, the servlet API also provides a mechanism for session tracking and statemanagement. These are described below. HTTP Request: The interface HttpServletRequest is the first abstraction provided by the servletAPI. This interface encapsulates HTTP request from a user agent. When a request is received bythe servlet engine, an object of this type is constructed and passed on to a servlet. This objectprovides methods for accessing parameter names and values of the request, other attributes ofthe request, and an input stream containing the body of the request. HTTP Response: The HttpServletResponse interface of the servlet API provides anencapsulation of the HTTP response generated by a servlet. This interface defines an objectcreated by the servlet engine that lets a servlet generate content in response to a user agentsrequest. This object provides methods to set type and length of the content, character encoding,cookies, response status including errors, and an output stream into which binary response datamay be written. Alternatively, this object also provides a print writer object for writing formattedtext responses.
  • 3. Application Logic and Content Generation: The HttpServlet interface specifies methods forimplementing the application logic and generating content in response to a HTTP request. Thesemethods handle the GET, POST, HEAD, DELETE, OPTIONS, PUT and TRACE requests ofHTTP. These methods are invoked by the servlet engine and act as placeholders forimplementing application logic. The servlet engine also supplies HttpServletRequest andHttpServletResponse objects to these methods. HTTP Servlet Framework Figure 1: HTTP Servlet Framework These interfaces are shown in Figure 1 in the context of a request and a response. In thisdiagram, the service method of the HttpServlet is shown to implement the application logic andcontent generation, although one of the doGet, doPost, doHead, doDelete, doOptions, doPut ordoTrace methods can handle HTTP requests. Session Tracking and State Management: The HTTP, which is the underlying protocol for webapplications, is stateless. This protocol covers only a single request (with the connection initiatedby the user agent) and a response. In this protocol, irrespective of the status of the protocol, theconnection may be closed by either of the transacting parties. This has the followingramifications: * The protocol has no mechanism by which a series of unique requests from a user agentmay be identified as being from the same user agent. Consequently, in a transaction spanningmultiple requests and responses, the web server can not uniquely determine that all the requestsare from the same user agent. A user, therefore, can not establish a dialog with the web server toperform a business transaction. * Since connections are not maintained by either of the transacting parties, the state of thetransaction (and the application) can not be preserved across multiple requests. The Java servlet API provides the HttpSession interface for session tracking and statemanagement in a session. A servlet obtains a HttpSession object from the associatedHttpServletRequest object. Servlets track sessions by URL rewriting or by cookies (See thetutorial on Servlet Essentials at http://www.novocode.com/doc/servlet-essentials for more details).Objects of type HttpSession can be set or obtained for new and existing sessions respectivelyfrom HttpServletRequest objects. Session specific data can be stored into these objects.Application Development Issues The Java servlet framework provides an object-oriented abstraction of the request-responserouting model of CGI, and is well suited for gluing back-end applications to the web server.However, this framework is not adequate for object-oriented application development because ofits inherent nature. This section examines the issues associated with servlet management, andsome of the possible application architectures. Servlet Management Java servlets are server-side programs and are completely managed by the host servletengine as described below: 1. Servlets are managed by a host servlet engine. The servlet specification guarantees that aservlet is available for service against a request pointing to that servlet. However, there is noguarantee that the same instance of the servlet will be invoked against another identical requestfrom the same or another user agent. There are several possibilities: * Based on some policy, the servlet engine might destroy and reinitialize a servletbetween two consecutive and identical requests from the same or different user agents. * Alternatively, the servlet engine may maintain a pool of servlet instances and executeone of the free instances in the request thread.
  • 4. * The web server may have a load-balancing scheme under which identical requests to aservlet URI (Universal Resource Interface)) may invoke service methods of different servletinstances in different servlet engines running on two different platforms. Thus, identical requestsmay be serviced by different servlet instances in different Java virtual machines. 2. Object references to servlets can be obtained by using the ServletContext (deprecated inversion 2.1 of the Java Servlet API Specification), but not directly. This implies that objects shouldnot hold references to instances of servlets, but should obtain them from the host servlet engine. 3. Servlet methods can not be invoked with object references in the usual way. There arethree ways in which a servlet can call methods of another servlet: * By specifying such methods to be "static." * By obtaining reference to a servlet as in (2) and then calling its methods. However,such instances can not maintain state in view of (1). * By forwarding the request and response objects to another servlet referenced by aURL (as of version 2.1 of the Java Servlet API Specification). * Alternatively, by including content generated by one servlet in the body of contentgenerated by the calling servlet (as of version 2.1 of the Java Servlet API Specification). 4. At any given instance, there can either be multiple instances of a servlet, or a singleinstance servicing multiple requests (in different service threads) or both. A servlet implementingthe SingleThreadModel interface is an exception to this, in which case a servlet instanceexecutes only one request at a time. The following issues summarize the above discussion: 1. Servlets are not reentrant programs, and therefore can not maintain state. HttpSessionobjects should be used to preserve state across multiple invocations of servlets. The applicationdeveloper must explicitly determine the state attributes and store these in HttpSession objects.The servlet specification recommends that only serializable objects be stored into sessions. Thisis necessary to allow a servlet engine to serialize sessions either for load balancing or formemory management. 2. Servlets may handle requests concurrently and must be ensured to be multi-thread safe.This precludes servlets having class-level attributes to hold application state. 3. Servlets are completely managed by the host servlet engine, and inter-servletcommunication is not equivalent to usual method invocation on objects. 4. Objects implementing application logic can not maintain state unless these are maintainedin HttpSession objects. 5. Each servlet need to implement session tracking and state management explicitly. 6. The bare-bones servlet API provides a simple abstraction over the traditional CGI model,but application developers need to leverage on the object-oriented features of the Javaprogramming language to implement the application logic. However, this is not the natural servletmodel. Application Architecture The following architectures are possible within the Java servlet framework. Single-Tier Architecture:One of simplest approaches for servlet-driven web applicationdevelopment is based on the single-tier architecture. In this architecture, the application consistsof a number of servlets each generating one or more web pages. The simplicity of this approacharises from the fact that there is often a one-to-one correspondence between a businesstransaction and a web page generated dynamically by the application. This usually leads to aone-to-one correspondence of a web page to a servlet generating that web page. The resultingarchitecture is shown in Figure 2. The arrows towards HTML pages indicate HTTP responsesfrom servlets while the arrows in the reverse direction are HTTP requests. Single-Tier Architecture Figure 2: Single-Tier Architecture
  • 5. Note that, in the cases of client-side programs (for example Java Applets or ActiveXcomponents) in the generated content, this architecture may be treated as a two-tier architecture.Web browsers rendering plain HTML pages should not otherwise be considered to form theadditional client-layer, since this approach does not actually partition the application. Two-Tier Architecture: The single-tier architecture is not adequate for applications requiringdata or services from additional servers. In this case, some or all the servlets need to connect tosuch back-end systems. This results in a two-tier architecture as shown in Figure 3. In thisarchitecture, servlets act as gateways for the backend systems. Two-Tier Architecture Figure 3: Two-Tier Architecture Three-Tier Architecture: This is the most common architecture for servlet based applications. Inthis architecture (shown in Figure 4), the application logic is implemented in a set of helperclasses. Methods on objects of these classes are invoked by the service methods in the servlets. Three-Tier Architecture Figure 4: Three-Tier Architecture If instances of helper classes contain session-specific state, such instances should be stored insession objects, as servlets can not hold references to such objects across multiple requests.This leads to breaking encapsulation of the application. In all the above architectures, each servlet typically performs the following tasks: 1. Session tracking: The first servlet establishes the session and the rest of the servlets in theapplication track the session either by cookies or by URL rewriting. 2. State management, by storing pre-identified state of the application (including instances ofhelper objects, if necessary) in HttpSession objects associated with HTTP requests. 3. Application logic, as necessary. 4. In the case of a two-tier and three-tier architectures, connections to back-end systems fordata or services. 5. In the case of a three-tier architecture, invocation of methods on helper objects. 6. Content generation. INTRDUCTION OF DATAABSTRACTION This is the second of a 4 part series, for those of you new to object-oriented programming,discussing the 4 major principles of an object-oriented language: Data Abstraction, Encapsulationwe’ve already discussed, Polymorphism and Inheritence. Data abstraction is the simplest ofprinciples to understand. Data abstraction and encapuslation are closely tied together, because asimple definition of data abstraction is the development of classes, objects, types in terms of theirinterfaces and functionality, instead of their implementation details. Abstraction denotes a model,a view, or some other focused representation for an actual item. Its the development of asoftware object to represent an object we can find in the real world. Encapsulation hides thedetails of that implementation.Abstraction is used to manage complexity. Software developers use abstraction to decompose
  • 6. complex systems into smaller components. As development progresss, programmers know thefunctionality they can expect from as yet undeveloped subsystems. Thus, programmers are notburdened by considering the waysin which the implementation of later subsystesm will affect thedesign of earlier development.The best definition of abstraction I’ve ever read is: “An abstraction denotes the essentialcharacteristics of an object that distinguish it from all other kinds of object and thus provide crisplydefined conceptual boundaries, relative to the perspective of the viewer.” — G. Booch, Object-Oriented Design With Applications, Benjamin/Cummings, Menlo Park, California, 1991.Lets look at this code for a person object. What are some things that a person can do? Thosethings must be represented here in our software model of a person. Things such as how tall theperson is, and the age of the person; we need to be able to see those. We need the ability for theperson to do things, such as run. We need to be able to ask the person if they can read.Public Class PersonPrivate _height As Int16Public Property Height() As Int16GetReturn _heightEnd GetSet(ByVal Value As Int16)_height = ValueEnd SetEnd PropertyPrivate _weight As Int16Public Property Weight() As Int16GetReturn _weightEnd GetSet(ByVal Value As Int16)_weight = ValueEnd SetEnd PropertyPrivate _age As Int16Public Property Age() As Int16GetReturn _ageEnd GetSet(ByVal Value As Int16)_age = ValueEnd SetEnd PropertyPublic Sub Sit()‘ Code that makes the person sitEnd SubPublic Sub Run()‘ Code that makes the person runEnd SubPublic Sub Cry()
  • 7. ‘ Code that make the person cryEnd SubPublic Function CanRead() As Boolean‘ Code that determines if the person can read‘ and returns a true or falseEnd FunctionEnd ClassSo, there we have started to create a software model of a person object; we have created anabstract type of what a person object is to us outside of the software world. The abstract personis defined by the operations that can be performed on it, and the information we can get from itand give to it. What does the abstracted person object look like to the software world that doesn’thave access to its inner workings? It looks like this:You can’t really see what the code is that makes the person run. This is encapsulation that wediscuseed last week.So, in short, data abstraction is nothing more than the implementation of an object that containsthe same essential properties and actions we can find in the original object we are representing. Definition Of EncapsulationIn programming, the process of combining elements to create a new entity. For example, aprocedure is a type of encapsulation because it combines a series of computer instructions.Likewise, a complex data type, such as a record or class, relies on encapsulation. ObjectOrientedProgrammingLanguages rely heavily on encapsulation to create high-level objects. Encapsulationis closely related to abstraction and information hiding.Encapsulation is a word that gets bandied about a lot in discussions on wiki, and it almost alwaysis being misused as a synonym for abstraction or information hiding. (I do it too.)To give a concrete example of the differences: * a java interface provides an abstraction. * implementations of this interface which do not exposed any other methods are employinginformation hiding; we cannot tell how they are implemented. * if the implementation exposes multiple methods, it is employing encapsulation.In the strictest OO sense of the term, encapsulation is gathering all operations on the objectsstate into the objects interface, and only those operations. This is one sense in which you cantalk about enforcing encapsulation. The other is that methods can only operate on the state oftheir own object (which implies that other objects in the system employ information hiding).Another example, Perls OO syntax allows for encapsulation, but does not provide full informationhiding - you can access any part of an objects data, to any depth. EmacsLisp is a language withvery little encapsulation - functions and data are often independent and freestanding. In theSelfLanguage method definitions (that would in normal OO be part of the class) are placed intraits objects; objects delegate manipulations of themselves to the traits object (ie encapsulation
  • 8. is broken, deliberately).Erm, not to be picky, but Perl does allow for information hiding, it just doesnt do it by default. SeeInformationHidingInPerl for my description of how to do it. -- JeffBayMostly when we associate encapsulation with OO, we mean that languages provide support for it,not that they enforce it (a claim made for ComponentOrientedProgramming that probably meantinformation hiding).Examples of ways to break (strict) encapsulation: * Utility classes, containing unrelated methods whose return value is a function only of theirinputs. e.g. Math.sin(x) in java. (Strict encapsulation would lead to x.sin()) * Operations on streams (usually achieved with a pipline of objects, each of which isresponsible for some of the manipulation of the stream state. (Strict encapsulation may well beachievable in this case, but doesnt lead to reusable code)Hopefully the message is getting through: encapsulation is not information hiding, and is notnecessarily an unequivocal force for good, especially in its strictest sense.Information hiding is more often pure natural goodness, allowing you to work with layeredarchitectures, component frameworks, and all that jazz. Im curious if anyone can provideexamples WhereInformationHidingIsaBadThing?. (whoops just thought of one. optimizing codehas a tendency to break IH - accessing members is faster than accessing methods)In Java, directly accessing class attributes is often slower than assigning an accessors returnvalue to a local variable, then using the local variable. JVMs use a longer bytecode for instancevariables than local variables. Lest you argue assigning a local variable directly to an instancevariable, keep in mind that the compiler will likely inline the call to the accessor, thus allowing thecode to maintain its speed without breaking encapsulation*.Before you mess with information hiding, use a profiler to make sure you are changing thesluggish part of your code! I very much doubt the techniques used in proper information hidingresult in poorly performing code. Parameterized AbstractData Type Parameterized Abstract Data TypeDivine answer all right, straight from the geek gods. If the phrase sounds Greek to you, then takecomfort in the knowledge that I, a programmer, was confounded, dumbfounded, and humiliatedby the answer. What the hell does that mean?Life poses many mysteries, and answers can only be found by delving deep into oursubconscious and, yes, daydreams. And finally, after much rumination (10 minutes is lengthyprison time for the wandering mind), I have broken down the answer and arrived at the conclusionthat this blog, Slip of the Pen, is indeed a parameterized abstract data type.Parameterized. Everything is bounded, restricted, chained to some rule. Even the free wolf canonly roam where there is prey. The corsair can only sail seas where the law doesn’t hold; the
  • 9. cutlass can only remain unscratched when sheathed. Same goes for this blog. What I write herehas limitations — you haven’t seen the worst of me, nor the best. You have seen the bad and thegood, but not all. Knowing me only in person won’t work either. I’m a writer, so part of me lives inthe pedestrian world and another in the pen-world. Know both, know me all.Abstract. Writers, insert knowing laugh here. Many artists proclaim their work as abstract, andlove to hear others comprehend and imbue mystical meanings to their art. I guess the same goesfor me (even though I write in relatively concrete images). This blog is an abstraction of its author— it presents to you the Corsarius through a mishmash of vignettes which, oddly enough, havesomething in common.Data type. What is a data type? According to E.P. Quiwa, it’s the kind of data a variable may takeon in a programming language. Examples are integers (9 and 23), characters (i and x), Booleanvalues (true and false). To put it more bluntly — it’s a category. And without trepidation, I can saythat this blog is a category of its own. Why, every blog is! Each blog has that x-factor, thatintangible something which renders it inimitable. My blog and your blog might have similarities,but they are not the same. Don’t be misled by web directories which order you to “kindly placeyour blog under the most relevant category, e.g. literary, technology, showbiz, etcetera”. They’reonly there to give some semblance of homogeneity amongst blogs. Use them, but don’t let themdictate what your blog is all about.