An object with properties that describe the object's stat us or error condition.
The information object could have a code property containing a string that represents a specific event or a level property containing a string that is either "status" or "error".
The information object could also be something different. The code and level properties might not work for some implementations and some servers might send different objects.
P2P connections send messages to a NetConnection with a stream parameter in the information object that indicates which NetStream the message pertains to.
For example, Flex Data Services sends Message objects that cause coercion errors if you try to access the code or level property.
The following table describes the possible string values of the code and level properties.

Code property

Level property

Meaning

"NetConnection.Call.BadVersion"

"error"

Packet encoded in an unidentified format.

"NetConnection.Call.Failed"

"error"

The NetConnection.call() method was not able to invoke the server-side method or command.

"NetConnection.Call.Prohibited"

"error"

An Action Message Format (AMF) operation is prevented for security reasons. Either the AMF URL is not in the same domain as the file containing the code calling the NetConnection.call() method, or the AMF server does not have a policy file that trusts the domain of the the file containing the code calling the NetConnection.call() method.

"NetConnection.Connect.AppShutdown"

"error"

The server-side application is shutting down.

"NetConnection.Connect.Closed"

"status"

The connection was closed successfully.

"NetConnection.Connect.Failed"

"error"

The connection attempt failed.

"NetConnection.Connect.IdleTimeout"

"status"

Flash Media Server disconnected the client because the client was idle longer than the configured value for <MaxIdleTime>. On Flash Media Server, <AutoCloseIdleClients> is disabled by default. When enabled, the default timeout value is 3600 seconds (1 hour). For more information, see Close idle connections.

"NetConnection.Connect.InvalidApp"

"error"

The application name specified in the call to NetConnection.connect() is invalid.

"NetConnection.Connect.NetworkChange"

"status"

Flash Player has detected a network change, for example, a dropped wireless connection, a successful wireless connection,or a network cable loss.

Use this event to check for a network interface change. Don't use this event to implement your NetConnection reconnect logic. Use "NetConnection.Connect.Closed" to implement your NetConnection reconnect logic.

"NetConnection.Connect.Rejected"

"error"

The connection attempt did not have permission to access the application.

"NetConnection.Connect.Success"

"status"

The connection attempt succeeded.

"NetGroup.Connect.Failed"

"error"

The NetGroup connection attempt failed. The info.group property indicates which NetGroup failed.

"NetGroup.Connect.Rejected"

"error"

The NetGroup is not authorized to function. The info.group property indicates which NetGroup was denied.

"NetGroup.Connect.Succcess"

"status"

The NetGroup is successfully constructed and authorized to function. The info.group property indicates which NetGroup has succeeded.

"NetGroup.LocalCoverage.Notify"

"status"

Sent when a portion of the group address space for which this node is responsible changes.

"NetGroup.MulticastStream.PublishNotify"

"status"

Sent when a new named stream is detected in NetGroup's Group. The info.name:String property is the name of the detected stream.

"NetGroup.MulticastStream.UnpublishNotify"

"status"

Sent when a named stream is no longer available in the Group. The info.name:String property is name of the stream which has disappeared.

"NetGroup.Neighbor.Connect"

"status"

Sent when a neighbor connects to this node. The info.neighbor:String property is the group address of the neighbor. The info.peerID:String property is the peer ID of the neighbor.

"NetGroup.Neighbor.Disconnect"

"status"

Sent when a neighbor disconnects from this node. The info.neighbor:String property is the group address of the neighbor. The info.peerID:String property is the peer ID of the neighbor.

"NetGroup.Posting.Notify"

"status"

Sent when a new Group Posting is received. The info.message:Object property is the message. The info.messageID:String property is this message's messageID.

"NetGroup.Replication.Fetch.Failed"

"status"

Sent when a fetch request for an object (previously announced with NetGroup.Replication.Fetch.SendNotify) fails or is denied. A new attempt for the object will be made if it is still wanted. The info.index:Number property is the index of the object that had been requested.

"NetGroup.Replication.Fetch.Result"

