White paper on Web component development using servlets & JSP
COURTESY :- vrindawan.in
Wikipedia
Web Components are a set of features that provide a standard component model for the Web allowing for encapsulation and interoperability of individual HTML elements.
Primary technologies used to create them include:
- Custom Elements: APIs to define new HTML elements
- Shadow DOM: encapsulated DOM and styling, with composition
- HTML Templates: HTML fragments that are not rendered, but stored until instantiated via JavaScript.
There are two parts to Custom Elements: autonomous custom elements and customized built-in elements. Autonomous custom elements are HTML elements that are entirely separated from native HTML elements; they are essentially built from the bottom up using the Custom Elements API. Customized built-in elements are elements that are built upon native HTML elements to reuse their functionality.
Shadow DOM is a functionality that allows the web browser to render DOM elements without putting them into the main document DOM tree. This creates a barrier between what the developer and the browser can reach; the developer cannot access the Shadow DOM in the same way they would with nested elements, while the browser can render and modify that code the same way it would with nested elements. The impact of CSS scoped within the Shadow DOM of a particular element is that HTML elements can be encapsulated without the risk of CSS styles leaking and affecting elements that they were not supposed to affect. Although these elements are encapsulated with regard to HTML and CSS, they can still fire events that can be picked up by other elements in the document.
The scoped sub tree in an element is called a shadow tree. The element the shadow tree is attached to is called a shadow host.
Web development is the work involved in developing a website for the Internet (World Wide Web) or an intranet (a private network). Web development can range from developing a simple single static page of plain text to complex web applications, electronic businesses, and social network services. A more comprehensive list of tasks to which Web development commonly refers, may include Web engineering, Web design, Web content development, client liaison, client-side/server-side scripting, Web server and network security configuration, and e-commerce development.
Among Web professionals, “Web development” usually refers to the main non-design aspects of building Web sites: writing markup and coding. Web development may use content management systems (CMS) to make content changes easier and available with basic technical skills.
For larger organizations and businesses, Web development teams can consist of hundreds of people (Web developers) and follow standard methods like Agile methodologies while developing Web sites. Smaller organizations may only require a single permanent or contracting developer, or secondary assignment to related job positions such as a graphic designer or information systems technician. Web development may be a collaborative effort between departments rather than the domain of a designated department. There are three kinds of Web developer specialization: front-end developer, back-end developer, and full-stack developer. Front-end developers are responsible for behavior and visuals that run in the user browser, while back-end developers deal with the servers. Since the commercialization of the Web with Tim Berners-Lee developing the World Wide Web at CERN, the industry has boomed and has become one of the most used technologies ever.
A Jakarta Servlet (formerly Java Servlet) is a Java software component that extends the capabilities of a server. Although servlets can respond to many types of requests, they most commonly implement web containers for hosting web applications on web servers and thus qualify as a server-side servlet web API. Such web servlets are the Java counterpart to other dynamic web content technologies such as PHP and ASP.NET.
A Jakarta Servlet processes or stores a Java class in Jakarta EE that conforms to the Jakarta Servlet API, a standard for implementing Java classes that respond to requests. Servlets could in principle communicate over any client–server protocol, but they are most often used with HTTP. Thus “servlet” is often used as shorthand for “HTTP servlet”. Thus, a software developer may use a servlet to add dynamic content to a web server using the Java platform. The generated content is commonly HTML, but may be other data such as XML and more commonly, JSON. Servlets can maintain state in session variables across many server transactions by using HTTP cookies, or URL mapping.
The Jakarta Servlet API has, to some extent, been superseded by two standard Java technologies for web services:
- the Jakarta RESTful Web Services (JAX-RS 2.0) useful for AJAX, JSON and REST services, and
- the Jakarta XML Web Services (JAX-WS) useful for SOAP Web Services.
To deploy and run a servlet, a web container must be used. A web container (also known as a servlet container) is essentially the component of a web server that interacts with the servlets. The web container is responsible for managing the lifecycle of servlets, mapping a URL to a particular servlet and ensuring that the URL requester has the correct access rights.
The Servlet API, contained in the Java package hierarchy javax.servlet, defines the expected interactions of the web container and a servlet.
A Servlet is an object that receives a request and generates a response based on that request. The basic Servlet package defines Java objects to represent servlet requests and responses, as well as objects to reflect the servlet’s configuration parameters and execution environment. The package javax.servlet.http defines HTTP-specific sub classes of the generic servlet elements, including session management objects that track multiple requests and responses between the web server and a client. Servlets may be packaged in a WAR file as a web application.
Servlets can be generated automatically from Jakarta Server Pages (JSP) by the Jakarta Server Pages compiler. The difference between servlets and JSP is that servlets typically embed HTML inside Java code, while JSPs embed Java code in HTML. While the direct usage of servlets to generate HTML (as shown in the example below) has become rare, the higher level MVC web framework in Jakarta EE (JSF) still explicitly uses the servlet technology for the low level request/response handling via the Faces Serv let. A somewhat older usage is to use servlets in conjunction with JSPs in a pattern called “Model 2”, which is a flavor of the model–view–controller.
The Java Servlet API was first publicly announced at the inaugural Java One conference in May 1996. About two months after the announcements at the conference, the first public implementation was made available on the JavaSoft website. This was the first alpha of the Java Web Server (JWS; then known by its code name Jeeves) which would eventually be shipped as a product on June 5, 1997.
In his blog on java.net, Sun veteran and Glass Fish lead Jim Dris coll details the history of servlet technology. James Gosling first thought of servlets in the early days of Java, but the concept did not become a product until December 1996 when Sun shipped JWS. This was before what is now the Jakarta EE was made into a specification.
The Servlet1 specification was created by Pavni Diwanji while she worked at Sun Micro Systems, with version 1.0 finalized in June 1997. Starting with version 2.2, the specification was developed under the Java Community Process.
Jakarta Server Pages (JSP; formerly Java Server Pages) is a collection of technologies that helps software developers create dynamically generated web pages based on HTML, XML, SOAP, or other document types. Released in 1999 by Sun Micro Systems, JSP is similar to PHP and ASP, but uses the Java programming language.
To deploy and run Jakarta Server Pages, a compatible web server with a servlet container, such as Apache Tomcat or Jetty, is required.
Architecturally, JSP may be viewed as a high-level abstraction of Java servlets. JSPs are translated into servlets at runtime, therefore JSP is a Servlet; each JSP servlet is cached and re-used until the original JSP is modified.
Jakarta Server Pages can be used independently or as the view component of a server-side model–view–controller design, normally with Java Beans as the model and Java servlets (or a framework such as Apache Struts) as the controller. This is a type of Model 2 architecture.
JSP allows Java code and certain predefined actions to be interleaved with static web markup content, such as HTML. The resulting page is compiled and executed on the server to deliver a document. The compiled pages, as well as any dependent Java libraries, contain Java byte code rather than machine code. Like any other .jar or Java program, code must be executed within a Java virtual machine (JVM) that interacts with the server’s host operating system to provide an abstract, platform-neutral environment.
JSPs are usually used to deliver HTML and XML documents, but through the use of Output Stream, they can deliver other types of data as well.
The Web container creates JSP implicit objects like request, response, session, application, config, page, page Context, out and exception. JSP Engine creates these objects during translation phase.
JSP pages use several delimiters for scripting functions. The most basic is <% ... %>, which encloses a JSP script let. A script let is a fragment of Java code that runs when the user requests the page. Other common delimiters include <%= ... %> for expressions, where the script let and delimiters are replaced with the result of evaluating the expression, and directives, denoted with <%@ ... %>.
Java code is not required to be complete or self-contained within a single scriptlet block. It can straddle markup content, provided that the page as a whole is syntactically correct. For example, any Java if/for/while blocks opened in one scriptlet must be correctly closed in a later scriptlet for the page to successfully compile. This allows code to be intermingled and can result in poor programming practices.
Content that falls inside a split block of Java code (spanning multiple scriptlets) is subject to that code. Content inside an if block will only appear in the output when the if condition evaluates to true. Likewise, content inside a loop construct may appear multiple times in the output, depending upon how many times the loop body runs.