[jboss-cvs] JBossAS SVN: r91476 - in projects/docs/enterprise/5.0: Administration_And_Configuration_Guide/en-US and 1 other directories.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Mon Jul 20 21:05:22 EDT 2009
Author: irooskov at redhat.com
Date: 2009-07-20 21:05:22 -0400 (Mon, 20 Jul 2009)
New Revision: 91476
Added:
projects/docs/enterprise/5.0/Examples/
projects/docs/enterprise/5.0/Examples/RESTEasy/
Modified:
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Deploy.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Microcontainer.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Web_Services.xml
Log:
updated admin guide and added folder for examples
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Deploy.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Deploy.xml 2009-07-20 23:34:56 UTC (rev 91475)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Deploy.xml 2009-07-21 01:05:22 UTC (rev 91476)
@@ -81,7 +81,7 @@
<para>The <emphasis>all</emphasis> profile is the default profile with clustering support and other enterprise extensions.</para></listitem>
<listitem>
<indexterm><primary>Profiles</primary><secondary>web</secondary></indexterm>
- <para>The <emphasis>web</emphasis> profile is a new experimental lightweight configuration created around JBoss Web that will follow the developments of the JavaEE 6 web profile. Except for the servlet/jsp container it provides support for JTA/JCA and JPA. It also limits itself to allowing access to the server only through the http port. Please note that this configuration is not JavaEE certified and will most likely change in the following releases.</para></listitem>
+ <para>The <emphasis>web</emphasis> profile is a new experimental lightweight configuration created around JBoss Web that will follow the developments of the JavaEE 6 web profile. Except for the <filename>servlet/jsp</filename> container it provides support for JTA/JCA and JPA. It also limits itself to allowing access to the server only through the http port. Please note that this configuration is not JavaEE certified and will most likely change in the following releases.</para></listitem>
</itemizedlist>
<para>The detailed services and APIs supported in each of those profiles will be discussed throughout.</para>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Microcontainer.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Microcontainer.xml 2009-07-20 23:34:56 UTC (rev 91475)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Microcontainer.xml 2009-07-21 01:05:22 UTC (rev 91476)
@@ -4,9 +4,9 @@
<chapter><title>Microcontainer</title>
<indexterm><primary>MC</primary><see>JBoss Microcontainer</see></indexterm>
-<para>JBoss Enterprise Application Platform 5.0 uses the microcontainer to integrate enterprise services together with a Servlet/JSP container, EJB container, deployers and management utilities in order to provide a standard Java EE environment. If you need additional services then you can simply deploy these on top of Java EE to provide the functionality you need. Likewise you are free to remove any services that you don't need simply by changing the configuration. You can even use the microcontainer to do this in other environments such as Tomcat and GlassFish since you can plug in different classloading models during the service deployment phase.</para>
+<para>JBoss Enterprise Application Platform 5.0 uses the Microcontainer to integrate enterprise services together with a Servlet/JSP container, EJB container, deployers and management utilities in order to provide a standard Java EE environment. If you need additional services then you can simply deploy these on top of Java EE to provide the functionality you need. Likewise any services that you do not need can be removed by changing the configuration. You can even use the Microcontainer to do this in other environments such as Tomcat and GlassFish by plugging in different classloading models during the service deployment phase.</para>
<para>Since JBoss Microcontainer is very lightweight and deals with POJOs, it can also be used to deploy services into a Java ME runtime environment. This opens up new possibilities for mobile applications that can now take advantage of enterprise services without requiring a full JEE application server. </para>
-<para>In common with other lightweight containers JBoss Microcontainer uses dependency injection to wire individual POJOs together to create services. Configuration is performed using either annotations or XML depending on where the information is best located. Finally unit testing is made extremely simple thanks to a helper class that extends JUnit to setup the test environment, allowing you to access POJOs and services from your test methods using just a few lines of code.
+<para>As with other lightweight containers, JBoss Microcontainer uses dependency injection to wire individual POJOs together to create services. Configuration is performed using either annotations or XML depending on where the information is best located. Unit testing is made extremely simple thanks to a helper class that extends JUnit to setup the test environment, allowing you to access POJOs and services from your test methods using just a few lines of code.
</para>
<section><title>An overview of the Microcontainer modules</title>
@@ -34,7 +34,7 @@
</listitem>
<listitem>
<para>
- The <literal>container</literal> module contains: reflection, the integration point for manipulating class information at runtime, e.g. overriding annotations or obtaining an aop instance advisor. joinpoint, the joinpoint model including the join point factory. classadaptor, the integration and configuration spi. metadata, base metadata types and repository
+ The <literal>container</literal> module contains: reflection, the integration point for manipulating class information at runtime (for example, overriding annotations or obtaining an aop instance advisor), joinpoint (the joinpoint model including the join point factory), classadaptor (the integration and configuration spi) and metadata (the base metadata types and repository).
</para>
</listitem>
<listitem>
@@ -59,7 +59,7 @@
</listitem>
<listitem>
<para>
- The <literal>metatype</literal> metatype module defines the base types found in the management view of a component.
+ The <literal>metatype</literal> module defines the base types found in the management view of a component.
</para>
</listitem>
<listitem>
@@ -73,13 +73,13 @@
</para>
</listitem>
<listitem>
- <para><literal>reliance-identity</literal> define identity as a MC POJO service</para>
+ <para><literal>reliance-identity</literal> defines identity as a MC POJO service</para>
</listitem>
<listitem>
- <para><literal>reliance-rules</literal> define your dependencies with Drools</para>
+ <para><literal>reliance-rules</literal> defines your dependencies with Drools</para>
</listitem>
<listitem>
- <para><literal>reliance-jbpm</literal> define your dependencies with jBPM</para>
+ <para><literal>reliance-jbpm</literal> defines your dependencies with jBPM</para>
</listitem>
<listitem>
<para>
@@ -91,87 +91,87 @@
</section>
<section><title>Configuration</title>
- <para>To configure the microcontainer bootstrap the you can use the <emphasis>JBOSS_HOME/server/<server_configuration>/conf/bootstrap.xml</emphasis> and <emphasis>JBOSS_HOME/server/<server_configuration>/conf/bootstrap/*.xml</emphasis> files where <emphasis><server_configuration></emphasis> represents the name of the server profile, for example, <emphasis>all</emphasis>, <emphasis>default</emphasis> or <emphasis>minimal</emphasis>. The bootstrap.xml simply references MC deployment descriptors that should be loaded in the indicated order. The current default profile bootstrap.xml references are:
+ <para>To configure the Microcontainer bootstrap you can use the <filename>JBOSS_HOME/server/<server_configuration>/conf/bootstrap.xml</filename> and <filename>JBOSS_HOME/server/<server_configuration>/conf/bootstrap/*.xml</filename> files where <emphasis><server_configuration></emphasis> represents the name of the server profile, for example, <emphasis>all</emphasis>, <emphasis>default</emphasis> or <emphasis>minimal</emphasis>. The <filename>bootstrap.xml</filename> simply references Microcontainer deployment descriptors that should be loaded in the indicated order. The current <emphasis>default</emphasis> profile <filename>bootstrap.xml</filename> references are:
</para>
<itemizedlist>
- <listitem><para>vfs.xml - JBoss VFS caching beans</para></listitem>
- <listitem><para>classloader.xml - the root class loading beans for the peer class loading model</para></listitem>
- <listitem><para>aop.xml - JBoss AOP integration and AspectManager beans</para></listitem>
- <listitem><para>jmx.xml - JBoss JMX kernel initialization</para></listitem>
- <listitem><para>deployers.xml - Core deployers for -jboss-beans.xml and -service.xml</para></listitem>
- <listitem><para>bindings.xml - Rewrite of the ServiceBindingManager as a POJO bean</para></listitem>
- <listitem><para>profile-repository.xml - full featured repository based profile service referenced by bootstrap.xml</para></listitem>
+ <listitem><para><filename>vfs.xml</filename> - JBoss VFS caching beans</para></listitem>
+ <listitem><para><filename>classloader.xml</filename> - the root class loading beans for the peer class loading model</para></listitem>
+ <listitem><para><filename>aop.xml</filename> - JBoss AOP integration and AspectManager beans</para></listitem>
+ <listitem><para><filename>jmx.xml</filename> - JBoss JMX kernel initialization</para></listitem>
+ <listitem><para><filename>deployers.xml</filename> - Core deployers for -<filename>jboss-beans.xml</filename> and -service.xml</para></listitem>
+ <listitem><para><filename>bindings.xml</filename> - Rewrite of the ServiceBindingManager as a POJO bean</para></listitem>
+ <listitem><para><filename>profile-repository.xml</filename> - full featured repository based profile service referenced by <filename>bootstrap.xml</filename></para></listitem>
</itemizedlist>
<para>The main beans are:
<itemizedlist>
<listitem>
- <para><emphasis>ProfileService</emphasis> : this bean loads the deployments associated with the named server profile, "default", "all" or whatever name is passed in as the "-c" option to the server. Its an extension of the JBoss Enterprise Application Platform 4.0.x and earlier notion of always looking to the filesystem <literal>server/name/conf/jboss-service.xml</literal> and <literal>server/name/deploy</literal> to load deployments.
+ <para><emphasis>ProfileService</emphasis> : This bean loads the deployments associated with the named server profile, <emphasis>default</emphasis>, <emphasis>all</emphasis> or the name that is passed to the server using the <code>-c</code> option. It's an extension of always looking to the filesystem <filename>server/name/conf/jboss-service.xml</filename> and <filename>server/name/deploy</filename> to load deployments.
</para>
</listitem>
<listitem>
- <para><emphasis>AspectManager?</emphasis> : the AOP aspects
+ <para><emphasis>AspectManager</emphasis> : the AOP aspects
</para>
</listitem>
<listitem>
- <para><emphasis>MainDeployer</emphasis> : this bean is an update of the JMX based MainDeployer from earlier versions to a one based on the Microcontainer, JBoss5VirtualFileSystem, and Virtual Deployment Framework(VDF). Deployer aspects are registered with the MainDeployer as an ordered list via inject of the deployers property.
+ <para><emphasis>MainDeployer</emphasis> : An update of the JMX based MainDeployer from earlier versions to a one based on the Microcontainer, <classname>JBoss5VirtualFileSystem</classname>, and Virtual Deployment Framework(VDF). Deployer aspects are registered with the MainDeployer as an ordered list via inject of the deployers property.
</para>
</listitem>
<listitem>
- <para><emphasis>ServiceClassLoaderDeployer?</emphasis> : this bean manages the class loading aspect of deployment.
+ <para><emphasis>ServiceClassLoaderDeployer</emphasis> : Manages the class loading aspect of deployment.
</para>
</listitem>
<listitem>
- <para><emphasis>JARDeployer</emphasis> : this bean is a structural deployment aspect which handles the legacy nested deployment behavior of adding non-deployable jars to the current deployment classpath.
+ <para><emphasis>JARDeployer</emphasis> : This bean is a structural deployment aspect which handles the legacy nested deployment behavior of adding non-deployable jars to the current deployment classpath.
</para>
</listitem>
<listitem>
- <para><emphasis>FileStructure?</emphasis> : this bean is a structural deployment aspect which recognizes well know deployment file types specified by suffix.
+ <para><emphasis>FileStructure</emphasis> : this bean is a structural deployment aspect which recognizes well know deployment file types specified by suffix.
</para>
</listitem>
<listitem>
- <para><emphasis>AspectDeployer?</emphasis> : handles aop descriptor deployments.
+ <para><emphasis>AspectDeployer</emphasis> : handles aop descriptor deployments.
</para>
</listitem>
<listitem>
- <para><emphasis>BeanDeployer?</emphasis> : this bean translates deployer-beans.xml into KernelDeployment? for the descriptor beans.
+ <para><emphasis>BeanDeployer</emphasis> : this bean translates <filename>deployer-beans.xml</filename> into <classname>KernelDeployment</classname> for the descriptor beans.
</para>
</listitem>
<listitem>
- <para><emphasis>KernelDeploymentDeployer?</emphasis> : translates a KernelDeployment? into the constituent BeanMetaData instances for the kernel beans.
+ <para><emphasis>KernelDeploymentDeployer</emphasis> : Translates a <classname>KernelDeployment</classname> into the constituent <classname>BeanMetaData</classname> instances for the kernel beans.
</para>
</listitem>
<listitem>
- <para><emphasis>BeanMetaDataDeployer?</emphasis> : creates the kernel beans from the deployment BeanMetaData.
+ <para><emphasis>BeanMetaDataDeployer</emphasis> : Creates the kernel beans from the deployment <classname>BeanMetaData</classname>.
</para>
</listitem>
<listitem>
- <para><emphasis>SARDeployer</emphasis> : this bean is a port of the legacy JMX SARDeployer to the VDF. It handles the legacy jboss-service.xml style of mbean deployment descriptors and maps this into a ServiceDeployment? pojo.
+ <para><emphasis>SARDeployer</emphasis> : this bean is a port of the legacy JMX <classname>SARDeployer</classname> to the VDF. It handles the legacy <filename>jboss-service.xml</filename> style of mbean deployment descriptors and maps this into a <classname>ServiceDeployment</classname> POJO.
</para>
</listitem>
<listitem>
- <para><emphasis>ServiceDeploymentDeployer?</emphasis> : translates ServiceDeployment? pojo into the constituent ServiceMetaData that represent the various mbeans.
+ <para><emphasis>ServiceDeploymentDeployer</emphasis> : Translates the <classname>ServiceDeployment</classname> POJO into the constituent <classname>ServiceMetaData</classname> that represent the various mbeans.
</para>
</listitem>
<listitem>
- <para><emphasis>ServiceDeployer?</emphasis> : creates the mbean services from deployment ServiceMetaData instances.
+ <para><emphasis>ServiceDeployer</emphasis> : creates the mbean services from deployment <classname>ServiceMetaData</classname> instances.
</para>
</listitem>
<listitem>
- <para><emphasis>JMXKernel</emphasis> : this bean manages the instantiation of a JMX kernel and MBeanServer in the jboss domain. It is used by the SARDeployer. It will be used by other management deployment aspects in the future to expose kernel beans via JMX.
+ <para><emphasis>JMXKernel</emphasis> : Manages the instantiation of a JMX kernel and <classname>MBeanServer</classname> in the jboss domain. It is used by the <classname>SARDeployer</classname>. It will be used by other management deployment aspects in the future to expose kernel beans via JMX.
</para>
</listitem>
<listitem>
- <para><emphasis>VFSDeployerScanner?</emphasis> : a scanner bean that loads the deployers directory contents into the basic profile service.
+ <para><emphasis>VFSDeployerScanner</emphasis> : A scanner bean that loads the deployers directory contents into the basic profile service.
</para>
</listitem>
<listitem>
- <para><emphasis>VFSDeploymentScanner?</emphasis> : a scanner bean that loads the deploy directory contents into the basic profile service.
+ <para><emphasis>VFSDeploymentScanner</emphasis> : A scanner bean that loads the deploy directory contents into the basic profile service.
</para>
</listitem>
<listitem>
- <para><emphasis>HDScanner</emphasis> : a bean that queries the profile service for changes in deploy directory contents and redeploys updated content, undeploys removed content, and add new deployment content to the profile service.
+ <para><emphasis>HDScanner</emphasis> : A bean that queries the profile service for changes in deploy directory contents and redeploys updated content, undeploys removed content, and add new deployment content to the profile service.
</para>
</listitem>
</itemizedlist>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Web_Services.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Web_Services.xml 2009-07-20 23:34:56 UTC (rev 91475)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Web_Services.xml 2009-07-21 01:05:22 UTC (rev 91476)
@@ -9,28 +9,25 @@
<indexterm><primary>JBossWS</primary><secondary>Web Services</secondary></indexterm>
<indexterm><primary>JAX-WS</primary><see>Web Services</see></indexterm>
- Web services are a key contributing factor in the ways Web commerce is conducted today.
- Web services enable application/programs to communicate by sending small and large chunks of data to each other.
+ Web services are a key contributing factor in the way Web commerce is conducted today.
+ Web services enable applications to communicate by sending small and large chunks of data to each other.
</para>
<para>
- A web service is essentially a software application that supports interaction of applications over a computer network or the world wide web. Web services usually interact via XML documents that map to an object, computer program, business process or database. To communicate, an application sends a message in XML document format to a web service which sends this message to the respective programs. Responses may be received based on requirements and the web service receives and sends them in XML document format to the required program or applications. Web services can be used in many ways examples include supply chain information management and business integration among a multitude of other applications.
+ A web service is essentially a software application that supports interaction of applications over a computer network or the world wide web. Web services usually interact through XML documents that map to an object, computer program, business process or database. To communicate, an application sends a message in XML document format to a web service which sends this message to the respective programs. Responses may be received based on requirements, the web service receives and then sends them in XML document format to the required program or applications. Web services can be used in many ways, examples include supply chain information management and business integration.
</para>
<para>
- JBossWS is a web service framework developed as part of the JBoss Enterprise Application Platform. It implements the JAX-WS specification that defines a programming model and run-time architecture for implementing web services in Java, targeted at the Java Platform, Enterprise Edition 5 (Java EE 5).
+ JBossWS is a web service framework included as part of the JBoss Enterprise Application Platform. It implements the JAX-WS specification that defines a programming model and run-time architecture for implementing web services in Java, targeted at the Java Platform, Enterprise Edition 5 (Java EE 5). Even though JAX-RPC is still supported (the web service specification for J2EE 1.4), JBossWS does put a clear focus on JAX-WS.
</para>
+ <section><title>The need for web services</title>
<para>
- JBossWS integrates with most current JBoss Enterprise Application Platform releases as well as earlier ones, that did implement the J2EE 1.4 specifications. Even though JAX-RPC, the web service specification for J2EE 1.4, is still supported JBossWS does put a clear focus on JAX-WS.
+ Enterprise systems communication may benefit from a wise adoption of web service technologies. Focusing attention on well designed contracts allows developers to establish an abstract view of their service capabilities. Considering the standardized way contracts are written, this definitely helps communication with third-party systems and eventually supports business-to-business integration; everything is clear and standardized in the contract the provider and consumer agree on. This also reduces the dependencies between implementations allowing other consumers to easily use the provided service without major changes.
</para>
- <section><title>Who needs web services?</title>
<para>
- Enterprise systems communication may benefit from a wise adoption of WS technologies. Exposing well designed contracts allows developers to extract an abstract view of their service capabilities. Considering the standardized way contracts are written, this definitely helps communication with third-party systems and eventually support business-to-business integration. No more agreement required on vendor specific implementation details, home-brew communication protocol or custom per-customer settings. Everything is clear and standardized in the contract the provider and consumer agree on. Of course this also reduces the dependencies between implementations allowing other consumers to easily use the provided service without major changes.
+ Other benefits exist for enterprise systems that incorporate web service technologies for internal heterogenous subsystems communication as web service interoperability boosts service reuse and composition. Web services elimenates the need to rewrite whole functionalities because they were developed by another enterprise department using a different software language.
</para>
- <para>
- Enterprise system may benefit from web service technologies also for internal heterogenous subsystems communication. As a matter of fact their interoperability boosts service reuse and composition. No more need to rewrite whole functionalities only because they were developed by another enterprise department using another software language.
- </para>
</section>
- <section><title>Service Oriented Architecture (SOA)</title>
+<!-- <section><title>Service Oriented Architecture (SOA)</title>
<para>
In case you think you already heard something like this... yes, those in previous paragraph are some of the principles Service Oriented Architecture is based on.
</para>
@@ -40,30 +37,30 @@
<para>
Of course SOA is an architectural model agnostic to technology platforms and every enterprise can pursue the strategic goals associated with service-oriented computing using different technologies. However in the current marketplace, Web Services are probably the technology platform that better suits SOA principles and are most used to get to this architecture.
</para>
- </section>
- <section><title>What web services are not...</title>
+ </section> -->
+ <section><title>What web services are not</title>
<para>
- Needless to say that web services are not the solution for every software system communication.
+ Web services are not the solution for every software system communication.
</para>
<para>
- Nowadays they are meant to be used for loosely-coupled coarse-grained communication, for message (document) exchange. Moreover during the last years a lot of specifications (WS-*) were discussed and finally approved to standardize ws-related advanced aspects including reliable messaging, message-level security, cross-service transactions, etc. Finally web service specifications also include notion of registries to collect service contract references, to easily discover service implementations, etc.
+ Nowadays they are meant to be used for loosely-coupled coarse-grained communication, message (document) exchange. Recent times has seen many specifications (WS-*) discussed and finally approved to establish standardized ws-related advanced aspects, including reliable messaging, message-level security and cross-service transactions. Web service specifications also include the notion of registries to collect service contract references, to easily discover service implementations.
</para>
<para>
This all means that the web services technology platform suits complex enterprise communication and is not simply the latest way of doing remote procedure calls.
</para>
</section>
- <section><title>Jboss Web services Attachment support with XOP (XML-binary Optimized Packaging) and SwA</title>
+ <section><title>Jboss Web Services Attachment support with XOP (XML-binary Optimized Packaging) and SwA</title>
<para>
JBoss-WS4EE relied on a deprecated attachments technology called SwA (SOAP with Attachments). SwA required soap/encoding which is disallowed by the WS-I Basic Profile. JBossWS provides support for WS-I AP 1.0, and MTOM instead. <!--There will be no API change for users, however, since this is an updated protocol you will not be able to transfer attachments between older versions of JBoss AS and JBoss AS 4.0.4 or above.-->
</para>
<para>
- WS-I Attachment Profile 1.0 defines mechanism to reference MIME attachment parts using swaRef. In this mechanism the content of XML element of type wsi:swaRef is sent as MIME attachment and the element inside SOAP Body holds the reference to this attachment in the CID URI scheme as defined by RFC 2111.
+ WS-I Attachment Profile 1.0 defines a mechanism to reference MIME attachment parts using swaRef. In this mechanism the content of XML element of type <property>wsi:swaRef</property> is sent as a MIME attachment and the element inside SOAP Body holds the reference to this attachment in the CID URI scheme as defined by RFC 2111.
</para>
</section>
<section><title>Using SwaRef with JAX-WS endpoints</title>
<para>
- JAX-WS endpoints delegate all marshalling/unmarshalling to the JAXB API. The most simple way to enable SwaRef encoding for DataHandler types is to annotate a payload bean with the @XmlAttachmentRef annotation as shown below:
+ JAX-WS endpoints delegate all marshalling/unmarshalling to the JAXB API. The most simple way to enable SwaRef encoding for DataHandler types is to annotate a payload bean with the <property>@XmlAttachmentRef</property> annotation as shown below:
</para>
<programlisting role="JAVA">/**
@@ -126,18 +123,15 @@
</section>
<section><title>MTOM/XOP</title>
<para>
- This chapter describes Message Transmission Optimization Mechanism (MTOM) and XML-binary Optimized Packaging (XOP), a means of more efficiently serializing XML Infosets that have certain types of content. The related specifications are
- <itemizedlist>
- <listitem><para>SOAP Message Transmission Optimization Mechanism ((MTOM) <ulink url="http://www.w3.org/TR/soap12-mtom/"/>)</para>
- </listitem>
- <listitem>
- <para>XML-binary Optimized Packaging (XOP) (<ulink url="http://www.w3.org/TR/xop10/"/>)</para>
- </listitem>
- </itemizedlist>
+ This chapter describes Message Transmission Optimization Mechanism (MTOM) and XML-binary Optimized Packaging (XOP), a means of more efficiently serializing XML Infosets that have certain types of content. The related specifications are:
</para>
-
-<para>
-
+<itemizedlist>
+ <listitem><para>SOAP Message Transmission Optimization Mechanism ((MTOM) <ulink url="http://www.w3.org/TR/soap12-mtom/"/>)</para>
+ </listitem>
+ <listitem>
+ <para>XML-binary Optimized Packaging (XOP) (<ulink url="http://www.w3.org/TR/xop10/"/>)</para>
+ </listitem>
+</itemizedlist>
<table frame="all"><title>Supported MTOM parameter types</title>
<tgroup cols="2"><tbody>
<row>
@@ -173,11 +167,11 @@
</entry>
</row></tbody></tgroup>
</table>
-
+<para>
The above table shows a list of supported endpoint parameter types. The recommended approach is to use the javax.activation.DataHandler classes to represent binary data as service endpoint parameters.
</para>
- <note><title>Note</title><para>Microsoft endpoints tend to send any data as application/octet-stream. The only Java type that can easily cope with this ambiguity is javax.activation.DataHandler</para></note>
+ <note><para>Microsoft endpoints tend to send any data as application/octet-stream. The only Java type that can easily cope with this ambiguity is javax.activation.DataHandler</para></note>
</section>
@@ -232,11 +226,9 @@
</section>
- <section><title>Document/Literal</title>
+<section><title>Document/Literal</title>
<para>
- With document style web services two business partners agree on the exchange of complex business documents that are well defined in XML schema. For example, one party sends a document describing a purchase order, the other responds (immediately or later) with a document that describes the status of the purchase order. No need to agree on such low level details as operation names and their associated parameters.
- The payload of the SOAP message is an XML document that can be validated against XML schema.
- Document is defined by the style attribute on the SOAP binding.
+ With document style web services two business partners agree on the exchange of complex business documents that are well defined in XML schema. For example, one party sends a document describing a purchase order, the other responds (immediately or later) with a document that describes the status of the purchase order. The payload of the SOAP message is an XML document that can be validated against XML schema. The document is defined by the style attribute on the SOAP binding.
</para>
<programlisting role="XML"><binding name='EndpointInterfaceBinding' type='tns:EndpointInterface'>
@@ -278,8 +270,7 @@
<section><title>Document/Literal (Bare)</title>
<para>
- Bare is an implementation detail from the Java domain. Neither in the abstract contract (i.e. wsdl+schema) nor at the SOAP message level is a bare endpoint recognizable.
- A bare endpoint or client uses a Java bean that represents the entire document payload.
+ Bare is an implementation detail from the Java domain. Neither in the abstract contract (for instance, wsdl+schema) nor at the SOAP message level is a bare endpoint recognizable. A bare endpoint or client uses a Java bean that represents the entire document payload.
</para>
<programlisting role="JAVA">@WebService
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
@@ -311,8 +302,7 @@
<section><title>Document/Literal (Wrapped)</title>
<para>
- Wrapped is an implementation detail from the Java domain. Neither in the abstract contract (i.e. wsdl+schema) nor at the SOAP message level is a wrapped endpoint recognizable.
- A wrapped endpoint or client uses the individual document payload properties. Wrapped is the default and does not have to be declared explicitly.
+ Wrapped is an implementation detail from the Java domain. Neither in the abstract contract (for instance, wsdl+schema) nor at the SOAP message level is a wrapped endpoint recognizable. A wrapped endpoint or client uses the individual document payload properties. Wrapped is the default and does not have to be declared explicitly.
</para>
<programlisting role="JAVA">@WebService
public class DocWrappedServiceImpl
@@ -326,9 +316,9 @@
}
}</programlisting>
-<para>
-Note, that with JBossWS the request/response wrapper annotations are not required, they will be generated on demand using sensible defaults.
- </para>
+<note><para>
+With JBossWS the request and response wrapper annotations are not required, they will be generated on demand using sensible defaults.
+</para></note>
</section>
@@ -368,7 +358,7 @@
<para>
- With rpc style web services the portType names the operation (i.e. the java method on the endpoint)
+ With RPC style web services the portType names the operation (i.e. the java method on the endpoint)
</para>
<programlisting role="XML"><portType name='EndpointInterface'>
@@ -390,9 +380,9 @@
<part name='result' type='xsd:string'/>
</message></programlisting>
-<para>
-Note, there is no complex type in XML schema that could validate the entire SOAP message payload.
-</para>
+<note><para>
+There is no complex type in XML schema that could validate the entire SOAP message payload.
+</para></note>
<programlisting role="JAVA">
@WebService
@@ -418,7 +408,7 @@
<para>
SOAP encodeding style is defined by the infamous <ulink url="http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383512">chapter 5</ulink> of the <ulink url="http://www.w3.org/TR/2000/NOTE-SOAP-20000508/">SOAP-1.1</ulink> specification. It has inherent interoperability issues that cannot be fixed. The <ulink url="http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html">Basic Profile-1.0</ulink> prohibits this encoding style in <ulink url="http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html#refinement16448072">4.1.7 SOAP encodingStyle Attribute</ulink>.
- JBossWS has basic support for rpc/encoded that is provided as is for simple interop scenarios with SOAP stacks that do not support literal encoding.
+ JBossWS has basic support for RPC/Encoded that is provided as is for simple interop scenarios with SOAP stacks that do not support literal encoding.
Specifically, JBossWS does not support:-
<itemizedlist>
<listitem>
@@ -438,7 +428,7 @@
</section>
<section><title>Web Service Endpoints </title>
- <para>JAX-WS simplifies the development model for a web service endpoint a great deal. In short, an endpoint implementation bean is annotated with JAX-WS annotations and deployed to the server. The server automatically generates and publishes the abstract contract (i.e. wsdl+schema) for client consumption. All marshalling/unmarshalling is delegated to JAXB [2].
+ <para>JAX-WS simplifies the development model for a web service endpoint a great deal. In short, an endpoint implementation bean is annotated with JAX-WS annotations and deployed to the server. The server automatically generates and publishes the abstract contract (for instance, wsdl+schema) for client consumption. All marshalling/unmarshalling is delegated to JAXB.
</para>
</section>
@@ -446,7 +436,7 @@
<section><title>Plain old Java Object (POJO)</title>
- <para>Let's take a look at simple POJO endpoint implementation. All endpoint associated metadata is provided via JSR-181 annotations
+ <para>Let us take a look at simple POJO endpoint implementation. All endpoint associated metadata is provided via JSR-181 annotations
</para>
<programlisting role="JAVA">@WebService
@SOAPBinding(style = SOAPBinding.Style.RPC)
@@ -482,7 +472,7 @@
<section><title>Packaging the endpoint</title>
<para>
- A JSR-181 java service endpoint (JSE) is packaged as a web application in a *.war file.
+ A JSR-181 java service endpoint (JSE) is packaged as a web application in a <filename>*.war</filename> file.
</para>
<programlisting role="XML"><war warfile="${build.dir}/libs/jbossws-samples-jsr181pojo.war" webxml="${build.resources.dir}/samples/jsr181pojo/WEB-INF/web.xml">
@@ -491,9 +481,9 @@
</classes>
</war> </programlisting>
-<para>
-Note that only the endpoint implementation bean and web.xml are required.
- </para>
+<note><para>
+Only the endpoint implementation bean and <filename>web.xml</filename> file are required.
+</para></note>
</section>
@@ -504,11 +494,11 @@
<section>
<title>Accessing the generated WSDL</title>
- <para>A successfully deployed service endpoint will show up in the service endpoint manager. This is also where you find the links to the generated wsdl.</para>
- <para>
+ <para>A successfully deployed service endpoint will show up in the service endpoint manager. This is also where you find the links to the generated WSDL.</para>
+
<screen>http://yourhost:8080/jbossws/services</screen>
-a
-Note, it is also possible to generate the abstract contract off line using jbossw tools. For details of that please see <ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=JAX-WS_User_Guide#Top_Down_.28Java_to_WSDL.29">#Top Down (Java to WSDL)</ulink></para>
+<para>
+It is also possible to generate the abstract contract off line using jboss tools. For details of that see <ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=JAX-WS_User_Guide#Top_Down_.28Java_to_WSDL.29">#Top Down (Java to WSDL)</ulink></para>
</section>
<section>
<title>EJB3 Stateless Session Bean (SLSB)</title>
@@ -529,24 +519,26 @@
}
} </programlisting>
- <para>Above you see an EJB-3.0 stateless session bean that exposes one method both on the remote interface and on and as an endpoint operation.</para>
- <para>
- <emphasis role="bold">Packaging the endpoint</emphasis>
- </para>
- <para>A JSR-181 EJB service endpoint is packaged as an ordinary ejb deployment.</para>
+ <para>Above you see an EJB-3.0 stateless session bean that exposes one method both on the remote interface and as an endpoint operation.</para>
+ <formalpara>
+ <title>Packaging the endpoint</title>
+ <para>
+ A JSR-181 EJB service endpoint is packaged as an ordinary ejb deployment.
+ </para>
+ </formalpara>
<programlisting role="XML"><jar jarfile="${build.dir}/libs/jbossws-samples-jsr181ejb.jar">
<fileset dir="${build.dir}/classes">
<include name="org/jboss/test/ws/samples/jsr181ejb/EJB3Bean01.class"/>
<include name="org/jboss/test/ws/samples/jsr181ejb/EJB3RemoteInterface.class"/>
</fileset>
</jar> </programlisting>
- <para>
- <emphasis role="bold">Accessing the generated WSDL</emphasis>
- </para>
- <para>A successfully deployed service endpoint will show up in the service endpoint manager. This is also where you find the links to the generated wsdl.</para>
+ <formalpara>
+ <title>Accessing the generated WSDL</title>
+ <para>A successfully deployed service endpoint will show up in the service endpoint manager. This is also where you will find the links to the generated WSDL.</para>
+ </formalpara>
<programlisting> <![CDATA[
http://yourhost:8080/jbossws/services]]> </programlisting>
- <para>Note, it is also possible to generate the abstract contract off line using jbossw tools. For details of that please see <ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=JAX-WS_User_Guide#Top_Down_.28Java_to_WSDL.29">#Top Down (Java to WSDL)</ulink></para>
+ <para>It is also possible to generate the abstract contract offline using JbossWS tools. For details of that please see <ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=JAX-WS_User_Guide#Top_Down_.28Java_to_WSDL.29">#Top Down (Java to WSDL)</ulink></para>
</section>
<section>
<title>Endpoint Provider</title>
@@ -563,11 +555,11 @@
// Access the entire request PAYLOAD and return the response PAYLOAD
}
} </programlisting>
- <para>Note, Service.Mode.PAYLOAD is the default and does not have to be declared explicitly. You can also use Service.Mode.MESSAGE to access the entire SOAP message (i.e. with MESSAGE the Provider can also see SOAP Headers)</para>
+ <para><property>Service.Mode.PAYLOAD</property> is the default and does not have to be declared explicitly. You can also use <property>Service.Mode.MESSAGE</property> to access the entire SOAP message (for example, with <property>MESSAGE</property> the Provider can also see SOAP Headers)</para>
</section>
<section>
<title>WebServiceContext</title>
- <para>The WebServiceContext is treated as an injectable resource that can be set at the time an endpoint is initialized. The WebServiceContext object will then use thread-local information to return the correct information regardless of how many threads are concurrently being used to serve requests addressed to the same endpoint object.</para>
+ <para>The <classname>WebServiceContext</classname> is treated as an injectable resource that can be set at the time an endpoint is initialized. The <classname>WebServiceContext</classname> object will then use thread-local information to return the correct information regardless of how many threads are concurrently being used to serve requests addressed to the same endpoint object.</para>
<programlisting role="JAVA">
@WebService
public class EndpointJSE
@@ -604,10 +596,10 @@
<para>For most clients, you will start with a set of stubs generated from the WSDL. One of these will be the service, and you will create objects of that class in order to work with the service (see "static case" below).</para>
<section>
<title>Service Usage</title>
- <para>
- <emphasis role="bold">Static case</emphasis>
- </para>
- <para>Most clients will start with a WSDL file, and generate some stubs using jbossws tools like <emphasis>wsconsume</emphasis>. This usually gives a mass of files, one of which is the top of the tree. This is the service implementation class.</para>
+ <formalpara>
+ <title>Static case</title>
+ <para>Most clients will start with a WSDL file, and generate some stubs using jbossws tools like <emphasis>wsconsume</emphasis>. This usually gives a mass of files, one of which is the top of the tree. This is the service implementation class.</para>
+ </formalpara>
<para>The generated implementation class can be recognised as it will have two public constructors, one with no arguments and one with two arguments, representing the wsdl location (a java.net.URL) and the service name (a javax.xml.namespace.QName) respectively.</para>
<para>Usually you will use the no-argument constructor. In this case the WSDL location and service name are those found in the WSDL. These are set implicitly from the WebServiceClient annotation that decorates the generated class.</para>
<para>The following code snippet shows the generated constructors from the generated class:</para>
@@ -630,32 +622,32 @@
...
}</programlisting>
<para>Section <ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=JAX-WS_User_Guide#Dynamic_Proxy">#Dynamic Proxy</ulink> explains how to obtain a port from the service and how to invoke an operation on the port. If you need to work with the XML payload directly or with the XML representation of the entire SOAP message, have a look at <ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=JAX-WS_User_Guide#Dispatch">#Dispatch</ulink>.</para>
- <para>
- <emphasis role="bold">Dynamic case</emphasis>
- </para>
- <para>In the dynamic case, when nothing is generated, a web service client uses <literal>Service.create</literal> to create Service instances, the following code illustrates this process.</para>
+ <formalpara>
+ <title>Dynamic case</title>
+ <para>In the dynamic case, when nothing is generated, a web service client uses <literal>Service.create</literal> to create Service instances, the following code illustrates this process.</para>
+ </formalpara>
<programlisting role="JAVA">
URL wsdlLocation = new URL("http://example.org/my.wsdl");
QName serviceName = new QName("http://example.org/sample", "MyService");
Service service = Service.create(wsdlLocation, serviceName);</programlisting>
- <para>This is the nastiest way to work with JBossWs. Older versions have extensive details on DII as it was then known.</para>
+ <para>This is not the recommended way to use JBossWS.</para>
</section>
<section>
<title>Handler Resolver</title>
- <para>JAX-WS provides a flexible plug-in framework for message processing modules, known as handlers, that may be used to extend the capabilities of a JAX-WS runtime system. <ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=JAX-WS_User_Guide#Handler_Framework">#Handler Framework</ulink> describes the handler framework in detail. A Service instance provides access to a HandlerResolver via a pair of getHandlerResolver/setHandlerResolver methods that may be used to configure a set of handlers on a per-service, per-port or per-protocol binding basis.</para>
- <para>When a Service instance is used to create a proxy or a Dispatch instance then the handler resolver currently registered with the service is used to create the required handler chain. Subsequent changes to the handler resolver configured for a Service instance do not affect the handlers on previously created proxies, or Dispatch instances.</para>
+ <para>JAX-WS provides a flexible plug-in framework for message processing modules, known as handlers, that may be used to extend the capabilities of a JAX-WS runtime system. <ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=JAX-WS_User_Guide#Handler_Framework">Handler Framework</ulink> describes the handler framework in detail. A <classname>Service</classname> instance provides access to a <classname>HandlerResolver</classname> via a pair of <methodname>getHandlerResolver</methodname> and <methodname>setHandlerResolver</methodname> methods that may be used to configure a set of handlers on a per-service, per-port or per-protocol binding basis.</para>
+ <para>When a <classname>Service</classname> instance is used to create a proxy or a <classname>Dispatch</classname> instance then the handler resolver currently registered with the service is used to create the required handler chain. Subsequent changes to the handler resolver configured for a <classname>Service</classname> instance do not affect the handlers on previously created proxies, or <classname>Dispatch</classname> instances.</para>
<!--<para>[TODO] <ulink url="http://jira.jboss.org/jira/browse/JBWS-1512">(JBWS-1512) Provide a sample for Service HandlerResolver</ulink></para>-->
</section>
<section>
<title>Executor</title>
- <para>Service instances can be configured with a java.util.concurrent.Executor. The executor will then be used to invoke any asynchronous callbacks requested by the application. The setExecutor and getExecutor methods of Service can be used to modify and retrieve the executor configured for a service.</para>
+ <para><classname>Service</classname> instances can be configured with a <classname>java.util.concurrent.Executor</classname>. The executor will then be used to invoke any asynchronous callbacks requested by the application. The <methodname>setExecutor</methodname> and <methodname>getExecutor</methodname> methods of <classname>Service</classname> can be used to modify and retrieve the executor configured for a service.</para>
<!--<para>[TODO] <ulink url="http://jira.jboss.org/jira/browse/JBWS-1513">(JBWS-1513) Provide a sample for Service Executor</ulink></para>-->
</section>
</section>
<section>
<title>Dynamic Proxy</title>
- <para>You can create an instance of a client proxy using one of getPort methods on the <ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=JAX-WS_User_Guide#Service">#Service</ulink>.</para>
+ <para>You can create an instance of a client proxy using one of <methodname>getPort</methodname> methods on the <ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=JAX-WS_User_Guide#Service"><classname>Service</classname></ulink>.</para>
<programlisting role="JAVA">
/**
* The getPort method returns a proxy. A service client
@@ -683,8 +675,8 @@
{
...
}</programlisting>
- <para>The service endpoint interface (SEI) is usually generated using tools. For details see <ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=JAX-WS_User_Guide#_Top_Down_.28WSDL_to_Java.29"># Top Down (WSDL to Java)</ulink></para>
- <para>A generated static <ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=JAX-WS_User_Guide#Service">#Service</ulink> usually also offers typed methods to get ports. These methods also return dynamic proxies that implement the SEI.</para>
+<para>The <emphasis>Service Endpoint Interface</emphasis> (SEI) is usually generated using tools. For details see <ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=JAX-WS_User_Guide#_Top_Down_.28WSDL_to_Java.29">Top Down (WSDL to Java)</ulink>.</para>
+<para>A generated static <ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=JAX-WS_User_Guide#Service"><classname>Service</classname></ulink> usually also offers typed methods to get ports. These methods also return dynamic proxies that implement the SEI.</para>
<programlisting role="JAVA">
@WebServiceClient(name = "TestEndpointService", targetNamespace = "http://org.jboss.ws/wsref",
wsdlLocation = "http://localhost.localdomain:8080/jaxws-samples-webserviceref?wsdl")
@@ -707,14 +699,14 @@
</section>
<section>
<title>WebServiceRef</title>
- <para>The WebServiceRef annotation is used to declare a reference to a Web service. It follows the resource pattern exemplified by the javax.annotation.Resource annotation in JSR-250 [5]</para>
- <para>There are two uses to the WebServiceRef annotation:</para>
+ <para>The <classname>WebServiceRef</classname> annotation is used to declare a reference to a Web service. It follows the resource pattern exemplified by the <classname>javax.annotation.Resource</classname> annotation in JSR-250 [5]</para>
+ <para>There are two uses to the <classname>WebServiceRef</classname> annotation:</para>
<orderedlist>
<listitem>
- <para> To define a reference whose type is a generated service class. In this case, the type and value element will both refer to the generated service class type. Moreover, if the reference type can be inferred by the field/method declaration the annotation is applied to, the type and value elements MAY have the default value (Object.class, that is). If the type cannot be inferred, then at least the type element MUST be present with a non-default value.</para>
+ <para> To define a reference whose type is a generated service class. In this case, the type and value element will both refer to the generated service class type. Moreover, if the reference type can be inferred by the field/method declaration the annotation is applied to, the type and value elements <emphasis>may</emphasis> have the default value (<classname>Object.class</classname>, that is). If the type cannot be inferred, then at least the type element <emphasis>must</emphasis> be present with a non-default value.</para>
</listitem>
<listitem>
- <para> To define a reference whose type is a SEI. In this case, the type element MAY be present with its default value if the type of the reference can be inferred from the annotated field/method declaration, but the value element MUST always be present and refer to a generated service class type (a subtype of javax.xml.ws.Service). The wsdlLocation element, if present, overrides theWSDL location information specified in the WebService annotation of the referenced generated service class.</para>
+ <para> To define a reference whose type is a SEI. In this case, the type element <emphasis>may</emphasis> be present with its default value if the type of the reference can be inferred from the annotated field and method declaration, but the value element <emphasis>must</emphasis> always be present and refer to a generated service class type (a subtype of <classname>javax.xml.ws.Service</classname>). The <property>wsdlLocation</property> element, if present, overrides <property>theWSDL</property> location information specified in the <classname>WebService</classname> annotation of the referenced generated service class.</para>
</listitem>
</orderedlist>
<programlisting role="XML">
@@ -726,16 +718,16 @@
@WebServiceRef
public TestEndpoint port3;
</programlisting>
- <para>
- <emphasis role="bold">WebServiceRef Customization</emphasis>
- </para>
- <para>In Jboss Enterprise Application Platform 5.0 we offer a number of overrides and extensions to the WebServiceRef annotation. These include</para>
+ <formalpara>
+ <title>WebServiceRef Customization</title>
+ <para>In Jboss Enterprise Application Platform 5.0 we offer a number of overrides and extensions to the <classname>WebServiceRef</classname> annotation. These include</para>
+ </formalpara>
<itemizedlist>
<listitem>
<para> define the port that should be used to resolve a container-managed port</para>
</listitem>
<listitem>
- <para> define default Stub property settings for Stub objects</para>
+ <para> define default <property>Stub</property> property settings for Stub objects</para>
</listitem>
<listitem>
<para> define the URL of a final WSDL document to be used</para>
@@ -773,15 +765,28 @@
</port-info>
</service-ref></programlisting>
-<para>For details please see <emphasis role="bold">service-ref_5_0.dtd</emphasis> in the jboss docs directory.</para>
+<!--<para>For details, see <emphasis role="bold">service-ref_5_0.dtd</emphasis> in the jboss documentation directory.</para> -->
</section>
<section>
<title>Dispatch</title>
<para>XMLWeb Services use XML messages for communication between services and service clients. The higher level JAX-WS APIs are designed to hide the details of converting between Java method invocations and the corresponding XML messages, but in some cases operating at the XML message level is desirable. The Dispatch interface provides support for this mode of interaction.</para>
- <para>Dispatch supports two usage modes, identified by the constants javax.xml.ws.Service.Mode.MESSAGE and javax.xml.ws.Service.Mode.PAYLOAD respectively:</para>
- <para><emphasis role="bold">Message</emphasis> In this mode, client applications work directly with protocol-specific message structures. E.g., when used with a SOAP protocol binding, a client application would work directly with a SOAP message.</para>
- <para><emphasis role="bold">Message Payload</emphasis> In this mode, client applications work with the payload of messages rather than the messages themselves. E.g., when used with a SOAP protocol binding, a client application would work with the contents of the SOAP Body rather than the SOAP message as a whole.</para>
- <para>Dispatch is a low level API that requires clients to construct messages or message payloads as XML and requires an intimate knowledge of the desired message or payload structure. Dispatch is a generic class that supports input and output of messages or message payloads of any type.</para>
+ <para>Dispatch supports two usage modes, identified by the constants <property>javax.xml.ws.Service.Mode.MESSAGE</property> and <property>javax.xml.ws.Service.Mode.PAYLOAD</property> respectively:</para>
+
+ <formalpara>
+ <title>Message</title>
+ <para>
+ In this mode, client applications work directly with protocol-specific message structures. E.g., when used with a SOAP protocol binding, a client application would work directly with a SOAP message.
+ </para>
+ </formalpara>
+ <formalpara>
+ <title>Message Payload</title>
+ <para>
+ In this mode, client applications work with the payload of messages rather than the messages themselves. E.g., when used with a SOAP protocol binding, a client application would work with the contents of the SOAP Body rather than the SOAP message as a whole.
+ </para>
+ </formalpara>
+ <para>
+ Dispatch is a low level API that requires clients to construct messages or message payloads as XML and requires an intimate knowledge of the desired message or payload structure. Dispatch is a generic class that supports input and output of messages or message payloads of any type.
+ </para>
<programlisting role="JAVA">
Service service = Service.create(wsdlURL, serviceName);
@@ -796,7 +801,7 @@
</section>
<section>
<title>Asynchronous Invocations</title>
- <para>The BindingProvider interface represents a component that provides a protocol binding for use by clients, it is implemented by proxies and is extended by the Dispatch interface.</para>
+ <para>The <classname>BindingProvider</classname> interface represents a component that provides a protocol binding for use by clients, it is implemented by proxies and is extended by the <classname>Dispatch</classname> interface.</para>
<!--<para>
<ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=Image:Binding-provider.gif">
@@ -808,7 +813,7 @@
</ulink>
</para>-->
- <para>BindingProvider instances may provide asynchronous operation capabilities. When used, asynchronous operation invocations are decoupled from the BindingProvider instance at invocation time such that the response context is not updated when the operation completes. Instead a separate response context is made available using the Response interface.</para>
+ <para><classname>BindingProvider</classname> instances may provide asynchronous operation capabilities. When used, asynchronous operation invocations are decoupled from the <classname>BindingProvider</classname> instance at invocation time such that the response context is not updated when the operation completes. Instead a separate response context is made available using the <classname>Response</classname> interface.</para>
<programlisting role="JAVA">
public void testInvokeAsync() throws Exception
@@ -828,7 +833,7 @@
</section>
<section>
<title>Oneway Invocations</title>
- <para>@Oneway indicates that the given web method has only an input message and no output. Typically, a oneway method returns the thread of control to the calling application prior to executing the actual business method.</para>
+ <para><property>@Oneway</property> indicates that the given web method has only an input message and no output. Typically, a oneway method returns the thread of control to the calling application prior to executing the actual business method.</para>
<programlisting role="JAVA">
@WebService (name="PingEndpoint")
@SOAPBinding(style = SOAPBinding.Style.RPC)
More information about the jboss-cvs-commits
mailing list