"status"

Sent when a fetch request was satisfied by a neighbor. The info.index:Number property is the object index of this result. The info.object:Object property is the value of this object. This index will automatically be removed from the Want set. If the object is invalid, this index can be re-added to the Want set with NetGroup.addWantObjects().

"NetGroup.Replication.Fetch.SendNotify"

"status"

Sent when the Object Replication system is about to send a request for an object to a neighbor.The info.index:Number property is the index of the object that is being requested.

"NetGroup.Replication.Request"

"status"

Sent when a neighbor has requested an object that this node has announced with NetGroup.addHaveObjects(). This request must eventually be answered with either NetGroup.writeRequestedObject() or NetGroup.denyRequestedObject(). Note that the answer may be asynchronous. The info.index:Number property is the index of the object that has been requested. The info.requestID:int property is the ID of this request, to be used by NetGroup.writeRequestedObject() or NetGroup.denyRequestedObject().

"NetGroup.SendTo.Notify"

"status"

Sent when a message directed to this node is received. The info.message:Object property is the message. The info.from:String property is the groupAddress from which the message was received. The info.fromLocal:Boolean property is TRUE if the message was sent by this node (meaning the local node is the nearest to the destination group address), and FALSE if the message was received from a different node. To implement recursive routing, the message must be resent with NetGroup.sendToNearest() if info.fromLocal is FALSE.

"NetStream.Buffer.Empty"

"status"

Flash Player is not receiving data quickly enough to fill the buffer. Data flow is interrupted until the buffer refills, at which time a NetStream.Buffer.Full message is sent and the stream begins playing again.

"NetStream.Buffer.Flush"

"status"

Data has finished streaming, and the remaining buffer is emptied.

"NetStream.Buffer.Full"

"status"

The buffer is full and the stream begins playing.

"NetStream.Connect.Closed"

"status"

The P2P connection was closed successfully. The info.stream property indicates which stream has closed.

"NetStream.Connect.Failed"

"error"

The P2P connection attempt failed. The info.stream property indicates which stream has failed.

"NetStream.Connect.Rejected"

"error"

The P2P connection attempt did not have permission to access the other peer. The info.stream property indicates which stream was rejected.

"NetStream.Connect.Success"

"status"

The P2P connection attempt succeeded. The info.stream property indicates which stream has succeeded.

"NetStream.DRM.UpdateNeeded"

"status"

A NetStream object is attempting to play protected content, but the required Flash Access module is either not present, not permitted by the effective content policy, or not compatible with the current player. To update the module or player, use the update() method of flash.system.SystemUpdater.

"NetStream.Failed"

"error"

(Flash Media Server) An error has occurred for a reason other than those listed in other event codes.

"NetStream.MulticastStream.Reset"

"status"

A multicast subscription has changed focus to a different stream published with the same name in the same group. Local overrides of multicast stream parameters are lost. Reapply the local overrides or the new stream's default parameters will be used.

"NetStream.Pause.Notify"

"status"

The stream is paused.

"NetStream.Play.Failed"

"error"

An error has occurred in playback for a reason other than those listed elsewhere in this table, such as the subscriber not having read access.

"NetStream.Play.FileStructureInvalid"

"error"

(AIR and Flash Player 9.0.115.0) The application detects an invalid file structure and will not try to play this type of file.

"NetStream.Play.InsufficientBW"

"warning"

(Flash Media Server) The client does not have sufficient bandwidth to play the data at normal speed.

"NetStream.Play.NoSupportedTrackFound"

"error"

(AIR and Flash Player 9.0.115.0) The application does not detect any supported tracks (video, audio or data) and will not try to play the file.

"NetStream.Play.PublishNotify"

"status"

The initial publish to a stream is sent to all subscribers.

"NetStream.Play.Reset"

"status"

Caused by a play list reset.

"NetStream.Play.Start"

"status"

Playback has started.

"NetStream.Play.Stop"

"status"

Playback has stopped.

"NetStream.Play.StreamNotFound"

"error"

