In this first section of Dojo tutorial we will familiarize you with the Dojo framework. Dojo is another great JavaScript framework to develop ajax based application.
What is Dojo?
* Dojo is JavaScript framework released as open source software. This JavaScript toolkit provides many components to develop rich internet applications
.
* You can use Dojo toolkit to develop dynamic web applications. Dojo toolkit will put life in your web application and turn it into highly interactive application. You can turn your web application into desktop like web application.
* Dojo offers many widgets, utilities and ajax libraries to develop your application.
* Dojo is released under BSD or AFL license
* Dojo is free and can be used to develop free or commercial application.
Features of Dojo
* Dojo is based on HTML and JavaScript, so its easy for the developers to learn it fast.
* There is no requirement of learning new programming language. Just HTML and JavaScript knowledge if sufficient.
* Dojo provides higher abstraction layer to the programmer. So, it helps the programmers to develop powerful functions very easily.
* Dojo has already invented the wheels for the programmers and now programmers just have to use the Dojo api into their application
Here is the list of components that comes along with Dojo framework:
* DOJO Tree
* DOJO Button
* DOJO Calendar control
* DOJO Grid
* DOJO List box
Dojo
Web Services Validation Tool for WSDL and SOAP
Web Services Analysis Tool analyzes and reports problems in SOAP messages and schema in Web Services Description Language.
While developing Web services, developers need to set up application servers and deploy Web services applications to the servers in order to validate Web services messages. This causes quite a bit of overhead for Web services developers, particularly during a tight development schedule. Current Web services architecture does not require validation of Web services messages against WSDLs during message processing. This could pose a potential security risk to enterprise servers hosting Web services.
With the Web Services Validation Tool for WSDL and SOAP, Web services developers are able to validate Web services messages without deploying actual Web services applications to application servers. This saves a lot of time and effort in deployment and maintenance of test servers.
Furthermore, this validation tool can be also used to filter live Web services messages after Web services applications are successfully deployed. In a Web services production environment, this technology can be deployed to validate Web services messages and filter invalid or malicious Web services messages. This provides Web services to operate in a more secure and efficient environment.
The package includes the Web Services Validation tool for WSDL and SOAP that provides analysis of Simple Object Access Protocol (SOAP) message structures and verifies the validity of the message against schema in Web Services Description Language (WSDL). This technology can used as an independent component in existing Web services architectures to validate and filter SOAP messages efficiently and securely.
Java Messaging Service (JMS)
Java Messaging Service (JMS) is a Java API for interfacing with enterprise-level messaging software. Traditional messaging software comes in two varieties: Publish-Subscribe (Pub/Sub) and Point-to-Point (PTP). The Publish-Subscribe model uses a topic similar to a mailing list where different clients can publish to a topic or receive messages from a subscribed topic. The Point-to-Point model uses a queue concept where clients send and receive messages. A topic can have zero to many message consumers or subscribers, where as a queue can have at most one receiver, similar to a mailbox.
Messages
A message contains headers, optional properties, and a body. All messages in the JMS API extend from the javax.jms.Message interface. There are five different types of messages differentiated by the contents of its body:
Message Interface Body Content
javax.jms.BytesMessage array of bytes
javax.jms.MapMessage key-value pairs
javax.jms.ObjectMessage serialized Java object
javax.jms.StreamMessage stream of Java primitive values
javax.jms.TextMessage Java String object (used for XML)
The message headers are used to provide information for message processing.
Header Field Description
JMSCorrelationID links one message to another
JMSDeliveryMode javax.jms.DeliveryMode.NON_PERSISTENT or javax.jms.DeliveryMode.PERSISTENT
JMSDestination Topic or Queue this message is bound for
JMSExpiration expiration value (default is never)
JMSMessageID message ID
JMSPriority priority level (default is 4)
JMSRedelivered is message being redelivered
JMSReplyTo Topic or Queue where a reply should be sent
JMSTimestamp message timestamp
JMSType message type supplied by client
Properties added to the message are primarily used for message selection. Using a subset of the SQL92 syntax, a message consumer can filter what messages are delivered based on a message selector.
Communication
All Destinations (Topics and Queues) are retrieved using a JNDI lookup. The general steps are the same for interacting with either type of Destination:
1. Obtain a javax.jms.ConnectionFactory using a JNDI lookup. (The default ConnectionFactory names are different depending on the JMS provider.)
2. Obtain a javax.jms.Connection from the ConnectionFactory.
3. Obtain a javax.jms.Session from the Connection.
4. Create a javax.jms.MessageProducer or javax.jms.MessageConsumer from the Session.
5. For a MessageProducer, send the message, or for a MessageConsumer, receive the message (synchronous) or set the message listener (asynchronous).
6. Start the Connection to start message delivery.
7. Ultimately close the Connection.
Session
A Session is a single-threaded context for sending and receiving messages. Messages are produced and/or consumed in serial; to increase salability, use an additional Session per thread. If a program wants to both produce and consume messages, one Session must be used for each task.
Transactions
A Session can be optional transacted, where messages consumed and/or produced within a transaction form a single unit of work. Upon a commit, all messages received are acknowledged and all produced messages are sent. Alternately, if a transaction is rolledback, all sent messages are destroyed and all received messages are recovered.
Acknowledgment
There are three modes for non-transacted Sessions:
Acknowledgment Mode Description
DUPS_OK_ACKNOWLEDGE Session lazily acknowledges message delivery; minimizes Session overhead.
AUTO_ACKNOWLEDGE Session automatically acknowledges receipt of message after consumer finishes processing.
CLIENT_ACKNOWLEDGE Client calls Session.acknowledge() to acknowledge receipt of all messages received during the session.
Delivery Mode
NON_PERSISTENT messages do not need to be stored in persistent storage in case of client failure. A JMS provider must deliver this kind of message at-most-once, i.e., the message can be lost, but can only be delivered once.
PERSISTENT messages are stored in persistent storage to be delivered at a later date if a client is unavailable. A JMS provider must deliver this kind of message once-and-only once, i.e., it cannot be lost and cannot be delivered more than once.
Asynchronous Delivery
A JMS client that wants to receive messages asynchronously must implement the javax.jms.MessageListener interface, which only defines one method: public void onMessage(Message message). The client must register itself with a MessageConsumer and the provider will call the onMessage() method as each message is delivered.
Message-Driven Beans (MDB)
A message-driven bean is anonymous asynchronous message consumer running within an EJB container. An MDB has no home or remote interface, just the Bean class itself, and therefore has no client-visible identity. A message-driven bean class must implement the javax.ejb.MessageDrivenBean interface. As of the EJB 2.0 specification, an MDB can only consume JMS messages by implementing the javax.jms.MessageListener interface. In the proposed EJB 2.1 specification, an MDB may also consume messages via the Java API for XML Messaging (JAXM) by implementing either the javax.xml.messaging.OneWayListener or javax.xml.messaging.ReqRespListener interfaces.
Clients can only interact with a message-driven bean through its associated JMS Destination, a non-durable/durable Topic or Queue. The onMessage() method is invoked in the transaction scope specified in the deployment descriptor. The only valid values are Required or NotSupported, because there can be no pre-existing transaction context or a client to handle exceptions. The other methods defined for a MessageDrivenBean, newInstance(), setMessageDrivenContext(), ejbCreate(), and ejbRemove() are called within an unspecified transaction context. Message-driven bean message acknowledgment is automatically handled by the container. An acknowledgment mode is only needed for bean-managed transaction demarcation, and then the only values available are AUTO_ACKNOWLEDGE (the default) and DUPS_OK_ACKNOWLEDGE.
Deployment Descriptor
Message-driven beans are defined in the
Example
A traditional Stock Ticker and Broker program. The StockTickerServer starts up two StockTickerThread instances representing the NYSE and NASDAQ stock exchanges. Each StockTickerThread sends a stock ticker message in XML format to the StockTicker topic. The StockTickerMessageConsumer waits for asynchronous delivery from the StockTicker topic and sends the notification to the StockGUI client which updates the stock price. When the user buys or sells a stock, the StockBroker sends a stock trade XML message to the StockTrader queue. The message-driven bean StockTraderBean then asynchronously processes the StockTrader queue messages.
Compilation and Execution
1. Run ant with the jaxb target to generate the JAXB files: ant jaxb
2. Due to a bug in JAXB, the generated Stock.java file must have line 192 changed to: if (xs.atStart("shares")) {
3. Copy jbossmq-destinations-service.xml and jaxb-rt-1.0-ea.jar to %JBOSS_HOME%\server\default\deploy
4. Start JBoss
5. Run ant with the default or deploy target: ant
6. Run ant with the server target in a new window: ant server
7. Run ant with the client target: ant client
Apache Tapestry
Apache Tapestry is an open-source framework for creating dynamic, robust, highly scalable web applications in Java. Tapestry complements and builds upon the standard Java Servlet API, and so it works in any servlet container or application server.
Tapestry divides a web application into a set of pages, each constructed from components. This provides a consistent structure, allowing the Tapestry framework to assume responsibility for key concerns such as URL construction and dispatch, persistent state storage on the client or on the server, user input validation, localization/internationalization, and exception reporting. Developing Tapestry applications involves creating HTML templates using plain HTML, and combining the templates with small amounts of Java code. In Tapestry, you create your application in terms of objects, and the methods and properties of those objects -- and specifically not in terms of URLs and query parameters. Tapestry brings true object oriented development to Java web applications.
Tapestry is specifically designed to make creating new components very easy, as this is a routine approach when building applications.
Tapestry is architected to scale from tiny, single-page applications all the way up to massive applications consisting of hundreds of individual pages, developed by large, diverse teams. Tapestry easily integrates with any kind of backend, including JEE, HiveMind, Spring and Hibernate.
It's more than what you can do with Tapestry ... it's also how you do it! Tapestry is a vastly productive environment. Java developers love it because they can make Java code changes and see them immediately ... no redeploy, no restart! And it's blazingly fast to boot (even when files change). Designers love it because Tapestry templates are so close to ordinary HTML, without all the cruft and confusion seen in JavaServer Pages. Managers love it because it makes it easy for large teams to work together, and because they know important features (including localization) are baked right in. Once you work in Tapestry there's no going back!
Tapestry is released under the Apache Software Licence 2.0.
New JBoss Cache based Hibernate Second Level Cache provider
I’m really pleased to announce the 1.0.0.GA release of a new JBoss Cache 1.4 series-based implementation of Hibernate’s 3.2 Second Level Cache provider SPI. The Second Level Cache is a Hibernate feature that allows entities, collections and queries to be cached in memory beyond the scope of a transaction, reducing the number of trips to the database. Hibernate provides an SPI for second level cache implementations; the JBoss Cache-based implementation is primarily used in clustered applications where there is a need to maintain cache consistency around the cluster. Over the past year, Brian Stansberry, lead of JBoss AS Clustering, has been working hard first, improving the JBoss Cache-based EJB3 Entity Second Level Cache for the AS/EAP 4.2/4.3 series and secondly, writing the JBoss Cache 2.x series-based implementation of the Hibernate 3.3 Second Level Cache which will be used in AS/EAP 5.x. Along the way, with the help of Steve Ebersole, lead of Hibernate, Brian has acquired a lot of expertise in this area as shown by the “Using JBoss Cache 2 as a Hibernate Second Level Cache” guide belonging to the Hibernate 3.3 series (Note: Readers interested in this blog entry should focus their attention on the “Chapter 2 – Core Concepts” to understand the interaction between Hibernate and JBoss Cache. The rest of the guide focuses on the Hibernate 3.3 and JBoss Cache 2.x integration, and this is of little interest to EAP or AS 4.x users as these Hibernate and JBoss Cache versions are more advanced that the ones supported in the EAP/AS versions mentioned).
JBoss Portal has been a consumer of the Hibernate Second Level Cache for quite a while now but unfortunately, it hasn’t been benefiting from the work done by Brian for a couple of reasons. First, JBoss Portal is still based in Hibernate 3.2, same as AS/EAP 4.2/4.3 and secondly, the improvements done to the EJB3 Entity Second Level Cache for AS/EAP 4.2/4.3 lived within the ejb3 project in AS/EAP and therefore, were not readily usable to other projects. This is not the case any more though.
A few weeks ago, Prabhat Jha, a Senior Engineer within JBoss division at Red Hat, was doing some scalability testing for JBoss Portal in a clustered environment but he was facing some issues as you can see from this forum entry. Brian believed that JBoss Portal could benefit from the work done to improve the Hibernate – JBoss Cache integration for EJB3 Entity Second Level Cache but he was quite busy working on AS 5, so I pinged him and volunteered to help with such task.
Essentially, I took the EJB3 Entity Second Level Cache integration code, put it in a separate project and enhanced it with lessons learned by Brian during the development of the JBoss Cache-based implementation of the Hibernate 3.3 Second Level Cache. The end result is a brand new JBoss Cache-based Hibernate Second Level Cache Provider that performs and scales much better than any previous Hibernate 3.2/JBoss Cache 1.4 Second Level Cache providers by analysing what Hibernate is trying to do and using that knowledge to eliminate all but required cluster message traffic. By doing this, the lock contention and potential deadlocks arising from synchronous communication (a requirement due to the need to keep entity data in synch across different nodes) are vastly reduced.
For example, amongst the enhancements, an option called hibernate.treecache.local.puts.only, whose default value is true, has been added that makes sure any put calls on the Second Level Cache as a result of a read operation from the database are done locally which means that data read from database is not replicated to other nodes. However, if put calls on the JBoss Cache Second Level Cache instance are as a result of an update of the data in the database, the new cache provider does replicate them. The effect is intra-cluster messaging traffic is greatly reduced, and each node in the cluster only caches data being used on that node. But if data is modified on any node, all nodes are made aware of the change, ensuring stale data isn’t left in a cache.
