Finally,world realizes the true purpose of Object Orientation - the Re-Usability and today any software development largely consists of adapting existing functionality to perform in a new environment,since large number of standard, well-tested building blocks have become readily available from various vendors.
Now, the core problem is, integration of many different libraries-(building blocks)as these libraries have become complex and require their own libraries to function --even if that functionality is never needed for the product.
This propels the need for tools/frameworks/specifications that standardize the integration aspects of software so that reusing existing components becomes reliable, robust and cheap.
There comes our OSGi!!!!!!!!!!!!!!
So what is OSGi?
A nonprofit organization-founded in March 1999- comprises of IBM,Ericsson,Nortel,Sybase,Sun,France Telecom,Motorola and Phillips that promotes an open dynamic component platform.
The objective of this Alliance is : "How to let applications from different vendors work reliably together and share resources in an embedded/network computer"
OSGi specifies JVM - (now only Java)- based service platform - so that software components/applications/modules/bundles can be remotely installed, started, stopped, updated and uninstalled without requiring a reboot;
Why JVM as Platform
Without any doubts, JVM is evovling as unanimous platform going forward for multi-layered, multi-faceted enterprise applications. Not only Java,but there are many other languages evovling on JVM [Current JVM Languages - PHP,Scala,Groovy,Ruby,Python]and certainly the list is growing day-by-day.
Speficiation - Overview
OSGi technology is the dynamic module system for Java™. The OSGi Service Platform provides functionality to Java that makes Java the premier environment for software integration and thus for development. Java provides the portability that is required to support products on many different platforms. The OSGi technology provides the standardized primitives that allow applications to be constructed from small, reusable and collaborative components. These components can be composed into an application and deployed.
The OSGi Service Platform provides the functions to change the composition dynamically on the device of a variety of networks, without requiring restarts. To minimize the coupling, as well as make these couplings managed, the OSGi technology provides a service-oriented architecture that enables these components to dynamically discover each other for collaboration. The OSGi Alliance has developed many standard component interfaces for common functions like HTTP servers, configuration, logging, security, user administration, XML and many more. Plug-compatible implementations of these components can be obtained from different vendors with different optimizations and costs. However, service interfaces can also be developed on a proprietary basis.
OSGi technology adopters benefit from improved time-to-market and reduced development costs because OSGi technology provides for the integration of pre-built and pre-tested component subsystems. The technology also reduces maintenance costs and enables unique new aftermarket opportunities because components can be dynamically delivered to devices in the field.
Framework
The core component of the OSGi Specifications is the OSGi Framework. The Framework provides a standardized environment to applications (called bundles). The Framework is divided in a number of layers.
L0: Execution Environment
L1: Modules
L2: Life Cycle Management
L3: Service Registry A ubiquitous security system is deeply intertwined with all the layers.
The L0 Execution environment is the specification of the Java environment. Java 2 Configurations and Profiles, like J2SE, CDC, CLDC, MIDP etc. are all valid execution environments. The OSGi platform has also standardized an execution environment based on Foundation Profile and a smaller variation that specifies the minimum requirements on an execution environment to be useful for OSGi bundles.
The L1 Modules layer defines the class loading policies. The OSGi Framework is a powerful and rigidly specified class-loading model. It is based on top of Java but adds modularization. In Java, there is normally a single classpath that contains all the classes and resources. The OSGi Modules layer adds private classes for a module as well as controlled linking between modules. The module layer is fully integrated with the security architecture, enabling the option to deploy closed systems, walled gardens, or completely user managed systems at the discretion of the manufacturer.
The L2 Life Cycle layer adds bundles that can be dynamically installed, started, stopped, updated and uninstalled. Bundles rely on the module layer for class loading but add an API to manage the modules in run time. The lifecycle layer introduces dynamics that are normally not part of an application. Extensive dependency mechanisms are used to assure the correct operation of the environment. Life cycle operations are fully protected with the security architecture, making it virtually impossible to be attacked by viruses.
The L3 layer adds a Service Registry. The service registry provides a cooperation model for bundles that takes the dynamics into account. Bundles can cooperate via traditional class sharing but class sharing is not very compatible with dynamically installing and uninstalling code. The service registry provides a comprehensive model to share objects between bundles. A number of events are defined to handle the coming and going of services. Services are just Java objects that can represent anything. Many services are server-like objects, like an HTTP server, while other services represent an object in the real world, for example a Bluetooth phone that is nearby. The service model is fully security instrumented. The service security model provides an elegant way to secure the communication between bundles passes.
Security
Security is based on Java and the Java 2 security model. The language by design limits many possible constructs. For example, buffer overflows used in viruses are impossible. Access modifiers in the language restrict the visibility of the code to other programmers. The OSGi platform extends this model by allowing private classes, a mechanism that is not available in a standard way in Java. The Java 2 security model provides a comprehensive model to check access by code to resources. The OSGi platform adds full dynamic management of the permissions, simplifying the life of operators and system administrators.
It Is SOA!
On top of the Framework, the OSGi Alliance has specified many services. Services are specified by a Java interface. Bundles can implement this interface and register the service with the Service Registry. Clients of the service can find it in the registry, or react to it when it appears or disappears.
This is similar to the service-oriented architecture made popular with web services. The key difference between web services and OSGi services is that web services always require some transport layer, which makes it thousands times slower than OSGi services that use direct method invocations. Also, OSGi components can directly react on the appearance and disappearance of services.
Examples:
Http Service
The Http Service is, among other things, a servlet runner. Bundles can provide servlets, which becomes available over the Http protocol. The dynamic update facility of the OSGi Service Platform makes the Http Service a very attractive web server that can be updated with new servlets, remotely if necessary, without requiring a restart.
Active participants:
Apache iFelix, iPojo, Spring - OSGi, Eclipse - Equinox
Whats new on OSGi-Release 4:
Powerful new modularization capabilities providing enhanced encapsulation of networked services that can share a single VM.
Modularized class sharing and hiding of implementation details.
Advanced handling of multiple versions of the same classes so old and new applications can execute within the same VM.
Localization of OSGi bundle manifests enabling service deployment anywhere.
Enhancements in security and policies: The new Conditional Permission Admin service provides an elegant and simple way to manage networked services securely. It also supports dynamic policies that can depend on external (custom) conditions. Combined with R4 support for digital signatures, this provides a central security solution to large deployments of products using the OSGi Service Platform.
A Declarative Services specification that addresses memory footprint issues that can prevent small embedded devices from using a service oriented architecture to support multiple applications. Additionally, it significantly simplifies the service-oriented programming model by declaratively handling the dynamics of services.
Compatibility with Release 3, requiring no changes for existing OSGi bundles, applications, or services.
Future is here...
The OSGi specifications are so widely applicable because the platform is a small layer that allows multiple Java™ based components to efficiently cooperate in a single Java Virtual Machine (JVM). It provides an extensive security model so that components can run in a shielded environment. However, with the proper permissions, components can reuse and cooperate, unlike other Java application environments. The OSGi Framework provides an extensive array of mechanisms to make this cooperation possible and secure.
The presence of OSGi technology-based middleware in many different industries creates a large software market for OSGi software components. The rigid definition of the OSGi Service Platform enables components that can run on a variety of devices, from very small to very big.
Adoption of the OSGi specifications can therefore reduce software development costs as well as provide new business opportunities.
Courtesy : ACM Queue Jan-Feb 2008 , Wiki
Tuesday, March 11, 2008
Tuesday, March 4, 2008
Whats Hot on J2EE design?
Below link describes the best architecure available for J2EE systems today
http://cwiki.apache.org/S2WIKI/struts-2-spring-2-jpa-ajax.html
http://cwiki.apache.org/S2WIKI/struts-2-spring-2-jpa-ajax.html
Design Patterns - FAQ
http://en.wikipedia.org/wiki/Design_Patterns
As per GOF (Gang of Four),the total is :23 and they are classified as below. Classification :Creational(5),Structural(7),Behavioral(11)
Creational Patterns
--- Abstract Factory
--- Builder
--- Factory Method
--- Prototype
--- Singleton
Structural Patterns
--- Adapter
--- Bridge
--- Composite
--- Decorator
--- Façade
--- Flyweight
--- Proxy
Behavioral Patterns
--- Chain of Responsibility
--- Command
--- Interpreter
--- Iterator
--- Mediator
--- Memento
--- Observer
--- State
--- Strategy
--- Template Method
--- Visitor
J2EE Patterns
--- MVC
--- Business Delegate
--- Composite Entity
--- Data Access Object
--- Front Controller
--- Intercepting Filter
--- Service Locator
--- Transfer Object
Misc
--- typesafe enum
As per GOF (Gang of Four),the total is :23 and they are classified as below. Classification :Creational(5),Structural(7),Behavioral(11)
Creational Patterns
--- Abstract Factory
--- Builder
--- Factory Method
--- Prototype
--- Singleton
Structural Patterns
--- Adapter
--- Bridge
--- Composite
--- Decorator
--- Façade
--- Flyweight
--- Proxy
Behavioral Patterns
--- Chain of Responsibility
--- Command
--- Interpreter
--- Iterator
--- Mediator
--- Memento
--- Observer
--- State
--- Strategy
--- Template Method
--- Visitor
J2EE Patterns
--- MVC
--- Business Delegate
--- Composite Entity
--- Data Access Object
--- Front Controller
--- Intercepting Filter
--- Service Locator
--- Transfer Object
Misc
--- typesafe enum
Tuesday, February 12, 2008
Connection Pool - Life Cycle
Lot of folks often ask something or other doubts on connection pooling, either with respect to transaction failures or performance issues. Found a good material and thought of sharing.. Here it is.
A ManagedConnection object is always in one of three states:
DoesNotExist, InFreePool, or fInUse.
Before a connection is created, it must be in the DoesNotExist state. After a connection is created, it can be in either the InUse or the InFreePool state, depending on whether it is allocated to an application.
Between these three states are transitions. These transitions are controlled by guarding conditions. A guarding condition is one in which true indicates when you can take the transition into another legal state. For example, you can make the transition from the InFreePool to InUse state only if:
- the application has called the data source or connection factory .getConnection method (getConnection)
- a free connection is available in the pool with matching properties (freeConnectionAvailable)
and one of the two following conditions are true:
- the getConnection request is on behalf of a resource reference that is marked unsharable
- the getConnection request is on behalf of a resource reference that is marked shareable but no shareable connection in use has the same properties.
This transition description follows:
InFreePool > InUse:
getConnection AND
freeConnectionAvailable AND
NOT(shareableConnectionAvailable)
Here is a list of guarding conditions and descriptions.
Condition Description
ageTimeoutExpired - Connection is older then its ageTimeout value.
close - Application calls close method on the Connection object.
fatalErrorNotification - A connection has just experienced a fatal error.
freeConnectionAvailable - A connection with matching properties is available in the free pool.
getConnection -Application calls getConnection method on DataSource or ConnectionFactory object.
markedStale-Connection is marked as stale, typically in response to a FatalErrorNotification.
noOtherReferences-There is only one connection handle to the ManagedConnection, and the Transaction Service is not holding a reference to the ManagedConnection.
noTx -No transaction is in force.
poolSizeGTMin-Connection pool size is greater than the minimum pool size (minimum number of connections)
poolSizeLTMax-Pool size is less than the maximum pool size (maximum number of connections)
shareableConnectionAvailable-The getConnection request was for a shareable connection and one with matching properties is in use and available to share.
TxEnds-The transaction has ended.
unshareableConnectionRequest-The getConnection request is for an unshareable connection.
unusedTimeoutExpired-Connection is in the free pool and not in use past its unused timeout value.
Getting connections
The first set of transitions covered are those in which the application requests a connection from either a data source or a connection factory. In some of these scenarios, a new connection to the database results. In others, the connection might be retrieved from the connection pool or shared with another request for a connection.
DoesNotExist
Every connection begins its life cycle in the DoesNotExist state. When an application server starts, the connection pool does not exist. Therefore, there are no connections. The first connection is not created until an application requests its first connection. Additional connections are created as needed, according to the guarding condition.
getConnection AND
NOT(freeConnectionAvailable) AND
poolSizeLTMax AND
(NOT(shareableConnectionAvailable) OR
unshareableConnectionRequest)
This transition specifies that a Connection object is not created unless the following conditions occur:
The application calls the getConnection() method on the data source or connection factory
No connections are available in the free pool (NOT(freeConnectionAvailable))
The pool size is less than the maximum pool size (poolSizeLTMax)
If the request is for a sharable connection and there is no sharable connection already in use with the same sharing properties (NOT(shareableConnectionAvailable)) OR the request is for an unsharable connection (unshareableConnectionRequest)
All connections begin in the DoesNotExist state and are only created when the application requests a connection. The pool grows from 0 to the maximum number of connections as applications request new connections. The pool is not created with the minimum number of connections when the server starts.
If the request is for a sharable connection and a connection with the same sharing properties is already in use by the application, the connection is shared by two or more requests for a connection. In this case, a new connection is not created. For users of the JDBC API these sharing properties are most often userid/password and transaction context; for users of the Resource Adapter Common Client Interface (CCI) they are typically ConnectionSpec, Subject, and transaction context.
InFreePool
The transition from the InFreePool state to the InUse state is the most common transition when the application requests a connection from the pool.
InFreePool>InUse:
getConnection AND
freeConnectionAvailable AND
(unshareableConnectionRequest OR
NOT(shareableConnectionAvailable))
This transition states that a connection is placed in use from the free pool if:
the application has issued a getConnection() call
a connection is available for use in the connection pool (freeConnectionAvailable),
and one of the following is true:
the request is for an unsharable connection (unsharableConnectionRequest)
no connection with the same sharing properties is already in use in the transaction. (NOT(sharableConnectionAvailable)).
Any connection request that a connection from the free pool can fulfill does not result in a new connection to the database. Therefore, if there is never more than one connection used at a time from the pool by any number of applications, the pool never grows beyond a size of one. This number can be less than the minimum number of connections specified for the pool. One way that a pool grows to the minimum number of connections is if the application has multiple concurrent requests for connections that must result in a newly created connection.
InUse
The idea of connection sharing is seen in the transition on the InUse state.
InUse>InUse:
getConnection AND
ShareableConnectionAvailable
This transition states that if an application requests a shareable connection (getConnection) with the same sharing properties as a connection that is already in use (ShareableConnectionAvailable), the existing connection is shared.
The same user (user name and password, or subject, depending on authentication choice) can share connections but only within the same transaction and only when all of the sharing properties match. For JDBC connections, these properties include the isolationLevel which is configurable on the resource-reference (IBM WebSphere extension) to data source default. For a resource adapter factory connection, these properties include those specified on the ConnectionSpec. Because a transaction is normally associated with a single thread, you should never share connections across threads.
Note: It is possible to see the same connection on multiple threads at the same time, but this situation is an error state usually caused by an application programming error.
Returning connections
All of the transitions so far have covered getting a connection for application use. From this point, the transitions result in a connection closing and either returning to the free pool or being destroyed. Applications should explicitly close connections (note: the connection that the user gets back is really a connection handle) by calling close() on the Connection object. In most cases, this action results in the following transition:
InUse>InFreePool:
(close AND
noOtherReferences AND
NoTx AND
UnshareableConnection)
OR
(ShareableConnection AND
TxEnds)
Conditions that cause the transition from the InUse state are:
If the application (or the container) calls close() (close) and there are no references (noOtherReferences) either by the application (application sharing) or by the transaction manager (NoTx - who holds a reference when the connection is enlisted in a transaction), the Connection object returns to the free pool.
If the connection was enlisted in a transaction but the transaction manager ends the transaction (txEnds), and the connection was a shareable connection (ShareableConnection), the connection closes and returns to the pool.
When the application calls close() on a connection, it is returning the connection to the pool of free connections; it is not closing the connection to the data store. When the application calls close() on a currently shared connection, the connection is not returned to the free pool. Only after the application drops the last reference to the connection, and the transaction is over, is the connection returned to the pool. Applications using unsharable connections must take care to close connections in a timely manner. Failure to do so can starve out the connection pool making it impossible for any application running on the server to get a connection.
When the application calls close() on a connection enlisted in a transaction, the connection is not returned to the free pool. Because the transaction manager must also hold a reference to the connection object, the connection cannot return to the free pool until the transaction ends. Once a connection is enlisted in a transaction, you cannot use it in any other transaction by any other application until after the transaction is complete.
There is a case where an application calling close() can result in the connection to the data store closing and bypassing the connection return to the pool. This situation happens if one of the connections in the pool is considered stale. A connection is considered stale if you can no longer use it to contact the data store. For example, a connection is marked stale if the data store server is shut down. When a connection is marked as stale, the entire pool is cleaned out by default because it is very likely that all of the connections are stale for the same reason (or you can set your configuration to clean just the failing connection). This cleansing includes marking all of the currently InUse connections as stale so they are destroyed upon closing. The following transition states the behavior on a call to close() when the connection is marked as stale:
InUse>DoesNotExist:
close AND
markedStale AND
NoTx AND
noOtherReferences
This transition states that if the application calls close() on the connection and the connection is marked as stale during the pool cleansing step (markedStale), the connection object closes to the data store and is not returned to the pool.
Finally, you can close connections to the data store and remove them from the pool.
This transition states that there are three cases in which a connection is removed from the free pool and destroyed.
If a fatal error notification is received from the resource adapter (or data source). A fatal error notification (FatalErrorNotification) is received from the resource adaptor when something happens to the connection to make it unusable. All connections currently in the free pool are destroyed.
If the connection is in the free pool for longer than the unused timeout period (UnusedTimeoutExpired) and the pool size is greater than the minimum number of connections (poolSizeGTMin), the connection is removed from the free pool and destroyed. This mechanism enables the pool to shrink back to its minimum size when the demand for connections decreases.
If an age timeout is configured and a given connection is older than the timeout. This mechanism provides a way to recycle connections based on age.
A ManagedConnection object is always in one of three states:
DoesNotExist, InFreePool, or fInUse.
Before a connection is created, it must be in the DoesNotExist state. After a connection is created, it can be in either the InUse or the InFreePool state, depending on whether it is allocated to an application.
Between these three states are transitions. These transitions are controlled by guarding conditions. A guarding condition is one in which true indicates when you can take the transition into another legal state. For example, you can make the transition from the InFreePool to InUse state only if:
- the application has called the data source or connection factory .getConnection method (getConnection)
- a free connection is available in the pool with matching properties (freeConnectionAvailable)
and one of the two following conditions are true:
- the getConnection request is on behalf of a resource reference that is marked unsharable
- the getConnection request is on behalf of a resource reference that is marked shareable but no shareable connection in use has the same properties.
This transition description follows:
InFreePool > InUse:
getConnection AND
freeConnectionAvailable AND
NOT(shareableConnectionAvailable)
Here is a list of guarding conditions and descriptions.
Condition Description
ageTimeoutExpired - Connection is older then its ageTimeout value.
close - Application calls close method on the Connection object.
fatalErrorNotification - A connection has just experienced a fatal error.
freeConnectionAvailable - A connection with matching properties is available in the free pool.
getConnection -Application calls getConnection method on DataSource or ConnectionFactory object.
markedStale-Connection is marked as stale, typically in response to a FatalErrorNotification.
noOtherReferences-There is only one connection handle to the ManagedConnection, and the Transaction Service is not holding a reference to the ManagedConnection.
noTx -No transaction is in force.
poolSizeGTMin-Connection pool size is greater than the minimum pool size (minimum number of connections)
poolSizeLTMax-Pool size is less than the maximum pool size (maximum number of connections)
shareableConnectionAvailable-The getConnection request was for a shareable connection and one with matching properties is in use and available to share.
TxEnds-The transaction has ended.
unshareableConnectionRequest-The getConnection request is for an unshareable connection.
unusedTimeoutExpired-Connection is in the free pool and not in use past its unused timeout value.
Getting connections
The first set of transitions covered are those in which the application requests a connection from either a data source or a connection factory. In some of these scenarios, a new connection to the database results. In others, the connection might be retrieved from the connection pool or shared with another request for a connection.
DoesNotExist
Every connection begins its life cycle in the DoesNotExist state. When an application server starts, the connection pool does not exist. Therefore, there are no connections. The first connection is not created until an application requests its first connection. Additional connections are created as needed, according to the guarding condition.
getConnection AND
NOT(freeConnectionAvailable) AND
poolSizeLTMax AND
(NOT(shareableConnectionAvailable) OR
unshareableConnectionRequest)
This transition specifies that a Connection object is not created unless the following conditions occur:
The application calls the getConnection() method on the data source or connection factory
No connections are available in the free pool (NOT(freeConnectionAvailable))
The pool size is less than the maximum pool size (poolSizeLTMax)
If the request is for a sharable connection and there is no sharable connection already in use with the same sharing properties (NOT(shareableConnectionAvailable)) OR the request is for an unsharable connection (unshareableConnectionRequest)
All connections begin in the DoesNotExist state and are only created when the application requests a connection. The pool grows from 0 to the maximum number of connections as applications request new connections. The pool is not created with the minimum number of connections when the server starts.
If the request is for a sharable connection and a connection with the same sharing properties is already in use by the application, the connection is shared by two or more requests for a connection. In this case, a new connection is not created. For users of the JDBC API these sharing properties are most often userid/password and transaction context; for users of the Resource Adapter Common Client Interface (CCI) they are typically ConnectionSpec, Subject, and transaction context.
InFreePool
The transition from the InFreePool state to the InUse state is the most common transition when the application requests a connection from the pool.
InFreePool>InUse:
getConnection AND
freeConnectionAvailable AND
(unshareableConnectionRequest OR
NOT(shareableConnectionAvailable))
This transition states that a connection is placed in use from the free pool if:
the application has issued a getConnection() call
a connection is available for use in the connection pool (freeConnectionAvailable),
and one of the following is true:
the request is for an unsharable connection (unsharableConnectionRequest)
no connection with the same sharing properties is already in use in the transaction. (NOT(sharableConnectionAvailable)).
Any connection request that a connection from the free pool can fulfill does not result in a new connection to the database. Therefore, if there is never more than one connection used at a time from the pool by any number of applications, the pool never grows beyond a size of one. This number can be less than the minimum number of connections specified for the pool. One way that a pool grows to the minimum number of connections is if the application has multiple concurrent requests for connections that must result in a newly created connection.
InUse
The idea of connection sharing is seen in the transition on the InUse state.
InUse>InUse:
getConnection AND
ShareableConnectionAvailable
This transition states that if an application requests a shareable connection (getConnection) with the same sharing properties as a connection that is already in use (ShareableConnectionAvailable), the existing connection is shared.
The same user (user name and password, or subject, depending on authentication choice) can share connections but only within the same transaction and only when all of the sharing properties match. For JDBC connections, these properties include the isolationLevel which is configurable on the resource-reference (IBM WebSphere extension) to data source default. For a resource adapter factory connection, these properties include those specified on the ConnectionSpec. Because a transaction is normally associated with a single thread, you should never share connections across threads.
Note: It is possible to see the same connection on multiple threads at the same time, but this situation is an error state usually caused by an application programming error.
Returning connections
All of the transitions so far have covered getting a connection for application use. From this point, the transitions result in a connection closing and either returning to the free pool or being destroyed. Applications should explicitly close connections (note: the connection that the user gets back is really a connection handle) by calling close() on the Connection object. In most cases, this action results in the following transition:
InUse>InFreePool:
(close AND
noOtherReferences AND
NoTx AND
UnshareableConnection)
OR
(ShareableConnection AND
TxEnds)
Conditions that cause the transition from the InUse state are:
If the application (or the container) calls close() (close) and there are no references (noOtherReferences) either by the application (application sharing) or by the transaction manager (NoTx - who holds a reference when the connection is enlisted in a transaction), the Connection object returns to the free pool.
If the connection was enlisted in a transaction but the transaction manager ends the transaction (txEnds), and the connection was a shareable connection (ShareableConnection), the connection closes and returns to the pool.
When the application calls close() on a connection, it is returning the connection to the pool of free connections; it is not closing the connection to the data store. When the application calls close() on a currently shared connection, the connection is not returned to the free pool. Only after the application drops the last reference to the connection, and the transaction is over, is the connection returned to the pool. Applications using unsharable connections must take care to close connections in a timely manner. Failure to do so can starve out the connection pool making it impossible for any application running on the server to get a connection.
When the application calls close() on a connection enlisted in a transaction, the connection is not returned to the free pool. Because the transaction manager must also hold a reference to the connection object, the connection cannot return to the free pool until the transaction ends. Once a connection is enlisted in a transaction, you cannot use it in any other transaction by any other application until after the transaction is complete.
There is a case where an application calling close() can result in the connection to the data store closing and bypassing the connection return to the pool. This situation happens if one of the connections in the pool is considered stale. A connection is considered stale if you can no longer use it to contact the data store. For example, a connection is marked stale if the data store server is shut down. When a connection is marked as stale, the entire pool is cleaned out by default because it is very likely that all of the connections are stale for the same reason (or you can set your configuration to clean just the failing connection). This cleansing includes marking all of the currently InUse connections as stale so they are destroyed upon closing. The following transition states the behavior on a call to close() when the connection is marked as stale:
InUse>DoesNotExist:
close AND
markedStale AND
NoTx AND
noOtherReferences
This transition states that if the application calls close() on the connection and the connection is marked as stale during the pool cleansing step (markedStale), the connection object closes to the data store and is not returned to the pool.
Finally, you can close connections to the data store and remove them from the pool.
This transition states that there are three cases in which a connection is removed from the free pool and destroyed.
If a fatal error notification is received from the resource adapter (or data source). A fatal error notification (FatalErrorNotification) is received from the resource adaptor when something happens to the connection to make it unusable. All connections currently in the free pool are destroyed.
If the connection is in the free pool for longer than the unused timeout period (UnusedTimeoutExpired) and the pool size is greater than the minimum number of connections (poolSizeGTMin), the connection is removed from the free pool and destroyed. This mechanism enables the pool to shrink back to its minimum size when the demand for connections decreases.
If an age timeout is configured and a given connection is older than the timeout. This mechanism provides a way to recycle connections based on age.
Migrate Struts App to Websphere Portal
Simple steps to migrate already developed struts application to host on websphere portal server
http://www.ibm.com/developerworks/websphere/techjournal/0403_yu/0403_yu.html
Developing new portal struts app:
http://www.ibm.com/developerworks/websphere/library/techarticles/0401_hanis/hanis.html
http://www-128.ibm.com/developerworks/websphere/library/techarticles/0601_patil/0601_patil.html
http://www-128.ibm.com/developerworks/websphere/library/techarticles/0601_patil2/0601_patil2.html
http://www.ibm.com/developerworks/websphere/techjournal/0403_yu/0403_yu.html
Developing new portal struts app:
http://www.ibm.com/developerworks/websphere/library/techarticles/0401_hanis/hanis.html
http://www-128.ibm.com/developerworks/websphere/library/techarticles/0601_patil/0601_patil.html
http://www-128.ibm.com/developerworks/websphere/library/techarticles/0601_patil2/0601_patil2.html
Saturday, February 9, 2008
RIA with Flex - Part 1
Most of the present day Rich Internet Applications, especially on public arena are built with some or other Flash components. The embedded support of flash player for IE and other prominent browsers provided the edge of reach.
The reach can be understood with the well known day-2-day use application YouTube.
Evolution
Macromedia was a US graphics and Web development software company producing such products as Adobe Flash. The line of Macromedia products is now controlled by its former rival, Adobe Systems which acquired Macromedia on December 3, 2005.
Almost all prominent prgramming languages are gearing up to support this integration, ex- JavaFx. Among them Flex-promoted by Adobe can be considered as pioneer.
So, What is Flex?
Flex is a development and run-time environment that you use to create rich Internet applications that use Adobe® Flash® Player 9 to deliver more intuitive and interactive online experiences.
The flex applications are developed with MXML and Action Scripts.
MXML - Macromedia XML
Every Flex application contains at least one MXML file, known as the main application file. MXML is a markup language, an implementation of XML that was designed specifically for creating Flex applications, and you use it to declaratively define the structure of your application using tags.
Action Script
You add dynamic behavior to your applications using ActionScript 3.0, which is an implementation of ECMAScript and is similar to JavaScript. You can add ActionScript to Flex applications directly in the MXML file as script blocks or you can create separate files of ActionScript functions and import them into your MXML files.
Architecure
A Flex application is compiled into a SWF file, which runs in Flash Player. When the source code is compiled into a Flex application it is converted to ActionScript classes and is then merged into the SWF file along with graphics and other assets. At run time, the Flex application SWF file interacts with external libraries, services, and data sources as needed.
Standard Flex applications do not require server-side Flex services. Therefore, you compile them locally on your computer and typically deploy them to your users from an HTML page on a web server. As all browsers supports playing flash contents, you can code java script to play swf file on browser flash player.
Data Services
The major advantage of Flex addressed when it started supporting data services.
To provide data to your application, Adobe Flex includes components designed specifically for interacting with HTTP servers, web services, or remote object services (Java objects). These components are called remote procedure call (RPC) service components.
Unlike web applications built with Adobe ColdFusion, PHP, or similar server technologies, Flex applications cannot connect directly to a database. They interact with data using services. For example, you can insert an HTTP service in a Flex file to interact with a ColdFusion file that retrieves data from a MySQL database, converts it to XML, and then feeds it to your Flex application.
First Look on how you embed 'flash component - test.swf' on html page
The reach can be understood with the well known day-2-day use application YouTube.
Evolution
Macromedia was a US graphics and Web development software company producing such products as Adobe Flash. The line of Macromedia products is now controlled by its former rival, Adobe Systems which acquired Macromedia on December 3, 2005.
Almost all prominent prgramming languages are gearing up to support this integration, ex- JavaFx. Among them Flex-promoted by Adobe can be considered as pioneer.
So, What is Flex?
Flex is a development and run-time environment that you use to create rich Internet applications that use Adobe® Flash® Player 9 to deliver more intuitive and interactive online experiences.
The flex applications are developed with MXML and Action Scripts.
MXML - Macromedia XML
Every Flex application contains at least one MXML file, known as the main application file. MXML is a markup language, an implementation of XML that was designed specifically for creating Flex applications, and you use it to declaratively define the structure of your application using tags.
Action Script
You add dynamic behavior to your applications using ActionScript 3.0, which is an implementation of ECMAScript and is similar to JavaScript. You can add ActionScript to Flex applications directly in the MXML file as script blocks or you can create separate files of ActionScript functions and import them into your MXML files.
Architecure
A Flex application is compiled into a SWF file, which runs in Flash Player. When the source code is compiled into a Flex application it is converted to ActionScript classes and is then merged into the SWF file along with graphics and other assets. At run time, the Flex application SWF file interacts with external libraries, services, and data sources as needed.
Standard Flex applications do not require server-side Flex services. Therefore, you compile them locally on your computer and typically deploy them to your users from an HTML page on a web server. As all browsers supports playing flash contents, you can code java script to play swf file on browser flash player.
Data Services
The major advantage of Flex addressed when it started supporting data services.
To provide data to your application, Adobe Flex includes components designed specifically for interacting with HTTP servers, web services, or remote object services (Java objects). These components are called remote procedure call (RPC) service components.
Unlike web applications built with Adobe ColdFusion, PHP, or similar server technologies, Flex applications cannot connect directly to a database. They interact with data using services. For example, you can insert an HTTP service in a Flex file to interact with a ColdFusion file that retrieves data from a MySQL database, converts it to XML, and then feeds it to your Flex application.
First Look on how you embed 'flash component - test.swf' on html page
<object width="425" height="373">
<param name="movie" value="test.swf"></param>
<param name="wmode" value="transparent"></param>
<embed src="test.swf"
type="application/x-shockwave-flash"
wmode="transparent"
width="425" height="373"></embed>
</object>
Tuesday, February 5, 2008
Evolution of Remote Procedure Calls - RPC
A remote procedure call is a request to a server application at another location to perform operations and return information.This is one of very common requirements for any enterprise world.From time to time, there are so many technological advances made on this arena.This article meant for Java evangelists who would like to understand the evolution of RPC with current context.
Remote method invocation - RMI
Enterprise Java Beans - EJB
XML over HTTP - Webservices
XML - RPC
Simple Object Access Protocol-SOAP
Evolution of Remote Procedure Calls - RPC
A remote procedure call is a request to a server application at another location
to perform operations and return information.This is one of very common requirements
for any enterprise world.From time to time, there are so many technological
advances made on this arena.This article meant for Java evangelists who would like
to understand the evolution of RPC with current context.
Microsoft's Distributed Common Object Model - DCOM
Common Object Request Broker Architecture - CORBA
Remote method invocation - RMI
Enterprise Java Beans - EJB
XML over HTTP - Webservices
XML - RPC
XML-RPC is a simple, stable, and well-understood specification. It’s not a
moving target like so many other Web service specifications. It also has
longevity, because the only things that it depends on are technologies such as
HTTP and XML, and basic programming constructs such as arrays, structures, and
scalars. None of those things is going away any time soon. And since everything
related to XML-RPC is freely available and downloadable, you can have a Web
service up and running in a single afternoon.
Simple Object Access Protocol-SOAP
XML-RPC is a simple protocol that
allows software running in different environments to make remote procedure calls
over the Internet. XML-RPC uses two industry standards: XML (extensible markup
language) for encoding messages, and HTTP (hypertext transfer protocol) for
transporting them. A properly formatted XML-RPC message is an HTTP POST request
whose body is in XML. The specified remote server executes the requested call
and returns any requested data in XML format.
XML-RPC recognizes procedure parameters by position. Parameters and return
values can be simple types such as numbers, strings, and dates, or more complex
types such as structures and arrays. To learn more about XML-RPC messages, see
the XML-RPC specification at http://www.xmlrpc.com/spec.
SOAP (Simple Object Access Protocol) is an RPC protocol designed for a
distributed environment, where a server may consist of a hierarchy of objects
whose methods can be called over the Internet. A goal of SOAP is to establish a
standard protocol that will serve both web service providers and service users.
As with other remote procedure call protocols, SOAP uses XML to encode messages
and HTTP to transport them. A SOAP request contains a header and an envelope;
the envelope in turn contains the body of the request.
One key difference between the SOAP and XML-RPC protocols is that with SOAP,
parameters are notational (a request must encode the method parameter names
within its XML), rather than positional (recognized by position). To learn more
about SOAP messages, see the SOAP specification at http://www.w3.org/TR/.
Remote procedure calls provide a powerful tool for accessing services over the
Internet. For example, there are already a variety of web-based servers that can
check spelling, translate text between languages, provide stock prices, supply
weather and traffic information, and more. You can find available services at
sites such as XMethods at http://www.xmethods.net/. There you can also find
information you’ll need to make remote procedure calls to these services.
The biggest conceptual difference between SOAP and XML-RPC is that XML-RPC
exchanges a limited number of parameters of six fixed types, plus structs and
arrays. However, SOAP allows you to send the server arbitrary XML elements. This
is a much more flexible approach.
Remote procedure call systems have been around since around 1984 when they were
first proposed (A.D. Birrell and B.J. Nelson, 1984). During the intervening 15
years, numerous evolutionary improvements have occurred in the basic RPC system,
leading to improved systems-such as NCS (T.H. Dineen et al., 1987)-that offer
programmers more functionality or greater simplicity. The Common Object Request
Broker Architecture from the Object Management Group and Microsoft's Distributed
Common Object Model are this evolutionary process's latest outgrowths. With the
introduction of Java Developer's Kit release 1.1, a third alternative for
creating distributed applications has emerged. The Java Remote Method Invocation
system has many of the same features of other RPC systems, letting an object
running in one Java virtual machine make a method call on an object running in
another, perhaps on a different physical machine. On the surface, the RMI system
is just another RPC mechanism, much like Corba and DCOM. But on closer
inspection, RMI represents a very different evolutionary progression, one that
results in a system that differs not just in detail but in the very set of
assumptions made about the distributed systems in which it operates. These
differences lead to differences in the programming model, capabilities, and the
way the mechanisms interact with the code that implements and built the
distributed systems
Remote method invocation - RMI
Enterprise Java Beans - EJB
XML over HTTP - Webservices
XML - RPC
Simple Object Access Protocol-SOAP
Evolution of Remote Procedure Calls - RPC
A remote procedure call is a request to a server application at another location
to perform operations and return information.This is one of very common requirements
for any enterprise world.From time to time, there are so many technological
advances made on this arena.This article meant for Java evangelists who would like
to understand the evolution of RPC with current context.
Microsoft's Distributed Common Object Model - DCOM
Common Object Request Broker Architecture - CORBA
Remote method invocation - RMI
Enterprise Java Beans - EJB
XML over HTTP - Webservices
XML - RPC
XML-RPC is a simple, stable, and well-understood specification. It’s not a
moving target like so many other Web service specifications. It also has
longevity, because the only things that it depends on are technologies such as
HTTP and XML, and basic programming constructs such as arrays, structures, and
scalars. None of those things is going away any time soon. And since everything
related to XML-RPC is freely available and downloadable, you can have a Web
service up and running in a single afternoon.
Simple Object Access Protocol-SOAP
XML-RPC is a simple protocol that
allows software running in different environments to make remote procedure calls
over the Internet. XML-RPC uses two industry standards: XML (extensible markup
language) for encoding messages, and HTTP (hypertext transfer protocol) for
transporting them. A properly formatted XML-RPC message is an HTTP POST request
whose body is in XML. The specified remote server executes the requested call
and returns any requested data in XML format.
XML-RPC recognizes procedure parameters by position. Parameters and return
values can be simple types such as numbers, strings, and dates, or more complex
types such as structures and arrays. To learn more about XML-RPC messages, see
the XML-RPC specification at http://www.xmlrpc.com/spec.
SOAP (Simple Object Access Protocol) is an RPC protocol designed for a
distributed environment, where a server may consist of a hierarchy of objects
whose methods can be called over the Internet. A goal of SOAP is to establish a
standard protocol that will serve both web service providers and service users.
As with other remote procedure call protocols, SOAP uses XML to encode messages
and HTTP to transport them. A SOAP request contains a header and an envelope;
the envelope in turn contains the body of the request.
One key difference between the SOAP and XML-RPC protocols is that with SOAP,
parameters are notational (a request must encode the method parameter names
within its XML), rather than positional (recognized by position). To learn more
about SOAP messages, see the SOAP specification at http://www.w3.org/TR/.
Remote procedure calls provide a powerful tool for accessing services over the
Internet. For example, there are already a variety of web-based servers that can
check spelling, translate text between languages, provide stock prices, supply
weather and traffic information, and more. You can find available services at
sites such as XMethods at http://www.xmethods.net/. There you can also find
information you’ll need to make remote procedure calls to these services.
The biggest conceptual difference between SOAP and XML-RPC is that XML-RPC
exchanges a limited number of parameters of six fixed types, plus structs and
arrays. However, SOAP allows you to send the server arbitrary XML elements. This
is a much more flexible approach.
Remote procedure call systems have been around since around 1984 when they were
first proposed (A.D. Birrell and B.J. Nelson, 1984). During the intervening 15
years, numerous evolutionary improvements have occurred in the basic RPC system,
leading to improved systems-such as NCS (T.H. Dineen et al., 1987)-that offer
programmers more functionality or greater simplicity. The Common Object Request
Broker Architecture from the Object Management Group and Microsoft's Distributed
Common Object Model are this evolutionary process's latest outgrowths. With the
introduction of Java Developer's Kit release 1.1, a third alternative for
creating distributed applications has emerged. The Java Remote Method Invocation
system has many of the same features of other RPC systems, letting an object
running in one Java virtual machine make a method call on an object running in
another, perhaps on a different physical machine. On the surface, the RMI system
is just another RPC mechanism, much like Corba and DCOM. But on closer
inspection, RMI represents a very different evolutionary progression, one that
results in a system that differs not just in detail but in the very set of
assumptions made about the distributed systems in which it operates. These
differences lead to differences in the programming model, capabilities, and the
way the mechanisms interact with the code that implements and built the
distributed systems
Subscribe to:
Posts (Atom)