Monday, March 26, 2012

java topics


Section 1: Fundamental Object-Oriented Concepts
  • Describe, compare, and contrast primitives (integer, floating point, boolean, and character), enumeration types, and objects.
  • Describe, compare, and contrast concrete classes, abstract classes, and interfaces, and how inheritance applies to them.
  • Describe, compare, and contrast class compositions, and associations (including multiplicity: (one-to-one, one-to-many, and many-to-many), and association navigation.
  • Describe information hiding (using private attributes and methods), encapsulation, and exposing object functionality using public methods; and describe the JavaBeans conventions for setter and getter methods.
  • Describe polymorphism as it applies to classes and interfaces, and describe and apply the "program to an interface" principle.
Section 2: Java Implementation of Object-Oriented Concepts
  • Notes: code examples may use the 'new' operator.
  • Develop code that uses primitives, enumeration types, and object references, and recognize literals of these types.
  • Develop code that declares concrete classes, abstract classes, and interfaces, code that supports implementation and interface inheritance, code that declares instance attributes and methods, and code that uses the Java access modifiers: private and public.
  • Develop code that implements simple class associations, code that implements multiplicity using arrays, and recognize code that implements compositions as opposed to simple associations, and code that correctly implements association navigation.
  • Develop code that uses polymorphism for both classes and interfaces, and recognize code that uses the "program to an interface" principle.
Section 3: Algorithm Design and Implementation
  • Describe, compare, and contrast these three fundamental types of statements: assignment, conditional, and iteration, and given a description of an algorithm, select the appropriate type of statement to design the algorithm.
  • Given an algorithm as pseudo-code, determine the correct scope for a variable used in the algorithm, and develop code to declare variables in any of the following scopes: instance variable, method parameter, and local variable.
  • Given an algorithm as pseudo-code, develop method code that implements the algorithm using conditional statements (if and switch), iteration statements (for, for-each, while, and do-while), assignment statements, and break and continue statements to control the flow within switch and iteration statements.
  • Given an algorithm with multiple inputs and an output, develop method code that implements the algorithm using method parameters, a return type, and the return statement, and recognize the effects when object references and primitives are passed into methods that modify them.
  • Given an algorithm as pseudo-code, develop code that correctly applies the appropriate operators including assignment operators (limited to: =, +=, -=), arithmetic operators (limited to: +, -, *, /, %, ++, --), relational operators (limited to: <, <=, >, >=, ==, !=), logical operators (limited to: !, &&, ||) to produce a desired result. Also, write code that determines the equality of two objects or two primitives.
  • Develop code that uses the concatenation operator (+), and the following methods from class String: charAt, indexOf, trim, substring, replace, length, startsWith, and endsWith.
Section 4: Java Development Fundamentals
  • Describe the purpose of packages in the Java language, and recognize the proper use of import and package statements.
  • Demonstrate the proper use of the "javac" command (including the command-line options: -d and -classpath), and demonstrate the proper use of the "java" command (including the command-line options: -classpath, -D and -version).
  • Describe the purpose and types of classes for the following Java packages: java.awt, javax.swing, java.io, java.net, java.util.
Section 5: Java Platforms and Integration Technologies
  • Distinguish the basic characteristics of the three Java platforms: J2SE, J2ME, and J2EE, and given a high-level architectural goal, select the appropriate Java platform or platforms.
  • Describe at a high level the benefits and basic characteristics of RMI.
  • Describe at a high level the benefits and basic characteristics of JDBC, SQL, and RDBMS technologies.
  • Describe at a high level the benefits and basic characteristics of JNDI, messaging, and JMS technologies.
Section 6: Client Technologies
  • Describe at a high level the basic characteristics, benefits and drawbacks of creating thin-clients using HTML and JavaScript and the related deployment issues and solutions.
  • Describe at a high level the basic characteristics, benefits, drawbacks, and deployment issues related to creating clients using J2ME midlets.
  • Describe at a high level the basic characteristics, benefits, drawbacks, and deployment issues related to creating fat-clients using Applets.
  • Describe at a high level the basic characteristics, benefits, drawbacks, and deployment issues related to creating fat-clients using Swing.
Section 7: Server Technologies
  • Describe at a high level the basic characteristics of: EJB, servlets, JSP, JMS, JNDI, SMTP, JAX-RPC, Web Services (including SOAP, UDDI, WSDL, and XML), and JavaMail.
  • Describe at a high level the basic characteristics of servlet and JSP support for HTML thin-clients.
  • Describe at a high level the use and basic characteristics of EJB session, entity and message-driven beans.
  • Describe at a high level the fundamental benefits and drawbacks of using J2EE server-side technologies, and describe and compare the basic characteristics of the web-tier, business-tier, and EIS tier.

Monday, March 22, 2010

Medical Billing Process (United States)

Medical billing is the process of submitting and following up on claims to insurance companies in order to receive payment for services rendered by a healthcare provider. The same process is used for most insurance companies, whether they are private companies or government-owned. Medical billers are strongly encouraged, but not required by law to become certified by taking an exam such as the Certified Medical Reimbursement Specialist Exam (CMRS Exam).
Contents
1 Billing Process
2 Electronic Billing Process
3 Payment
4 History
5 HIPAA
6 Patient Demographics
7 References

Billing Process

The medical billing process is an interaction between a healthcare provider and the insurance company (payer). The interaction begins with the office visit: A doctor or their staff will typically create or update the patient's medical record. This record contains a summary of treatment and demographic information(patients name,address,social security number,home telephone number,work telephone number,policy identity number for the respective insurance holded by the patient...if the patient is minor the guarantor information should be updated) related to the patient. Upon the first visit, the provider will usually give the patient one or more diagnoses in order to better coordinate and streamline his/her care. In the absence of a definitive diagnosis, the reason for the visit will be cited for the purpose of claims filing. The patient record contains highly personal information: the nature of illness, examination details, medication lists, diagnoses, and suggested treatment.
The extent of the physical examination, the complexity of the medical decision making and the background information (history) obtained from the patient are evaluated to determine the correct level of service that will be used to bill the insurance. The level of service, once determined by qualified staff is translated into a five digit procedure code from the Current Procedural Terminology. The verbal diagnosis is translated into a numerical code as well, drawn from the ICD-9-CM. These two codes, a CPT and an ICD-9-CM, are equally important for claims processing.
Once the procedure and diagnosis codes are determined, the medical biller will transmit the claim to the insurance company (payer). This is usually done electronically by formatting the claim as an ANSI 837 file and using Electronic Data Interchange to submit the claim file to the payer directly or via a clearinghouse. Historically, claims were submitted using a paper form; in the case of professional (non-hospital) services and for most payers the CMS-1500 form or HICF (Health Insurance Claim Form)was and is still commonly used. The CMS-1500 form is so named for its originator, the Centers for Medicare and Medicaid Services. To this day about 30% of medical claims get sent to payers using paper forms which are either manually entered or entered using automated recognition or OCR software.
The insurance company (payer) processes the claims usually by medical claims examiners or medical claims adjusters. For higher dollar amount claims, the insurance company has medical directors review the claims and evaluate their validity for payment using rubrics(procedure) for patient eligibility, provider credentials, and medical necessity. Approved claims are reimbursed for a certain percentage of the billed services. These rates are pre-negotiated between the health care provider and the insurance company. Failed claims are rejected and notice is sent to provider. Most commonly, rejected claims are returned to providers in the form of Explanation of Benefits (EOB's) or Remittance Advice.
Upon receiving the rejection message the provider must decipher the message, reconcile it with the original claim, make required corrections and resubmit the claim. This exchange of claims and rejections may be repeated multiple times until a claim is paid in full, or the provider relents and accepts an incomplete reimbursement. Without Medical billing providers can no longer be getting paid for the services given by them and healthcare process cycle will be affected.
The frequency of rejections, denials, and over payments is high (often reaching 50%)(HBMA 7/07 [1]), mainly because of high complexity of claims and/or errors due to similarities in diagnosis' and their corresponding codes. This number may also be high due to insurance companies denying certain services that they do not cover (or think they can get away without covering) in which case small adjustments are made and the claim is re-sent. Finished no changes
Electronic Billing Process

A practice that has interactions with the patient must now under HIPAA send most billing claims for services via electronic means. Prior to actually performing service and billing a patient, the care provider may use software to check the eligibility of the patient for the intended services with the patient's insurance company. This process uses the same standards and technologies as an electronic claims transmission with small changes to the transmission format, this format is known specifically as X12-270 Health Care Eligibility & Benefit Inquiry transaction [2]. A response to an eligibility request is returned by the payer through a direct electronic connection or more commonly their website. It is called an X12-271 "Health Care Eligibility & Benefit Response" transaction. Most practice management/EMR software will automate this transmission, making them hidden from the user.
This first transaction for a claim for services is known technically as X12-837 or ANSI-837, and it contains a large amount of data regarding the provider interaction as well as reference information about the practice and the patient. Following that submission, the payer will respond with an X12-997, simply acknowledging that the claim's submission was received and that it was accepted for further processing. When the claim(s) are actually adjudicated by the payer, the payer will ultimately respond with a X12-835 transaction, which shows the line-items of the claim that will be paid or denied; if paid, the amount; and if denied, the reason.
Due to limited technology, many payers (especially states' Medicaid) still adjudicate claims manually; this results in significant delays — up to 48 hours or even weeks to issue 835 responses to properly submitted 837 transactions. In many cases this manual processing subverts the entire point of Congress in mandating a standardized electronic billing process. These delays can also present catastrophic problems to the availability of healthcare for those patients with difficult payers — such as happened in California with the state Medicaid program referred to as "Medi-cal"[3].
Payment

In order to be clear on the payment of a medical billing claim, the health care provider or medical biller must have complete knowledge of different insurance plans that insurance companies are offering, and the laws and regulations that preside over them. Large insurance companies can have up to 15 different plans contracted with one provider. When providers agree to accept an insurance company’s plan, the contractual agreement includes many details including fee schedules which dictate what the insurance company will pay the provider for covered procedures and other rules such as timely filing guidelines.
Providers typically charge more for services than what has been negotiated by the doctor and the insurance company, so the expected payment from the insurance company for services is reduced. The amount that is paid by the insurance is known as an allowable amount. For example, although a psychiatrist may charge $80.00 for a medication management session, the insurance may only allow $50.00, so a $30 reduction would be assessed. This is called a "provider write off" or "contractual adjustment." After payment has been made a provider will typically receive an Explanation of Benefits (EOB) or Electronic Remittance Advice (ERA) along with the payment from the insurance company that outlines these transactions.
The insurance payment is further reduced if the patient has a copay, deductible, or a coinsurance. If the patient in the previous example had a $5.00 copay, the doctor would be paid $45 by the insurance. The doctor is then responsible for collecting the out-of-pocket expense from the patient. If the patient had a $500.00 deductible, the contracted amount of $50 would not be paid by the insurance company. Instead, this amount would be the patient's responsibility to pay, and subsequent charges would also be the patient's responsibility, until his expenses totaled $500. At that point, the deductible is met, and the insurance would issue payment for future services.
A coinsurance is a percentage of the allowed amount that the patient must pay. It is most often applied to surgical and/or diagnostic procedures. Using the above example, a coinsurance of 20% would have the patient owing $10 and the insurance company owing $40.
In Medicare the physician can either be 'Participating' in which he will receive 80% of the allowable Medicare fee and 20% will be sent to the patient or can be 'Nonparticipating' in which the physician will receive 80% of the fee, and may bill patients for 15% or more on the scheduled amount.
For example the regular fee for a particular service is $100, while Medicare's fee structure is $70. Therefore the physician will get $56, and the patient will pay $14. Similarly Medicaid has its own set of policies which are slightly more complex than Medicare.
Steps have been taken in recent years to make the billing process clearer for patients. The Healthcare Financial Management Association (HFMA) unveiled a "Patient-Friendly Billing" project to help healthcare providers create more informative and simpler bills for patients. Additionally, as the Consumer-Driven Health movement gains momentum, payers and providers are exploring new ways to integrate patients into billing process in a clearer, more straightforward manner.[4]
History

For several decades, medical billing was done almost entirely on paper. However, with the advent of medical practice management software also known as health information systems it has become possible to efficiently manage large amounts of claims. Many software companies have arisen to provide medical billing software to this particularly lucrative segment of the market. Several companies also offer full portal solutions through their own web-interfaces, which negates the cost of individually licensed software packages.
Due to the rapidly changing requirements by U.S. health insurance companies, several aspects of medical billing and medical office management have created the necessity for specialized training. Medical office personnel may obtain certification through various institutions who may provide a variety of specialized education and in some cases award a certification credential to reflect professional status. The Certified Medical Reimbursement Specialist (CMRS) accreditation by the American Medical Billing Association is one of the most recognized of specialized certification for medical billing professionals.
HIPAA

The billing field has been challenged in recent years due to the introduction of the Health Insurance Portability and Accountability Act (HIPAA).
HIPAA is a set of rules and regulations which hospitals, doctors, healthcare providers and health plans must follow in order to provide their services aptly and ensure that there is no breach of confidence while maintaining patient records.
Since 2005, medical providers have been urged to electronically send their claims in compliance with HIPAA to receive their payment.
Title I of this Act protects health insurance of workers and their families when they change or lose a job. Title II calls for the electronic transmission of major financial and administrative dealings, including billing, electronic claims processing, as well as reimbursement advice.
Medical billing service providers and insurance companies were not the only ones affected by HIPAA regulations - many patients found that their insurance companies and health care providers required additional waivers and paperwork related to HIPAA.
As a result of these changes, software companies and medical offices spent thousands of dollars on new technology and were forced to redesign business processes and software in order to become compliant with this new act. If an insured claim is billed by another insured with a different name than that might be a big issue by the insurance companies.
Patient Demographics

The medical billing specialists enter patient, and if applicable guarantor demographic details such as name, date of birth, address, insurance details as provided by the patients at the time of the visit. For established patients, these details are validated.

References

  1. ^ Healthcare Billing and Management Association Publications HMBA Edition July 2007
  2. ^ CMS Glossary X12 270
  3. ^ Medi-cal delays deplete reserve fund California Healthline
  4. ^ http://www.healthharbor.com

Thursday, March 18, 2010

GWT

Friday, March 12, 2010

Difference between Servlet 2.5 and Servlet 2.4


Features of Servlet 2.4
  1. Upgraded supports for Http, J2SE, and J2EE: Servlet 2.4 depends on Http1.1 and J2SE 1.3.
  2. Additional ServletRequest methods : In Servlet 2.4 four new methods are added in the ServletRequest 
    • getRemotePort(): It returns the IP source port of the client.
    • getLocalName(): It returns the host name on which the request was recieved.
    • getLocalAddr(): It returns the IP addresson which the request was recieved. 
    • getLocalPort(): It returns the IP port number.
  3. New Support for internationalization and charset choice: For  the support of internationization Servlet 2.4 has added to new methods in the ServletReponse interface. 
    • setCharacterEncoding(String encoding): The purpose of this method is to set the response's character encoding.  This  method helps us to pass a charset parameter tosetContentType(String) or passing a Locale to setLocale(Locale). We can now avoid setting the charset in the setContentType("text/html;charset=UTF-8") assetCharacterEncoding() methods pairs with the preexistinggetCharacterEncoding() method to manipulate and view the response's character encoding.
       
    • getContentType(): It is responsible for returning the response's content type. The content type can be dynamically set with a combination of setContentType(),setLocale(), and setCharacterEncoding() calls, and the method getContentType()provides a way to view the generated type string. 
  4. New features has been added in RequestDispatcher: In Servlet 2.4 five new request attributes has been added to provide the extra information during a RequestDispatcherforward() call. This features has been added is Servlet 2.4 to know the true original request URI. The following request attributes are:
    • javax.servlet.forward.request_uri
    • javax.servlet.forward.context_path
    • javax.servlet.forward.servlet_path
    • javax.servlet.forward.path_info
    • javax.servlet.forward.query_string
  5. SingleThreadModel interface has been deprecated: In Servlet 2.4 the SingleThreadModel interface has been deprecated. 
  6. HttpSession details and interaction with logins has been clarified: The new method HttpSession.logout() has been added in the Servlet 2.4. Now session allows zero or negative values in the < session-timeout> element to indicate sessions should never time out.
    If the object in the session can't be serialized in a distributed environment then it must throw an IllegalArgumentException. 
  7. Welcome file behavior and Classloading has been clarified: In servlet 2.4 welcome file can be servlets. 
  8. The web.xml file now uses XML Schema: Version 2.4 servers must still accept the 2.2 and 2.3 deployment descriptor formats, but all new elements are solely specified in Schema.


Features of Servlet 2.5
This version has been released on September 26, 2005 by the Sun MicroSystems. It is not necessary that all web servers and application servers support the features of Servlet 2.5. Still most of the popular containers like Tomcat 5.5 and JBoss 4.0 still support Servlet 2.4
The list of the added features is given below:
  1. Dependency on J2SE 5.0: The minimum platform requirement for Servlet2.5 is JDK 1.5. Servet2.5 can't be used in versions below that JDK1.5. All the available features of Jdk1.5 like generics, autoboxing, an improved for loop etc, etc are guaranteed available to Servlet2.5programmers
  2. Support For annotations: Annotations provide a mechanism for decorating java codeconstructs (classes, methods, fields, etc.) with metadata information. Annotations are mark code in such a way that code processors may alter their behavior based on the metadata information. 
  3. Several web.xml convenience: Servlet 2.5 introduces several small changes to the web.xml file to make it more convenient to use.  For example while writing a , we can now use a asterisk in a which will represent all servlets as well as Jsp.

    Previously we used to do

    < filter-mapping>
    < filter-name>FilterName
    < servlet-name>FilterName

    < /filter-mapping> 

    Now,

    < filter-mapping>
    < filter-name>FilterName
    < servlet-name>*
    < /filter-mapping>
     

    Previously in < servlet-mapping> or < filter-mapping> there used to be only one < url-pattern>, but now we can have multiple < url-pattern>, like

    < servlet-mapping>
        < servlet-name>abc< /servlet-name>
        < url-pattern>/abc/*< /url-pattern>
        < url-pattern>/abc/*< /url-pattern>
    < /servlet-mapping> 

    Apart from these changes, many more facilities added in web.xml. 
  4. A Handful of removed restrictions: Servlet 2.5 removed a few restrictions around error handling and session tracking. Now it has removed the restriction that the could not call the setStatus() method to alter the error code that triggered them. In session tracking, Servlet 2.5 eased a rule that a servlet called by RequestDispatcher include() couldn't set response headers. 
  5. Some edge case clarifications: : The servlet2.4 specification says that before callingrequest.getReader() we  must call request.setCharacterEncoding().  However there is no such clarification given why it is so. It has been described properly in Servlet 2.5.

Thursday, March 11, 2010

Java Servlets


Java Servlets are server side components that provides a powerful mechanism for developing server side of web application. Earlier CGI was developed to provide server side capabilities to the web applications. Although CGI played a major role in the explosion of the Internet, its performance, scalability and reusability issues make it less than optimal solutions. Java Servlets changes all that. Built from ground up using Sun's write once run anywhere technology java servlets provide excellent framework for server side processing.
   With Java servlets web developers can create fast and efficient server side application   and can run it on any Servlet enabled web server. Servlets runs entirely inside the Java Virtual Machine. Because the Servlet is running on the server side, it does not depend on browser compatibility. I just send the result in html formats.
    Java Servlets have a number of advantages over CGI and other API's. They are:
  1. Platform Independence
    Java Servlets are 100% pure Java, so it is platform independent. It can run on any Servlet enabled web server. For example if you develop an web application in windows machine running Java web server. You can easily run the same on apache web server (if Apache Serve is installed) without modification or compilation of code. Platform independency of servlets provides a great advantage over alternatives of servlets.
  2. Performance
    Due to interpreted nature of java, programs written in java are slow. But the java servlets runs very fast. These are due to the way servlets run on web server. For any program initialization takes significant amount of time. But in case of servlets initialization takes place very first time it receives a request and remains in memory till times out or server shut downs. After servlet is loaded, to handle a new request it simply creates a new thread and runs service method of servlet. In comparison to traditional CGI scripts which creates a new process to serve the request. This intuitive method of servlets could be use to develop high speed data driven websites.
  3. Extensibility
    Java Servlets are developed in java which is robust, well-designed and object oriented language which can be extended or polymorphed into new objects. So the java servlets takes all these advantages and can be extended from existing class the provide the ideal solutions.
  4. Safety
    Java provides a very good safety features like memory management, exception handling etc. Servlets inherits all these features and emerged as a very powerful web server extension.
  5. Secure
    Servlets are server side components, so it inherits the security provided by the web server. Servlets are also benefited with Java Security Manager.
Java Servlet API
Java Servlet API contains two core packages:
  • javax.servlet
  • javax.servlet.http
     Servlets implement the javax.servlet.Servlet interface. The javax.servlet package contains the generic interfaces and classes that are implemented and extended by all servlets. While thejavax.servlet.http package contains the classes that are used when developing HTTP - specific servlets. The HttpServlet is extended from GenericServlet base class and it implements the Servlet interface. HttpServlet class provides a framework for handling the HTTP requests.
The  javax.servlet.Servlet defines five methods:
  1. service() metho called by servlet to handle the client request in a new thead. service() methos accepts ServletRequest and a ServletResponse ohjects as parameters. ServletRequestobject represents the client request. It contains the data sent in name/value pairs.ServletResponse object is used to send the response to the client.
  2. init() is called once when servlet is loaded. It is a good place to initialize global variables. This methos accepts ServletConfig as parameter which provides initialization arguments for the servlet.
  3. getServletConfig() returns the ServletConfig object passed to init().
  4. destory() is called when wervlet is unloaded from memory. This is a good place to clean up any resources(such as open files or database connections).
  5. getServletInfo() returns a string with version, copyright informations etc.

Installing Servlets
The servlet run inside a Web Server program. After it has been compiled, it must be installed onto Web Server in order to test it. Thus we have to follow the following steps:
  1. Install the servlet in a hosting server
  2. Request the servlet through web browser.
Java servlets are supported by a number of web servers. Java Web Server from JavaSoft was first servlet enabled web server. Now a days a number of web server supports java servlets. In this article we will use Java Web Server, whose evaluation copy can be downloaded fromhttp://jserv.javasoft.com . In order to compile your servlet you also need Java Servlet Development Kit (JSDK) which is available at same place.

Installing on Windows95 and Win NT
  1. Download the distribution of Java Web Server from http://www.javasoft.com/products . Distribution is in the form of self-extracting file.
  2. The Java Web Server can be installed in any directory, so you can choose your favorite directory for installation. Move the downloaded file into your favorite directory.
  3. To begin the installation just double-click on the self-extracting file and the file extract itself and then installation begins.
  4. Follow the instruction and complete the installation.
To run the Web Server go to your installation directory and then to bin directory and then double click httpd.exe. To test the Web Server open your browser and type http://localhost:8080 in address bar and then press enter. Browser should display default index.html into browser.

Links To Servlets Tutorials

Designing JSP Custom Tag Libraries


In this article you'll learn

  • what a custom tag library is,
  • why you want to use a custom tag library,
  • the composition of a tag library, and
  • how to build and use a complete library.

What a Custom Tag Library Is

If you've ever had the opportunity to build a web application using Java technology, chances are you have used Java Server Pages (JSP) for content display. JSP is the technology that helps separate the front end presentation from the middle and backend tiers. The custom tag library is a powerful feature of JSP v1.1 that aids in that separation. This technology is valuable to anyone who is building production-quality web applications, and it is very applicable in today's market.
Custom tag libraries allow the Java programmer to write code that provides data access and other services, and they make those features available to the JSP author in a simple to use XML-like fashion. An action in a web application -- for example, gaining database access -- can be customized by using a custom tag in a JSP page. The JSP author doesn't have to understand the underlying detail to complete the action. In short, a tag library is a collection of custom actions presented as tags.
Custom tags have many features that make them attractive to use from any JSP. Custom tags can
  • be customized via attributes passed from the calling page, either staticly or determined at runtime;
  • have access to all the objects available to JSP pages including request, response, in and out;
  • modify the response generated by the calling page;
  • communicate with each other; you can create and initialize a JavaBeans component, create a variable that refers to that bean in one tag, and then use the bean in another tag;
  • be nested within one another, allowing for complex interactions within a JSP page; and
  • encapsulate both simple and complex behaviors in an easy to use syntax and greatly simplify the readability of JSP pages.
Any of these points is reason enough to consider using a tag library.
Let's look at what makes up a tag library and build one step by step.

The Composition of a Tag Library

There are two types of components for a tag library: the tag library descriptor file and the tag handlers. With these a JSP is able to use tags contained in the library within its page.
The TLD File
A tag library descriptor (TLD) file is an XML document that describes the library. A TLD contains information about the library as a whole and about each tag contained in the library. TLDs are used by a JSP container to validate the tags.
There is typically some header information followed by elements used to define the tag library. The elements are
< taglib>
The tag library itself.
< tlibversion>
The tag library's version.
< jspversion>
The JSP specification version the tag library depends on.
< shortname>
A simple default name with a mnemonic value. For example, may be used as the preferred prefix value in taglib directives and/or to create prefixes for IDs.
< uri>
A optional URI that uniquely identifies the tag library.
< info>
Descriptive information about the tag library.

Then each tag contained in the library is described. There can be one or many tags per library. There is only one TLD element required for all tags, and that is the one used to specify a tag handler's class: < tagclass>classname
There are various other elements used to describe tags. Which elements a tag uses will depend on how the tag is implemented in the handler. We'll get to that discussion in the section below.
If a tag has attributes associated with it, then each attribute must be described within the < tag> element. If an attribute is required by a tag, < required> is set to "true" or "yes". To allow a runtime expression value to be used by the tag, the< rtexpvalue> is set to "true" or "yes". For each attribute of a tag, a Bean-like getter/setter method needs to be defined in the handler class. It's also possible to define scripting variables for use in tags. This is accomplished using a TagExtraInfo class and will be discussed in the tag handler section. If a TagExtraInfo is to be used, the class must be defined using the< teiclass>classname< teiclass> within the tag definition.

A sample TLD named oreillySample.tld looks like
< ?xml version="1.0" encoding="ISO-8859-1" ?>
< !DOCTYPE taglib PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.1//EN" 
"http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd">
< taglib>
 < tlibversion>1.0
 < jspversion>1.1
 < shortname>oreillySamples
 < info>OReilly Sample Tag library
  < !-A Simple tag -->
  < tag>
    < name>hello
    < tagclass>oreilly.examples.Hello < /tagclass>
  < !--Body content can have a value of 
    empty: no body 
      JSP: body that is evaluated by container, then possibly processed by the tag 
      tagdependent: body is only processed by tag; JSP in body is not evaluated.
   -- >
    < bodycontent>empty
    < info>
 This is a simple hello tag.
    < /info>
  < !-- Optional attributes  -->
  < !- personalized name -->
  < attribute>
      < name>name< /name>
      < required>false< /required>
      < rtexpvalue>false< /rtexpvalue>
  < /attribute>
< /tag>
< /taglib>
The Tag Handler
The tag is defined in a handler class. TagSupport is the base class used for simple tags. It can be found in thejavax.servlet.tagext package. What your tag is implementing will depend on what methods could potentially be called and what needs to be implemented. TagSupport and TagBodySupport supply default implementations of the methods listed below.

If your Tag Handler:
You need to implement the following methods:
has no attributes and no body
doStartTag, doEndTag, release
has attributes
doStartTag, doEndTag, set/getAttribute1...N
has a body with no interaction
doStartTag, doEndTag, release
has a body with interaction
doStartTag, doEndTag, release, doInitBody, doAfterBody

A more advanced feature is the use of scripting variables. Typically an attribute is passed to the tag that contains the ID of the object to be used. The usual operation is that the tag handler retrieves a scripting variable value object usingpageContext.getAttribute(name), performs some processing on it, and then sets the scripting variable's value using thepageContext.setAttribute(name, object). In addition to setting the value of the variable within the tag handler, you must define a class derived from TagExtraInfo that provides information to the JSP container about the nature of the variable. That class is then listed in the  attribute of the tag.
The Java code for the tag defined in the oreillySample.tld file would look like

package oreilly.examples
import javax.servlet.jsp.*;
import javax.servlet.jsp.tagext.*;
/**
 * This is a simple tag example to show how content is added to the
 * output stream when a tag is encountered in a JSP page. 
 */
public class Hello extends TagSupport {
 private String name=null;
    /**
      * Getter/Setter for the attribute name as defined in the tld file 
      * for this tag
      */
public void setName(String value){
    name = value;
}

 public String getName(){
          return(name);
       }
/**
* doStartTag is called by the JSP container when the tag is encountered
*/
    public int doStartTag() {
   try {
        JspWriter out = pageContext.getOut();
        out.println("< table border="\1\">");
      if (name != null)
       out.println("< tr>< td> Hello " + name + " < /td>< /tr>");
        else
       out.println("< tr>< td> Hello World < /td>< /tr>");
   } catch (Exception ex) {
     throw new Error("All is not well in the world.");
   }
   // Must return SKIP_BODY because we are not supporting a body for this 
   // tag.
   return SKIP_BODY;
    }
/**
 * doEndTag is called by the JSP container when the tag is closed
 */
 public int doEndTag(){
    try {
         JspWriter out = pageContext.getOut();
        out.println("< /table>");
    } catch (Exception ex){
      throw new Error("All is not well in the world.");
    }
 }
}
The JSP

Once your TLD and tag handlers are created, you can begin accessing the tags in your JSP. You declare that a JSP page will use tags defined in a tag library by including a taglib directive in the page before any custom tag is used. The prefix attribute is a shortcut to referencing the library throughout the page.
Sample Hello.jsp:
< %@ taglib uri="/oreillySample.tld" prefix="sample" %>
< html>
        < head>
                < title>Your Standard Hello World Demo
        < /head>
        < body bgcolor="#ffffff">
                < hr />
                < sample:hello name="Sue"/>
                < hr />
        < /body>
< /html>
The HTML source output from this JSP would look like:
< html>
        < head>
                < title>Your Standard Hello World Demo< /title>
        < /head>
        < body bgcolor="#ffffff">
                < hr />
        < table border="1">
          < tr>< td> Hello Sue < /td>< /tr>
                < /table>
                < hr />
        < /body>
< /html>
You can see how the tag was evaluated and the contents of the tag inserted into the output stream.
If you wanted to add functionality to our tag to make it more flexible, say to evaluate a body a certain number of times and make the name attribute evaluated at runtime, you can do so fairly easily with a few changes. First you would make the following changes to the TLD file. The tag definition would look like
  < tag>
    < name>hello
    < tagclass>oreilly.examples.Hello < /tagclass>
 < !-- Allow for a body to be included for this tag -->
    < bodycontent>JSP
    < info>
 This is a simple hello tag.
    < /info>
    
    < !-- Optional attributes  -->
    < !-- personalized name -->
    < attribute>
      < name>name< /name>
      < required>false< /required> 
    < rtexpvalue>true< /rtexpvalue>
    < /attribute>
    < !-allow for the jsp coder to specify how many times to iterate -->
    < attribute>
      < name>iterations< /name>
      < required>false< /required> 
    < rtexpvalue>false< /rtexpvalue>
    < /attribute>

< /tag>
Then you must alter the handler class by extending TagBodySupport and implementing the body methods if you wanted different behavior from that provided in the base class implementation. The handler class would now look like
public class Hello extends BodyTagSupport {
 private String name=null;
    private int iterations=1;

 /**
     * Getter/Setter for the attribute name as defined in the tld file 
     * for this tag
     */
 public void setName(String value){
  name = value;
 }

 public String getName(){
  return(name);
 }
 /**
     * Getter/Setter for the attribute iterations as defined in the tld file 
     * for this tag
     */

 public void setIterations(String value){
     try {
       iterations = Integer.parseInt(value);
     } catch(NumberFormatException nfe) {
       iterations = 1;
     } 
   }

 public String getIterations(){
  return(Integer.toString(iterations));
 }

    public int doStartTag() throws JspTagException{
   try {
        JspWriter out = pageContext.getOut();
        out.println("< table border=\"1\">");
      if (name != null)
       out.println("< tr>< td> Hello " + name + " < /td>< /tr>");
        else 
       out.println("< tr>< td> Hello World < td>< /tr>");
   } catch (Exception ex) {
     throw new JspTagException("All is not well in the world." + ex );
   }
   // Evaluate the body if there is one
   return EVAL_BODY_TAG;
    }

 public int doEndTag()throws JspTagException {
    try {
         JspWriter out = pageContext.getOut();
        out.println("< /table>");
    } catch (Exception ex){
      throw new JspTagException("All is not well in the world." + ex);
    }
 }

 public int doAfterBody() throws JspTagException {
    if (iterations-- >= 1) {
      BodyContent body = getBodyContent();
      try {
  // Make sure we put anything in the output stream in the 
  // body to the output stream of the JSP
        JspWriter out = body.getEnclosingWriter();
        out.println(body.getString());
        body.clearBody(); // Clear for next evaluation
      } catch(IOException ioe) {
        throw new JspTagException("Error in Hello tag doAfterBody " + ioe);
      }
      return(EVAL_BODY_TAG);
    } else {
      return(SKIP_BODY); 
 }
}
Now let's make the simple changes in the JSP file. Our sample Hello.jsp looks like
< %@ taglib uri="/oreillySample.tld" prefix="sample" %>
< %!
    // allow a username to be passed in the request
    String userName = request.getParameter("NAME");
% >

< html>
        < head>
                < title>Your Standard Hello World Demo < /title>
        < /head>
        < body bgcolor="#ffffff">
                < hr />
                < sample:hello name="" iterations="2" >
   < tr>< td>Have a nice day< /b>< /td>
   < /sample:hello>
                < hr />
        < /body>
< /html>
If our JSP page was called like hello.jsp?NAME=Sue our output would look like
< html>
        < head>
                < title>Your Standard Hello World Demo
        < / head>
        < body bgcolor="#ffffff">
                < hr />
        < table border="1">
          < tr>< td> Hello Sue < /td>< /tr>
     < tr>< td>< b>Have a nice day< /b>< /td>< /tr>
     < tr>< td>< b>Have a nice day< /b>< /td>< /tr>
                < /table>
                < hr />
        < /body>
< /html>
This simple example is but a small glimpse at the power of custom tag libraries. We examined how to create and use a simple tag library and then easily extend its functionality. The next article will examine some of the advanced features of tags, including defining scripting variables and cooperating tags. It will also go through working examples of each.