The file passed to the NetStream.play() method can't be found.

"NetStream.Play.Transition"

"status"

(Flash Media Server 3.5) The server received the command to transition to another stream as a result of bitrate stream switching. This code indicates a success status event for the NetStream.play2() call to initiate a stream switch. If the switch does not succeed, the server sends a NetStream.Play.Failed event instead. When the stream switch occurs, an onPlayStatus event with a code of "NetStream.Play.TransitionComplete" is dispatched. For Flash Player 10 and later.

"NetStream.Play.UnpublishNotify"

"status"

An unpublish from a stream is sent to all subscribers.

"NetStream.Publish.BadName"

"error"

Attempt to publish a stream which is already being published by someone else.

"NetStream.Publish.Idle"

"status"

The publisher of the stream is idle and not transmitting data.

"NetStream.Publish.Start"

"status"

Publish was successful.

"NetStream.Record.AlreadyExists"

"status"

The stream being recorded maps to a file that is already being recorded to by another stream. This can happen due to misconfigured virtual directories.

"NetStream.Record.Failed"

"error"

An attempt to record a stream failed.

"NetStream.Record.NoAccess"

"error"

Attempt to record a stream that is still playing or the client has no access right.

"NetStream.Record.Start"

"status"

Recording has started.

"NetStream.Record.Stop"

"status"

Recording stopped.

"NetStream.Seek.Failed"

"error"

The seek fails, which happens if the stream is not seekable.

"NetStream.Seek.InvalidTime"

"error"

For video downloaded progressively, the user has tried to seek or play past the end of the video data that has downloaded thus far, or past the end of the video once the entire file has downloaded. The info.details property of the event object contains a time code that indicates the last valid position to which the user can seek.

"NetStream.Seek.Notify"

"status"

The seek operation is complete.

Sent when NetStream.seek() is called on a stream in AS3 NetStream Data Generation Mode. The info object is extended to include info.seekPoint which is the same value passed to NetStream.seek().

"NetStream.Step.Notify"

"status"

The step operation is complete.

"NetStream.Unpause.Notify"

"status"

The stream is resumed.

"NetStream.Unpublish.Success"

"status"

The unpublish operation was successfuul.

"SharedObject.BadPersistence"

"error"

A request was made for a shared object with persistence flags, but the request cannot be granted because the object has already been created with different flags.

"SharedObject.Flush.Failed"

"error"

The "pending" status is resolved, but the SharedObject.flush() failed.

"SharedObject.Flush.Success"

"status"

The "pending" status is resolved and the SharedObject.flush() call succeeded.

"SharedObject.UriMismatch"

"error"

An attempt was made to connect to a NetConnection object that has a different URI (URL) than the shared object.

If you consistently see errors regarding the buffer, try changing the buffer using the NetStream.bufferTime property.
See Also:
NetConnection class
NetStream class
NetGroup class
Language Version:
3.0
Player Version:
Flash 9, Lite 4


AND

출처 : http://www.adobe.com/devnet/flashmediaserver/articles/calculating_bandwidth.html 

If you want to incorporate audio, video, or both into your web applications, you should first develop a bandwidth strategy. The purpose of it is to ensure that the total amount of bandwidth served by Flash Media Server and consumed by each client is sufficient to deliver the quality of service you want, is in line with the physical hardware limitations and software licenses you have, and can accommodate various levels of traffic. Like any good functional specification, a bandwidth strategy should highlight any problem areas up front before you purchase systems or develop your application.

If you have not developed your bandwidth strategy yet, this article will help you out. It examines ways you can estimate your application's bandwidth to help determine your software license needs for Flash Media Server.

The amount of peak bandwidth used by Flash Media Server depends on a number of factors, such as the bandwidth that users connect at, the bandwidth in your pipeline, the bandwidth of the audio and video streams, and, of course, the type of application you develop—is it a one-way streaming application or a two-way/multi-way chat application?

