1. apt-get install gammu
2. Detecting mobile
Unplug the mobile from usb and run 'lsusb'. You would get something like this
Bus 002 Device 006: ID 413c:8162 Dell Computer Corp.
Bus 002 Device 005: ID 413c:8161 Dell Computer Corp.
Bus 002 Device 004: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth)
Bus 002 Device 003: ID 12d1:140b Huawei Technologies Co., Ltd. EC1260 Wireless Data Modem HSD USB Card
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
3. Plugin the mobile on USB and run again 'lsusb'
Bus 002 Device 006: ID 413c:8162 Dell Computer Corp.
Bus 002 Device 005: ID 413c:8161 Dell Computer Corp.
Bus 002 Device 004: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth)
Bus 002 Device 003: ID 12d1:140b Huawei Technologies Co., Ltd. EC1260 Wireless Data Modem HSD USB Card
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 024: ID 0fce:d053 Sony Ericsson Mobile Communications AB
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Load the driver
>modprobe usbserial vendor=0x0fce product=0xd053
>dmesg
[ 4670.288435] usb 1-1.2: new full speed USB device using ehci_hcd and address 24
[ 4670.389320] cdc_acm 1-1.2:1.1: ttyACM0: USB ACM device
[ 4670.391582] cdc_acm 1-1.2:1.3: ttyACM1: USB ACM device
[ 4670.395248] cdc_wdm 1-1.2:1.7: cdc-wdm0: USB WDM device
ttyACM0 would be the connected port
4. Configure gammu
>gammu-config
Port : /dev/ACM0
Connection : at19200
LogFile : gammulog
Save it
5. Check it
>gammu --identify
You should get som
Device : /dev/ttyACM0
Manufacturer : Sony Ericsson
Model : W300i/W300c (AAF-1052031-BV)
Firmware : xxxxxxxxx
IMEI : xxxxxxxxxx
Product code : xxxxxxxxxxxx
SIM IMSI : xxxxxxxxxx
6. Send your first message
>gammu sendsms TEXT 9995960189 -text "Thanks Biju"
If you want break, press Ctrl+C...
Sending SMS 1/1....waiting for network answer..OK, message reference=0
Enjoy!!!
Installing and Configuring GAMMU on Ubuntu
Configuring Tata photon on Linux
On the usb device you can find the linux installer. Run it as root user. Photon connector will be in Applications->Internet->Tata Photon+
Run and connect it. I got problem in connecting to net if the browser not as root user.
Its works fine for me if a take the browser as root user
Take browser as root user >sudo firefox. It works fine then.
If anyone knows better idea please let me know.
Aspect Oriented Programming in Spring
Chapter 6. Aspect Oriented Programming with Spring
Aspect-Oriented Programming (AOP) complements Object-Oriented Programming (OOP) by providing another way of thinking about program structure. The key unit of modularity in OOP is the class, whereas in AOP the unit of modularity is the aspect. Aspects enable the modularization of concerns such as transaction management that cut across multiple types and objects. (Such concerns are often termed crosscutting concerns in AOP literature.)
One of the key components of Spring is the AOP framework. While the Spring IoC container does not depend on AOP, meaning you do not need to use AOP if you don't want to, AOP complements Spring IoC to provide a very capable middleware solution.
Spring Annotations
Annotation-based configuration
As mentioned in the section entitled Section 3.7.1.2, “Example: The RequiredAnnotationBeanPostProcessor”, using a BeanPostProcessor in conjunction with annotations is a common means of extending the Spring IoC container. For example, Spring 2.0 introduced the possibility of enforcing required properties with the @Required annotation. As of Spring 2.5, it is now possible to follow that same general approach to drive Spring's dependency injection. Essentially, the @Autowired annotation provides the same capabilities as described in Section 3.3.5, “Autowiring collaborators” but with more fine-grained control and wider applicability. Spring 2.5 also adds support for JSR-250 annotations such as @Resource, @PostConstruct, and @PreDestroy. Of course, these options are only available if you are using at least Java 5 (Tiger) and thus have access to source level annotations. Use of these annotations also requires that certain BeanPostProcessors be registered within the Spring container. As always, these can be registered as individual bean definitions, but they can also be implicitly registered by including the following tag in an XML-based Spring configuration (notice the inclusion of the 'context' namespace):
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-2.5.xsd">
3.11.1. @Required
The @Required annotation applies to bean property setter methods, as in the following example:
public class SimpleMovieLister {
private MovieFinder movieFinder;
@Required
public void setMovieFinder(MovieFinder movieFinder) {
this.movieFinder = movieFinder;
}
// ...
}
This annotation simply indicates that the affected bean property must be populated at configuration time: either through an explicit property value in a bean definition or through autowiring.
3.11.2. @Autowired
As expected, the @Autowired annotation may be applied to "traditional" setter methods:
public class SimpleMovieLister {
private MovieFinder movieFinder;
@Autowired
public void setMovieFinder(MovieFinder movieFinder) {
this.movieFinder = movieFinder;
}
// ...
}
The annotation may also be applied to methods with arbitrary names and/or multiple arguments:
public class MovieRecommender {
private MovieCatalog movieCatalog;
private CustomerPreferenceDao customerPreferenceDao;
@Autowired
public void prepare(MovieCatalog movieCatalog, CustomerPreferenceDao customerPreferenceDao) {
this.movieCatalog = movieCatalog;
this.customerPreferenceDao = customerPreferenceDao;
}
// ...
}
The @Autowired annotation may even be applied on constructors and fields:
public class MovieRecommender {
@Autowired
private MovieCatalog movieCatalog;
private CustomerPreferenceDao customerPreferenceDao;
@Autowired
public MovieRecommender(CustomerPreferenceDao customerPreferenceDao) {
this.customerPreferenceDao = customerPreferenceDao;
}
// ...
}
By default, the autowiring will fail whenever zero candidate beans are available; the default behavior is to treat annotated methods, constructors, and fields as indicating required dependencies. This behavior can be changed as demonstrated below.
public class SimpleMovieLister {
private MovieFinder movieFinder;
@Autowired(required=false)
public void setMovieFinder(MovieFinder movieFinder) {
this.movieFinder = movieFinder;
}
// ...
}
@Autowired may also be used for well-known "resolvable dependencies": the BeanFactory interface, the ApplicationContext interface, the ResourceLoader interface, the ApplicationEventPublisher interface and the MessageSource interface. These interfaces (and their extended interfaces such as ConfigurableApplicationContext or ResourcePatternResolver) will be automatically resolved, with no special setup necessary.
public class MovieRecommender {
@Autowired
private ApplicationContext context;
public MovieRecommender() {
}
// ...
}
3.11.5. @Resource
Spring also supports injection using the JSR-250 @Resource annotation on fields or bean property setter methods. This is a common pattern found in Java EE 5 and Java 6 (e.g. in JSF 1.2 managed beans or JAX-WS 2.0 endpoints), which Spring supports for Spring-managed objects as well.
@Resource takes a 'name' attribute, and by default Spring will interpret that value as the bean name to be injected. In other words, it follows by-name semantics as demonstrated in this example:
public class SimpleMovieLister {
private MovieFinder movieFinder;
@Resource(name="myMovieFinder")
public void setMovieFinder(MovieFinder movieFinder) {
this.movieFinder = movieFinder;
}
}
If no name is specified explicitly, then the default name will be derived from the name of the field or setter method: In case of a field, it will simply be equivalent to the field name; in case of a setter method, it will be equivalent to the bean property name. So the following example is going to have the bean with name "movieFinder" injected into its setter method:
public class SimpleMovieLister {
private MovieFinder movieFinder;
@Resource
public void setMovieFinder(MovieFinder movieFinder) {
this.movieFinder = movieFinder;
}
}
3.11.6. @PostConstruct and @PreDestroy
The CommonAnnotationBeanPostProcessor not only recognizes the @Resource annotation but also the JSR-250 lifecycle annotations. Introduced in Spring 2.5, the support for these annotations offers yet another alternative to those described in the sections on initialization callbacks and destruction callbacks. Provided that the CommonAnnotationBeanPostProcessor is registered within the Spring ApplicationContext, a method carrying one of these annotations will be invoked at the same point in the lifecycle as the corresponding Spring lifecycle interface's method or explicitly declared callback method. In the example below, the cache will be pre-populated upon initialization and cleared upon destruction.
public class CachingMovieLister {
@PostConstruct
public void populateMovieCache() {
// populates the movie cache upon initialization...
}
@PreDestroy
public void clearMovieCache() {
// clears the movie cache upon destruction...
}
}
4.7. Application contexts and Resource paths
4.7.1. Constructing application contexts
An application context constructor (for a specific application context type) generally takes a string or array of strings as the location path(s) of the resource(s) such as XML files that make up the definition of the context.
When such a location path doesn't have a prefix, the specific Resource type built from that path and used to load the bean definitions, depends on and is appropriate to the specific application context. For example, if you create a ClassPathXmlApplicationContext as follows:
ApplicationContext ctx = new ClassPathXmlApplicationContext("conf/appContext.xml");
The bean definitions will be loaded from the classpath, as a ClassPathResource will be used. But if you create a FileSystemXmlApplicationContext as follows:
ApplicationContext ctx =
new FileSystemXmlApplicationContext("conf/appContext.xml");
The bean definition will be loaded from a filesystem location, in this case relative to the current working directory.
Note that the use of the special classpath prefix or a standard URL prefix on the location path will override the default type of Resource created to load the definition. So this FileSystemXmlApplicationContext...
ApplicationContext ctx =
new FileSystemXmlApplicationContext("classpath:conf/appContext.xml");
... will actually load its bean definitions from the classpath. However, it is still a FileSystemXmlApplicationContext. If it is subsequently used as a ResourceLoader, any unprefixed paths will still be treated as filesystem paths.
Spring
IoC container
3.1. Introduction
This chapter covers the Spring Framework's implementation of the Inversion of Control (IoC) [1] principle.
The org.springframework.beans and org.springframework.context packages provide the basis for the Spring Framework's IoC container. The BeanFactory interface provides an advanced configuration mechanism capable of managing objects of any nature. The ApplicationContext interface builds on top of the BeanFactory (it is a sub-interface) and adds other functionality such as easier integration with Spring's AOP features, message resource handling (for use in internationalization), event propagation, and application-layer specific contexts such as the WebApplicationContext for use in web applications.
In short, the BeanFactory provides the configuration framework and basic functionality, while the ApplicationContext adds more enterprise-centric functionality to it. The ApplicationContext is a complete superset of the BeanFactory, and any description of BeanFactory capabilities and behavior is to be considered to apply to the ApplicationContext as well.
This chapter is divided into two parts, with the first part covering the basic principles that apply to both the BeanFactory and ApplicationContext, and with the second part covering those features that apply only to the ApplicationContext interface.
3.2.1. The container
The org.springframework.beans.factory.BeanFactory is the actual representation of the Spring IoC container that is responsible for containing and otherwise managing the aforementioned beans.
Find below an example of the basic structure of XML-based configuration metadata.
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
3.2.2. Instantiating a container
Instantiating a Spring IoC container is straightforward.
ApplicationContext context = new ClassPathXmlApplicationContext( new String[] {"services.xml", "daos.xml"}); // an ApplicationContext is also a BeanFactory (via inheritance) BeanFactory factory = context;
3.2.3.2.2. Instantiation using a static factory method
factory-method="createInstance"/>
3.2.3.2.3. Instantiation using an instance factory method
factory-method="createInstance"/>
3.3. Dependencies
The basic principle behind Dependency Injection (DI) is that objects define their dependencies (that is to say the other objects they work with) only through constructor arguments, arguments to a factory method, or properties which are set on the object instance after it has been constructed or returned from a factory method.
Then, it is the job of the container to actually inject those dependencies when it creates the bean. This is fundamentally the inverse, hence the name Inversion of Control (IoC), of the bean itself being in control of instantiating or locating its dependencies on its own using direct construction of classes, or something like the Service Locator pattern.
3.3.1.1. Constructor Injection
Constructor-based DI is effected by invoking a constructor with a number of arguments, each representing a dependency. Additionally, calling a static factory method with specific arguments to construct the bean, can be considered almost equivalent, and the rest of this text will consider arguments to a constructor and arguments to a static factory method similarly. Find below an example of a class that could only be dependency injected using constructor injection.
3.3.1.1.1. Constructor Argument Resolution
Constructor argument resolution matching occurs using the argument's type. If there is no potential for ambiguity in the constructor arguments of a bean definition, then the order in which the constructor arguments are defined in a bean definition is the order in which those arguments will be supplied to the appropriate constructor when it is being instantiated. Consider the following class:
package x.y;
public class Foo {
public Foo(Bar bar, Baz baz) {
// ...
}
}
When another bean is referenced, the type is known, and matching can occur (as was the case with the preceding example). When a simple type is used, such as
package examples;
public class ExampleBean {
// No. of years to the calculate the Ultimate Answer
private int years;
// The Answer to Life, the Universe, and Everything
private String ultimateAnswer;
public ExampleBean(int years, String ultimateAnswer) {
this.years = years;
this.ultimateAnswer = ultimateAnswer;
}
}
3.3.1.1.1.2. Constructor Argument Index
Constructor arguments can have their index specified explicitly by use of the index attribute. For example:
As well as solving the ambiguity problem of multiple simple values, specifying an index also solves the problem of ambiguity where a constructor may have two arguments of the same type. Note that the index is 0 based.
3.3.1.2. Setter Injection
Setter-based DI is realized by calling setter methods on your beans after invoking a no-argument constructor or no-argument static factory method to instantiate your bean.
Find below an example of a class that can only be dependency injected using pure setter injection. Note that there is nothing special about this class... it is plain old Java.
public class SimpleMovieLister { // the SimpleMovieLister has a dependency on the MovieFinder private MovieFinder movieFinder; // a setter method so that the Spring container can 'inject' a MovieFinder public void setMovieFinder(MovieFinder movieFinder) { this.movieFinder = movieFinder; } // business logic that actually 'uses' the injected MovieFinder is omitted... }
Bean dependency resolution generally happens as follows:
1.
The BeanFactory is created and initialized with a configuration which describes all the beans. (Most Spring users use a BeanFactory or ApplicationContext implementation that supports XML format configuration files.)
2.
Each bean has dependencies expressed in the form of properties, constructor arguments, or arguments to the static-factory method when that is used instead of a normal constructor. These dependencies will be provided to the bean, when the bean is actually created.
3.
Each property or constructor argument is either an actual definition of the value to set, or a reference to another bean in the container.
4.
Each property or constructor argument which is a value must be able to be converted from whatever format it was specified in, to the actual type of that property or constructor argument. By default Spring can convert a value supplied in string format to all built-in types, such as int, long, String, boolean, etc.
The Spring container validates the configuration of each bean as the container is created, including the validation that properties which are bean references are actually referring to valid beans. However, the bean properties themselves are not set until the bean is actually created. For those beans that are singleton-scoped and set to be pre-instantiated (such as singleton beans in an ApplicationContext), creation happens at the time that the container is created, but otherwise this is only when the bean is requested.
3.3.1.3. Some examples
First, an example of using XML-based configuration metadata for setter-based DI. Find below a small part of a Spring XML configuration file specifying some bean definitions.
public class ExampleBean {
private AnotherBean beanOne;
private YetAnotherBean beanTwo;
private int i;
public void setBeanOne(AnotherBean beanOne) {
this.beanOne = beanOne;
}
public void setBeanTwo(YetAnotherBean beanTwo) {
this.beanTwo = beanTwo;
}
public void setIntegerProperty(int i) {
this.i = i;
}
}
As you can see, setters have been declared to match against the properties specified in the XML file. Find below an example of using constructor-based DI.
public class ExampleBean {
private AnotherBean beanOne;
private YetAnotherBean beanTwo;
private int i;
public ExampleBean(
AnotherBean anotherBean, YetAnotherBean yetAnotherBean, int i) {
this.beanOne = anotherBean;
this.beanTwo = yetAnotherBean;
this.i = i;
}
}
As you can see, the constructor arguments specified in the bean definition will be used to pass in as arguments to the constructor of the ExampleBean.
Now consider a variant of this where instead of using a constructor, Spring is told to call a static factory method to return an instance of the object:
public class ExampleBean {
// a private constructor
private ExampleBean(...) {
...
}
// a static factory method; the arguments to this method can be
// considered the dependencies of the bean that is returned,
// regardless of how those arguments are actually used.
public static ExampleBean createInstance (
AnotherBean anotherBean, YetAnotherBean yetAnotherBean, int i) {
ExampleBean eb = new ExampleBean (...);
// some other operations...
return eb;
}
}
Note that arguments to the static factory method are supplied via
3.3.4. Lazily-instantiated beans
3.3.7.1. Lookup method injection
3.3.7.1. Lookup method injection
Lookup method injection refers to the ability of the container to override methods on container managed beans, to return the result of looking up another named bean in the container. The lookup will typically be of a prototype bean as in the scenario described above. The Spring Framework implements this method injection by dynamically generating a subclass overriding the method, using bytecode generation via the CGLIB library.
So if you look at the code from previous code snippet (the CommandManager class), the Spring container is going to dynamically override the implementation of the createCommand() method. Your CommandManager class is not going to have any Spring dependencies, as can be seen in this reworked example below:
package fiona.apple;
// no more Spring imports!
public abstract class CommandManager {
public Object process(Object commandState) {
// grab a new instance of the appropriate Command interface
Command command = createCommand();
// set the state on the (hopefully brand new) Command instance
command.setState(commandState);
return command.execute();
}
// okay... but where is the implementation of this method?
protected abstract Command createCommand();
}
In the client class containing the method to be injected (the CommandManager in this case), the method that is to be 'injected' must have a signature of the following form:
If the method is abstract, the dynamically-generated subclass will implement the method. Otherwise, the dynamically-generated subclass will override the concrete method defined in the original class. Let's look at an example:
The bean identified as commandManager will call its own method createCommand() whenever it needs a new instance of the command bean. It is important to note that the person deploying the beans must be careful to deploy the command bean as a prototype (if that is actually what is needed). If it is deployed as a singleton, the same instance of the command bean will be returned each time!
Please be aware that in order for this dynamic subclassing to work, you will need to have the CGLIB jar(s) on your classpath. Additionally, the class that the Spring container is going to subclass cannot be final, and the method that is being overridden cannot be final either. Also, testing a class that has an abstract method can be somewhat odd in that you will have to subclass the class yourself and supply a stub implementation of the abstract method. Finally, objects that have been the target of method injection cannot be serialized.
3.4. Bean scopes
singleton
Scopes a single bean definition to a single object instance per Spring IoC container.
prototype
Scopes a single bean definition to any number of object instances.
request
Scopes a single bean definition to the lifecycle of a single HTTP request; that is each and every HTTP request will have its own instance of a bean created off the back of a single bean definition. Only valid in the context of a web-aware Spring ApplicationContext.
session
Scopes a single bean definition to the lifecycle of a HTTP Session. Only valid in the context of a web-aware Spring ApplicationContext.
global session
Scopes a single bean definition to the lifecycle of a global HTTP Session. Typically only valid when used in a portlet context. Only valid in the context of a web-aware Spring ApplicationContext.
3.4.4.1. Initial web configuration
In order to support the scoping of beans at the request, session, and global session levels (web-scoped beans), some minor initial configuration is required before you can set about defining your bean definitions. Please note that this extra setup is not required if you just want to use the 'standard' scopes (namely singleton and prototype).
...
...
If you are using an older web container (Servlet 2.3), you will need to use the provided javax.servlet.Filter implementation. Find below a snippet of XML configuration that has to be included in the 'web.xml' file of your web application if you want to have access to web-scoped beans in requests outside of Spring's DispatcherServlet on a Servlet 2.3 container. (The filter mapping depends on the surrounding web application configuration and so you will have to change it as appropriate.)
..
...
3.4.4.5. Scoped beans as dependencies
Being able to define a bean scoped to a HTTP request or Session (or indeed a custom scope of your own devising) is all very well, but one of the main value-adds of the Spring IoC container is that it manages not only the instantiation of your objects (beans), but also the wiring up of collaborators (or dependencies). If you want to inject a (for example) HTTP request scoped bean into another bean, you will need to inject an AOP proxy in place of the scoped bean. That is, you need to inject a proxy object that exposes the same public interface as the scoped object, but that is smart enough to be able to retrieve the real, target object from the relevant scope (for example a HTTP request) and delegate method calls onto the real object.
Let's look at the configuration that is required to effect this; the configuration is not hugely complex (it takes just one line), but it is important to understand the “why” as well as the “how” behind it.
xmlns:aop="http://www.springframework.org/schema/aop"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd">
3.5.1. Lifecycle callbacks
3.5.1.1. Initialization callbacks
Implementing the org.springframework.beans.factory.InitializingBean interface allows a bean to perform initialization work after all necessary properties on the bean have been set by the container. The InitializingBean interface specifies exactly one method:
void afterPropertiesSet() throws Exception;
Implementing the org.springframework.beans.factory.InitializingBean interface allows a bean to perform initialization work after all necessary properties on the bean have been set by the container. The InitializingBean interface specifies exactly one method:
void afterPropertiesSet() throws Exception;
Generally, the use of the InitializingBean interface can be avoided and is actually discouraged since it unnecessarily couples the code to Spring. As an alternative, bean definitions provide support for a generic initialization method to be specified. In the case of XML-based configuration metadata, this is done using the 'init-method' attribute. For example, the following definition:
public class ExampleBean {
public void init() {
// do some initialization work
}
}
...is exactly the same as...
public class AnotherExampleBean implements InitializingBean {
public void afterPropertiesSet() {
// do some initialization work
}
}
... but does not couple the code to Spring.
3.5.1.2. Destruction callbacks
Implementing the org.springframework.beans.factory.DisposableBean interface allows a bean to get a callback when the container containing it is destroyed. The DisposableBean interface specifies a single method:
void destroy() throws Exception;
Generally, the use of the DisposableBean callback interface can be avoided and is actually discouraged since it unnecessarily couples the code to Spring. As an alternative, bean definitions provide support for a generic destroy method to be specified. When using XML-based configuration metadata this is done via the 'destroy-method' attribute on the
public class ExampleBean {
public void cleanup() {
// do some destruction work (like releasing pooled connections)
}
}
...is exactly the same as...
public class AnotherExampleBean implements DisposableBean {
public void destroy() {
// do some destruction work (like releasing pooled connections)
}
}
... but does not couple the code to Spring.
3.8.5. Convenient ApplicationContext instantiation for web applications
As opposed to the BeanFactory, which will often be created programmatically, ApplicationContext instances can be created declaratively using for example a ContextLoader. Of course you can also create ApplicationContext instances programmatically using one of the ApplicationContext implementations. First, let's examine the ContextLoader mechanism and its implementations.
The ContextLoader mechanism comes in two flavors: the ContextLoaderListener and the ContextLoaderServlet. They both have the same functionality but differ in that the listener version cannot be reliably used in Servlet 2.3 containers. Since the Servlet 2.4 specification, servlet context listeners are required to execute immediately after the servlet context for the web application has been created and is available to service the first request (and also when the servlet context is about to be shut down): as such a servlet context listener is an ideal place to initialize the Spring ApplicationContext. It is up to you as to which one you use, but all things being equal you should probably prefer ContextLoaderListener; for more information on compatibility, have a look at the Javadoc for the ContextLoaderServlet.
You can register an ApplicationContext using the ContextLoaderListener as follows:
The listener inspects the 'contextConfigLocation' parameter. If the parameter does not exist, the listener will use /WEB-INF/applicationContext.xml as a default. When it does exist, it will separate the String using predefined delimiters (comma, semicolon and whitespace) and use the values as locations where application contexts will be searched for. Ant-style path patterns are supported as well: e.g. /WEB-INF/*Context.xml (for all files whose name ends with "Context.xml", residing in the "WEB-INF" directory) or /WEB-INF/**/*Context.xml (for all such files in any subdirectory of "WEB-INF").
The ContextLoaderServlet can be used instead of the ContextLoaderListener. The servlet will use the 'contextConfigLocation' parameter just as the listener does.
3.3.5. Autowiring collaborators
The Spring container is able to autowire relationships between collaborating beans. This means that it is possible to automatically let Spring resolve collaborators (other beans) for your bean by inspecting the contents of the BeanFactory. The autowiring functionality has five modes. Autowiring is specified per bean and can thus be enabled for some beans, while other beans will not be autowired. Using autowiring, it is possible to reduce or eliminate the need to specify properties or constructor arguments, thus saving a significant amount of typing. [2] When using XML-based configuration metadata, the autowire mode for a bean definition is specified by using the autowire attribute of the
Table 3.2. Autowiring modes
Mode Explanation
no
No autowiring at all. Bean references must be defined via a ref element. This is the default, and changing this is discouraged for larger deployments, since explicitly specifying collaborators gives greater control and clarity. To some extent, it is a form of documentation about the structure of a system.
byName
Autowiring by property name. This option will inspect the container and look for a bean named exactly the same as the property which needs to be autowired. For example, if you have a bean definition which is set to autowire by name, and it contains a master property (that is, it has a setMaster(..) method), Spring will look for a bean definition named master, and use it to set the property.
byType
Allows a property to be autowired if there is exactly one bean of the property type in the container. If there is more than one, a fatal exception is thrown, and this indicates that you may not use byType autowiring for that bean. If there are no matching beans, nothing happens; the property is not set. If this is not desirable, setting the dependency-check="objects" attribute value specifies that an error should be thrown in this case.
constructor
This is analogous to byType, but applies to constructor arguments. If there isn't exactly one bean of the constructor argument type in the container, a fatal error is raised.
autodetect
Chooses constructor or byType through introspection of the bean class. If a default constructor is found, the byType mode will be applied.
3.7.2. Customizing configuration metadata with BeanFactoryPostProcessors
The next extension point that we will look at is the org.springframework.beans.factory.config.BeanFactoryPostProcessor. The semantics of this interface are similar to the BeanPostProcessor, with one major difference: BeanFactoryPostProcessors operate on the bean configuration metadata; that is, the Spring IoC container will allow BeanFactoryPostProcessors to read the configuration metadata and potentially change it before the container has actually instantiated any other beans.
A bean factory post-processor is executed manually (in the case of a BeanFactory) or automatically (in the case of an ApplicationContext) to apply changes of some sort to the configuration metadata that defines a container. Spring includes a number of pre-existing bean factory post-processors, such as PropertyOverrideConfigurer and PropertyPlaceholderConfigurer, both described below. A custom BeanFactoryPostProcessor can also be used to register custom property editors, for example.
In a BeanFactory, the process of applying a BeanFactoryPostProcessor is manual, and will be similar to this:
XmlBeanFactory factory = new XmlBeanFactory(new FileSystemResource("beans.xml"));
// bring in some property values from a Properties file
PropertyPlaceholderConfigurer cfg = new PropertyPlaceholderConfigurer();
cfg.setLocation(new FileSystemResource("jdbc.properties"));
// now actually do the replacement
cfg.postProcessBeanFactory(factory);
This explicit registration step is not convenient, and this is one of the reasons why the various ApplicationContext implementations are preferred above plain BeanFactory implementations in the vast majority of Spring-backed applications, especially when using BeanFactoryPostProcessors.
An ApplicationContext will detect any beans which are deployed into it which implement the BeanFactoryPostProcessor interface, and automatically use them as bean factory post-processors, at the appropriate time. Nothing else needs to be done other than deploying these post-processor in a similar fashion to any other bean.
3.7.2.1. Example: the PropertyPlaceholderConfigurer
The PropertyPlaceholderConfigurer is used to externalize property values from a BeanFactory definition, into another separate file in the standard Java Properties format. This is useful to allow the person deploying an application to customize environment-specific properties (for example database URLs, usernames and passwords), without the complexity or risk of modifying the main XML definition file or files for the container.
Consider the following XML-based configuration metadata fragment, where a DataSource with placeholder values is defined. We will configure some properties from an external Properties file, and at runtime, we will apply a PropertyPlaceholderConfigurer to the metadata which will replace some properties of the DataSource:
Annotations
1) Introduction
Annotations in Java is all about adding meta-data facility to the Java Elements. Like Classes, Interfaces or Enums, Annotations define a type in Java and they can be applied to several Java Elements. Tools which will read and interpret the Annotaions will implement a lot of functionalities from the meta-information obtained. For example, they can ensure the consistency between classes, can check the validity of the paramters passed by the clients at run-time and can generate lot of base code for a project. This article provides you a complete guide detailing the various aspects of Annotations. The topics covered in this article are as follows,
public @interface TestAnnotation
{
// Property Definition here.
}
Don't get confused with the interface keyword. It has nothing to do with annotations. '@' along with interface is the start of the annotation definition and TestAnnotation in the above case is the name of the Annotation. Whether annotations can be applied to class (a class-level annotation), or a method (method-level annotation) or a field (field-level annotation) is specified in the declaration of the annotation itself. This is referred to as Annotating an Annotation itself.
2.2) Target Annotation
For example, if the case is that @TestAnnotation annotation can only be applied to methods, then there is a Meta-Annotation (meta-data about meta-data) which tells for which element type this annotation is applicable. For example, the following is the declaration of the @TestAnnotation annotation along with some meta-data that states the elements that this annotation can be applied to.
TestAnnotation.java
@Target(ElementType.METHOD)
public @interface TestAnnotation
{
// Property Definitions here.
}
From the above, we can see that the Annotation @TestAnnotation is annotated with @Target. This kind of Annotation Chaining is always possible. The target element tells that the @TestAnnotation annotation can be applied only to methods and not to any other element types. The argument to @Target Annotation can be one from the possible set of values of any Java Element, which is defined in a well-defined Enum called ElementType. Here are the possible values taken by this Enum,
- TYPE – Applied only to Type. A Type can be a Java class or interface or an Enum or even an Annotation.
- FIELD – Applied only to Java Fields (Objects, Instance or Static, declared at class level).
- METHOD – Applied only to methods.
- PARAMETER – Applied only to method parameters in a method definition.
- CONSTRUCTOR – Can be applicable only to a constructor of a class.
- LOCAL_VARIABLE – Can be applicable only to Local variables. (Variables that are declared within a method or a block of code).
- ANNOTATION_TYPE – Applied only to Annotation Types.
- PACKAGE – Applicable only to a Package.
2.3) Retention Annotation
Another commonly used Meta-data for an Annotation is the Retention Policy. Assume that we have some Annotations defined in the source code. We have a mechanism through which we can say that to what extent the Annotations should be retained. The three possible ways of telling this are,
- Retain the Annotation in the Source Code only
- Retain the Annotation in the Class file also.
- Retain the Annotation Definition during the Run-time so that JVM can make use of it.
The Annotation that is used to achieve this is @Retention and it takes a possible values of SOURCE, CLASS and RUNTIME defined in RetentionPolicy Enumeration. For example, if we want to retain the @TestAnnotation information till the class file, we can define something like this,
TestAnnotation.java
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.CLASS)
public @interface TestAnnotation
{
// Property Definitions here.
}
.
3) Built-in Annotations in Java
There are some pre-defined annotations available in the Java They are,
- Override
- Deprecated
- SuppressWarnings
http://www.javabeat.net/articles/30-annotations-in-java-50-2.html
Java and Web Services
Web Services have at their core XML as a mechanism for communication. Ultimately, Web Services are based on three specific technologies: a mechanism to register a service, a mechanism to find a service, and a mechanism for two parties to communicate. Today, developers can use the Java 2 Enterprise Edition APIs and XML to provide Web Services. Such developments leverage existing Web sites and provide simple methods to extend, interconnect and publish existing J2EE-based applications in new and exciting ways.
a Web Service is three specific things:
- A way to find and register interest in a service.
- A transport mechanism to access a service.
- A way to define what the input and output parameters are for such a service.
Defining a Service, Web Services Description Language
Specifically WSDL provides a number of key pieces of information:
- A definition of the format of the messages that are passed between two endpoints using its
and elements and appropriate schema definitions. - The semantics of the service: how it might be called to make a synchronous request/reply, synchronous reply-only or asynchronously communicate.
- The end point and transport of the service via the
element: that is, who provides the service. - An encoding via the
element, that is how the service is accessed.
Universal Discovery and Description Integration (UDDI)
Connecting It All Together With the Simple Object Access Protocol
We now understand three things: how a Web Service is defined, and where it can be published and accessed. But we've left out one crucial aspect of the puzzle: how do we actually access the service once we've found it? Web Services become accessible using a protocol known as the Simple Object Access Protocol, or SOAP. In fact, you normally access a UDDI registry using well-defined SOAP calls! But what is SOAP? SOAP, at its simplest, is a protocol for encapsulating a request as an XML payload using standard communications protocols such as HTTP. The power of SOAP comes from the fact that is simple, easy to implement, and well supported in the industry.
Typically, a SOAP call is packaged as the body of an HTTP request. The listing below, from the W3C SOAP specification, shows an example of a SOAP call to access a service known as GetLastTradePrice as an HTTP server might receive it.
Guruji Oru Vakku (1985) - Penninte chenchundil
Movie : Guruji Oru Vakku
Singer: Yesudas,Chithra
Music : Jerry Amaldas
Lyrics: Bichu Thirumala
Director: Rajan Sankaradi
*******************************************************
Penninte chenchundil punjiri poothu
Hayya kannaadi puzhayil viriyana kulirala pole
Kandille kinnaaram parayanoraale
Hayya illikkad adimudi ulayana kalapila pole
(penninte)
Kari vandina kannukalil oliyambukal eyyanatho
Thein kudikkanatho kandu....
Vira kollana chundukalil uriyadana thanthramo
Maara manthramo kettoo
Hoyyaaram payyaaram thudi kottana sringaaram
Oh..hoy hoy manassinu kulirane (penninte)
Azhakaarnnoru chandirano mazhavillezhum indirano
Aaru neeyariyaararo
Kulirekanorambiliyo kuliraatana kambiliyo
Mangayaanival aararo...
Annaaram Punnaaram mozhi muttana kinnaaram
Oh..hoy hoy adimudi thalirane (kandille)
Java Beans
JavaBeans™ is a portable, platform-independent component model written in the Java programming language. The JavaBeans architecture was built through a collaborative industry effort and enables developers to write reusable components in the Java programming language.
With the JavaBeans API you can create reuseable, platform-independent components. Using JavaBeans-compliant application builder tools, you can combine these components into applets, applications, or composite components.
JavaBean components are known as beans. Beans are dynamic in that they can be changed or customized. Through the design mode of a builder tool, you use the property sheet or bean customizer to customize the bean and then save (persist) your customized beans.
Bob Parsons 16 rules
A serial entrepreneur, Parsons' first endeavor was Parsons Technology, a software company he started in his basement in 1984, after teaching himself how to write computer programs. After creating the company’s initial software, MoneyCounts and Personal Tax Edge, Parsons used direct mail marketing to sell these and subsequent products.
When Parsons Technology was sold to Intuit, Inc. in 1994 for $64 million dollars, the company had nearly 1,000 employees, $100 million in annual revenue and three million customers. At the time, Parsons Technology sold more than 100 products, was releasing a new product or significant product upgrade every six days, and was sending more than six million pieces of direct marketing mail each month.
1. Get and stay out of your comfort zone.
I believe that not much happens of any significance when we're in our comfort zone. I hear people say, "But I'm concerned about security." My response to that is simple: "Security is for cadavers."
2. Never give up.
Almost nothing works the first time it's attempted. Just because what you're doing does not seem to be working, doesn't mean it won't work. It just means that it might not work the way you're doing it. If it was easy, everyone would be doing it, and you wouldn't have an opportunity.
3. When you’re ready to quit, you’re closer than you think.
There's an old Chinese saying that I just love, and I believe it is so true. It goes like this: "The temptation to quit will be greatest just before you are about to succeed."
4. With regard to whatever worries you, not only accept the worst thing that could happen, but make it a point to quantify what the worst thing could be.
Very seldom will the worst consequence be anywhere near as bad as a cloud of "undefined consequences." My father would tell me early on, when I was struggling and losing my shirt trying to get Parsons Technology going, "Well, Robert, if it doesn't work, they can't eat you."
5. Focus on what you want to have happen.
Remember that old saying, "As you think, so shall you be."
6. Take things a day at a time.
No matter how difficult your situation is, you can get through it if you don't look too far into the future, and focus on the present moment. You can get through anything one day at a time.
7. Always be moving forward.
Never stop investing. Never stop improving. Never stop doing something new. The moment you stop improving your organization, it starts to die. Make it your goal to be better each and every day, in some small way. Remember the Japanese concept of Kaizen. Small daily improvements eventually result in huge advantages.
8. Be quick to decide.
Remember what General George S. Patton said: "A good plan violently executed today is far and away better than a perfect plan tomorrow."
9. Measure everything of significance.
I swear this is true. Anything that is measured and watched, improves.
10. Anything that is not managed will deteriorate.
If you want to uncover problems you don't know about, take a few moments and look closely at the areas you haven't examined for a while. I guarantee you problems will be there.
11. Pay attention to your competitors, but pay more attention to what you’re doing.
When you look at your competitors, remember that everything looks perfect at a distance. Even the planet Earth, if you get far enough into space, looks like a peaceful place.
12. Never let anybody push you around.
In our society, with our laws and even playing field, you have just as much right to what you're doing as anyone else, provided that what you're doing is legal.
13. Never expect life to be fair.
Life isn't fair. You make your own breaks. You'll be doing good if the only meaning fair has to you, is something that you pay when you get on a bus (i.e., fare).
14. Solve your own problems.
You'll find that by coming up with your own solutions, you'll develop a competitive edge. Masura Ibuka, the co-founder of SONY, said it best: "You never succeed in technology, business, or anything by following the others." There's also an old Asian saying that I remind myself of frequently. It goes like this: "A wise man keeps his own counsel."
15. Don’t take yourself too seriously.
Lighten up. Often, at least half of what we accomplish is due to luck. None of us are in control as much as we like to think we are.
16. There’s always a reason to smile.
Find it. After all, you're really lucky just to be alive. Life is short. More and more, I agree with my little brother. He always reminds me: “We’re not here for a long time, we’re here for a good time!”
Web Server and Application server
What is the difference between an application server and a Web server?
Taking a big step back, a Web server serves pages for viewing in a Web browser, while an application server provides methods that client applications can call. A little more precisely, you can say that:
A Web server exclusively handles HTTP requests, whereas an application server serves business logic to application programs through any number of protocols.
Let's examine each in more detail.
The Web server
A Web server handles the HTTP protocol. When the Web server receives an HTTP request, it responds with an HTTP response, such as sending back an HTML page. To process a request, a Web server may respond with a static HTML page or image, send a redirect, or delegate the dynamic response generation to some other program such as CGI scripts, JSPs (JavaServer Pages), servlets, ASPs (Active Server Pages), server-side JavaScripts, or some other server-side technology. Whatever their purpose, such server-side programs generate a response, most often in HTML, for viewing in a Web browser.
Understand that a Web server's delegation model is fairly simple. When a request comes into the Web server, the Web server simply passes the request to the program best able to handle it. The Web server doesn't provide any functionality beyond simply providing an environment in which the server-side program can execute and pass back the generated responses. The server-side program usually provides for itself such functions as transaction processing, database connectivity, and messaging.
While a Web server may not itself support transactions or database connection pooling, it may employ various strategies for fault tolerance and scalability such as load balancing, caching, and clustering—features oftentimes erroneously assigned as features reserved only for application servers.
The application server
As for the application server, according to our definition, an application server exposes business logic to client applications through various protocols, possibly including HTTP. While a Web server mainly deals with sending HTML for display in a Web browser, an application server provides access to business logic for use by client application programs. The application program can use this logic just as it would call a method on an object (or a function in the procedural world).
Such application server clients can include GUIs (graphical user interface) running on a PC, a Web server, or even other application servers. The information traveling back and forth between an application server and its client is not restricted to simple display markup. Instead, the information is program logic. Since the logic takes the form of data and method calls and not static HTML, the client can employ the exposed business logic however it wants.
In most cases, the server exposes this business logic through a component API, such as the EJB (Enterprise JavaBean) component model found on J2EE (Java 2 Platform, Enterprise Edition) application servers. Moreover, the application server manages its own resources. Such gate-keeping duties include security, transaction processing, resource pooling, and messaging. Like a Web server, an application server may also employ various scalability and fault-tolerance techniques. Continued
An example
As an example, consider an online store that provides real-time pricing and availability information. Most likely, the site will provide a form with which you can choose a product. When you submit your query, the site performs a lookup and returns the results embedded within an HTML page. The site may implement this functionality in numerous ways. I'll show you one scenario that doesn't use an application server and another that does. Seeing how these scenarios differ will help you to see the application server's function.
Scenario 1: Web server without an application server
In the first scenario, a Web server alone provides the online store's functionality. The Web server takes your request, then passes it to a server-side program able to handle the request. The server-side program looks up the pricing information from a database or a flat file. Once retrieved, the server-side program uses the information to formulate the HTML response, then the Web server sends it back to your Web browser.
To summarize, a Web server simply processes HTTP requests by responding with HTML pages.
Scenario 2: Web server with an application server
Scenario 2 resembles Scenario 1 in that the Web server still delegates the response generation to a script. However, you can now put the business logic for the pricing lookup onto an application server. With that change, instead of the script knowing how to look up the data and formulate a response, the script can simply call the application server's lookup service. The script can then use the service's result when the script generates its HTML response.
In this scenario, the application server serves the business logic for looking up a product's pricing information. That functionality doesn't say anything about display or how the client must use the information. Instead, the client and application server send data back and forth. When a client calls the application server's lookup service, the service simply looks up the information and returns it to the client.
By separating the pricing logic from the HTML response-generating code, the pricing logic becomes far more reusable between applications. A second client, such as a cash register, could also call the same service as a clerk checks out a customer. In contrast, in Scenario 1 the pricing lookup service is not reusable because the information is embedded within the HTML page. To summarize, in Scenario 2's model, the Web server handles HTTP requests by replying with an HTML page while the application server serves application logic by processing pricing and availability requests.
Caveats
Recently, XML Web services have blurred the line between application servers and Web servers. By passing an XML payload to a Web server, the Web server can now process the data and respond much as application servers have in the past.
Additionally, most application servers also contain a Web server, meaning you can consider a Web server a subset of an application server. While application servers contain Web server functionality, developers rarely deploy application servers in that capacity. Instead, when needed, they often deploy standalone Web servers in tandem with application servers. Such a separation of functionality aids performance (simple Web requests won't impact application server performance), deployment configuration (dedicated Web servers, clustering, and so on), and allows for best-of-breed product selection.
Web Services
Web Services Concept:
Web services are the mechanism to develop a Service-Oriented-Architecture (SOA). SOA is an architectural approach for designing large scale distributed systems to integrate heterogeneous application on the service interfaces. Web services technologies support to the Service-Oriented-Architecture in various ways. Some of them are illustrated below:
A service requestor uses the selection criteria to the query registry for finding the services description.
A service requestor can bind and use the service if it finds a suitable descriptor.
Web services are used in various fields such converting a temperature value from Fahrenheit to Celsius. More realistic examples built using the web services are heterogeneous applications such as billing application and report generator, interconnected in-house architectures. A service interface is just like an object interface with a slight difference that the contract between the interface and the client is more flexible and the implementation of client and the service is not much tightly coupled as compared to EJB or other distributed platform. Looser coupling allows the client and service implementation to run on various platforms, independently such as Microsoft .NET is capable of using a Java EE application server to access a service running on it. From the client's point of view, web services's life cycle is more static as compared to average objects because web services stay around rather than pop-up and go away, even if the services are implemented using the object technology.
Web Services Standards: The de facto standardized set of web services can be summarized by using an equation.
Web Services = WSDL + SOAP + UDDI
Lets take a quick look over WSDL and UDDI, but we are not going to cover these topics here because these are less useful. The requestor does not necessarily have the registry to know the services and its end point address. Registry not only supports a simple naming service but also queries for the services that follow the given predicate.
WSDL: There is no need to write down the xml file. The tool you are using automatically creates an xml file. A number of things are worth nothing while using WSDL.
The service description includes an endpoint address: WSDL is similar to java interface and an object reference joined together or in other words, we can say web services don't have distinct identities. Since they are not objects therefore they must be viewed like objects. It does not have any client visible state therefore your are not able to compare the two references for equality.
It uses larger number of concepts than in java: Service provides one or more ports at an address. Ports are the representation of the service interfaces that binds to protocols.
Operations result in terms of input and output messages rather than parameters and return values:
Services are bind using SOAP binding:
Building a Web Service with JEE: The creation of the portable and interoperable distributed components from the web services is not a trivial task. Either regular Java classes or stateless EJBs can be easily deployed as web services. Package the Java regular classes in a web module and EJB web services in normal ejb-jar modules.
Two options are there to deploy an application, you can use one of the two deployment options given below:
Java Class versus Stateless EJB: It depends upon you whether you should have a regular Java class or EJBs as your technology to build a Web Service. We can easily develop java classes than EJBs. Java classes are pure java objects and do not have the extra baggage that the EJBs do. One benefit of using EJB is that it supports the features such as declarative transaction and security. EJB leaves free to the developer just to concentrate only on applying the business logic without worrying about the infrastructure services.
Packaging Requirement: Whatever you are using either a regular Java class or EJB, in both the conditions you need to package several artifacts into your WAR or ejb-jar accordingly, to expose components as a Java Web Service. Web Services use the following two packaging structures based on either regular Java classes or EJBs.
Web app (.war) for a regular Java web service:
| /WEB-INF/ |
ejb-jar for an EJB-based web service:
| /META-INF/ |
Lets discuss each of the descriptors and the deployment-time artifacts one-by-one.
WSDL: We are not going to discuss about the WSDL any more as we have already discuss it in the previous section.
Web Services deployment descriptor: webservices.xml is the standard deployment descriptor that a JEE plateform requires. This descriptor specifies the description for deployment about the set of web services into the JEE application server and also their dependencies on the container resources and services. The mapping.xml file that contains Java-to-WSDL mapping and the service endpoint interface for the HelloWorld web service is also specified by this deployment descriptor.
Endpoint interface: The Web Service endpoint implements the java.rmi.Remote interface therefore every method of web service endpoint interface must throw the java.rmi.RemoteException. The deployment descriptor registers to the end point for the module (ejb-jar.xml) or web.xml. The deployment descriptor (e.g. ejb-jar.xml) should have the following entry.
|
|
Following is the code for the Web Service endpoint for a HelloWorld web service:
| public interface HelloServiceInf extends java.rmi.Remote { |
Vendor-specific deployment descriptors: We can not specify several implementation-specific reference, such as endpoint addresses, context root in the Web Services deployment descriptor but we can rather specify the vendor-specific deployment descriptor. For example if you are using OC4J then an oracle-webservices.xml file is required to package in WAR or ejb-jar to define the properties.
Java-WSDL mapping: Mapping between the WSDL and Java types is defined in this file. Mapping file does not have any standard name, web services deployment descriptor defines its name.
Before deploying your component as a web service, first you must package all these artifacts in the ejb-jar module or in the WAR. Most of the development tools like Oracle JDeveloper simplifies the development task of web services simply by mapping files, generating the deployment descriptor etc. Moreover most of the application servers provide Web Services assembly tools that fulfill the JEE web service packaging requirements.
Before understanding the components required to make up a Web Service and the associated packaging requirements, first you must deal with the architectural issues when developing a web service.
Approaches to Construct Services: The main thing about building a Web Service is to identify the service along with its right granularity. Its depends upon you either you can expose an existing component that is built as a Java class or EJB and expose it as a service or build the new service. You can use either top-down or bottom-up approach while building a new service.
Top-down approach: While building the services from scratch, this is the most appropriate approach. With this approach start describing the service with WSDL instead of jumping right into the implementation. This is the most preferable approach since services become maintainable, more usable and interoperable due to the control over the WSDL while deploying your web service, careful consideration of the operations and message exposed. Several JEE vendors provide tools to make the approach easier such as Oracle Application Server's web services assembler generates deployment descriptors, interfaces and skeleton implementation classes which can be used to build your application.
Bottom-up approach: This approach is used whenever an existing Java class or EJB is to be exposed as a Web Service. The reason behind the populalrity of this approach is that, this approach allows to reuse the existing business logic without rewriting the applications. While using this approach, you have to create a WSDL to describe the Web Service along with other deployment descriptors and add a web service end-point interface for the implementation to which you want to expose as a Web Service. Tools provided by application servers (such as Oracle Application Server's web services assembler tool) are used to make the life simpler by generating the descriptors such as webservices.xml, WSDL and mapping files for Web Services components free up the developer from manually creating these files.
Tips for developing Web Services: Here are the some points that must follow while developing Web Services.
Most of the conventional best practices are for JEE applications that are relevant to Web Services. for example, avoid exposing a component involve in the long-run transaction as a Web Service.
Confirm design of your Web Service so that it can create minimum network traffic.
Do not overuse Web Services in your applications. Check the necessity to expose your application as a Web Service.
Compare your security requirements with the performance of your application as security comes with the higher cost. Performance of end-to-end security for web services are quite costly.
To build java based web services, J2EE Blueprint Application ( Java Adventure Builder) provides a nice blueprint application.
After designing, developing and deploying, we generally create the associated components to interact with the given service.
Invoking Web Services: Web Service can have the client of any of the following type: Dynamic Invocation Interface (DII) or dynamic proxy, static stub.
Building a Web Service client may be complex similar to build a simple web service. But JEE 1.4 makes it simple to use the web services for JEE developers from any type of JEE component such as EJB components or web clients.
Invoking a Web Service is similar to invoking any other resource using JNDI via the following:
First define your component by using a "service-ref" element in the deployment descriptor. For example, if you are accessing the HelloWorldService web service by using web module then the module's web.xml file may contain the following:
Allow your application to find Web Service just by specifying the location of the Web Service in the vendor-specific deployment descriptor.
localpart="HelloWorldServicePort"/> javax.xml.rpc.service.endpoint.address http://localhost:8888/hello/HelloWorldInf Package type classes and end-point interface with your application before deploying it to the server. Make the JNDI lookup to use a Web Service.
-
InitialContext ctx= new InitialContext();
HelloServiceInf hs = (HelloServiceInf)
ctx.lookup("java:comp/env/service/HelloWorldService");
HelloWorld hello= hs.getHelloWorldServicePort();
String myhello = hs.sayHello("Zulfiqar") ;
Simplifying SOA Development with JEE 5.0: Building service-oriented applications are rather difficult with JEE, JEE 5.0 is designed to simplify the development by using Web Services Metadata annotations defined by JSR 181. Web Services Metadata and EJB 3.0 both are used to provide friendly environment to the developer.
To develop a simple Java Web Service in JEE 1.4, several Web Service artifacts such as mapping files, WSDL, proprietary web services deployment descriptor and several verbose standard are designed in JEE 5.0. Web Services Metadata specification receives a by default configuration approach similar to EJB 3.0 for simplifying the development process. Web Services Metadata annotation process generates these files for you so just concentrate on the implementation class.
Following is the Java Web Service developed using Web Services Metadata:
| package oracle.jr181.demo; |
EJB 3.0 uses regular Java classes to simplify the development process. EJB-based Web Services developed using EJB 3.0 and Web Services Metadata, are much simpler. HelloWorld EJB is the example given below developed by using EJB 3.0 and Web Services Metadata. Don't worry while creating WSDL, deployment descriptors, etc., since the application server generates these artifacts during deployment.
| package oracle.ejb30.ws; |
Implementation of HelloWorld EJB using EJB 3.0 is given below:
| package oracle.ejb30.ws; |
The above example demonstrates the simplification of service development while simplifying by using Web Services Metadata and EJB 3.0.
Conclusion
This articles gives you the understanding about the basics of building Web Services using the J2EE platform. You can build and deploy your Web Services in J2EE-compliant application servers such as Sun Java System Application Sever, Oracle Application Server 10g, etc.
EJB
The J2EE Architecture allows the programmers to divide their work into two major categories:
Business Logic
Presentation Logic
Presentation Logic:
Presentation Logic consists of all the program (JSP and Servlets), images and html files that are used to interact with the client. These files are archived into .war file. These files are installed on the web server and these interacts with the users.
Business Logic:
These are EJB applications which implements the business logic of the system and are archived into .jar file. Business logic runs on the application server.
These two types of archives are bundled into complete J2EE applications, and delivered as Enterprise Archive (EAR) file.
Let's took an example of form processing. In this example J2EE application could have and HTML form, which prompts the user to input the data, a servlet to receive the data from the form and process it, and also an Enterprise Bean to store the data in a database. In this example the HTML form and servlet are archived in a WAR file, and the Enterprise Java Bean is archived into JAR file. These two archive files (WAR and JAR) both are added to the EAR file, which is finally deployed on the server.
Enterprise Java Beans (EJB) - An Introduction
One of Java's most important features is platform independence. Since its arrival, Java has been depicted as "write once, run anywhere". But Enterprise JavaBeans (EJBs) go one step further. They are not only platform independent but also implementation independent. That is, EJBs can run in any application server that implements the EJB specifications. In this overview, I discuss about the background, necessity and motivations for the emergence of EJBs in the enterprise distributed computing arena and a short EJB architectural overview.
Enterprise Distributed Object Computing (EDOC)
Distributed computing allows a business system to be more accessible. Distributed systems allow parts of the system to be located on separate computers located in different locations, where they make the most sense. That is, distributed computing allows business logic and data to be reached from remote locations at any time from anywhere by any one. The most recent development in distributed computing is distributed object computing. The technologies such as Java RMI, CORBA and Microsoft's DCOM help to accomplish distributed object computing paradigm by allowing objects running on one computer to be accessed for servicing the clients in other computers.
Object-oriented (OO) programming languages, such as Java, C++ and Smalltalk, are used to code software that fulfills the goals such as flexibility, extensibility and reusability, of OO technology. In business systems, OO languages are being used to improve development of GUIs, to simplify access to data and above all, to encapsulate the business logic into business objects. As a business's products, processes,and objectives evolve over time, the software that models the business has to be flexible, extensible, adaptable and reusable. The OO programming methodologies, namely encapsulation, polymorphism and inheritance, play a very important share in accomplishing the above mentioned goals. As today's enterprises are being shaped to comprise a number of business objects fulfilling various tasks, distributed computing is all set to take a very significant role in developing and deploying enterprise-class software in the days ahead. In the following sections, I discuss some of the earlier computing paradigms and the context in which EJB architecture came out and promises to shape the future requirements.
Transaction Processing (TP) Monitors
TP monitors have been evolving for about 30 years and have become powerful, high-speed server platforms for mission-critical applications. TP monitors are operating systems for business systems whose applications are written in languages like COBOL. TP monitors automatically manage the entire environment that a business system runs in, including transactions, resource management, and fault tolerance and thus are eligible to be called operating systems. The business logic in TP monitors is made up of procedural applications that are often accessed through network messaging or remote procedural calls (RPC). RPC is a distributed mechanism that allows clients to invoke procedures on applications in a TP monitor as if the procedure was executed locally.
The downside for TP monitors is as follows: TP monitors are not object oriented and they work with procedural code that can perform complex and mission-critical tasks but no sense of identity. Accessing a TP monitors through RPC is like executing static methods; there is no such thing as a unique and distinct object. Also the business logic, which is procedural, is not as flexible, extensible, or reusable as business logic, which is object-oriented.
Object Request Brokers (ORBs)
Distributed objects allow unique objects that have state and identity to be distributed across a network so that they can be accessed by other systems. Distributed object computing technologies like CORBA and Java RMI grew out of RPC with one significant and necessary difference that the invoking method is on an object instance, not an application procedure. Distributed objects are usually deployed on some kind of ORB, which is responsible for helping client applications find distributed objects in a transparent manner. The down side for an ORB is as follows: ORBs do not define an operating system for distributed objects. That is, all the responsibility for concurrency, transactions, resource management and fault tolerance rests on the application developers. These services may be available from the ORB vendors or can be purchased from third party vendors and can be implemented in an ORB, but the developer has to write the glue code to incorporate them into the business objects.
Component Transaction Monitor (CTM)
As the advantages of distributed objects became visible, the number of systems deployed using ORBs gets increased. But as indicated above, there happened to be a number of deficiencies on server side due to the poor server-side component model, which ORB architecture has been blessed with. The vital and relevant server-side services according to the ORB architecture specifications have been made to be explicitly accessed through APIs by the distributed object, resulting in more complexity. Also, the resource management strategies such as instance swapping, resource pooling, and activation may not be supported at all in this component model. These strategies are mainly responsible for distributed object systems to scale, improving performance and throughput and reducing latency. Without automatic support for resource management, application developers must implement home-grown resource management solutions, which requires a very sophisticated understanding of distributed object systems. Further on, ORBs fail to address the complexities of managing a component in a high-volume, mission-critical environment, an area where TP monitors have always excelled.
Having realized that combining these two revolutionary technologies will do wonders for enterprises, companies like IBM and BEA started to design a hybrid of ORBs and TP monitor systems, which is referred to as component transaction monitors (CTMs) or application servers. These types of application servers combine the flexibility and accessibility of distributed object systems based on ORBs with the robust operating system of a TP monitor. CTMs provide a comprehensive environment for server-side components by managing concurrency, transactions, object distribution, load balancing, security and resource management automatically.
CTMs have started to come out of several different industries including the relational database industry, the application server industry, the web server industry, the CORBA ORB industry, and the TP monitor industry. Each vendor offers products that reflect their particular area of expertise. But a CTM that supports the Enterprise JavaBeans standard server-side component model from Sun Microsystems seems to be a more elegant and productive choice. There are a number of reasons for this fine architectural decision. Sun Microsystems has framed a number of excellent standard server-side specifications for several technologies and made the Java implementation an open standard quite successfully. The Java Database Connectivity API (JDBC) was one of the shining examples.
Consequently, a critical mass of enterprise computing vendors - developers of application servers, transaction process monitors, object request brokers, database management systems, and others - are rolling out precise, robust and powerful implementations of the EJB technology specifications. Component-based, multi-tier applications are the future of enterprise computing. EJB is poised to realize the benefits of these components: portability, scalability to a wide range of enterprise servers, simplified development, deployment, and maintenance. With this brief background information on EJBs, let us enter a very brief discussion on EJB's robust architecture.
Enterprise JavaBeans - An Introduction
Enterprise JavaBeans (EJB) is a comprehensive technology that provides the infrastructure for building enterprise-level server-side distributed Java components. The EJB technology provides a distributed component architecture that integrates several enterprise-level requirements such as distribution, transactions, security, messaging, persistence, and connectivity to mainframes and Enterprise Resource Planning (ERP) systems. When compared with other distributed component technologies such as Java RMI and CORBA, the EJB architecture hides most the underlying system-level semantics that are typical of distributed component applications, such as instance management, object pooling, multiple threading, and connection pooling. Secondly, unlike other component models, EJB technology provides us with different types of components for business logic, persistence, and enterprise messages.
Thus, an Enterprise Java Bean is a remote object with semantics specified for creation, invocation and deletion. The EJB container is assigned the system-level tasks mentioned above. What a web container does for Java servlets and JSPs in a web server, the EJB container is for EJBs.
EJB Architecture
Any distributed component technology should have the following requirements:
1. There should be a mechanism to create the client-side and server-side proxy objects. A client-side proxy represents the server-side object on the client-side. As far as the client is concerned, the client-side proxy is equivalent to the server-side object. On the other hand, the purpose of the server-side proxy is to provide the basic infrastructure to receive client requests and delegate these request to the actual implementation object
2. We need to obtain a reference to client-side proxy object. In order to communicate with the server-side object, the client needs to obtain a reference to the proxy.
3. There should be a way to inform the distributed component system that a specific component is no longer in use by the client.
In order to meet these requirements, the EJB architecture specifies two kinds of interfaces for each bean. They are home interface and remote interface. These interfaces specify the bean contract to the clients. However, a bean developer need not provide implementation for these interfaces. The home interface will contain methods to be used for creating remote objects. The remote interface should include business methods that a bean is able to serve to clients. One can consider using the home interface to specify a remote object capable of creating objects conforming to the remote interface. That is, a home interface is analogous to a factory of remote objects. These are regular Java interfaces extending the javax.ejb.EJBHome and javax.ejb.EJBObject interfaces respectively.
As discussed below, the EJB architecture specifies three types of beans - session beans, entity beans, and message-driven beans. A bean developer has to specify the home and remote interfaces and also he has to implement one of these bean interfaces depending upon the type of the bean. For instance, for session beans, he has to implement the javax.ejb.SessionBean interface. The EJB architecture expects him to implement the methods specified in the bean interface and the methods specified in the home and remote interfaces. During the deployment time, he should specify the home and remote interfaces and bean implementation class to define a bean. The EJB container relies on specific method names and uses delegation for invoking methods on bean instances.
Thus regarding the first requirement, the EJB container generates the proxy objects for all beans. For the second one, the EJB container for each bean implement a proxy object to the home interface and publishes in the JNDI implementation of the J2EE platform. One can use JNDI to look for this and obtain a reference. As this object implements the home interface only, he can use one of the creation methods of the home object to get a proxy to the remote interface of the bean. When one invokes a creation method on the home proxy object, the container makes sure that a bean instance is created on the EJB container runtime and its proxy is returned to the client. Once the client gets hold of the proxy for the remote interface, it can directly access the services of the bean.
Finally, once the client decides to stop accessing the services of the bean, it can inform the EJB container by calling a remote method on the bean. This signals the EJB container to disassociate the bean instance from the proxy and that bean instance is ready to service any other clients.
Types of EJBs
The EJB architecture is based on the concept that in an enterprise computing system, database persistence-related logic should be independent of the business logic that relies on the data. This happens to be a very useful technique for separating business logic concerns from database concerns. This makes that business logic can deal with the business data without worrying about how the data is stored in a relational database.
Enterprise JavaBeans server-side components come in two fundamentally different types: entity beans and session beans.
Basically entity beans model business concepts that can be expressed as nouns. For example, an entity bean might represent a customer, a piece of equipment, an item in inventory. Thus entity beans model real-world objects. These objects are usually persistent records in some kind of database.
Session beans are for managing processes or tasks. A session bean is mainly for coordinating particular kinds of activities. That is, session beans are plain remote objects meant for abstracting business logic. The activity that a session bean represents is fundamentally transient. A session bean does not represent anything in a database, but it can access the database.
Thus an entity bean has persistent state whereas a session bean models interactions but does not have persistent state.
Session beans are transaction-aware. In a distributed component environment, managing transactions across several components mandates distributed transaction processing. The EJB architecture allows the container to manage transactions declaratively. This mechanism lets a bean developer to specify transactions across bean methods. Session beans are client-specific. That is, session bean instances on the server side are specific to the client that created them on the client side. This eliminates the need for the developer to deal with multiple threading and concurrency.
Unlike session beans, entity beans have a client-independent identity. This is because an entity bean encapsulates persistent data. The EJB architecture lets a developer to register a primary key class to encapsulate the minimal set of attributes required to represent the identity of an entity bean. Clients can use these primary key objects to accomplish the database operations, such as create, locate, or delete entity beans. Since entity beans represent persistent state, entity beans can be shared across different clients. Similar to session beans, entity beans are also transactional, except for the fact that bean instances are not allowed to programmatically control transactions.
These two types of beans are meant for synchronous invocation. That is, when a client invokes a method on one of the above types, the client thread will be blocked till the EJB container completes executing the method on the bean instance. Also these beans are unable to service the messages which comes asynchronously over a messaging service such as JMS. To overcome this deficiency, the EJB architecture has introduced a third type of bean called message-driven bean. A message-driven bean is a bean instance that can listen to messages from the JMS.
Unlike other types of beans, a message-driven bean is a local object without home and remote interfaces. In a J2EE platform, message-driven beans are registered against JMS destinations. When a JMS message receives a destination, the EJB container invokes the associated message-driven bean. Thus message-driven beans do not require home and remote interfaces as instances of these beans are created based on receipt of JMS messages. This is an asynchronous activity and does not involve clients directly. The main purpose of message-driven beans is to implement business logic in response to JMS messages. For instance, take a B2B e-commerce application receiving a purchase order via a JMS message as an XML document. On receipt of such a message in order to persist this data and perform any business logic, one can implement a message-driven bean and associate it with the corresponding JMS destination. Also these beans are completely decoupled from the clients that send messages.
Session Beans: Stateful and Stateless
Session beans can be either stateful or stateless. Stateful session beans maintain conversational state when used by a client. Conversational state is not written to a database but can store some state in private variables during one method call and a subsequent method call can rely on this state. Maintaining a conversational state allows a client to carry on a conversation with a bean. As each method on the bean is invoked, the state of the session bean may change and that change can affect subsequent method calls.
Stateless session beans do not maintain any conversational state. Each method is completely independent and uses only data passed in its parameters. One can specify whether a bean is stateful or not in the bean's deployment descriptor.
Entity Beans: Container and Bean Managed Persistence
An example entity bean in a B2B application is given as follows. A purchase order is a business identity and requires persistence store such as a relational database. The various purchase order attributes can be defined as the attributes of an entity bean. Since database operations involve create, update, load, delete, and find operations, the EJB architecture requires entity beans to implement these operations. Entity beans should implement the javax.ejb.EntityBean interface that specifies the load and delete operations among others. In addition, the bean developer should specify the appropriate create and find methods on the home interface, and provide their implementation in an entity bean.
There are two types of entity beans and they are distinguished by how they manage persistence. Container-managed beans have their persistence automatically managed by the EJB container. This is a more sophisticated approach and here the bean developer does not implement the persistence logic. The developer relies on the deployment descriptor to specify attributes whose persistence should be managed by the container. The container knows how a bean instance's fields map to the database and automatically takes care of inserting, updating, and deleting the data associated with entities in the database.
Beans using bean-managed persistence do all this work explicitly: the bean developer has to write the code to manipulate the database. The EJB container tells the bean instance when it is safe to insert, update, and delete its data from the database, but it provides no other help. The bean instance has to do the persistence work itself.
EJB Container: The environment that surrounds the beans on the EJB server is often referred to as the container. The container acts as an intermediary between the bean class and the EJB server. The container manages the EJB objects and EJB homes for a particular type of bean and helps these constructs to manage bean resources and apply the primary services relevant to distributed systems to bean instances at run time. An EJB server can have more than one container and each container in turn can accommodate more than one enterprise bean.
Remote Interface: This interface for an enterprise bean defines the enterprise bean's business methods that clients for this bean can access. The remote interface extends javax.ejb.EJBObject, which in turn extends java.rmi.Remote.
Home interface: This interface defines the bean's life cycle methods such as creation of new beans, removal of beans, and locating beans. The home interface extends javax.ejb.EJBHome, which in turn extends java.rmi.Remote.
Bean Class: This class has to implement the bean's business methods in the remote interface apart from some other callback methods. An entity bean must implement javax.ejb.EntityBean and a session bean must implement javax.ejb.SessionBean. Both EntityBean and Session Bean extend javax.ejb.EnterpriseBean.
Primary Key: This is a very simple class that provides a reference into the database. This class has to implement java.io.Serializable. Only entity beans need a primary key.
Deployment Descriptors: Much of the information about how beans are managed at runtime is not supplied in the interfaces and classes mentioned above. There are some common primary services related with distributed systems apart from some specific services such as security, transactions, naming that are being handled automatically by EJB server. But still EJB server needs to know beforehand how to apply the primary services to each bean class at runtime. Deployment descriptors exactly do this all important task.
JAR Files: Jar files are ZIP files that are used specifically for packaging Java classes that are ready to be used in some type of application. A Jar file containing one or more enterprise beans includes the bean classes, remote interfaces, home interfaces, and primary keys for each bean. It also contains one deployment descriptor.
Deployment is the process of reading the bean's JAR file, changing or adding properties to the deployment descriptor, mapping the bean to the database, defining access control in the security domain, and generating vendor-specific classes needed to support the bean in the EJB environment. Every EJB server product comes with its own deployment tools containing a graphical user interface and a set of command-line programs.
For clients like enterprise bean itself, Java RMI or CORBA client, to locate enterprise beans on the net, Java EJB specifications specify the clients to use Java Naming and Directory Interface (JNDI). JNDI is a standard Java extension that provides a uniform Application Programming Interface (API) for accessing a wide range of naming and directory services. The communication protocol may be Java RMI-IIOP or CORBA's IIOP
There are some special integrated application development tools such as Inprise's JBuilder, Sun's Forte and IBM's VisualAge, for designing EJBs in the market.
