Reuse

1
Reuse
Reuse of what ? Software Code libraries, compo
nents Design Design patterns Analysis Domain
knowledge Granularity of reuse Small e.g.
sum 0
for all data values
sum sum value
end
for Large sort utility inventory control
P. Martin 2001 - R-1
2
Reuse
Method of reuse ? Direct Quality and producti
vity benefits Indirect Questionable value Ben
efits of reuse Productivity Facilitates rapid
prototyping (RAD) and reduces production time
and cost. Quality Leads to higher quality comp
onents. Maintenance Lower maintenance costs ?
P. Martin 2001 - R-2
3
Reuse
Problems with reuse? Technical Location and u
nderstanding of component. Platform de
pendencies. High specificity of code.
Obscelescence. Non-technical NIH syndrome.
High development cost (rule of
3) Legal liability and licensing issues
P. Martin 2001 - R-3
4
Reuse
Requirements for reuse Management commitments
and incentives for reuse. Well defined standa
rds for code production and design
documentation. High quality and stringent QA
processes. Repository with tools for maintenan
ce and access. Librarian role to maintain libr
ary and promote reuse. Separation of design wi
th reuse and design for reuse.
P. Martin 2001 - R-4
5
Reuse
Software development in a reuse environment
Analysis
Design for reuse
Design with reuse
Component library
Component integration
P. Martin 2001 - R-5
6
Java Beans
Definition - A bean is a reusable software
component that can be manipulated using a build
er tool. Nature of beans -Beans can be small
GUI components such as buttons
or they can be substantial system components
with no visible representation. Benefits -
The ability to be able to manipulate (e.g.
interconnect) groups of beans automatically wit
hin a builder tool (i.e. without having to pro
grammatically connect them) opens up the possib
ility of plug and play in a visual tool.
Means of achieving pluggability - Design pa
tterns A prescribed set of design rules to
assist a builder tool identify bean anatomy.
BeanInfo class A way of making beans self
documenting Introspection Facilities in Java
for self analysis.
P. Martin 2001 - JB-1
7
Java Beans
Design Patterns Construction To enable
builder tools to instantiate beans they
must either have a zero parameter constructor
provide a serialised prototype. (Beans are no
rmally required to be serialisable)
Bean features Beans are characterised by a
number of features - Properties their pr
operties which may be edittable by a
builder tool during configuration.
Events that they generate as an event sourc
e or respond to as a listener. Methods
which form the public interface of the
component Whilst methods can be identified by i
ntrospection, automatic configuration
and inter-connection of beans requires use of
standard naming conventions.
P. Martin 2001 - JB-2
8
Java Beans
Bean Properties These are the beans private att
ributes (or more specifically those we wish to
be able to edit). They come in four varieties
- Simple properties Single valued attributes
Indexed properties Arrays of attributes Bou
nd properties Properties whose changes might
affect other components and need to be relaye
d to them. Constrained properties Whose c
hanges might be forbidden by other components
for some reason.
P. Martin 2001 - JB-3
9
Java Beans
Simple Properties Single valued edittable attri
butes, e.g. hatColour and boolean attribute
bareHeaded. Must supply get and set methods as
illustrated below.
P. Martin 2001 - JB-4
10
Java Beans
Indexed Properties Arrays of edittable attribut
es, e.g. int marks. Must supply get and se
t for both individual components and the whole
collection -
P. Martin 2001 - JB-5
11
Java Beans
Defining Events Before dealing with bound and c
onstrained properties, the mechanism for
identifying event source beans is needed.
If a bean gives rise to an event E, it must prov
ide add and remove methods for Elisteners as foll
ows -
P. Martin 2001 - JB-6
12
Java Beans
Bound Properties These are not discernable from
method names and may require additional
BeanInfo support - see later. As other beans mu
st be notified of property changes, this bean
must be a source of property change events, so th
ere must be add and remove methods.
P. Martin 2001 - JB-7
13
Java Beans
Bound Properties(continued) Can also add proper
ty change listeners for specific bound properties
in one of two ways - By providing the proper
ty name as a String parameter -
Or, by including the property name in the
add/remove methods. This latter approach obviate
s the need for BeanInfo here.
P. Martin 2001 - JB-8
14
Java Beans
Support for Property Change Notification
Java provides support for the registering and br
oadcasting of property change
events in the PropertyChangeSupport class.
With this, it is only necessary to wrap the add/
remove methods and make calls to a firePropertyCh
ange method, e.g. sup.fireProperyChange(value,5
,10)
public class Demo implements Serialisable
private int value private PropertyChan
geSupport sup new PropertyChangeSupport(this)
public Demo() public void addProper
tyChangeListener(PropertyChangeListener p)
sup.addPropertyChangeListener(p)
public void removePropertyChangeListe
ner(PropertyChangeListener p)
sup.removePropertyChangeListener(p)
//end Demo
P. Martin 2001 - JB-9
15
Java Beans
Constrained Properties Here, property changes c
an be forbidden by listener objects. This is done
by a listener throwing a PropertyVetoException. T
he add and remove methods for listener registrati
on and the set method for the property become -
The two other forms of add/remove method can also
be used as can a
VetoableChangeSupport class.
P. Martin 2001 - JB-10
16
Java Beans
Introspection Introspection and reflection refe
r to Javas capability to discover the names
of methods and the types of parameters and return
values from methods. This is of great help to a
Builder Tool in presenting information to the
component assembler. The class Object This pr
ovides the method Class getClass()
which is inherited by all objects and
returns an instance of the Class class. T
he class Class This class provides its instances
with many methods for retrieving features of
the class of an object, e.g.- Const
ructor getConstructors() Method getMet
hods() Field getFields()
P. Martin 2001 - JB-11
17
Java Beans
Introspection (continued) The package java.lang
.reflect contains key meta classes which provide
means of examining the features of a classes attr
ibutes and methods - The class Method This cl
ass provides methods for extracting
the features of a method, e.g. -
String getName() int getModifiers() Clas
s getParameterTypes() Class getReturnType()
The class Field This allows fields to be exami
ned and set - Class getType() void setInt
(Object o, int i) int getModifiers() int get
Int() String getName() ab
ove 2 also for other data types
A Constructor class similarly allows parameter
types to be determined.
P. Martin 2001 - JB-12
18
Java Beans
Additional Bean Information Accessing desc
riptive information To further assi
st a bean builder tool in introspection, the
java.beans package provides a BeanInf
o interface which gives access to a series of
feature descriptor classes such as
BeanDescriptor, EventSetDescriptor,
MethodDescriptor and
PorpertyDescriptor, each of which contains user
documentation on the bean and its
features. Accessing editors and customiser
s PropertyDescriptor objects provide
access to custom PropertyEditors if
the default editors are inappropriate
and the BeanDescriptor class gives
access to a Customizer class which a
bean developer can use to take over
the configuration process entirely.
The package also contains definitions of propert
y change support classes and listener interfaces.
P. Martin 2001 - JB-13
19
Distributed Systems
Java Data Base Connectivity(JDBC)
JDBC provides a standardised API for interactin
g with an SQL database - classes found in packag
e java.sql For portability, JDBC drivers are
used to implement this interface
and access database functions. This is provided
in one of two ways - As customised JDBC driv
ers supplied by database vendors
In the form of a JDBC-ODBC bridge for database
s which do not provide JDBC drivers but are con
formant to the ODBC standard. Classes in th
is package include Connection to create and
maintain a database connection, Statement and Pr
eparedStatement to provide SQL query and update
facilities and ResultSet to capture and
analyse results from a query.
P. Martin 2001 - D-1
20
Distributed Systems
Simple JDBC example
Steps involved - 1. Register the driver w
ith the driver manager. 2. Use the dr
iver to get a connection to a dat
abase. 3. Call display to issue a query
and analyse the results set.
P. Martin 2001 - D-2
21
Distributed Systems
The application
ResultSets
ResultSet objects capture the table returned from
an SQL query and the class provide functionality
to move a cursor over the rows and extract data
from columns as well as delete, insert and change
rows (such amendments being reflected in the data
base).
P. Martin 2001 - D-3
22
Distributed Systems
Prepared statements These allow sql statements
to be defined in advance with embedded
parameters. Before use actual parameters can be
supplied to complete the statement. E.g. -
In addition to executeQuery(), executeUpdate()
can be used with an sql update command. A Call
ableStatement class permits the creation of
callable database procedures.
Transaction handling
The Connection class also provides transaction
support in the form of manual or auto commit and
rollback.
P. Martin 2001 - D-4
23
Distributed Systems
Client/Server Architectures Two-tier system -
fat client containing business and presentation
logic
DBMS SERVER
LAN/WAN JDBC
CLIENT
Three-tier system - thin client with business
logic contained in an
application server.
LAN JDBC
DBMS SERVER
LAN/WAN RMI/CORBA
APP. SERVER
CLIENT
P. Martin 2001 - D-5
24
Distributed Systems
Remote Method Invocation (RMI)
RMI supports distributed Java-to-Java interactio
n. Unlike the RPC mechanism it allows the transf
er of objects as parameters and return types
across a network - RMI provides - Seriali
sation and de-serialisation of objects when
passed as parameters or return types marshall
ing/unmarshalling of data. Handles the interac
tion with the network layer. In Java 2 it perm
its the automatic activation and deactivation of
server objects. It provides location transpar
ency to the client. Through RMI/IIOP it suppor
ts integration with CORBA.
P. Martin 2001 - D-6
25
Distributed Systems
Components of RMI
CLIENT
SERVER STUB
SERVER
DBMS
TCP/IP
Thin client e.g. applet
Proxy for remote object
Remote server
DataBase
REMOTE INTERFACE
Steps involved Specify the Remote Servers Inte
rface definition. Implement the remote Server.
Compile the remote server and use rmic to gen
erate stub Run rmiregistry and bind server to
it.
P. Martin 2001 - D-7
26
Distributed Systems
RMI Example Defining the remote interface
-
Implement the interface in the Server class
P. Martin 2001 - D-8
27
Distributed Systems
RMI Example (continued)
public static void main(String args)
throws RemoteException System.setSecu
rityManager(new RMISecurityManager())
try Server obj new S
erver(args0) Naming.rebind(/Se
rver, obj) System.out.println(S
erver bound in registry) //end try
catch(Exception e)
System.err.println(ServerImpl error
e.getMessage()) e.printStackTrace
() //end catch //end main
//end Server
Compile the server and generate the stub

