Difference between a bean and a simple java class??

Thanks Kim for your explanations...)))

dev-archive@finao.co.uk (Kim Fowler) wrote:
>Hi
>Luckily in the java world the definition of components is a little
>less severe than when using COM (I also have, and still occasionaly
>do, worked in the COM world)
>
>Firstly there are two definitions that need to be clarified and
>separated: JavaBean and EnterpriseJavaBean (EJB)
>
>EJB are the high end, enterprise level, support for distributed
>component architectures. They are roughly equivalent to the use of MTS
>components in the COM/ COM+ world. They can only run within an EJB
>server and provide support, via the server, for functionality such as
>object pooling, scalability, security, transactions etc. In order to
>hook into this ability EJB have sets of interfaces that they are
>required to support
>
>JavaBeans are standard Java Classes that follow a set of rules:
>
>a) Hava a public, no argument constructor
>
>b) follow a naming patterns such that all accessor and modifier
>functions begin with set/ get or is, e.g.
>
>public void setAge( int x)
>public int getAge()
>
>The system can then use a mechanism known as 'reflection/
>introspection' to determine the properties of a JavaBean, literally
>interacting with the class file to find its method and constructor
>signatures, in the example above the JavaBean would end with a single
>property named 'age' and of type 'int' The system simply drops the
>'set' 'get' or 'is' prefix, switches the first letter to lower case
>and deduces the property type via the method definition.
>
>Event support is handled in a similar manner, the system looks for
>methods similar to
>
>addFredListener(...)
>addXXXListener
>
>means the JavaBean supports Fred and XXX events, this information is
>particularly useful for Visual builder tools
>
>In addition there is the abiliity to define a "BeanInfo' class that
>explicitly defines the above information giving the capability to hide
>methods, change names etc. this can also be used in the case where you
>cannot, for one reason or another, use the naming patterns.
>
>Finally the JavaBean can optionally - though usually does - support
>the Serializable interface to allow persistence of state.
>
>As well as standard application programming, JavaBeans are regularly
>used in the interaction between Servlets and JSP giving the java
>developer the ability to ceate ojbect using standard java whilst the
>JSP developer can potentially use JSP markup tags to interact in a
>more property based mechanism. EJB are heaviliy used in Enterprise
>application to allow the robust distribution of process
>
>HTH.
>Kim
>
>On 11 Oct 2000 00:00:06 -0700, "JMi" <JMIDelsaux@compuserve.com> did
>scribble:
>
>>
>>Hi, i come from MS world with COM architecture. I am wonder what's the
difference
>>between a Bean and a simple java class that define an object. I know bean
>>is component for multiple platform uses but... a java class is java code
>>so it is also multiple platform don't you? Perhaps the difference is that
>>your bean has to be compile only once to run under Windows or Linux but...
>>isn't it the same for other java class? The only one difference i could
>>see for the moment is transaction support.
>>
>>I probably miss spmething somewhere... so explanations are welcome.
>>
>>Thanks
>>
>>JMi
>