To estimate the bandwidth that your Flash Media Server application will use, you will need to know the following:

  • Number of simultaneous users your application must support at peak load
  • Data transmission speed at which you expect your users to connect (what percent of users will be on a 56 Kbps dial-up connection, cable/DSL, or a LAN?)
  • Number of audio/video streams your application will support per user
  • Limitations of the server hardware and Internet connection
  • Target encoding rate of the audio and video streams in your application

At this point you should also have a relatively firm idea of the functionality of your application and how users will be interacting with it. Now you need to figure out how to calculate your application's overall bandwidth.

Bandwidth calculations

You can easily estimate bandwidth for two different types of applications: a one-to-many application, such a video-on-demand system; and a many-to-many application, such as a video conferencing application. For each example you can follow a simple formula for calculating both the server bandwidth (required to determine the number of software licenses you need) and the client bandwidth (calculated as part of your bandwidth strategy to ensure good quality of service to each client).

Example 1: One to many

This sample application is a one-way video-on-demand system that streams recorded video at the user's request. Flash Media Server serves only one stream to each user (see Figure 1).

 

 

Figure 1. One-to-many video-on-demand system
Bandwidth calculations

Here are the bandwidth calculations you would make:

  • Calculating server bandwidth needs (BWs):
    BWs = N × S
    N = number of simultaneous users (subscribers)
    S = average bitrate of encoded A/V content
  • Calculating client bandwidth needs (BWc):
    BWc = S
    S = average bitrate of encoded A/V content
Sample calculation

Calculate the overall server bandwidth needed to stream video encoded at 500 Kbps to 1000 simultaneous users:

500 Mbps = 1000 × 500 Kbps

This calculation determines the overall bandwidth and can help you determine how many servers and licenses are needed. For example, if your server hardware configuration is capable of 600 Mbps throughput, you would need only one server and license.

Of course, if you wanted to stream to more users, you would need as many servers and licenses as are required to cover your overall server bandwidth. For example, 10,000 simultaneous users will require the following:

5000 Mbps = 10,000 × 500 Kbps

Assuming each server configuration is capable of 600 Mbps, you would need:

8.3 = 5000 Mbps ÷ 600 Mbps

This rounds up to nine servers and licenses.

Adjusting the calculation for multiple bitrates

The preceding calculations assume that content is encoded at a constant bitrate. Most often, however, you will vary the bitrate of the content to suit the viewing audience. This affects your bandwidth needs at both the client and server level.

For example, suppose in the previous example you estimated that half of the 1000 simultaneous users were going to connect via 350 Kbps DSL modem and the other half via 3 Mbps cable modem. Suppose further that while the video encoded at 500 Kbps was appropriate for the cable viewers, you wanted to encode a separate video at 150 Kbps for the DSL modem users.

In this case, the total bandwidth required of the system is lowered to 325 Mbps:

325 Mbps = (500 Kbps × 500) + (150 Kbps × 500)

Example 2: Many to many

This example shows a number of people connect to an online conference room. While in the conference room, each person is broadcasting their own audio and video (via a webcam, for example) while receiving the audio and video broadcasts from others in the room (see Figure 2).

 

 

Figure 2. Many-to-many video/audio conferencing

Calculating the bandwidth estimates here is very similar to Example 1. However, the number of streams increases exponentially. In this case, Flash Media Server needs to serve x2 number of streams where x is the number of simultaneous users in a room.

For example, if there were four people in a room, the first person would send (publish) one stream and receive three other streams for a total of four streams. Likewise, the second, third, and fourth persons would also consume four streams each. Therefore the total number of streams that Flash Media Server serves in this case is 16—four people using four streams each, or (thought about in a slightly different manner) four publishers of streams and four consumers or subscribers of streams.

Bandwidth calculations

Here are the bandwidth calculations you would make:

  • Calculating server bandwidth needs (BWs):
    BWs = (P × N) × S
    P = number of publishers
    N = number of subscribers
    S = average stream bitrate of encoded A/V content
  • Calculating client bandwidth needs (BWc):
    BWc = P × S
    P = number of publishers
    S = average stream bitrate of encoded A/V content
