3.25. Allocation structure
3.29.4. CORBA - ORB
ORB - Client side
• Client IDL Stubs provide the static interfaces on the client side for CORBA component connections
• A proxy for remote procedure call, which transmit the calls to the remote server.
• Forward parameters to the server by the marshalling technique.
• ORB interface provides some useful local services to CORBA users:
• E.g. Convert component-references to character sequences (sequencialization) etc.
3.29.5. CORBA - ORB
ORB - Client side
• Dynamic Invocation Interface - DII helps to create dynamic components, whiches are able to explore and call methods of the server-side components in runtime.
• DII provides better flexibility at runtime, but static stubs support type checking at compilation.
• Interface Repository API provides the runtime access to the interface-repository, which contains the preprocessed IDL definitions.
• In CORBA 2.0, it also contains ORB global identifiers (Repository ID). Repository IDs are uniq identifiers of components and their interfaces.
3.29.6. CORBA - ORB
ORB - Server side
• Server IDL Stub defines static services of the server side components. Its skeleton also generated by the IDL compiler.
• Dynamic Skeleton Interface (DSI) is the pair of the Dynamic Invocation Interface (DII). It provides information in runtime about those server side components, those do not have IDL defined static stubs. DSI determines the corresponding component and its service (method), by the parameteres of the incoming message.
3.29.7. 3.2.2 Object Adapter 3.29.8. CORBA
Object Adapter
• Required to the implementation of DSI, DII, but can be used independently also.
• Runtime environment manages the
• Object references,
• Implementation Repository
• All ORB support at least one adapter
• Basic Object Adapter (BOA)
3.29.9. 3.2.3 Implementation Repository, ORB interface 3.29.10. CORBA
Implementation Repository, ORB interface
• Implementation Repository
• Container of descriptions of the implemented server side classes.
• Keeps track the instantiated objects and how to identify them.
• ORB interface is the pair of the server side IR on the client side.
3.29.11. 3.2.4 IDL 3.29.12. CORBA - IDL
Interface Definition Language (IDL)
• CORBA is strictly an object based system
• Server components can be defined as classes. Their properties are
• Inheritance,
• Exception handling,
• Encapsulation.
• IDL is used to define the classes
• Portable
• Programming language and operating system independent declarative language. It does not contain procedural elements, but supports
• Interfaces given in IDL language are compiled by the IDL compiler to a concrete language (e.g. Java). Their methods should be implementated in the same programming language.
• The structure of IDL can be found in the Java 2 Útikalauz programozóknak book (editor: Nyékiné Gaizler Judit, ELTE TTK Hallgatói Alapítvány, Budapest, 1999.)
3.29.14. CORBA - IDL
IDL compilers
• IDL - Java compiler
• Input: Interface description in IDL langauge
• Output: Java program code
• Usage of the compiler described in the book (section 22.3.)
• A simple, but useful example can be found about the usage of CORBA in the section 22.4 of the book.
• In the example, a group of objects are created on several servers.
• In the example above, the client and the server are using the CORBA Naming Service to localize each others.
3.29.15. Generated code execution within the CORBA infrastructure
3.30. 3.3 COM/DCOM
3.30.1. COM/DOM
COM/DCOM
• Component Object Model - COM
• The first component model of Microsoft (1993)
• COM+
• An expansion of COM: transactions, asynchronous messaging, with the tools of clustering.
• Distributed COM - DCOM
• An extension to COM to handle distributes systems
• A DCOM component is able to communicate with a DCOM server - by client proxies and server stubs.
• The services of CORBA and DCOM are getting closer, but not their tools!
4. 4 JavaBeans
4.1. 4.1 Introduction
4.1.1. Introduction
Sun Microsystems's Java 2 Enterprise Edition (J2EE)
• Describes how to design and develop Java programs, and how the objects communicate.
• Describes several business services: naming, transactions, lifecycle handling.
• Elements created in the standardized way are platform independent.
• The J2EE architecture was developed at the late '90s.
Enterprise JavaBeans (EJB) It defines the server side components.
4.2. 4.2 JavaBeans
4.2.1. JavaBeans
JavaBeans
• The simplest component model of Java.
• At the first sight, JavaBean is a reusable software component, which can be visually manipulated in the developer environment.
• In the JavaBeans component model
• a component may have several independent implementation.
• More instances can be created from a given component, customizing to the applications.
• Components can elements of containers.
• A component can be a container and also able to contain other components.
• Connections and communications among components are done by event handlers and method calls.
4.2.2. JavaBeans
JavaBeans
• The JavaBeans component model supports the hierarchic software development, where complex components can be created by containers from simpler components.
• Services of visual developer tools can be used.
• Development of beans is simplified by the Sun's BeanBox development environment.
• The JavaBeans model supports the customization of the beans by property lists. These lists can be displayed for easier manipulations.
4.2.3. 4.2.1 Enterprise Java Bean 4.2.4. JavaBeans - EJB
EJB - Enterprise Java Bean
• Server side distributed component model
• Types based on functionalities:
• Session Bean
• Enterprise Bean
• MessageDriven Bean
• An application server is requiered to run the components (an EJB container is required).
• Contracts between the EJB and the container
• set of interfaces,
• deployment descriptors.
4.2.5. 4.2.2 J2EE overview 4.2.6. Java2EE
Java2EE
• An architecture for a component-based, multi-layered enterprise application development.
• J2EE architecture:
4.2.7. Quality requirements of web-application
Quality requirements of web-application
• Scalability - System should be functional without human interaction, if load increases. The number of servers may change.
• Availability - System should be reachable 24 hours a day, and it should provide a short download time.
• Security - Provide possibility to register new accounts, and do right management (each person can get only that data for right is granted).
• Usability - Different users should be able to get different contents in different formats at the same time.
• Performance - Short response time is required.
4.2.8.
Additional requirements to J2EE
• Portability - Should be implemented easily on several platforms
• Ability to build - Developers can manage generally used services, like transactions, name services and security services
• Balanced specifications - Detailed specifications for manufacturers, developers and integrators, and sufficiently general specification for business and optimailty properties.
• Implementation, transparency - clear implementation; clients should not depend on details of implementations
• Cooperation - Components of different manufacturers should be able to communicate. Bridges should exist to different technologies (e.g. CORBA, .Net)
• Developmnet - Opportunity for developers to adopt different technologies.
• Expansibility - Possibility to integrate important and new technologies.
4.2.9. 4.2.3 J2EE - EJB overview 4.2.10. J2EE - EJB
Goals of EJB
• Support component-based software development by the reusability of the Java components.
• A tool is needed with server side applications can be developed as easy as e.g. GUI applications in Visual Basic.
• The standard framework has to be easy to use.
4.2.11. J2EE - Tasks of EJB
Tasks of EJB
• Support the lifecycle of a business application, including its deployment, and its runtime supervision.
• Define contracts, which provide the communcication ability to the components of different manufacturers.
• Cooperate with other Java APIs.
• Offer a cooperation between the Enterprise Beans and non Java application.
• Cooperate with CORBA.
4.2.12. Properties of J2EE
Main properties of J2EE
• Multilayered distributed application model
• Client layer
• Web layer
• Business component layer
• Enterprise information system tier
• Server side component model
• Built in transaction handling
4.2.13. 4.2.4 J2EE - architecture 4.2.14. Architecture of J2EE
4.2.14.1. 4.2.4.1 Client layer
4.2.15. J2EE - Client layer
Client Layer
• For a web application, it contains only a web browser. It sends HTTP requests to the Web server and download HTML pages from there.
• In applications, those are not using browser, Java clients ot applets can be used. These have direct connections to the Business component layer.
4.2.15.1. 4.2.4.2 Web layer
4.2.16. J2EE - Web layer
Web layer
• A Web server is running in the Web layer, which answers to the requests coming from the client layer, using servlets or JPS (Java Server Pages). Servlets are called by the server depending on the type of user requests.
• Servlets are gathering the required information from the business component layer. JPSs are HTML pages, containing small server side codes. These codes are processed by the JPS mechanism.
4.2.16.1. 4.2.4.3 Business component layer
4.2.17. J2EE - Business component layer
Business component layer
• This layer contains business logic, which is realized by the EJB component. EJBs are receiving requests from the Web layer, and answers after successfully retrieved the required information from the databases (they are located in the Enterprise information systems tier). EJBs are located in a common container, which offers the following services to the EJBs:
• Life-cycle management
• State management
• Security
• Multi-threading
• Resource pooling
• EJB simply determines a behavioural pattern required from the container, and let the container do the rest of the task. By this, EJB code contains only the business logic, so it is clear and not mixed with other system or environment dependent codes.
4.2.17.1. 4.2.4.4 Enterprise information systems tier
4.2.18. J2EE - Enterprise information systems tier
Enterprise information systems tier (EIS)
• It contains some databases and some background applications (they are used by the EJBs). The connections are usually realized through JDBC drivers. Databases are usually Relation Database Management Systems (RDBMS).
4.2.19. 4.2.5 J2EE - EJB architecture 4.2.20. J2EE - EJB architecture
J2EE - EJB architecture
• EJB architecture supports the creation of the distributed server-side object-oriented Java applications.
• An existing EJB can be used anywhere. Task of the programmer is often to bulk them.
• Portability of EJBs is mainly guaranteed by the JVM. EJBs may need services, those are not provided by the JVM. These services are provided by a manufacturer independent interface set.
4.2.21. J2EE - EJB architecture
J2EE - EJB architecture Figure shows the relations of an application server, a container and the services.
4.2.22. J2EE - EJB container
EJB container
• Manage the execution of application components.
• Provide a process of the operating system, which is a host of one or more EJB components.
• When a client calls a server component, the container automatically allocates a thread, and calls the instance of the server component.
• Container does resource pooling for server components, and provides connection to the outer environment.
4.2.23. J2EE - Component model
Component model
• Define the basic architecture to the EJB components.
• Specify the interface-structure of the EJB components, and the mechanism with an EJB component can communicate with its container and other components.
• The model also contains a prescription how to develop components, which will be able to interact and be a part of a larger system.
4.2.24. J2EE - EJB Component types
EJB Component types - Session bean
• Session beans represent the business logic and provide services to clients. They can be:
• Stateless session bean or
• It does not have information about the state of the client, the client does not have a reference to the beans, and does not preserve them.
• The EJB container delegates the calls of clients to the session bean. They do not preserve the information that who called them. Client gets a reference to the bean, but if client wants to use the reference again, EJB does not guarantee that client will get the same bean instance. It is only guaranteed that a bean will called, which is able to perform the request.
• Stateful session bean
• The container generates a dedicated session bean to each client, which creates a bean instance.
• Client preserves the reference, and all the later calls go to the same bean instance.
• If the bean is not used for a long period, container saves the states of the bean to the storage device and automatically loads back when the client calls it.
4.2.25. 4.2.6 J2EE - EJB component types 4.2.26. J2EE - EJB Component types
EJB Component types - Entity beans
• Used to represent typical business data objects.
• An entity bean can be reached through a session bean.
• Entity beans can be
• Container managed persistence entity beans
• Bean-managed persistence entity beans
4.2.27. J2EE - EJB Component types - Entity beans
Container managed persistence entity beans
• This beans have direct connections to the database through the container.
• Container guarantees that at the beginning of a transaction the corresponding data should be written into the bean instance, and after transaction, container writes back the data to the data storage.
• The advantage is that the programmer does not have to deal with problems related to the data management, which simplifies the code.
4.2.28. J2EE - EJB Component types - Entity beans
Bean-managed persistence entity beans
• Only the bean consider how to represent and manage data. Usually JDBC calls are used to this.
• Advantage: in some cases, queries can be written more efficiently compared to the case, when container does it itself. We can manage datasources, those are not supported by the container.
• Disadvantage: programmers work more, but data operations can be optimized.
4.2.29. J2EE - Example for J2EE/EJB-compliant implementation
4.2.30. 4.2.7 J2EE - EJB programming 4.2.31. J2EE - EJB programming
EJB programming
• EJBs have connections only through the containers. If an EJB wants to reach a JDBC connection or an other bean, then it can be done throught the container.
• Beans can interact with a container
• with Callback methods, or
• through an EJBContext interface, or
• using Java Naming and Directory Interface (JNDI).
4.2.31.1. 4.2.7.1 Server side
4.2.32. J2EE - Creating a server side bean
Creating a server side bean
• Two interfaces should be defined, when the business methods are defined:
• Home - Instanciated from EJBHome. Contains methods to handle life-cycle: constructor, destructor, finding a bean-instance.
• Remote - Contains the business methods. If a client wants to call a method of these, a reference to the bean should be retrieved first through the Home interface. Client interacts with the bean always through the interface of remote. These methods are application specific.
• A bean class has to be written. It loads only, when it is needed. Functions contained in the interfaces are implemented here.
4.2.33. J2EE - EJB program units
[fragile]J2EE Example - A simple home interface
Creating a Broker type EJB
public interface BrokerHome extends EJBHome {
Broker create() throws RemoteException, CreateException;
}
[fragile]J2EE Example - Part of the Broker remote interface
public interface Broker extends EJBObject {
// Return the newly created account number
public int newAccount(String sub_name, String sub_address,
int sub_credit) throws RemoteException, SQLException;
...
public void updateAccount(int sub_accno, int start_stock_id) throws RemoteException, SQLException;
...
public Vector getHoldingStatement(int sub_accno, int start_stock_id) throws RemoteException, SQLException;
}
Part of the Broker remote interface Interface contains methods, used by the container, when that manages the creation and the life-cycle of an EJB. Programmer can provide a bean specific behaviour to the EJB, or it can inherit a default behaviour. After that, client can use the public interface of the EJB to create, manipulate or destroy beans.
4.2.34. J2EE Example - The realizer class
Realizer class
• The realizer class, which is known as bean class, instanciated at runtime, and can be reached as a distributed object. The next figure shows a simple client code.
• An EJB client can be a standard application, servlets, applets or an other EJB. Each client uses the home interface of a server bean in order to get a reference to an instance of the server bean. Then, client connects to the server bean via the remote interface, when uses its methods.
• In this example the Broker bean is a stateless session bean, which processes the requests of the client.
4.2.34.1. 4.2.7.2 Client side
[fragile]J2EE Example - A code of a simple client
Broker broker = null;
// Find home interface
Object _h = ctx.lookup("EntityStock.BrokerHome");
BrokerHome home = (BrokerHome)javax.rmi.PortableRemoteObject.narrow(_h, BrokerHome.class);
// Use the home interface to create the Broker EJB Object broker = home.create();
// Execute requests at the broker EJB broker.updateAccount(accountNo, 200000);
broker.buyStock(accountNo, stockID, 5000);
// We are finished...
broker.remove();
4.2.34.2. 4.2.7.3 Entity and Broker bean functions
[fragile]J2EE Example - An Entity bean, and a Broker bean function
public void updateAccount(int sub_accno, int sub_credit) throws RemoteException {
try {
Account account = accountHome.findByPrimaraKey(new AccountPK(sub_accno));
account.update(sub_credit);
Entity bean of the broker example
• The updateAccount method uses an entity bean called Account, which contains all the important functions of the application.
• The code of updateAccount uses a findByPrimaryKey method, which was defined in the home interface of the Account bean.
4.2.34.3. 4.2.7.4 Account bean, Home/Remote interface
[fragile]J2EE Example - Account bean - Home/Remote interface
public interface AccountHome extends EJBHome {
public Account create(String sub_name, String sub_address,int sub_credit) throws CreateException, RemoteException;
// Finds an account by its primary Key (Account ID)
public Account findByPrimaryKey(AccountPK key) throws FinderException, RemoteException;
}
public interface Account extends EJBObject {
public void update( int amount) throws RemoteException;
public void deposit( int amount) throws RemoteException;
public int withdraw(int amount) throws RemoteException, AccountException;
// Getter/setter methods on Entity Bean fields
public int getCredit() throws RemoteException;
public String getSubName() throws RemoteException;
public void setSubName(String name) throws RemoteException;
}
[fragile]J2EE Example - Account bean - update method
public class AccountBean implements EntityBean {
// Container-managed state fields public int sub_accno;
• The greatest attraction of EJB model is that the business logic and the technical parts of programming can be separated.
• Technical details are often solved by the container. To achieve this, beans should define, what they require from the container. These requirements are described in the deployment descriptors, which are contained in an XML file.
• Requirements are defined in a declarative way.
• Advantage: several descriptors can be given for the same bean, to change its functionality.
[fragile]J2EE Example - Broker bean - Deployment descriptors
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>EntityStock.BrokerHome</ejb-name>
<home>j2ee.entitystock.BrokerHome</home>
<remote>j2ee.entitystock.Broker</remote>
<ejb-class>j2ee.entitystock.BrokerBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<trans-attribute>Required</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>
4.2.37. 4.2.9 Summary 4.2.38. Summary
Summary
• The EJB component model can be used efficiently after a few practicing, to create client/server applications.
• The EJB model gives the chance to apply different architecture schemas in the same application. It is hard to decide, which schema is the best to the given application.
• The interaction between the beans and the container is very complicated, which effects the performance of the application.
• Efficient and scalable EJB applications can be written only after a lot of practice.
5. 5 KobrA program-development model
Based on the book of Hans-Gerhard Gross: Component-Based Software Testing with UML. Springer-Verlag Berlin-Heidelberg 2005.
5.1. KobrA
Introduction
• Developed by Fraunhofer Institute for Experimental Software Engineering, Kaiserslautern, Germany.
• A synthesis of more currenty existing component-based program-development model:
• OMT
5.2. KobrA
Introduction
• Goal: combine the strongnesses of the available methods and avoid their weaknesses.
• KobrA gives help to the activities (analysis, designing, programming, verification, documentation).
• The tool of the analysis and designing is the UML
• UML is a good choice, because modeling can be done without implementation or system specific considerations.
5.3. KobrA
Introduction
• The main goal is to create the abstract form of the basic structure of the system. Because of this, several implementation technology can be used.
• Principles:
• Separate problems
• Model based development
• Use of components
• Use of object oriented technology
• The figure shows that three dimensional model, which is suggested by the creators of KobrA.
5.4. 5.0.1 Development process
5.5. KobrA
5.6. KobrA
Development process
• KobrA divides the development process into two basic dimensions.
• All activities are rated in these two dimensions and analysed from this viewpoint.
• It defines four directions for the development:
• Composition / Decomposition
• Abstraction / Concretization
5.7. KobrA
Development process
• Composition / Decomposition
• Decomposition: Apply the Divide and conquer approach. It breaks up the system into flexible, independently managable parts.
• Decomposition: Apply the Divide and conquer approach. It breaks up the system into flexible, independently managable parts.