Transcript www.aryansexport.com

Technical training at
SCIENTECH TECHNOLOGIES
By Deeksha Chauhan, VII sem (CSE)
http://powerpointpresentationon.blogspot.com
• Scientech Technologies was found in 1983
• an ISO 9001:2000 certified company
• Scientech Technologies is a leading name in the field of Test
and Measuring Instruments and Technical Training
Equipment.
• Head office is at Indore and Branch offices at Mumbai, Pune,
New Delhi, Chennai, Hyderabad, Kolkata, Jaipur, Lucknow,
Chandigarh and Bangalore.
• Scientech has won the prestigious EFY readers choice award
in the Educational Trainers/kits category in 2004, 2005, 2006
and again in 2008.
• Scientech is an active member of Worlddidac, Switzerland
• Are emerging Global Leader of Innovative, Competitive
and Eco friendly Electronic Equipments, Software
Products and Turn-key Solutions for Industry and
Technology Training.
• To achieve this they are enhancing Customer
Satisfaction based on Research, Modern manufacturing
techniques and continuous improvement in Quality of the
products and the Services.
• key drivers to growth focus on Employees and
Customers, Use of latest Technology, Intense Marketing,
Service Support and High Ethical Practices.
• Fuel Cell Trainer
NV6007 Fuel Cell Trainer is a modular experimental
system designed to study the working of Solar-Hydrogen
cycle. The Reversible Fuel Cell is unique, as it acts as
both, an Electrolyzer and a Fuel Cell.
• Video Processing Platform
The ST111 Video Processing Solution provides an ideal
vehicle for study and implementation of Video/ Image
Processing Algorithm. ST111 provides a complete, readyto-teach platform that can be used in courses on Video
Processing. The ST111 board suits a wide range of
exercises from simple tasks and illustrating fundamental
concepts, to challenging designs requiring detailed
knowledge.
• Robotic Arm
NV3301 Robotic Arm is versatile training equipment for all
robotics enthusiasts to understand the very basic concept
of robotics. Robotic arm can be controlled from software or
control panel. Control panel has LCD, switches, home
sensor LED, connector for external interface with DIP
switches and USB interface. From software user can
control each DOF individually through mouse click or key
board.
• JAVA
• J2EE
EJB(Enterprise JavaBeans)
Why java?
1.It’s almost entirely object-oriented
2.It has a vast library of predefined objects and
operations
3.It’s more platform independent
4.It’s more secure
5.It isn’t C++
• An applet is designed to be embedded in a Web page,
•
•
•
and run by a browser
Applets run in a sandbox with numerous restrictions; for
example, they can’t read files and then use the network
A servlet is designed to be run by a web server
An application is a conventional program
• The .class files generated by the compiler are not
•
•
executable binaries
o so Java combines compilation and interpretation
Instead, they contain “byte-codes” to be executed by the
Java Virtual Machine
o other languages have done this, e.g. UCSD Pascal
This approach provides platform independence, and
greater security
• Comments are almost like C++
• Primitive data types are like C
• Declarations look like C
• Expressions are like C(Assignment statements ,
Arithmetic operators, Boolean operators, Comparisons
operators
JAVA does not have pointers or pointer arithmetic
Control statements are like C
but conditions must be boolean
•
•
• In C, almost everything is in functions
• In Java, almost everything is in classes
• There is often only one class per file
• There must be only one public class per file
• The file name must be the same as the name of that
public class, but with a .java extension
• Java is case-sensitive; maxval, maxVal, and MaxVal are
•
•
•
•
•
three different names
Class names begin with a capital letter
All other names begin with a lowercase letter
Subsequent words are capitalized: theBigOne
Underscores are not used in names
These are very strong conventions!
• Classes are arranged in a hierarchy
• The root, or topmost, class is Object
• Every class but Object has at least one superclass
• A class may have subclasses
• Each class inherits all the fields and methods of its
(possibly numerous) superclasses
• Stands for “Java 2, Enterprise Edition”
• It is a collection of standards
o JDBC, JNDI, JMX, JMS
• It is a component technology
o Enterprise JavaBeans
• It is an “application server”
o Following in the footsteps of Component Transaction
Monitors
• Distributed Objects
o CORBA, DCOM, etc.
o Three-tier scenario: presentation, business logic, and
backend databases
 Hard to “get right” without the proper infrastructure
• Server-Side Components
o Focuses on encapsulating “business rules” into
objects in the middle tier
• Component Transaction Monitors
o Descendant of CORBA’s Object Request Broker
 provides discovery, persistence, event notification,
transactions, etc. for three-tier or n-tier applications
• A specification
o Version 1.4
o Response to JSR-151
o Umbrella which freezes other technologies
 Each has its own spec / rev + reference implementation
• A Download
o Interfaces
o Reference implementation
 Rollup of individual technologies’ reference
implementations
 E.g. Tomcat 4.X for Servlet 2.0
o Compatibility Test Suite
o BluePrints
• High Availability
• Security
• Reliability
• Scalability
…of Enterprise Information Services (EISs),
…Usually in a multitier environment.
• Applets (Just like conventional Applet)
• Application Clients
o Just like conventional J2SE application
o Except may require J2EE APIs
• JSP / Servlet
o Anything that talks HTTP
o Requires container; Apache/Tomcat is RefImpl
• EJB
o Transactional component
o Requires container + server
o Download gives you RefImpl
Enterprise JavaBeans is a standard server-side
component model for component transaction monitors
It’s a standard for building server-side components and
deploying them in component transaction monitors
ClientSide
invoke
s
Stub
Clien
t
Networ
k
connect
to
remote
object
Middle
Tier
Skeleton
invok
e
Server-Side
Component
return
return
return
result
result
result
s
s
s “thinks” its making
Stub and Skeleton are auto-generated; client
a local
call, most networking details are hidden from client; the main
The Cast…In Order of Appearance
1. EJB Server Provider
2. EJB Container Provider
3. Enterprise Bean Provider
4. Deployer
Combined for
our
purposes...
5. Application [EJB Client] Assembler
6. System Administrator
EJB Spec lists roles in a different order
EnterpriseBean-centric vice chronological
• Implement majority of EJB spec
• Provide backbone of EJB System
o Mediator among other players:
 EJB Clients
 EnterpriseBean
 At least one “backend” database
• Various implementations
o BEA/Weblogic, IBM/Websphere, 8 others
• EJB 2.X should clear up Container bounds
• Reusable software component
• Built / bought to meet a business need
• Deployed to an EJB Server implementation
• Serves multiple users across enterprise
• Application that uses EnterpriseBean
o GUI or non-GUI (e.g. Servlets)
o Java or CORBA
o Remote or local (EB Intranet; NNS; other
EnterpriseBean)
• Client view is remote interfaces
• Considered less trustworthy than server side
o Client flaw should not affect EJB Server
create(
)
Clientfind()
EJB
Server
Containe
r
XHome
EnterpriseBe
an
X
(Wire
Tier 1……………………Tier
)
2………………………..Tier N
Existing
Databas
(Wire e
)
Doesn’t
Exist
pooled
ejbCreate
()
ejbLoad(
)
ejbPassivate
() ejbActivate
()
ready
ejbFind(
)
ejbRemov
e()
ejbStore
businessMetho()
d()
• Two Types of Enterprise JavaBeans
o Entity Beans
 Used to model business concepts such as
customer, cruise ship, inventory item, etc.
o Session Beans
 A server-side “representative” of the client; session
beans are responsible for managing processes or
tasks; for instance in an airline reservation
scenario, the session bean would be responsible
for reserving a seat on a particular flight and
verifying payment
EnterpriseBean that is long lived
• Maps to backend data store
o Bean-managed persistence
o Container-managed persistence
• Has unique key (“primary key” or XPK)
• Implements EntityBean interface
Examples:
EmployeeBean with SSN as PK
EnterpriseBean that is short lived
• Duration no longer than user login
• State not stored to any database
• Examples:
o ShoppingCartBean
o TableModelBean
• Implements EnterpriseBean interface
Client Using
only Entity Beans
Client Using
Session Beans
EJB Server
• 6 classes
o All are of type Exception
• 12 interfaces
o 6 are seen by EJB Client
o other 6 are only seen by EJB Server/Container
o Often implement java.io.Serializable or java.io.Remote
• Any enterprise bean must define two interfaces and one
or two classes
o Remote interface
 defines a bean’s external interface
 must extend javax.ejb.EJBObject (which in turn
extends java.rmi.Remote)
o Home interface
 The home interface defines a bean’s “life cycle”
methods, eg. create bean, remove bean, find bean,
etc.
 must extend javax.ejb.EJBHome which also
extends java.rmi.Remote
• Bean Class
o The java class that actually implements the bean’s
external interface, e.g. the bean class provides
implementations for the bean’s “business methods”
o An entity bean must implement the
javax.ejb.EntityBean interface, while a session bean
must implement the (you guessed it)
javax.ejb.SessionBean. Both of these interfaces
extend javax.ejb.EnterpriseBean
• Primary Key
o The primary key is a very simple class that provides a
pointer into a database; Only entity beans need a
primary key. This class must implment
java.io.Serializable (so the entity bean can
• Clients never interact directly with a bean class, they use
•
•
stubs (which connect to skeletons, which connect to
“containers” which call the bean class…whew!)
Why? This allows the application server to replicate bean
instances (for performance reasons), manage
transactions, etc.
A bean also interacts with its server via a container
interface: the container calls the bean’s life cycle
methods, manages the bean’s persistence, etc.
Client
EJB Server
Home
Interface
Hom
e
Stub
EJB Container
Remote
Interface
EJB
Stu
b
Home
Interface
EJB
Hom
e
Remote
Interface
EJB
Object
Bean
Class
• Entity beans are distinct from Session
But no distinction between Bean Managed & Container Managed
Persistence
Void ejbActivate();
 Invoked by container to associate with EJBObject
void ejbLoad();
 “Do a database lookup” (bean-managed persistence only)
void ejbPassivate();
 Invoked by container; about to get dissociated with EJBObject
void ejbRemove();
void ejbStore();
- “Persist yourself to database” (bean-managed persistence
only)
void setEntityContext(EntityContext ctx);
• SessionBeans are distinct from Entity
Void ejbActivate();
void ejbPassivate();
void ejbRemove();
void setSessionContext(SessionContext);
• Resource Management
o Instance Pooling and Swapping
 Server can invoke multiple instances of a bean to
handle multiple incoming requests (pooling)
 An instance of a bean class can handle requests
from multiple skeletons (swapping)
o Activation
 if a bean is “stateful”, application servers automate
the process of saving and restoring bean state
• Primary Services
o Concurrency
 Beans are automatically thread safe; application servers
handle concurrent access to a bean; They also handle
reentrance
o Transactions
 Bean operations can belong to a transaction and the
application server handles “rolling back” an application’s
state if a partially completed transaction fails
o Persistence
 Application servers can map beans into database
entries (and back again)
o Naming (bean discovery) and Security (encrypted
communication and access control)