Sample calculation

Server bandwidth needed for a four-person webcam chat using 100 Kbps streams:

4.8 Mbps = (4 × 4) × 300 Kbps

Client bandwidth needed for a four-person webcam chat using 100 Kbps streams:

900 Kbps = 3 × 300 Kbps downstream

300 Kbps = 1 × 300 Kbps upstream

How many users can you support on a single server? In this example, each video conference room generates a bandwidth of 4.8 Mbps. Again assuming 600 Mbps server machine throughput, you can have 600 Mbps ÷ 4.8 Mbps = 125 rooms. Because each room has four participants, you can get 125 × 4 = 500 simultaneous users on one server.

No limit on the number of streams

This example illustrates another important aspect of Flash Media Server: there is no limit on the number of streams it can serve. Each user of your application (or, said another way, each connection) can publish or subscribe to an unlimited number of streams as long as the total peak bandwidth-per-second limit is not reached.

Bandwidth considerations

Conducting calculations in your bandwidth strategy document, such as those in the previous section, helps you identify important bandwidth considerations for your application. However, it's worth exploring two important considerations that are highlighted in this last many-to-many example.

Client connection speed

Your bandwidth strategy document should help you deliver the correct amount of information to each client. In the last many-to-many calculation example discussed, note that even though it was a relatively simple application with a relatively small video stream, each client received 900 Kbps of information and published 300 Kbps. This is a lot of bandwidth—in fact, too much if your user is on a dial-up modem or, in some cases, even on DSL. Users connecting to this application with connections less than 400 Kbps will most likely encounter pauses for rebuffering and suffer other poor-quality effects.

Here are two things to keep in mind concerning client connections:

  • Save bandwidth for network overhead. A client's bandwidth will not only need to carry data from your application, it will also need to carry traffic for normal network overhead. Reserve about 20% of a client's bandwidth for overhead when calculating the amount of data to send to each client.
  • Some connections do not have the same upload and download speed. If your application requires interaction from the client (e.g., sending webcam video), make sure your application takes their upload limitations into account.

You can find good online tools for testing upload and download connection speeds. One useful test is at the Broadband Tests and Tools page from BroadbandReports.com.

Application design matters

In the previous example, you estimated that you would be able to add 500 total simultaneous participants to one server (125 rooms with four people each). What if you were to change the design of the application and, instead of allowing four people to connect to one conference room, you allowed only two people to connect to a particular room? Or you only have one big conference room and everyone connects?

Example 2a: Many rooms, few people

In the scenario where you have many rooms but limit each room to only two participants, the server bandwidth drops to 1.2 Mbps per room:

1.2 Mbps = (2 × 2) × 300 Kbps

You can now accommodate 1000 total simultaneous participants across 500 rooms on one server. Note also that the required client bandwidth drops to 300 Kbps upstream and downstream, which opens up the app to more possible users. It's still not a good application for dial-up users, but most DSL users should now be able to use this application.

Example 2b: Many more people in a room

These examples illustrate that the design of the application plays a very important role in bandwidth utilization and, ultimately, in the user experience.

Where to go from here

By now you should have a good idea of how to calculate the server bandwidth requirements for your application. What if your estimates require the server to serve up 800 Mbps of audio/video? Is it realistic to push this much bandwidth on one physical server machine? Two servers? Three servers?

Besides knowing the server bandwidth requirements, you should also have the information you need to estimate the bandwidth utilization of your application and the appropriate Flash Media Server licenses you will need—and some ballpark information about when you can expect to start thinking about adding another server as your traffic grows.

The last but most important piece of advice is to be sure that you thoroughly test your application yourself. Ultimately the only way to know for sure how what type of server resources your application will take is to test it in real-world conditions.

 

AND

Passing the data from JSP to Flex & from Flex to JSP

이 포스팅은 Flex와 JSP의 Data연동하는 방법을 기술하였습니다.

시작하기에 앞서 간단한 기본 개념정리부터 하겠습니다. 