Start the rmiregistry and start the server
P. Martin 2001 - D-9
28
Distributed Systems
Common Object Broker Architecture (CORBA)
Standard developed bu the Object Management Group
(OMG). OMG is a consortium of more than 800 c
ompanies worldwide. Founded in 1989 Obje
ct management defined as software development
that models the real-world in terms of objects.
Established the CORBA middleware standard and
other related standards.
P. Martin 2001 - D-10
29
Distributed Systems
CORBA Components
IDL compiler
Interface repository
Implementation repository
in args
CLIENT
OBJECT(servant)
operation()
Obj ref
out args return val
DSI
IDL skeleton
DII
ORB interface
IDL stubs
Object Adapter
ORB CORE
GIOP/IIOP
ORB specific Interface
Standard Interface
Standard language Mapping
Standard Protocol
P. Martin 2001 - D-11
30
Distributed Systems
CORBA - Interface Definition Language (IDL)

• PRIMITIVE
• Integer
• short, long,
• signed unsigned
• Floating point
• float, double, long double, fixed
• char, wchar, boolean, octet
• Any
• CORBA Object Reference

• CONSTRUCTED
• Structs
• Unions
• Enums
• Sequences
• Strings, wstrings
• Arrays

P. Martin 2001 - D-12
31
Distributed Systems
CORBA - IDL (continued)
Modules are collections of related interface
definitions (like Java packages). Operations h
ave return types and in and out parameters.
Attributes can be defined (and automatically hav
e set and get methods unless they are designated
read only).
P. Martin 2001 - D-13
32
Distributed Systems
CORBA - Object References
Object references (which are portable across
systems) can be obtained - As a stringified r
eference convertible into a true object
reference. By reference to the CORBA Naming Se
rvice (white pages). Using the Trader Service
(Yellow pages). Once an object reference is obt
ained, it can be used to invoke interface
operations either - In the usual way (static
interface - defined at compile time)
By reference to the Interface Repository at run
-time (dynamic interface invocation - DII).
P. Martin 2001 - D-14
33
Distributed Systems
CORBA - Dynamic Interface Invocation
Invoking the dynamic interface is done as follows
- Step 1 Obtain method description from the
interface repository lookup_name() descri
be() Step 2 Create argument list and add argum
ents create_list() add_arg() add_arg()
add_arg() Step 3 Create request create_r
equest(object_ref, method_name,
argument_list) Step 4 Invoke remot
e method in one of three ways
invoke() normal blocking request/response
send() send request and later, getrespon
se() get response send() one way send, no r
esponse
P. Martin 2001 - D-15
34
Distributed Systems
CORBA - Method invocation
CORBA provides five different message protocols
- Synchronous Normal request/reply (line RPC
). Deferred synchronous After request, client
continues and can pick up response later.
One-way Request with no reply (like UDP).
Asynchronous Server does not need to be ready
when call is made. Time-independent Serve
r is automatically activated if not
running. CORBA also allows users to define
quality of service - in terms of message
delivery, queuing and priority.
P. Martin 2001 - D-16
35
Distributed Systems
CORBA- Communication Protocols
GIOP (general inter-orb protocol) -
Provides a set of message formats and a common
data representation language for communication b
etween ORBs. The Internet Inter-Orb protocol
(IIOP) specifies how GIOP messages
are exchanged over TCP/IP. GIOP provides -
Reliable, connection-oriented
communication. Can be viewed as a byte stream.
Notification of connection loss.
P. Martin 2001 - D-17
36
Distributed Systems
CORBA - Counter Example - 1
The IDL Interface
Description
The interface count has a single method called
increment which increments by one the value of a
variable sum which is returned to the client.
sum is defined to be a CORBA read/write
attribute. Clients can use built-in set and get
CORBA accesssor functions. A module is the equiv
alent of a package in Java and provides a naming
context for a set of related interfaces.
// File Count.idl module Counter interfa
ce Count attribute long sum long increm
ent()

