Saturday, October 10, 2009

Configuring a JBoss + Spring + JPA (Hibernate) + JTA web application

(From http://www.swview.org/node/214)
Here's how one might go about deploying a Spring application in JBoss (4.something) that uses JPA with Hibernate as the provider for persistence and JTA for transaction demarcation.

1. Define the Spring configuration file in the web.xml file

<context-param>
        <description>Spring configuration file</description>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>



2. Define the Spring loader in the web.xml file

<listener>
        <description>Spring Loader</description>
        <listener-class>
         org.springframework.web.context.ContextLoaderListener
        </listener-class>
</listener>


3. Define the persistence unit reference in the web.xml file (which in fact has no effect until the Servlet container supports Servlet spec 2.5):

<persistence-unit-ref>
        <description>
            Persistence unit for the bank application.
        </description>
       
       <persistence-unit-ref-name>
              persistence/BankAppPU
       </persistence-unit-ref-name>
        <persistence-unit-name>BankAppPU</persistence-unit-name>       
</persistence-unit-ref>


* Note that this is what enables "" which has been commented out in the below given Spring configuration file.

* For the above to work well, your web.xml should start like this (note the version 2.5):

<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">


4. Here's the persistence.xml file. Make the changes to the as you have defined in your system (for example in a file like JBOSS_HOME/server/default/deploy/bank-ds.xml - See JBOSS_HOME/docs/examples/jca/ for templates).

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
  <persistence-unit name="BankAppPU" transaction-type="JTA">
    <provider>org.hibernate.ejb.HibernatePersistence</provider>
    <jta-data-source>java:BankAppDS</jta-data-source>
    <properties>
      <property name="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.JBossTransactionManagerLookup"/>
      <property name="hibernate.dialect" value="org.hibernate.dialect.MySQLDialect"/>
      <property name="jboss.entity.manager.factory.jndi.name" value="java:/BankAppPU"/>
      <property name="hibernate.hbm2ddl.auto" value="update"/>
    </properties>
  </persistence-unit>
</persistence>


5. Here's a sample Spring configuration file (applicationContext.xml):

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xmlns:tx="http://www.springframework.org/schema/tx"
       xmlns:jee="http://www.springframework.org/schema/jee"
       xsi:schemaLocation="
       http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
       http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd
       http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd
       http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee-2.5.xsd">

    <!-- In a fully J5EE compatible environment, the following xml tag should work in accessing the EMF -->          
<!--
    <jee:jndi-lookup id="entityManagerFactory" jndi-name="java:/BankAppPU"/>
-->
  
    <!-- Hack for JBoss 4.something until full compliance is reached -->
    <bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalEntityManagerFactoryBean">
      <property name="persistenceUnitName" value="BankAppPU"/>
    </bean>

    <!-- Let's access the JTA transaction manager of the application server -->
    <bean id="txManager" class="org.springframework.transaction.jta.JtaTransactionManager">
        <property name="transactionManagerName" value="java:/TransactionManager"/>
        <property name="userTransactionName" value="UserTransaction"/>
    </bean>
   
    <!-- Let's define a DAO that uses the EMF -->
    <bean id="accountHolderDAO" class="bankapp.dao.AccountHolderDAO">
        <property name="emf" ref="entityManagerFactory"/>
    </bean>
   
    <!-- This is a service object that we want to make transactional.
         You will have an interface implemented (AccountManager) in the class.
    -->
    <bean id="accountManager" class="bankapp.AccountManagerImpl">
        <property name="accountHolderDAO" ref="accountHolderDAO"/>
    </bean>
   
   
    <!-- The transactional advice (i.e. what 'happens'; see the <aop:advisor/> bean below) -->
    <tx:advice id="txAdvice" transaction-manager="txManager">
        <!-- the transactional semantics... -->
        <tx:attributes>
            <!-- all methods starting with 'get' are read-only transactions -->
            <tx:method name="get*" read-only="true"/>
            <!-- other methods use the default transaction settings (see below) -->
            <tx:method name="*" read-only="false" />
        </tx:attributes>
    </tx:advice>
   
   
    <!-- ensure that the above transactional advice runs for execution
      of any operation defined by the AccountManager interface -->
    <aop:config>
        <aop:pointcut id="accountManagerOperation",
           expression="execution(* bankapp.AccountManager.*(..))"/>
        <aop:advisor advice-ref="txAdvice" pointcut-ref="accountManagerOperation"/>
    </aop:config>
</beans>


6. Here's the sample AccountManagerImpl:

public class AccountManagerImpl implements AccountManager {
   
    /** Creates a new instance of AccountManagerImpl */
    public AccountManagerImpl() {
    }


    private AccountHolderDAO accountHolderDAO;
   
    public AccountHolder createAccountHolder(AccountHolder accountHolder) throws BankException {
        return accountHolderDAO.create(accountHolder);
    }


    public AccountHolderDAO getAccountHolderDAO() {
        return accountHolderDAO;
    }


    public void setAccountHolderDAO(AccountHolderDAO accountHolderDAO) {
        this.accountHolderDAO = accountHolderDAO;
    } 
}




7. Here's the sample AccountHolderDAO:

public class AccountHolderDAO {
   
    /** Creates a new instance of AccountHolderDAO */
    public AccountHolderDAO() {
    }
   
    private EntityManagerFactory emf;


    public EntityManagerFactory getEmf() {
        return emf;
    }


    public void setEmf(EntityManagerFactory emf) {
        this.emf = emf;
    }
   
    public AccountHolder create(AccountHolder newAccountHolder) throws BankException {
        try {
           
            // JTA Transaction assumed to have been started by AccountManager (Spring tx advice)
            EntityManager em = emf.createEntityManager();
            //em.getTransaction().begin(); - Not required
            em.persist(newAccountHolder);
            //em.getTransaction().commit(); - Not required
            return newAccountHolder;
            // JTA Transaction will be completed by Spring tx advice
           
        } catch (Exception e) {
            throw new BankException("Account creation failed" + e.getMessage(), e);
        }
    } 
}




You will have some other code accessing the Spring bean "accountManager" and invoke the createAccountHolder() with the required parameters. Things should work well.

Java Persistence API

The Java Persistence API is a POJO persistence API for object/relational mapping. It contains a full object/relational mapping specification supporting the use of Java language metadata annotations and/or XML descriptors to define the mapping between Java objects and a relational database. Java Persistence API is usable both within Java SE environments as well as within Java EE.

It supports a rich, SQL-like query language (which is a significant extension upon EJB QL) for both static and dynamic queries. It also supports the use of pluggable persistence providers.

The Java Persistence API originated as part of the work of the JSR 220 Expert Group to simplify EJB CMP entity beans. It soon became clear to the expert group, however, that a simplification of EJB CMP was not enough, and that what was needed was a POJO persistence framework in line with other O/R mapping technologies available in the industry. The Java Persistence API draws upon the best ideas from persistence technologies such as Hibernate, TopLink, and JDO.

Thursday, October 08, 2009

HTML ASCII Reference

HTML ASCII Reference
http://www.w3schools.com/TAGS/ref_ascii.asp

What new in JSF 2?

What new in JSF 2?
The follow link gives out a lot of info. Andy Schwartz has created a fantastic introduction to the new features of JavaServer Faces 2.

http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/

The follow is a slide of introduction of JSF.
http://horstmann.com/presentations/javaone-2009-sl/what-is-new-in-jsf2.html#(1)

JSF 1.x Part of Java EE Standard (JSR 127, 252)
Component oriented web framework
Two implementations: Sun, Apache
Veeeery extensible
Tool support
Third party component libraries

JSF 2.0Part of Java EE 6 (JSR 314)
Reduced XML configuration
Better error handling
Ajax
Support for GET requests
Easier component authoring
Resource handling
Lots of plumbing for tool builders

Easy NavigationBefore:


Managed Bean Annotations


FaceletsWas third party extension (Jacob Hookom)
Now part of the standard
The preferred view handler in JSF
No more JSP mess
MUCH better error messages
Page composition

Bookmarkable URLsIn JSF 1.x, everything is a POST
Browser bar URL one step behind
Can't be bookmarked
JSF 2.x supports GET requests
New tags h:button, h:link
View Parameters
.Bound to beans when request comes in
.Can be attached to next request



Composite ComponentsMade up of simpler components
Example: Login component with username/password fields
True JSF components
Can attach validators, listeners
Specified with XHTML+composite tags


Ajax



Minor Features
Resource loading
Standard resources directory
h:graphicImage, h:outputStylesheet, h:outputScript have library, name attributes
<h:outputStylesheet library="css" name="styles.css" />
Dynamic versioning
Botched attempt at i18n
New scopes
View scope
Flash
14 new events
Most useful for app developers: preRenderView, postValidate
<f:event type="postValidate" listener="#{user.validate}"/>

How to PlayRI is feature-complete but not bug-free
Download JSF 2.0 RI from http://javaserverfaces.dev.java.net/
Works with Tomcat
Or download Glassfish v3 Prelude
Or Netbeans 6.7 RC
Caveat: These may not have the latest JSF 2.0 implementations today

Looking ForwardComponent libraries for 2.0
IceFaces
RichFaces
Trinidad
Cruft removal
Integration with Web Beans (JSR 299)

RichFaces - another wheel from JBoss.

RichFaces 3.3.2 GA finally available for donwloads! Numerous bug fixes, optimizations and community RFCs are ready for the review and usage!

RichFaces is a component library for JSF and an advanced framework for easily integrating AJAX capabilities into business applications.

100+ AJAX enabled components in two libraries
a4j: page centric AJAX controls
rich: self contained, ready to use components
Whole set of JSF benefits while working with AJAX
Skinnability mechanism
Component Development Kit (CDK)
Dynamic resources handling

Testing facilities for components, actions, listeners, and pages
Broad cross-browser support

Large and active community


JSF 2 and RichFaces 4
We are working hard on RichFaces 4.0 which will have full JSF 2 integration. That is not all though, here is a summary of updates and features:

Redesigned modular repository and build system.
Simplified Component Development Kit with annotations, faces-config extensions, advanced templates support and more..
Ajax framework improvements extending the JSF 2 specification.
Component review for consistency, usability, and redesign following semantic HTML principles where possible.
Both server-side and client-side performance optimization.
Strict code clean-up and review.

ICEfaces - the best JSF framework

ICEfaces has been supported by NetBeans IDE. It looks pretty good and ease the developer to develop web application visually.

ICEfaces 1.8.2 Released

ICEfaces 1.8.2 is an official release that includes over 160 fixes and improvements.

Notable changes include:

• All-new support for "cookieless" mode operation for synchronous ICEfaces applications (deployed to browsers with cookies disabled).
• Enhanced keyboard navigation for the menuBar, menuPopup, panelCollapsible, panelTabSet, and tree components.
• The panelTab component now supports an optional label facet for defining arbitrarily complex labels.
• Enhanced dataExporter: define which columns & rows to export, seamless operation with dataPaginator, portlet support, and improved robustness.
• Improved panelTooltip: smarter positioning, mouse tracking, and customizable display event triggers (hover, click, etc.).
• Support for nested modal panelPopups.
• The inputFile component now supports optional "autoUpload" mode.
• The graphicImage component now supports all ICEfaces Resource APIs for specifying image resources.
• The outputResource component now has improved special character support for resource file-names.
• Rendering performance optimizations have been made to the dataTable, panelGroup, panelSeries, and menuBar components.
• Updated Component Showcase sample application illustrating new component capabilities.

Monday, September 21, 2009

PrimeFaces UI 0.9.3 is released/IPhone App Development with JSF

(From http://www.theserverside.com/news/thread.tss?thread_id=58131)
UI Components 0.9.3 features the TouchFaces mobile UI kit, 5 new components, improved portlet support, enhanced datatable and various improvements.

* TouchFaces - UI Development kit for mobile devices mainly iphone
* New component : FileUpload (Reimplemented)
* New component : Tooltip (Reimplemented)
* New component : PickList
* New component : HotKey
* New component : Virtual Keyboard
* Easy row selection, ajax pagination, data filtering and lazy loading enhancements to DataTable
* Significantly improved portal support for JSR168 and JSR268 portlets.
* Pojo and Converter support for AutoComplete


(From http://www.theserverside.com/news/thread.tss?thread_id=57877)
TouchFaces is a new subproject of PrimeFaces targeting the mobile
devices mainly iphone. Applications created with TouchFaces have the native look and feel of an IPhone applications and still benefit from the Java/JSF infrastructure. In addition TouchFaces depends on the PrimeFaces UI so ajax is built-in.

There's a 10 minute getting started screencast available online.


Website: http://primefaces.prime.com.tr/en/

User specified error message

Error messages starting from -20000 until -20999 are user specified error messages.

Oracle provides these range of codes so applications can raise an application specific error, which will be displayed after the chosen code.
This is done using the raise_application_error pl/sql function.

You'll have to contact the application provider should you want to have more detail about the error message.
Unless the error message is of an Oracle application or functionality, it is useless to contact Oracle for these errors.

Imagine I have a procedure which takes an argument. This arguments needs to be between 0 and 100:
create or replace procedure add_salary(pRaise number) is begin   if pRaise not between 0 and 100 then     raise_application_error(-20000, 'Raise need to be between 0 and 100');   end if;   -- do further processing end; / Procedure created.  SQL> 
Now we test the procedure with a valid argument:
SQL> exec add_salary(0);  PL/SQL procedure successfully completed. 
And now with an invalid argument:
SQL> exec add_salary(110); BEGIN add_salary(110); END;  * ERROR at line 1: ORA-20000: Raise need to be between 0 and 100 ORA-06512: at "DEV01.ADD_SALARY", line 4 ORA-06512: at line 1 
As one can see, we raised a custom error -20000 with a user defined error message.
The same thing happened with you, if you receive this error with one of our applications, you need to contact us in order to solve this problem.

So the only one who can help is the application vendor or service provider.

Handle Oracle PL/SQL Exception.

Few use the Oracle stored procedure in Java application. Today, I have to learn it as there is a modification in stored procedure. By the searching, got a link from Oracle website. It is a official help and pretty good. But I really hate to use them in application if not very very necessary. Anyway, just put here for a reference.

http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14261/errors.htm#i1863

Thursday, July 23, 2009

GMaps4JSF 1.1.2 release

GMaps4JSF 1.1.2 release: "GMaps4JSF 1.1.2 release"

JSF is really a good framework and this feature is truely help us.

Monday, July 06, 2009

Ubuntu下如何安装Cisco VPN client - Rainman的专栏 - CSDN博客

This is a installation guide for VPN on Ubuntu.

Ubuntu下如何安装Cisco VPN client - Rainman的专栏 - CSDN博客: "Ubuntu下如何安装Cisco VPN client"


我的环境是Ubuntu 8.04, VPN Client的版本是vpnclient-linux-x86_64-4.8.01.0640-k9。

1. 下载Cisco VPN client 的压缩包vpnclient-linux-x86_64-4.8.01.0640-k9.tar.gz, 可以直接在google输入这个文件名下载。

2. 下载以后打开命令窗口执行 tar zxvf vpnclient-linux-x86_64-4.8.01.0640-k9.tar.gz解压,目录下会出现vpnclient的文件夹。

3. 下载vpnclient的patch文件, 对应这个版本的patch是vpnclient-linux-2.6.24.diff,用其他的版本应该不会成功。这个文件也可以直接在google输入文件名下载。

4. 把下载下来的vpnclient-linux-2.6.24.diff放到刚才解压的vpnclient文件夹内。

5. 把目录切换到vpnclient文件夹下。

6. 执行$ patch < vpnclient-linux-2.6.24-final.diff

7. 执行$ sudo ./vpn_install 根据提示选择安装的路径或者直接按回车按照默认路径安装

8. 执行 sudo /etc/init.d/vpnclient_init start 输入密码,如果提示Starting /opt/cisco-vpnclient/bin/vpnclient: Done就表示安装成功了。

9. 把你的pcf文件放到etc/opt/cisco-vpnclient/Profiles/ 文件夹下,比如是mypcf.pcf。

10. 执行$vpnclient connect mypcf按照提示输入你的用户名密码等等就可以开始vpn之旅了。



本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/jinhuiyu/archive/2009/01/18/3821246.aspx

Tuesday, March 17, 2009

Understanding Java's "Perm Gen" (MaxPermSize, heap space, etc.)

(http://mark.kolich.com/2009/01/understanding-javas-perm-gen-maxpermsize-heap-space-etc.html)

During my travels at work, I've come across a few interesting memory management issues in Java. My team has deployed several large web-applications in a single instance of Apache Tomcat. The Linux box running these applications only has about 2GB of physical memory available. Once the apps are deployed, about 1.8 GB of the memory is consumed by Java alone. Clearly, we need to improve our memory management a bit.

However, I took a few minutes to do some digging on Java's Permanent Generation (Perm Gen) and how it relates to the Java heap. Here are some distilled notes from my research that you may find useful when debugging memory management issues in Java ...
JVM arg -Xmx defines the maximum heap size. Arg -Xms defines the initial heap size. Here is an example showing how you use these JVM arguments:

-Xmx1638m -Xms512m

In Tomcat, these settings would go in your startup.sh or init script, depending on how you start and run Tomcat. With regards to the MaxPermSize, this argument adjusts the size of the "permanent generation." As I understand it, the perm gen holds information about the "stuff" in the heap. So, the heap stores the objects and the perm gen keeps information about the "stuff" inside of it. Consequently, the larger the heap, the larger the perm gen needs to be. Here is an example showing how you use MaxPermSize:

-XX:MaxPermSize=128m



FOLLOWUP 1/30/09

Here are some additional notes on interesting/important JVM parameters:

Use the JVM options -XX:+TraceClassloading and -XX:+TraceClassUnloading to see what classes are loaded/un-loaded in real-time. If you have doubts about excessive class loading in your app; this might help you find out exactly what classes are loaded and where.

Use -XX:+UseParallelGC to tell the JVM to use multi-threaded, one thread per CPU, garbage collection. This might improve GC performance since the default garbage collector is single-threaded. Define the number of GC threads to use with the -XX:ParallelGCThreads={no of threads} option.

Never call System.gc(). The application doesn't know the best time to garbage-collect, only the JVM really does.

The JVM option -XX:+AggressiveHeap inspects the machine resources (size of memory and number of processors) and attempts to set various heap and memory parameters to be optimal for long-running, memory allocation-intensive jobs.

TrackBack URL: http://mark.kolich.com/mt-tb.cgi/96

MaxPermSize and how it relates to the overall heap

(Got from Google page cache. Lost the Author)

MaxPermSize and how it relates to the overall heap
Many people have asked if the MaxPermSize value is a part of the overall -Xmx heap setting or additional to it. There is a GC document on the Sun website which is causing some confusion due to a somewhat vague explanation and an errant diagram. The more I look at this document, the more I think the original author has made a subtle mistake in describing -Xmx as it relates to the PermSize and MaxPermSize.

First, a quick definition of the "permanent generation".
"The permanent generation is used to hold reflective data of the VM itself such as class objects and method objects. These reflective objects are allocated directly into the permanent generation, and it is sized independently from the other generations." [ref]

Yes, PermSize is additional to the -Xmx value set by the user on the JVM options. But MaxPermSize allows for the JVM to be able to grow the PermSize to the amount specified. Initially when the VM is loaded, the MaxPermSize will still be the default value (32mb for -client and 64mb for -server) but will not actually take up that amount until it is needed. On the other hand, if you were to set BOTH PermSize and MaxPermSize to 256mb, you would notice that the overall heap has increased by 256mb additional to the -Xmx setting.

So for example, if you set your -Xmx to 256m and your -MaxPermSize to 256m, you could check with the Solaris 'pmap' command how much memory the resulting process is taking up.

i.e.,
$ uname -a
SunOS devnull 5.8 Generic_108528-27 sun4u sparc
SUNW,UltraSPARC-IIi-cEngine

$ java -version
java version "1.3.1_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_02-b02)
Java HotSpot(TM) Client VM (build 1.3.1_02-b02, mixed mode)

---------------------------------------------
$ java -Xms256m -Xmx256m -XX:MaxPermSize=256m Hello &
$ pmap 6432
6432: /usr/java1.3.1/bin/../bin/sparc/native_threads/java -Xms256m -Xmx256m
total 288416K
---------------------------------------------
Notice above that the overall heap is not 256m+256m yet? Why? We did not specify PermSize yet, only MaxPermSize.

---------------------------------------------
$ java -Xms256m -Xmx256m -XX:PermSize=256m -XX:MaxPermSize=256m Hello &
$ pmap 6472
6472: /usr/java1.3.1/bin/../bin/sparc/native_threads/java -Xms256m -Xmx256m
total 550544K
---------------------------------------------

Now we see the overall heap grow, -Xmx+PermSize. This shows conclusive proof that PermSize and MaxPermSize are additional to the -Xmx setting.

Tuesday, November 04, 2008

How pretty it is - Click

http://click.sourceforge.net/

Click is a open source simple JEE web application framework for commercial Java developers, licensed under the Apache license.Click uses an event based programming model for processing Servlet requests and Velocity for rendering the response. (Note other template engines such as JSP and Freemarker are also supported).

It is really a pretty good framework to develop website and easy to learn also.

Get to know Apache Click.
http://www.ibm.com/developerworks/web/library/wa-apacheclick/?ca=dgr-jw22ApacheClick&S_TACT=105AGX59&S_CMP=grjw22

Friday, October 24, 2008

Reap the benefits of document style Web services

http://www.ibm.com/developerworks/webservices/library/ws-docstyle.html

James McCarthy (mailto:jmccarthy@symmetrysolutions.com?subject=Reap), President and CTO, Symmetry Solutions, Inc.

While most Web services are built around remote procedure calls, the WSDL specification allows for another kind of Web services architecture: document style, in which whole documents are exchanged between service clients and servers. In this article, James McCarthy explains what document style is and when you should use it.

Buried deep in the Web Service Definition Language (WSDL) specification is a very subtle switch that can turn the SOAP binding of a Web service from a remote procedure call to a pass-through document. The style attribute within the SOAP protocol binding can contain one of two values: rpc or document. When the attribute is set to document style, the client understands that it should make use of XML schemas rather than remote procedure calling conventions. This article will provide a description of this WSDL switch, describe its benefits, and explain when you should use pass-through documents.
Setting your service to use document style
First, let's briefly touch on a few point about WSDL to understand how this subtle change occurs. WSDL is an XML specification that is used to describe network services and the protocol-specific requirements for reaching an endpoint (the service). WSDL describes services in abstract terms; through an extensible binding definition, it is able to define the protocol and data format specifications for calling a service in concrete terms. The following grammar, taken directly from the WSDL specification, shows the extensibility elements contained within a binding:

Listing 1. WSDL grammar for extending elements within a binding

<wsdl:definitions .... >
<wsdl:binding name=3D"nmtoken" type=3D"qname"> *
<-- extensibility element (1) --> *
<wsdl:operation name=3D"nmtoken"> *
<-- extensibility element (2) --> *
<wsdl:input name=3D"nmtoken"? > ?
<-- extensibility element (3) -->=20
</wsdl:input>
<wsdl:output name=3D"nmtoken"? > ?
<-- extensibility element (4) --> *
</wsdl:output>
<wsdl:fault name=3D"nmtoken"> *
<-- extensibility element (5) --> *
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
< /wsdl:definitions>

The WSDL specification (see the Resources section below for a link) currently describes three binding extensions: HTTP GET/POST, MIME, and SOAP version 1.1. The binding extensions defined in HTTP GET/POST and MIME are used to define the requirements to communicate with standard Web applications that may or may not return XML documents. When sending or returning an XML document, the HTTP GET/POST binding extension is implicitly document style.
The SOAP binding extension is used to define a service that supports the SOAP envelope protocol. The SOAP envelope is a simple schema that is designed to contain an XML message, providing an application-specific header and a body portion of the message. The SOAP binding extension allows the WSDL document to declare the requirements of a SOAP message so that the application is able to properly communicate with the service. The SOAP extension allows the style of the SOAP message to be declared as either document or RPC. If the style attribute is declared in the soap:binding element, then that style becomes the default for all soap:operation elements that do not explicitly declare a style attribute. If the style attribute is not declared in the soap:binding element, then the default style is document. Here is an explicit declaration of document style:

Regardless of the declaration within the soap:binding element, the soap:operation element can override the declaration for each operation, like so:

In a SOAP message for which document style is declared, the message is placed directly into the body portion of the SOAP envelope, either as-is or encoded. If the style is declared as RPC, the message is enclosed within a wrapper element, with the name of the element taken from the operation name attribute and the namespace taken from the operation namespace attribute.

Benefits of document style
No one can dispute that the ability to invoke a cross-platform remote procedure call using XML is extremely useful and is a compelling argument for using Web services. But if Web services were constrained exclusively to RPC messaging, the reach of the technology would be limited. Fortunately, developers have a choice of using either RPC or document style messaging and are able to use the right technology for the tasks they face.

  • With document style, you can make full use of XML
    The XML specification was developed to allow ordinary data that is usually locked up in a proprietary format to be described in an open format that is human readable, self-describing, and self-validating. When a Web service uses document messaging, it can use the full capabilities of XML to describe and validate a high-level business document. When a service uses RPC message formatting, the XML describes the method and the parameters encoded for the method call and cannot be used to enforce high-level business rules. In order to enforce these rules, the RPC message must include an XML document as a string parameter and hide the validation within the method being called. For this reason, some of the benefits of XML are lost, or at least hidden within the back-end application.

  • Document style does not require a rigid contract
    Another reason to use document messaging is that a remote procedure call is meant to be relatively static and any changes to the interface would break the contract between the service and the application. If a service is widely distributed, then it is likely that a large number of applications have produced stub code from its WSDL document. Changing the WSDL would cause all of the applications that rely on a specific method signature to break and a lot of support lines to ring. Good design dictates that the method signature of an RPC message service should never change. With document messaging, the rules are less rigid and many enhancements and changes can be made to the XML schema without breaking the calling application.

  • Document style is better suited for asynchronous processing
    When businesses are using a Web-based application to exchange information over the Internet, the application should be able to use a guaranteed delivery mechanism to improve its reliability, scalability, and performance. To achieve this, an application will generally use asynchronous message queues. Since a document message is usually self-contained, it is better suited for asynchronous processing and can be placed directly into the queue. The reliability of the application is improved because the message queue guarantees the delivery of the message even if the target application is not currently active; performance is improved because the Web application simply delivers the document to a queue and is then free to perform other tasks; and scalability is improved because the document is offloaded to one or more instances of an application that handles its processing.

  • Document style makes object exchange more flexible
    The design of a business document is often very well suited to object-oriented architectures. As a result, two applications may be designed to exchange the state of an object by using XML. In contrast with object serialization, in an object exchange, each end of the exchange is free to design the object as it sees fit as long as the exchange conforms to the agreed upon XML document format. One reason for not using object serialization is to support client-side and server-side implementations of an object. Many current industry-specific XML schemas are designed as client/server architectures in which the processing that is done at the client is separate from the processing intended at the server. As is often the case, the client is simply requesting or saving information in a specific document format that is persisted at the server. Certainly, this type of exchange could be done using an RPC message, but the encoding scheme of such a message places constraints on the design of the object at each end. These constraints are not a problem with document style.


    When to use document style
    When should you use document style? The short answer: Anytime you are not interfacing to a preexisting remote procedure call, the benefits of document style may outweigh the extra effort that is often required to interface to the service. A caveat: The effort to build a service that uses document messaging is usually greater than the effort required to build an RPC message service. This extra effort usually involves the design of an XML schema or support for a preexisting schema, as well as the extraction of relevant information from a document. The schema design is important because the XML parser uses the schema to validate the document, supporting the intended business rules. Additional effort is required by the service to extract relevant information from the document to be used while handling the request. In contrast, an RPC message only requires the design of the method interface, from which it will automatically marshal and unmarshal the parameters.
    When making your decision to publish a service, you might want to consider the following questions. I'll examine the consequences of your answers in the following sections.
    Is this service interfacing to a preexisting procedure call and is the procedure call stateless?
    Is the service to be used only within your organization, or by outside users as well?
    Is one of the parameters simply an XML document specification?
    Does the service require a request/response architecture?
    Do the parameters represent complex structures that may benefit from an XML document schema for validation?
    Can all of the information that needs to be exchanged be reasonably contained in memory?

  • Use document style when maintaining application state
    You should consider a document architecture for your service if multiple procedures must be called in a particular sequence to maintain application state. If multiple procedure calls are required, then the procedure is not stateless and the service must maintain application state. Maintaining state within a Web service can be difficult; in the case of a remote procedure call, very few client platforms will generate stub code that is able to support state information. One possible solution is to use document architecture and pass the contents of an entire transaction within the document. In this case, the service will perform the calls to ensure that the proper sequence is maintained inside the service and state information is not maintained beyond a single transaction. If state information is still required, it can be built in to the resulting document, or the client application can maintain a token that identifies its state to the service.

  • Use document style to publish services for outside partners
    If an application is being published outside of the organization, the publisher has very little control over who is relying on the service and what the consequences will be if any changes are made. In such cases, it may be more advantageous to use document messaging and support a common exchange protocol such as ebXML. Common exchange protocols are evolving to improve the management of external exchanges so that new trading partner agreements can be rapidly deployed. Also, if your service does not require a request/response architecture, then common exchange protocols are better designed to handle authentication, reliable message delivery, and asynchronous request/response.

  • Use document style to ease validation and use of complex documents
    If your service is using a string parameter to pass or return an XML document, or if one of its parameters is an object with a complex structure that requires custom handling, then document messaging may be the better alternative. Hiding the true meaning of a parameter within a string can often lead to valid calls with invalid parameters. If the service publishes an XML document schema, then it is easier to validate against that schema prior to calling the service. A complex structure is often used to pass hundreds of pieces of information making up a complete transaction. When dealing with complex structures, a remote procedure service may have to deal with custom marshaling code while the application is still responsible for meticulously validating each element of the structure. If document messaging is used, then the application programmer can offload validation to the document designer using an XML schema, and no custom marshaling code is required.

  • Use document style to minimize in-memory processing
    One final consideration when choosing between document and RPC messaging is the amount of information that may need to be handled. Since most if not all of the implementations that marshal parameters in RPC messaging perform this operation in-memory, memory constraints may make RPC messaging unfeasible. Many document-messaging services are able to choose between DOM and SAX handling of the document and as a result are able to minimize in-memory processing. This is particularly critical for a Web service that may be required to handle thousands of requests, many simultaneously.


    Conclusion
    When designing your next Web service, you need to consider all of the options that the current WSDL specification gives you. Before starting with a procedural interface, consider how the service will be used, who will be using it, and the type and volume of information that needs to be exchanged. Designing and developing a document style Web service may require a little more effort, but in many cases the effort will pay off in the quality of information and the reliability of the exchange.

    Resources
    "Deploying Web services with WSDL," Bilal Siddiqui (developerWorks, November 2001) is a good introduction to the Web services and Web Services Description Language.
    Check out the specifications for WSDL and SOAP.
    The XMethods site is hosting a demo Web service that is built using document style.
    Check out the latest on IBM's Web Services initiative.


  • Monday, March 26, 2007

    The difference of Timer implementation in WebLogic 8.x and 9.x

    eDocs of wl8.x http://edocs.bea.com/wls/docs81/jmx/timer.html
    eDocs of wl9.x http://edocs.bea.com/wls/docs90/jmxinst/timer.html

    In the 8.1, the timer uses a simple way to add and remove notification while 9.x uses a service to do schedule.