サーバの機能を拡張するJavaプログラム
一般的にはWebサーバのアプリケーション機能を拡張するために使用されるJ2EEコンポーネントの一つ
Webコンテナ或いはサーブレットエンジンとも呼ぶ
サーブレットの動作環境であり、WARファイルから成る
デプロイメントディスクリプタとも呼ぶXML形式のファイルで、アーカイブファイル毎に付加される
EJBコンポーネントが配備される動作環境であり、EJB JARファイルから成る
サーブレット・EJBコンポーネント・クライアントコンポーネントなどのJ2EEコンポーネントを、配備前にEARファイルとしてまとめておくこと
クライアントからのアクセスにより、サーブレットが一度メモリ内にロードされると、そのインスタンスはそのままメモリ上に常駐する
Javaであることによる拡張性・移植性も、CGIスクリプトの短所を補うと考えられる
javax.servlet.Servletインターフェースを実装
javax.servlet.GenericServletを継承
javax.servlet.http.HttpServletを継承
メモリにロードされたときにinit(servletConf)が、アンロードされるときにdestroy()が呼ばれる
ロードされている状態で、javax.servlet.SingleThreadModelを実装していない場合はマルチスレッドで動作する
javax.servlet.ServletConfigインターフェースに定義されているgetInitParameter(name) Servlet+ServletConfig<-GenericServlet<-HttpServlet
web.xmlにてinit-paramタグでparam-name/param-valueを文字列で指定 servletタグ内部でサーブレット別の初期化パラメータ設定
HTTPリクエストは、リクエスト行・ヘッダフィールド・ボディからなる
リクエスト行は、要求メソッド＜SP＞要求URL＜SP＞HTTPバージョン＜CR/LF＞
ヘッダフィールドは、一般ヘッダ・要求ヘッダ・エンティティヘッダから成る（Javaで"Status"という名のカスタムヘッダは格納できないようだ）
連続する＜CR/LF＞をはさんでボディとなり、たとえばPOST要求の場合、FORMデータがボディに格納される
HttpServletを継承する場合、HTTPリクエストを処理できる
service()メソッドはHTTPのどの要求でも処理できる。doGet()/doPost()/doPut()/doDelete()/doHead()/doOptions()などは、それぞれ一種のリクエストしか処理しない。
service()メソッドがあれば、doXXX()は無視される
HTTPパラメータ getParameterNames()/getParameter(name)/getParameterValues(name)
データ共有 getAttribute(name, value)/getAttribute(name)/getAttributeNames()/removeAttribute(name)
ヘッダ情報 getHeader(name)/getHeaders(name)/getHeaderNames()/getIntHeader()/getDateHeader()
要求URL情報 getContextPath()/getServletPath()/getRequestURI()/getRequestURL()
クッキー getCookies() セッション情報 getSession(bool) 文字コード指定 setCharacterEncoding(env)
出力チャネル getWriter()/getOutputStream()
ヘッダ情報 set:addHeader(name,value)/set:addIntHeader(name,ivalue)/set:addDateHeader(name,lvalue)/containsHeader(name)
コンテンツタイプ setCotentType(type) エラー sendError(code(,msg))/sendErrorCode()/setStatus(code)
クッキー addCookie(c) リダイレクトなど sendRedirect(url)/encodeURL(url)
クッキー情報の名前と値の一対がjavax.http.servlet.Cookieオブジェクトで表現
getName()/getValue()/setValue(value)/setMaxAge(ivalue)/getPath()/setPath(url)/getDomain()/setDomain(pattern)
getSecure()/setSecure(bool)では、ブラウザがセキュリティ保護されたプロトコル経由でのみクッキーを送信している場合は戻り値でtrue
HttpServletRequestは、Requestスコープでのデータ共有であるのに対し、HttpSessionはSessionスコープ・ServletContextはApplicationスコープのデータ共有を行う
setAttribute(name,value)/getAttribute(value)/removeAttribute(name)/getAttributeNmaes()
キーとして次のものは予約されているので使用不可 java./javax./sun./com.sun.ではじまるもの
ServletContext.getRequestDispatcher(path)
ServletContext.getNamedDispatcher(name)
ServletRequest.getRequestDispatcher(path)などで取得する
MVCパターンなどでサーブレットからJSPへの処理の委譲を行う転送機能 ＜jsp:forward＞
RequestDispatcher.forward(req,res)を使用して転送する
クライアントへの応答出力が実行される前に呼び出される必要があり、実行されている場合はIllegalStateExceptionとなる
指定した別リソースの出力内容をサーブレットの応答出力に組み込む機能 ＜jsp:include＞
RequestDispatcher.include(req.res)
Filterインターフェースを実装しweb.xmlへの登録を行うと、リクエストやレスポンスをフィルタリングするオブジェクトを作成できる
init(filterConf)/destroy()でのライフサイクルを持ち、doFilter(req,res,chain)が実行時に呼ばれる
引数として与えられたFilterChainオブジェクトに対して、doFilter(req,res)により次のフィルターを呼び出す
FilterConfigオブジェクトからはgetFilterName()/getInitParameter(name)/getInitParameterNames()/getServletContext()などが可能
インターフェースとして、Filter/FilterChain/FilterConfig/RequestDispatcher/Servlet/ServletContextAttributeListener/ServletContextListener/ServletRequest/ServletResponse/SingleThreadModel
クラスとして、GenericServlet/ServletContextAttributeEvent/ServletContextEventなどがある
インターフェースとして、HttpServletRequest/HttpServletResponse/HttpSession/HttpSessionActivationListener/HttpSessionAttributeListener/HttpSessionBindingListener/HttpSessionListener
クラスとして、Cookie/HttpServlet/HttpSessionBindingEvent/HttpSessionEventなどがある
セッションオブジェクトの監視が行える web.xmlへ登録
HttpSessionListenerより、sessionCreated(e)/sessionDestroyed(e)
HttpSessionAttributeListenerより、attributeAdded(HttpSessionBindingEvent e)/attributeRemoved(e)/attributeReplaced(e)
HttpSessionBindingListenerより、valueBound(HttpSessionBindingEvent e)/valueUnbound(e)
HttpSessionActivationListenerより、sessionWillPassivate(HttpSessionEvent e)/sessionDidActivate(e)
HttpServletRequest.getSession()/getSession(bool)により取得
データ共有以外に、getId()/getServletContext()/invalidate()/isNew()/getCreationTime()/getLastAccessedTime()/getMaxInactiveInterval()/setMaxInactiveInterval(interval)などがある
クッキーが使用できないクライアントに対しては、セッションIDを送信するURLに付加してセッショントラッキングを利用できる
Servlet2.3仕様では、URL;jsessionid=＜セッションID＞のフォーマットとなる
encodeRedirectURL(url)/encodeURL(url)を利用してURLをエンコードする セッションIDをエンコードする必要があるかを判断するロジックを含む
１つのWebアプリケーションに対して１つ割り当てられるコンテキストで、サーブレットコンテナから提供される
サーブレットに対してgetServletContext()で取得し、データ共有以外にgetInitParameter(name)が可能
サーブレットコンテキストの監視が行える web.xmlへ登録
ServletContextListenerより、contextInitialized(ServletContextEvent e)/contextDestroyed(e)
ServletContextAttributeListenerより、attributeAdded(ServletContextAttributeEvent e)/attributeRemoved(e)/attributeReplaced(e)
web.xmlなどの設定ファイル コンテキストルート以下WEB-INFディレクトリに格納
EJBモジュール用のejb-jar.xml や エンタープライズアプリケーションモジュール用のapplication.xmlなどがある
デプロイ後の実際のフォルダ構造は、サーブレットコンテナ依存となり、Tomcatではserver.xmlにて設定
サーブレットであれJavaBeanであれ、サーブレットコンテナ上で展開されるJavaクラスはWEB-INF/classes以下に格納されなくてはいけない
Jarアーカイブのライブラリとして展開される場合、WEB-INF/lib/などに格納する
JDBCドライバやカスタムタグのようなものは、上位のクラスパスに格納したほうがよい
サーブレット初期化パラメータと同様であるが、コンテキスト全体のパラメータとして使用される ServletContext.getInitParameter()
＜context-param＞タグにparam-name/param-valueを指定する
JNDI検索などのバインディングに有用
宣言によるセキュリティ（Declarative Security）とプログラムによるセキュリティ（Programmatic Security）に分類
宣言によるセキュリティでは、デプロイメント記述子によるセキュリティ設定を行い、「誰が何を実行できるかできないか」を設定できる
これに対し、ユーザーは認証と許可を通過する事によってアプリケーションを実行できる
ほとんどのコンテナは、以下の4種類の認証を設定可能である
web.xmlにて＜login-config＞タグ内、auth-methodにてrealm-nameと共に指定
基本認証（Basic Authentication） BASICと指定 ブラウザの入力画面にてユーザーIDとパスワードを入力 パスワードはBase64エンコードのみであり、SSLと組み合わせるケースが多い
ダイジェスト認証（Digest Authentication） DIGESTと指定 基本認証と同じくユーザーIDとパスワードを入力 ただしパスワードを暗号化 HTTP/1.1からの機能である
フォームベース認証（Form-Based Authentication） FORMと指定 独自のログイン画面を用意 暗号化されずBase64エンコードのみ form-login-configタグに、form-login-page/form-error-pageを指定
クライアント証明書認証（Client Certificate Authentication） CLIENT-CERTと指定 HTTPSすなわちSSLを用いる 商用認証機関から「サーバ証明書」と必要なクライアント数だけ「クライアント証明書」を購入する必要あり
realm-nameで設定するレルムは、同一コンテナ上の複数のWebアプリケーションで同じ名前を設定可能
ユーザーIDとは別のアプリケーション毎のセキュリティロールを設定する ＜security-role＞タグ内、role-nameで設定し、ユーザーIDと紐付ける
「認証」を通過したあとの「許可」のためのルールは、「セキュリティ制約」と呼ばれる
＜security-constraint＞タグにて、web-resource-collection/auth-constraint/user-data-constraintなどを設定
web-resource-collectionでは、リソース名と適応されるURLパターン及びHTTPメソッドを記述できる（複数のURL指定可）
auth-constraintでは、role-nameを指定する（複数可）
HttpServletRequestに対して、getUserPrincipal()にてjava.security.Principal型のオブジェクト ユーザーIDを取得できる
HttpServletRequestに対して、isUserInRole()メソッドで、ログインユーザーが引数で指定したロールを持つかどうかを調べることができる
user-data-constraintでは、transport-guaranteeとしてCONFIDENTIALまたはNONEを指定 データの機密性や完全性を保証する必要がある際に指定