P. Martin 2001 - D-18
37
Distributed Systems
CORBA - Counter Example - 2
Description
// File CountImpl.java class CountImpl exte
nds Counter._CountImplBase private int sum
// Constructors CountImpl(String name)
super(name) System.out.println("Count Obje
ct Created") sum 0
This is the implementation of the count IDL
interface. This server implementation class inh
erits (extends) _xxxxImplBase class the skeleton
generated by the IDL compiler. Another way to
associate it with the skeleton is by delegation
(the Tie method). We also have to implement a c
onstructor.
P. Martin 2001 - D-19
38
Distributed Systems
CORBA - Counter Example - 3
Description
// get sum public int sum() return sum
// set sum public void sum(int val)
sum val // increment method public
int increment() sum return sum

The constructor calls is super class which in
this case is the skeleton to create a named
implementation object. This means that each named
instance of CountImpl will have a persistent
name. If super is called without and argument
then a transient object will be created.
P. Martin 2001 - D-20
39
Distributed Systems
CORBA - Counter Example - 4
ORB
CountImpl
CountServer
BOA
ORB.init
BOA_init
new
Obj_is_ready
impl_is_ready
P. Martin 2001 - D-21
40
Distributed Systems
CORBA - Counter Example - 5
// CountServer.java The Count Server main
program class CountServer static public void
main(String args) try // Initializ
e the ORB org.omg.CORBA.ORB orb org.omg.C
ORBA.ORB.init(args, null) // Initialize
the BOA ( in future calls will be to the POA )
org.omg.CORBA.BOA boa orb.BOA_init()
// Create the Count object CountImp
l count new CountImpl("My Count")
P. Martin 2001 - D-22
41
Distributed Systems
CORBA - Counter Example - 6
// CountServer.java The Count Server main
program continued .. // Export to the
ORB the newly created object boa.obj_is_rea
dy(count) // Ready to service requests
boa.impl_is_ready() catch(o
rg.omg.CORBA.SystemException e)
System.err.println(e)

P. Martin 2001 - D-23
42
Distributed Systems
CORBA - Counter Example - 7
Client
Count proxy
ORB
CountHelper
CountImpl
Orb.init
bind
Sum(0)
Sum(0)
increment
increment
P. Martin 2001 - D-24
43
Distributed Systems
CORBA - Counter Example - 8
// CountClient.java Static Client, VisiBroker
for Java class CountClient public static voi
d main(String args) try // Initializ
e the ORB System.out.println("Initializing
the ORB") org.omg.CORBA.ORB orb org.omg.
CORBA.ORB.init(args, null) // Bind to th
e Count Object System.out.println("Binding
to Count Object") Counter.Count counter
Counter.CountHelper.bind(orb, "My Count")
// Set sum to initial value of 0 Sy
stem.out.println("Setting sum to 0")
counter.sum((int)0)
P. Martin 2001 - D-25
44
Distributed Systems
CORBA - Counter Example - 9
// Calculate Start time long startTime Sy
stem.currentTimeMillis() // Increment 1000
times System.out.println("Incrementing")
for (int i 0 i counter.increment() // Calculate s
top time print out statistics
long stopTime System.currentTimeMillis()
System.out.println("Avg Ping "
((stopTime - startTime)/1000f)
" msecs") System.out.println("Sum " co
unter.sum()) catch(org.omg.CORBA.SystemExc
eption e) System.err.println("System Except
ion") System.err.println(e)

P. Martin 2001 - D-26
45
Distributed Systems
CORBA - Counter Example - 10
CountClient
javac -d CountClient.java
CountClient.java
count.idl
idl2java count.idl
CountImpl.java
CountServer
javac -d CountImpl.java javac -d CountServer.java
CountServer.java
P. Martin 2001 - D-27
46
Distributed Systems
CORBA - Counter Example - 11

• _CountImplBase - Class implements server side
  skeleton
  
• Count - maps Count interface to corresponding
  Java Interface
  
• -example_Count - an example class for the
  Count object implementation
  
• _st_Count - client stub class
• CountHelper - class that provides useful helper
  functions
  
• CountHolder - class that handles OUT INOUT
  parameters
  

P. Martin 2001 - D-28
47
Distributed Systems
CORBA - Counter Example - 12

• associated Helper class
• Narrow method allows clients to cast object
  references class
  
• non-standard bind method
• any insertion/extraction
• get repository ID
• get typecode
• associated Holder class
• supports stream for portable stubs skeletons
• enable out and inout parameters

P. Martin 2001 - D-29
48
Distributed Systems
CORBA - Counter Example - 13
IDL Declaration to show parameter passing
interface example1 long op1 ( in long arg1,
out long arg2, inout long arg3) produce
s the following Java public interface example1
int op1 ( int arg1, IntHolder arg2, Int
Holder arg3)
P. Martin 2001 - D-30
49
Distributed Systems
CORBA - Counter Example - 14

• The IN parameter is passed from client to server
  and it is expected that the server will not
  modify it. Pass by value semantics.
  
• The OUT parameter is passed from server to client
  which will be available to the client to modify.
  Pass by reference semantics.
  
• The INOUT parameter is passed from the client to
  the server. The server modifies the parameter
  which is then available to the client. Pass by
  reference semantics.
• A request may also return a single return value.
  Pass by value semantics. There can be any number
  of IN, OUT, INOUT parameters.

P. Martin 2001 - D-31
50
Enterprise Java Beans (EJB)
In developing and deploying distributed object
systems, a number of issues need to be addressed
- Persistence Object state must be re
tained between runs of application programs.
Concurrency Server objects frequently h
ave to serve multiple clients concurrently.
Transactions In a multi-tasking
environment, large grain atomic operations re
quire transaction comit and rollback capabilit
ies. Security Authorisation of access
and enactment of security policies is essentia
l for data integrity. Activation Autom
atic activation/de-activation along the
lines of CORBA is an essential requirement.
P. Martin 2001 - EJB-1
51
Enterprise Java Beans (EJB)
Types of EJB
These universal requirements are provided for in
EJB by means of an EJB Container or EJB Server.
Developers create and deploy Beans within such a
Container which manages these aspects automatica
lly, allowing developers to concentrate
on the business logic. Three types of Bean can
be identified - Entity Bean Model ap
plication domain objects and have
persistent state. Uniquely identified by a
primary key. Session Bean Represe
nt server side processes - may have
state (e.g. shopping cart) but are short
lived. Message Bean More recent devel
opment - used in conjunction with JMS to suppo
rt messaging.
P. Martin 2001 - EJB-2
52
Enterprise Java Beans (EJB)
Characteristics of EJBs
Enterprise Java Beans have two interfaces with
which they can be manipulated - Remote inter
face This provide the interface which clients
use to interact with the Bean and
provides the business application
functionality. Home interface Accessed on
ly by the EJB container, this provides for -
creation removal activation
passivation and location
P. Martin 2001 - EJB-3
53
Enterprise Java Beans (EJB)
Entity Beans
Suppose we wish to create an AddressBook Bean
which has two attributes -
name and address -
The first step is to construct a database table
which supports the persistent storage of the Bean
s attributes. The column names of the table will
match the attribute names. The remote interfac
e is then defined, e.g. -
P. Martin 2001 - EJB-4
54
Enterprise Java Beans (EJB)
Entity Beans (continued)
The next step is to implement the home interface
which provides operation support for creation and
location of the Bean. Note that all interface
methods are capable of raising RemoteException
as the methods will be accessed over a network.
P. Martin 2001 - EJB-5
55
Enterprise Java Beans (EJB)
Entity Beans (continued)
Now the implementation can be created -
P. Martin 2001 - EJB-6
56
Enterprise Java Beans (EJB)
Entity Beans (continued)
Insert here any user specific processing in addi
ttion to default
processing

P. Martin 2001 - EJB-7
57
Enterprise Java Beans (EJB)
Entity Beans (continued)
The Bean can now be built and deployed in the EJB
Container by - Compiling the interfaces and t
he implementation class. Creating a jar file
containing the components and a Bean
descriptor in the form of an ejb-jar.xml file
Running the EJB Compiler. All of the code sh
own here can be automatically created by EJB
tools and can then be customised for application
specific processing. The home methods are not c
alled directly but are called by the EJB
Container when appropriate.
P. Martin 2001 - EJB-8
58
Enterprise Java Beans (EJB)
Entity Beans (continued)
The generated Bean descriptor XML file is as
follows -
P. Martin 2001 - EJB-9
59
Enterprise Java Beans (EJB)
Entity Beans (continued)
Finally, the client can then access the Bean
remotely as follows -
P. Martin 2001 - EJB-10
60
Enterprise Java Beans (EJB)
Session Beans
Session beans are similar in many ways to Entity
Beans, they have a remote and a home interface bu
t they differ in the following respects -
They represent a process rather than an object
They have no primary key They are not per
sistence (and are not backed up by a database)
They do persist for a limited time, but it may
be no more than duration of the client interact
ion. They can be stateless or stateful. St
ateless session beans may be pooled by the
container to optimize performance.
P. Martin 2001 - EJB-11
61
Enterprise Java Beans (EJB)
Session Bean Example
An example application which would require a
Session Bean is an Airline Booking System. The
Booking Session Bean which allowed users to
first browse and then book a flight could provid
e these two methods and the Bean would access
a collection of Entity Beans representing Flight
instances. The book method would carry out the
following operations - allow user to select o
rigin and destination and date/time
confirm availability of different seat prices a
nd allow selection request name, address and c
redit card number request final confirmation f
rom user confirm booking
P. Martin 2001 - EJB-12
62
Enterprise Java Beans (EJB)
Transaction Handling
The Airline Booking System book method raises an
important issue. As the system handles multiple c
lients simultaneously - Seats selected by a c
lient must be held until credit-card
authorisation and client confirmation has
occurred. Such seats must be released if autho
risation fails or client changes their mind.
This requires transactions with commit or
rollback capability. EJB provides the following d
esignations for methods - NotSupported
Transactions not supported in method
Supports Method can be called as part of
a transaction or independently. Requi
red Method must be called as part of a
transaction. RequiresNew Method Requires
a new transaction to be started.
Mandatory Method must be called as part
of a transaction. Never Method cannot be
called as part of a transaction.
P. Martin 2001 - EJB-13
63
Enterprise Java Beans (EJB)
Transaction Handling (continued)
The designation of methods for transaction
handling is contained within the XML descriptor f
or a Bean as follows -
Note - The transaction handling can be defined
as container (EJB container) managed or Bean (u
ser) managed. Similarly, persistence can also
be container or bean managed.
P. Martin 2001 - EJB-14