HTTPService는 Flex에서 제공하는 RPC의 한 방법입니다.

출처 : http://ko.wikipedia.org/wiki/%EC%9B%90%EA%B2%A9_%ED%94%84%EB%A1%9C%EC%8B%9C%EC%A0%80_%ED%98%B8%EC%B6%9C

* 원격프로시저호출(RPC, Remote Procedure Call)란? 

원격 프로시저 호출(remote procedure call, 리모트 프로시저 콜, RPC)은 컴퓨터 프로그램이 다른 주소 공간에서 원격 제어를 위한 프로그래머의 세세한 코딩 없이 함수나 프로시저의 실행을 허용하는 기술이다. 다시 말해, 프로그래머는 함수가 실행 프로그램에 로컬 위치에 있든 원격 위치에 있든 간에 반드시 동일한 코드를 짜게 된다.

어떠한 소프트웨어가 객체 지향의 원칙을 사용하여 프로그래밍 때, RPC는 원격 호출(remote invocation) 또는 원격 메소드 호출(remote method invocation)이라고 일컫는다.

쉽게말해  서로다른 컴퓨터, 즉 서로다른 서버에서 Data 연동하는 것을 의미합니다.

Flex에서 제공하는 RPC Data연동하는 방법으로 HTTPService, WebService, RemoteObject 3가지가 있습니다.

이번 포스팅은 3가지 클래스 중 HTTPService에 대해 알아보고자 합니다.

HTTPService Class properties

HTTPService클래스의 기본 속성은 다음과 같습니다. 

<S:HTTPService
		id="No default."
		method="GET|POST|HEAD|OPTIONS|PUT|TRACE|DELETE"
		resultFormat="object|array|xml|e4x|flashvars|text"
		url="No default."
		fault="No default."
		result="No default."
	>

● id  HTTPService를 참조할때 쓰는 이름

● method  서버로 Request 하는 방법

● resultFormat  결과 포멧방식 설정

● url  요청할 서버 주소

● fault  예외발생시 핸들러를 호출하는 이벤트핸들러장치

● result  서버로부터 결과를 받을때 핸들러를 호출하는 이벤트핸들러장치 

Example

출처 : 다음 예제는 네어버카페Flex4u 공룡님 강의 실습 예제 입니다.http://cafe.naver.com/flex4u

다음 예제는 DB를 사용하지 않고 간단하게 ID/PWD를 입력받아 로그인 하는 예제입니다.

HTTPServiceTest.jsp

HTTPServiceTest.mxml

소스는 다운받으시면 되시고, jsp파일은 서버에 올려주세요. 예를들면 톰캣의 경우에는 /tomcat/webapps/<AppName>/ 에 위치하면 되겠습니다.

 

 

전체적인 흐름을 살펴보기에 앞서, 코드상에 간단한 규칙(?)을 살펴보겠습니다.

 

HTTPService에서 send 할 때 인자값으로 Model객체를 넣습니다. 그럼 sending할때 Model안의 태그값들도 같이 넘어갑니다. 그러므로 Model안의 태그이름들이 JSP에서의 getParameter()이름과 매칭이 되어야 합니다. (당연한 소리~!)

B

JSP페이지의 태그 이름들은 Flex에서 HTTPService의 result값의 속성에 매칭됩니다.

C

자동으로 사용자가 입력한 값들이 바인딩 됩니다.

 

사용자가 LogIn버튼을 클릭하면, 사용자가 입력한 ID,PWD를 Model객체의 태그에 담겨져 JSP로 넘깁니다. 그럼 JSP페이지에서는 getParameter()로 사용자가 입력한 값을 자겨옵니다. 그 후 Flex는 result값으로 xml형태의 Data를 읽어들이고, ID,PWD가 맞으면 "환영" 이라고 Alert창을 띄웁니다.

 

 

 

 

AND

Connection Pooling

HTML/About Web 2012. 4. 13. 10:04

Connection Pooling이란?

