JavaBeans are based a component model on the programming language Java. Their goal is it to make the composition of components possible for a complete program at minimum expenditure over graphic surfaces. Also individual Beans can be inserted as applet e.g. on web pages. In Builder Tools can JavaBeans by mouse-click to be joined. Each Bean a Java class, which was modified on configuration and adaptability, is in principle. JavaBeans reveal their characteristics, methods and events in a Builder for the additional adaptability and are This introspektiv.
In them are indicated (characteristics can take several values), bound (divides other Beans changes with) and characteristics with secondary conditions (other Beans can insert a veto before a change) implements.
They are connected loosely by events by means of GET () and set () methods, a JavaBean can so their services other Javabeans offer and again different services stress, by announcing themselves as a receiver and/or snoopers with the appropriate Bean. This loose coupling makes applicable ¹²³ very flexible for JavaBeans
JavaBeans need thereby a container, This a run time environment, in that them to be always can embedded¹²⁴.
For the development of JavaBeans Sun specifications gave change, in order to place the adherence to the standard surely.

Evaluation of the JavaBeans125

Advantages

Disadvantages

Architecture and platform independence '' Write Once run Anywhere '' Do not type-bind Structured application development Simple production, there Java Strong support on the part of the industry (Apple, Borland, IBM, JustSystem, Microsoft, Netscape, Rogue Wave, SunSoft and Symantec etc.) Large application scope (complex traditional applications up to the integration of individual Beans) Simple and above all fast extension of existing programs Portierbarkeit Snaps adaptability Use of the many Java safety precautions Late binding as part of the Java language carries out Graphic connection of components already in the language scope in fact standardizes.

Slow execution, since they must be interpreted on the Java Virtual Machine only Difficult accesses to data system and hardware by safety barriers No bridge of ActiveX toward JavaBeans No utilization of the Java interfaces No strict separation from interfaces and implementation

3.2.5.3 CORBA of OMG

CORBA belonged to distributed object-oriented applications and supported as middleware exactly like COM+ or like the EnterpriseJavaBeans of business procedures in distributed and heterogeneous systems. Middleware platforms must possess This multi-user abilities, on which number of the users, the data and business process scalable its and a high availability possess.
CORBA is thereby only a standard and a specification for the infrastructure of such platforms and component models, which communicate exclusively over interfaces.
The basis for it is short reference architecture Object management Architecture, GRANNY:

Illustration 11: GRANNY architecture of CORBA¹²⁶

Components of this architecture are short the Client and server objects and the Object Request broker, ORB. This continues to lead the inquiry between the Client and server interfaces in the distributed system, in order not to have to fall back to complicated network minutes. The whole happens by Stubs on the Clientseite and Skeletons on the server side. They simulate the offered object services such as naming, a copying and deletion of objects (Lifecycle services), emergency services, pressures, security agencies, as if they would be locally present. Communication is made exclusively by it. The objects directly can be never accessed. Interfaces, classes and objects are described thereby with the help of the definition language IDL. The interface description supplies that dynamic to Invocation with interface (DII) and replaces unknown interfaces.
The described structure is equivalent to the EnterpriseJavaBeans¹²⁷
Summary of the pro and cons of the middleware standard:

Evaluation of CORBA128

Advantages

Disadvantages

Open standard with unrestricted expandability Programming languages and platform independence Improved applications of Internet Arbitrary integration of CORBAObjekten For mobile devices there is a slimmer CORBA form Fail safe middleware with simple communication Scaling barness Specification to the development of distributed applications/components Strong support on the part of the industry Portable system Complementary working with EJB Separation from interfaces and implementation Dynamic connection

Computer-bound architecture Transmission can be possible: The CORBA standard does not give to function references such as Stubs and Skeletons has. Therefore transmission can be quite used internally with all disadvantages. No possibility multiple interface handling: This there is also no possibility of the regulated update of individual components of CORBA systems.

Table 22: Evaluation of CORBA

• 123: See [Balz 2001] S 856 FF
• 124: See [Java 2005]
• 125: See [Balz 2001] P. 896 and [Java 2005] and [point 1999] P. 19 FF and [Lemp 2002] P. 9 FF and [Punz 1999]
• 126: See [Balz 2001] P. 925 and 927
• 127: See [Balz 2001] P. 924 FF and [Wiki 2005] CORBA
• 128: See [point 1999] P. 19 FF and [Balz 2001] P. 924 FF and [Punz 1999]

 

---

Top| Home| << back | next >> " TARGET="_blank">>> Home Page <<