일정한 Connection갯수를 미리 정해놓고, 그 공간만큼 Connection을 빌려주고 다시 반환받는 형태로 컨넥션을 관리하는 것을 말한다. 컨넥션을 미리 생성해 놓아서 컨넥팅하는 시간을 줄일 수 가 있다.

'HTML > About Web' 카테고리의 다른 글

Apache와 Tomcat의 역할  (12) 2013.04.11
HTTPD (HyperText Transfer Protocol Daemon)란?  (1) 2013.04.11
CGI(Common Gateway Interface)와 Servlet  (0) 2012.04.09
서블릿(Servlet)이란?  (0) 2012.04.06
AND

 

CGI 

 Servlet

 모든 Client의 요청을 프로세스 단위로 처리

모든 Client의 요청을 쓰레드 단위로 처리 

 다양한 언어로 작성

 자바로 작성

대부분의 CGI는 OOP가 아니라 OOP의 이점을 활용할 수 없다.

자바언어 자체가 OOP이므로 OOP의 이점을 활용할 수 있다. 

 플랫폼에 따른 제약이 따른다.

 플랫폼에 독립적이다.

 

'HTML > About Web' 카테고리의 다른 글

Apache와 Tomcat의 역할  (12) 2013.04.11
HTTPD (HyperText Transfer Protocol Daemon)란?  (1) 2013.04.11
Connection Pooling  (0) 2012.04.13
서블릿(Servlet)이란?  (0) 2012.04.06
AND

누군가 당신에게 '서블릿이 뭐야?' 라고 묻는다면 뭐라 답을 해야할까요?

아마 저는  "서버에서 실행되는 자바 프로그램이다." 라고 답할 것 같습니다.

위키피아 사전을 보면 다음과 같이 나와있습니다.


자바 서블릿(Java Servlet)은 자바를 사용하여 웹페이지를 동적으로 생성하는 서버측 프로그램 혹은 그 사양을 말하며, 흔히 "서블릿" 이라 불린다. 

자바 서블릿은 자바EE 사양의 일부분으로, 주로 이 기능을 이용하여 쇼핑몰이나 온라인 뱅킹 등의 다양한 웹 시스템이 구현되고 있다. 

비슷한  기술로는 펄 등을 이용한 CGI,PHP를 아파치 웹 서버 프로세스에서 동작하게 하는 mod_php, 마이크로소프트사의 IIS에서 동작하는 ASP 등이 있다. CGI는 요청이 있을 때마다 새로운 프로세스가 생성되어 응답하는 데 비해, 자바 서블릿은 외부 요청마다 프로세스보다 가벼운 스레드로써 응답하므로 보다 가볍다. 또한, 서블릿은 자바로 구현되므로 다양한 플랫폼에서 동작한다.

출처: http://ko.wikipedia.org/wiki/%EC%84%9C%EB%B8%94%EB%A6%BF

이해가 가나요? 

인터넷이 보급되고 처음 웹페이지가 만들어 질 때, 대부분의 웹페이지는 정적인 페이지였습니다. 어떠한 동작도 없었고 다아나믹한 맛(?)이 없었습니다. 오로지 "뿌려주기" 기능만 있었고 사용자는 그 뿌려진 화면을 볼 수만 있었을 뿐, 서버와의 어떠한 상호작용도 없었죠. 이러한 단방향식구조를 극복하기 위한 대안으로 CGI(Common Gateway Interface)라는 놈이 나왔습니다. 서버와 Data를 송수신 하기위한 우리들만의 약속(?), 규약 입니다. 이에 자바를 CGI에 접목시킨놈이 서블릿이죠. 자바가 가지는 이점을 모두 활용 가능하게 되었죠.  서버입장에서는 천군만마를 얻은것이지 않을까요?


 



'HTML > About Web' 카테고리의 다른 글

Apache와 Tomcat의 역할  (12) 2013.04.11
HTTPD (HyperText Transfer Protocol Daemon)란?  (1) 2013.04.11
Connection Pooling  (0) 2012.04.13
CGI(Common Gateway Interface)와 Servlet  (0) 2012.04.09
AND