jboss-remoting-commits
August 2008
jboss-remoting-commits@lists.jboss.org
- 1 participants
- 86 discussions
JBoss Remoting SVN: r4520 - remoting2/branches/2.x/src/main/org/jboss/remoting/serialization/impl/java.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-08-30 02:21:08 -0400 (Sat, 30 Aug 2008)
New Revision: 4520
Added:
remoting2/branches/2.x/src/main/org/jboss/remoting/serialization/impl/java/ClearableObjectOutputStream.java
Log:
JBREM-1028: Extends ObjectOutputStream and exposes clear().
Added: remoting2/branches/2.x/src/main/org/jboss/remoting/serialization/impl/java/ClearableObjectOutputStream.java
===================================================================
--- remoting2/branches/2.x/src/main/org/jboss/remoting/serialization/impl/java/ClearableObjectOutputStream.java (rev 0)
+++ remoting2/branches/2.x/src/main/org/jboss/remoting/serialization/impl/java/ClearableObjectOutputStream.java 2008-08-30 06:21:08 UTC (rev 4520)
@@ -0,0 +1,78 @@
+
+/*
+* JBoss, Home of Professional Open Source
+* Copyright 2005, JBoss Inc., and individual contributors as indicated
+* by the @authors tag. See the copyright.txt in the distribution for a
+* full listing of individual contributors.
+*
+* This is free software; you can redistribute it and/or modify it
+* under the terms of the GNU Lesser General Public License as
+* published by the Free Software Foundation; either version 2.1 of
+* the License, or (at your option) any later version.
+*
+* This software is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+* Lesser General Public License for more details.
+*
+* You should have received a copy of the GNU Lesser General Public
+* License along with this software; if not, write to the Free
+* Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+* 02110-1301 USA, or see the FSF site: http://www.fsf.org.
+*/
+package org.jboss.remoting.serialization.impl.java;
+
+import java.io.IOException;
+import java.io.ObjectOutputStream;
+import java.io.OutputStream;
+import java.lang.reflect.Method;
+
+import org.jboss.logging.Logger;
+import org.jboss.remoting.util.SecurityUtility;
+
+/**
+ * @author <a href="ron.sigal(a)jboss.com">Ron Sigal</a>
+ * @version $Revision: 1.1 $
+ * <p>
+ * Copyright Aug 27, 2008
+ * </p>
+ */
+public class ClearableObjectOutputStream extends ObjectOutputStream
+{
+ protected static Logger log = Logger.getLogger(ClearableObjectOutputStream.class);
+ protected static Method clearMethod;
+
+ static
+ {
+ try
+ {
+ clearMethod = SecurityUtility.getDeclaredMethod(ObjectOutputStream.class, "clear", new Class[]{});
+ }
+ catch (SecurityException e)
+ {
+ log.error(e.getMessage(), e);
+ }
+ catch (NoSuchMethodException e)
+ {
+ log.error(e.getMessage(), e);
+ }
+ }
+
+ public ClearableObjectOutputStream(OutputStream out) throws IOException
+ {
+ super(out);
+ }
+
+ public void clear()
+ {
+ try
+ {
+ clearMethod.invoke(this, new Object[]{});
+ }
+ catch (Throwable e)
+ {
+ log.error(e.getMessage(), e);
+ }
+ }
+}
+
16 years, 3 months
- 1
- 0
JBoss Remoting SVN: r4519 - remoting2/branches/2.x/src/main/org/jboss/remoting/serialization/impl/java.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-08-30 02:20:07 -0400 (Sat, 30 Aug 2008)
New Revision: 4519
Modified:
remoting2/branches/2.x/src/main/org/jboss/remoting/serialization/impl/java/JavaSerializationManager.java
Log:
JBREM-1028: Uses ClearableObjectOutputStream.
Modified: remoting2/branches/2.x/src/main/org/jboss/remoting/serialization/impl/java/JavaSerializationManager.java
===================================================================
--- remoting2/branches/2.x/src/main/org/jboss/remoting/serialization/impl/java/JavaSerializationManager.java 2008-08-29 01:18:58 UTC (rev 4518)
+++ remoting2/branches/2.x/src/main/org/jboss/remoting/serialization/impl/java/JavaSerializationManager.java 2008-08-30 06:20:07 UTC (rev 4519)
@@ -60,7 +60,7 @@
{
log.trace("Creating ObjectOutputStream");
}
- return new ObjectOutputStream(output);
+ return new ClearableObjectOutputStream(output);
}
/**
@@ -119,6 +119,11 @@
oos.reset();
oos.writeObject(dataObject);
oos.flush();
+
+ if (oos instanceof ClearableObjectOutputStream)
+ {
+ ((ClearableObjectOutputStream) oos).clear();
+ }
}
public Object receiveObject(InputStream inputStream, ClassLoader customClassLoader, int version) throws IOException, ClassNotFoundException
16 years, 3 months
- 1
- 0
JBoss Remoting SVN: r4518 - in remoting2/branches/2.x/src/tests/org/jboss/test/remoting/transport/http: query and 1 other directory.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-08-28 21:18:58 -0400 (Thu, 28 Aug 2008)
New Revision: 4518
Added:
remoting2/branches/2.x/src/tests/org/jboss/test/remoting/transport/http/query/
remoting2/branches/2.x/src/tests/org/jboss/test/remoting/transport/http/query/URLQueryTestCase.java
Log:
JBREM-1027: New unit test.
Added: remoting2/branches/2.x/src/tests/org/jboss/test/remoting/transport/http/query/URLQueryTestCase.java
===================================================================
--- remoting2/branches/2.x/src/tests/org/jboss/test/remoting/transport/http/query/URLQueryTestCase.java (rev 0)
+++ remoting2/branches/2.x/src/tests/org/jboss/test/remoting/transport/http/query/URLQueryTestCase.java 2008-08-29 01:18:58 UTC (rev 4518)
@@ -0,0 +1,167 @@
+/*
+* JBoss, Home of Professional Open Source
+* Copyright 2005, JBoss Inc., and individual contributors as indicated
+* by the @authors tag. See the copyright.txt in the distribution for a
+* full listing of individual contributors.
+*
+* This is free software; you can redistribute it and/or modify it
+* under the terms of the GNU Lesser General Public License as
+* published by the Free Software Foundation; either version 2.1 of
+* the License, or (at your option) any later version.
+*
+* This software is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+* Lesser General Public License for more details.
+*
+* You should have received a copy of the GNU Lesser General Public
+* License along with this software; if not, write to the Free
+* Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+* 02110-1301 USA, or see the FSF site: http://www.fsf.org.
+*/
+package org.jboss.test.remoting.transport.http.query;
+
+import java.net.InetAddress;
+import java.util.HashMap;
+import java.util.Map;
+
+import javax.management.MBeanServer;
+
+import junit.framework.TestCase;
+
+import org.apache.log4j.ConsoleAppender;
+import org.apache.log4j.Level;
+import org.apache.log4j.Logger;
+import org.apache.log4j.PatternLayout;
+import org.jboss.logging.XLevel;
+import org.jboss.remoting.Client;
+import org.jboss.remoting.InvocationRequest;
+import org.jboss.remoting.InvokerLocator;
+import org.jboss.remoting.ServerInvocationHandler;
+import org.jboss.remoting.ServerInvoker;
+import org.jboss.remoting.callback.InvokerCallbackHandler;
+import org.jboss.remoting.transport.Connector;
+import org.jboss.remoting.transport.PortUtil;
+import org.jboss.remoting.transport.http.HTTPMetadataConstants;
+
+
+/**
+ * Unit test for JBREM-1027.
+ *
+ * @author <a href="ron.sigal(a)jboss.com">Ron Sigal</a>
+ * @version $Revision: 1.1 $
+ * <p>
+ * Copyright Aug 28, 2008
+ * </p>
+ */
+public class URLQueryTestCase extends TestCase
+{
+ private static Logger log = Logger.getLogger(URLQueryTestCase.class);
+
+ private static boolean firstTime = true;
+ protected static final String QUERY = "a=y&b=z";
+
+ protected String host;
+ protected int port;
+ protected String locatorURI;
+ protected InvokerLocator serverLocator;
+ protected Connector connector;
+ protected TestInvocationHandler invocationHandler;
+
+
+ public void setUp() throws Exception
+ {
+ if (firstTime)
+ {
+ firstTime = false;
+ Logger.getLogger("org.jboss.remoting").setLevel(XLevel.INFO);
+ Logger.getLogger("org.jboss.test.remoting").setLevel(Level.INFO);
+ String pattern = "[%d{ABSOLUTE}] [%t] %5p (%F:%L) - %m%n";
+ PatternLayout layout = new PatternLayout(pattern);
+ ConsoleAppender consoleAppender = new ConsoleAppender(layout);
+ Logger.getRootLogger().addAppender(consoleAppender);
+ }
+ }
+
+
+ public void tearDown()
+ {
+ }
+
+
+ public void testQueryInRequestMap() throws Throwable
+ {
+ log.info("entering " + getName());
+
+ // Start server.
+ setupServer();
+
+ // Create client.
+ InvokerLocator clientLocator = new InvokerLocator(locatorURI);
+ HashMap clientConfig = new HashMap();
+ clientConfig.put(InvokerLocator.FORCE_REMOTE, "true");
+ addExtraClientConfig(clientConfig);
+ Client client = new Client(clientLocator, clientConfig);
+ client.connect();
+ log.info("client is connected");
+
+ // Test connections.
+ Object response = client.invoke("abc");
+ log.info("response: " + response);
+ assertEquals(QUERY, response);
+
+ client.disconnect();
+ shutdownServer();
+ log.info(getName() + " PASSES");
+ }
+
+
+ protected String getTransport()
+ {
+ return "http";
+ }
+
+
+ protected void addExtraClientConfig(Map config) {}
+ protected void addExtraServerConfig(Map config) {}
+
+
+ protected void setupServer() throws Exception
+ {
+ host = InetAddress.getLocalHost().getHostAddress();
+ port = PortUtil.findFreePort(host);
+ locatorURI = getTransport() + "://" + host + ":" + port + "/?" + QUERY;
+ serverLocator = new InvokerLocator(locatorURI);
+ log.info("Starting remoting server with locator uri of: " + locatorURI);
+ HashMap config = new HashMap();
+ config.put(InvokerLocator.FORCE_REMOTE, "true");
+ addExtraServerConfig(config);
+ connector = new Connector(serverLocator, config);
+ connector.create();
+ invocationHandler = new TestInvocationHandler();
+ connector.addInvocationHandler("test", invocationHandler);
+ connector.start();
+ }
+
+
+ protected void shutdownServer() throws Exception
+ {
+ if (connector != null)
+ connector.stop();
+ }
+
+
+ static class TestInvocationHandler implements ServerInvocationHandler
+ {
+ public void addListener(InvokerCallbackHandler callbackHandler) {}
+ public Object invoke(final InvocationRequest invocation) throws Throwable
+ {
+ Map requestMap = invocation.getRequestPayload();
+ log.info("query: " + requestMap.get(HTTPMetadataConstants.QUERY));
+ return requestMap.get(HTTPMetadataConstants.QUERY);
+ }
+ public void removeListener(InvokerCallbackHandler callbackHandler) {}
+ public void setMBeanServer(MBeanServer server) {}
+ public void setInvoker(ServerInvoker invoker) {}
+ }
+}
\ No newline at end of file
16 years, 3 months
- 1
- 0
JBoss Remoting SVN: r4517 - remoting2/branches/2.x/src/main/org/jboss/remoting/transport/coyote.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-08-28 21:17:28 -0400 (Thu, 28 Aug 2008)
New Revision: 4517
Modified:
remoting2/branches/2.x/src/main/org/jboss/remoting/transport/coyote/CoyoteInvoker.java
Log:
JBREM-1027: Puts QUERY in InvocationRequest request map.
Modified: remoting2/branches/2.x/src/main/org/jboss/remoting/transport/coyote/CoyoteInvoker.java
===================================================================
--- remoting2/branches/2.x/src/main/org/jboss/remoting/transport/coyote/CoyoteInvoker.java 2008-08-29 01:16:55 UTC (rev 4516)
+++ remoting2/branches/2.x/src/main/org/jboss/remoting/transport/coyote/CoyoteInvoker.java 2008-08-29 01:17:28 UTC (rev 4517)
@@ -630,6 +630,7 @@
metadata.put(HTTPMetadataConstants.METHODTYPE, req.method().getString());
metadata.put(HTTPMetadataConstants.PATH, req.requestURI().getString());
+ metadata.put(HTTPMetadataConstants.QUERY, req.query().toString());
metadata.put(HTTPMetadataConstants.HTTPVERSION, req.protocol().getString());
}
16 years, 3 months
- 1
- 0
JBoss Remoting SVN: r4516 - remoting2/branches/2.x/src/main/org/jboss/remoting/transport/http.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-08-28 21:16:55 -0400 (Thu, 28 Aug 2008)
New Revision: 4516
Modified:
remoting2/branches/2.x/src/main/org/jboss/remoting/transport/http/HTTPMetadataConstants.java
Log:
JBREM-1027: Added QUERY.
Modified: remoting2/branches/2.x/src/main/org/jboss/remoting/transport/http/HTTPMetadataConstants.java
===================================================================
--- remoting2/branches/2.x/src/main/org/jboss/remoting/transport/http/HTTPMetadataConstants.java 2008-08-27 15:30:54 UTC (rev 4515)
+++ remoting2/branches/2.x/src/main/org/jboss/remoting/transport/http/HTTPMetadataConstants.java 2008-08-29 01:16:55 UTC (rev 4516)
@@ -33,6 +33,7 @@
{
public static final String METHODTYPE = "MethodType";
public static final String PATH = "Path";
+ public static final String QUERY = "Query";
public static final String HTTPVERSION = "HttpVersion";
public static final String RESPONSE_CODE = "ResponseCode";
public static final String CONTENTTYPE = "Content-Type";
16 years, 3 months
- 1
- 0
JBoss Remoting SVN: r4515 - in remoting3/trunk: protocol/basic/src/test/java/org/jboss/cx/remoting/protocol/basic and 1 other directories.
by jboss-remoting-commits＠lists.jboss.org
Author: david.lloyd(a)jboss.com
Date: 2008-08-27 11:30:54 -0400 (Wed, 27 Aug 2008)
New Revision: 4515
Removed:
remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/Connection.java
remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/ServiceRegistry.java
remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/ServiceRegistryImpl.java
Modified:
remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/AbstractConnection.java
remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/BasicHandler.java
remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/BasicProtocol.java
remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/ConnectionListener.java
remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/MessageType.java
remoting3/trunk/protocol/basic/src/test/java/org/jboss/cx/remoting/protocol/basic/ConnectionTestCase.java
remoting3/trunk/standalone/src/main/java/org/jboss/cx/remoting/Remoting.java
Log:
Pause here for a moment before ripping out marshalling stuff...
Modified: remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/AbstractConnection.java
===================================================================
--- remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/AbstractConnection.java 2008-08-13 06:02:45 UTC (rev 4514)
+++ remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/AbstractConnection.java 2008-08-27 15:30:54 UTC (rev 4515)
@@ -22,13 +22,13 @@
package org.jboss.cx.remoting.protocol.basic;
-import org.jboss.cx.remoting.spi.AbstractHandleableCloseable;
+import org.jboss.cx.remoting.spi.AbstractSimpleCloseable;
import java.util.concurrent.Executor;
/**
*
*/
-public abstract class AbstractConnection extends AbstractHandleableCloseable<Connection> implements Connection {
+public abstract class AbstractConnection extends AbstractSimpleCloseable {
/**
* Basic constructor.
*
Modified: remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/BasicHandler.java
===================================================================
--- remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/BasicHandler.java 2008-08-13 06:02:45 UTC (rev 4514)
+++ remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/BasicHandler.java 2008-08-27 15:30:54 UTC (rev 4515)
@@ -52,7 +52,10 @@
import static org.jboss.cx.remoting.protocol.basic.MessageType.REQUEST_FAILED;
import static org.jboss.cx.remoting.protocol.basic.MessageType.CANCEL_ACK;
import static org.jboss.cx.remoting.protocol.basic.MessageType.VERSION;
+import static org.jboss.cx.remoting.protocol.basic.MessageType.SERVICE_ADVERTISE;
+import static org.jboss.cx.remoting.protocol.basic.MessageType.SERVICE_UNADVERTISE;
import org.jboss.cx.remoting.CloseHandler;
+import org.jboss.cx.remoting.Endpoint;
import java.util.concurrent.ConcurrentMap;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.Executor;
@@ -71,16 +74,20 @@
public final class BasicHandler implements IoHandler<AllocatedMessageChannel> {
private static final Logger log = Logger.getLogger(BasicHandler.class);
- private static final int LOCAL_VERSION = 1;
+ private static final int LOCAL_VERSION = 0x00000100;
+ // running on remote node
+ private final ConcurrentMap<Integer, ReplyHandler> outstandingRequests = concurrentMap();
+
// clients whose requests get forwarded to the remote side
private final ConcurrentMap<Integer, RequestHandler> remoteClients = concurrentMap();
- // running on remote node
- private final ConcurrentMap<Integer, ReplyHandler> outstandingRequests = concurrentMap();
// forwarded to remote side (handled on this side)
private final ConcurrentMap<Integer, Handle<RequestHandler>> forwardedClients = concurrentMap();
- private final ServiceRegistry registry;
+ // services forwarded to us
+ private final ConcurrentMap<Integer, RequestHandlerSource> remoteServices = concurrentMap();
+ // forwarded to remote side (handled on this side)
+ private final ConcurrentMap<Integer, Handle<RequestHandlerSource>> forwardedServices = concurrentMap();
private final boolean server;
private final BufferAllocator<ByteBuffer> allocator;
@@ -94,13 +101,13 @@
private final ClassLoader classLoader;
private List<String> localMarshallerList = Collections.singletonList("java-serialization");
private volatile String marshallerType;
+ private volatile int metric;
private final AtomicBoolean initialized = new AtomicBoolean(false);
- public BasicHandler(final boolean server, final BufferAllocator<ByteBuffer> allocator, final Executor executor, final MarshallerFactory<ByteBuffer> marshallerFactory, final ServiceRegistry registry) {
+ public BasicHandler(final boolean server, final BufferAllocator<ByteBuffer> allocator, final Executor executor, final MarshallerFactory<ByteBuffer> marshallerFactory) {
this.server = server;
this.allocator = allocator;
this.executor = executor;
- this.registry = registry;
final RequestHandlerImpl endpoint = new RequestHandlerImpl(0, allocator);
remoteClients.put(Integer.valueOf(0), endpoint);
this.marshallerFactory = marshallerFactory;
@@ -116,11 +123,11 @@
/**
* Sequence number of local clients forwarded to the remote side.
*/
- private final AtomicInteger localClientIdSeq = new AtomicInteger(1);
+ private final AtomicInteger localClientIdSeq = new AtomicInteger();
/**
* Sequence number of remote clients opened locally from services from the remote side.
*/
- private final AtomicInteger remoteClientIdSeq = new AtomicInteger(1);
+ private final AtomicInteger remoteClientIdSeq = new AtomicInteger();
public void handleOpened(final AllocatedMessageChannel channel) {
if (isnew.getAndSet(false)) {
@@ -335,6 +342,26 @@
registry.unbind(buffer.getInt());
break;
}
+ case SERVICE_ADVERTISE: {
+ final int serviceId = buffer.getInt();
+ final String serviceType = readUTFZ(buffer);
+ final String groupName = readUTFZ(buffer);
+ final String endpointName = readUTFZ(buffer);
+ final int baseMetric = buffer.getInt();
+ Endpoint endpoint;
+ int id;
+ final RequestHandlerSource handlerSource = new RequestHandlerSourceImpl(allocator, id);
+ final int calcMetric = baseMetric + metric;
+ if (calcMetric > 0) {
+ endpoint.registerRemoteService(serviceType, groupName, endpointName, handlerSource, calcMetric);
+ }
+ break;
+ }
+ case SERVICE_UNADVERTISE: {
+ final int serviceId = buffer.getInt();
+ IoUtils.safeClose(remoteServices.get(Integer.valueOf(serviceId)));
+ break;
+ }
default: {
log.trace("Received invalid message type %d", Integer.valueOf(msgType));
}
Modified: remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/BasicProtocol.java
===================================================================
--- remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/BasicProtocol.java 2008-08-13 06:02:45 UTC (rev 4514)
+++ remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/BasicProtocol.java 2008-08-27 15:30:54 UTC (rev 4515)
@@ -23,6 +23,7 @@
package org.jboss.cx.remoting.protocol.basic;
import org.jboss.cx.remoting.RemotingException;
+import org.jboss.cx.remoting.SimpleCloseable;
import org.jboss.cx.remoting.spi.remote.RequestHandlerSource;
import org.jboss.cx.remoting.spi.remote.Handle;
import org.jboss.cx.remoting.core.marshal.JavaSerializationMarshallerFactory;
@@ -55,10 +56,10 @@
* @param allocator the buffer allocator to use
* @return a handler factory for passing to an XNIO server
*/
- public static IoHandlerFactory<AllocatedMessageChannel> createServer(final Executor executor, final BufferAllocator<ByteBuffer> allocator, final ServiceRegistry serviceRegistry) {
+ public static IoHandlerFactory<AllocatedMessageChannel> createServer(final Executor executor, final BufferAllocator<ByteBuffer> allocator) {
return new IoHandlerFactory<AllocatedMessageChannel>() {
public IoHandler<? super AllocatedMessageChannel> createHandler() {
- return new BasicHandler(true, allocator, executor, new JavaSerializationMarshallerFactory(executor), serviceRegistry);
+ return new BasicHandler(true, allocator, executor, new JavaSerializationMarshallerFactory(executor));
}
};
}
@@ -69,15 +70,14 @@
* @param executor the executor to use for invocations
* @param channelSource the XNIO channel source to use to establish the connection
* @param allocator the buffer allocator to use
- * @param serviceRegistry the service registry
* @return a handle which may be used to close the connection
* @throws IOException if an error occurs
*/
- public static IoFuture<Connection> connect(final Executor executor, final ChannelSource<AllocatedMessageChannel> channelSource, final BufferAllocator<ByteBuffer> allocator, final ServiceRegistry serviceRegistry) throws IOException {
- final BasicHandler basicHandler = new BasicHandler(false, allocator, executor, new JavaSerializationMarshallerFactory(executor), serviceRegistry);
+ public static IoFuture<SimpleCloseable> connect(final Executor executor, final ChannelSource<AllocatedMessageChannel> channelSource, final BufferAllocator<ByteBuffer> allocator) throws IOException {
+ final BasicHandler basicHandler = new BasicHandler(false, allocator, executor, new JavaSerializationMarshallerFactory(executor));
final IoFuture<AllocatedMessageChannel> futureChannel = channelSource.open(basicHandler);
- return new AbstractConvertingIoFuture<Connection, AllocatedMessageChannel>(futureChannel) {
- protected Connection convert(final AllocatedMessageChannel channel) throws RemotingException {
+ return new AbstractConvertingIoFuture<SimpleCloseable, AllocatedMessageChannel>(futureChannel) {
+ protected SimpleCloseable convert(final AllocatedMessageChannel channel) throws RemotingException {
return new AbstractConnection(executor) {
public Handle<RequestHandlerSource> getServiceForId(final int id) throws IOException {
return basicHandler.getRemoteService(id).getHandle();
Deleted: remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/Connection.java
===================================================================
--- remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/Connection.java 2008-08-13 06:02:45 UTC (rev 4514)
+++ remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/Connection.java 2008-08-27 15:30:54 UTC (rev 4515)
@@ -1,36 +0,0 @@
-/*
- * JBoss, Home of Professional Open Source
- * Copyright 2008, JBoss Inc., and individual contributors as indicated
- * by the @authors tag. See the copyright.txt in the distribution for a
- * full listing of individual contributors.
- *
- * This is free software; you can redistribute it and/or modify it
- * under the terms of the GNU Lesser General Public License as
- * published by the Free Software Foundation; either version 2.1 of
- * the License, or (at your option) any later version.
- *
- * This software is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this software; if not, write to the Free
- * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
- */
-
-package org.jboss.cx.remoting.protocol.basic;
-
-import org.jboss.cx.remoting.spi.remote.RequestHandlerSource;
-import org.jboss.cx.remoting.spi.remote.Handle;
-import org.jboss.cx.remoting.HandleableCloseable;
-import org.jboss.cx.remoting.RemotingException;
-import java.io.IOException;
-
-/**
- *
- */
-public interface Connection extends HandleableCloseable<Connection> {
- Handle<RequestHandlerSource> getServiceForId(int id) throws IOException;
-}
Modified: remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/ConnectionListener.java
===================================================================
--- remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/ConnectionListener.java 2008-08-13 06:02:45 UTC (rev 4514)
+++ remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/ConnectionListener.java 2008-08-27 15:30:54 UTC (rev 4515)
@@ -22,9 +22,11 @@
package org.jboss.cx.remoting.protocol.basic;
+import org.jboss.cx.remoting.SimpleCloseable;
+
/**
*
*/
public interface ConnectionListener {
- void handleOpened(Connection connection);
+ void handleOpened(SimpleCloseable connection);
}
Modified: remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/MessageType.java
===================================================================
--- remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/MessageType.java 2008-08-13 06:02:45 UTC (rev 4514)
+++ remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/MessageType.java 2008-08-27 15:30:54 UTC (rev 4515)
@@ -26,12 +26,19 @@
*
*/
public final class MessageType {
+ // Initial version & marshaller negotiation
public static final int VERSION = 0;
+ // One-way request, no return value may be sent
public static final int REQUEST_ONEWAY = 1;
+ // Two-way request, return value is expected
public static final int REQUEST = 2;
+ // Reply
public static final int REPLY = 3;
+ // Attempt to cancel a request
public static final int CANCEL_REQUEST = 4;
+ // Acknowledge that a request was cancelled
public static final int CANCEL_ACK = 5;
+ // Request failed due to exception
public static final int REQUEST_FAILED = 6;
// Remote side called .close() on a forwarded RequestHandler
public static final int CLIENT_CLOSE = 7;
Deleted: remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/ServiceRegistry.java
===================================================================
--- remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/ServiceRegistry.java 2008-08-13 06:02:45 UTC (rev 4514)
+++ remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/ServiceRegistry.java 2008-08-27 15:30:54 UTC (rev 4515)
@@ -1,43 +0,0 @@
-/*
- * JBoss, Home of Professional Open Source
- * Copyright 2008, JBoss Inc., and individual contributors as indicated
- * by the @authors tag. See the copyright.txt in the distribution for a
- * full listing of individual contributors.
- *
- * This is free software; you can redistribute it and/or modify it
- * under the terms of the GNU Lesser General Public License as
- * published by the Free Software Foundation; either version 2.1 of
- * the License, or (at your option) any later version.
- *
- * This software is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this software; if not, write to the Free
- * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
- */
-
-package org.jboss.cx.remoting.protocol.basic;
-
-import org.jboss.cx.remoting.spi.remote.RequestHandlerSource;
-import org.jboss.cx.remoting.spi.remote.Handle;
-import org.jboss.cx.remoting.RemotingException;
-import java.io.IOException;
-
-/**
- *
- */
-public interface ServiceRegistry {
- int bind(RequestHandlerSource requestHandlerSource) throws IOException;
-
- void bind(RequestHandlerSource requestHandlerSource, int id) throws IOException;
-
- void unbind(int id) throws RemotingException;
-
- void clear();
-
- Handle<RequestHandlerSource> lookup(int id) throws IOException;
-}
Deleted: remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/ServiceRegistryImpl.java
===================================================================
--- remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/ServiceRegistryImpl.java 2008-08-13 06:02:45 UTC (rev 4514)
+++ remoting3/trunk/protocol/basic/src/main/java/org/jboss/cx/remoting/protocol/basic/ServiceRegistryImpl.java 2008-08-27 15:30:54 UTC (rev 4515)
@@ -1,112 +0,0 @@
-/*
- * JBoss, Home of Professional Open Source
- * Copyright 2008, JBoss Inc., and individual contributors as indicated
- * by the @authors tag. See the copyright.txt in the distribution for a
- * full listing of individual contributors.
- *
- * This is free software; you can redistribute it and/or modify it
- * under the terms of the GNU Lesser General Public License as
- * published by the Free Software Foundation; either version 2.1 of
- * the License, or (at your option) any later version.
- *
- * This software is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this software; if not, write to the Free
- * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
- */
-
-package org.jboss.cx.remoting.protocol.basic;
-
-import org.jboss.cx.remoting.spi.remote.RequestHandlerSource;
-import org.jboss.cx.remoting.spi.remote.Handle;
-import org.jboss.cx.remoting.RemotingException;
-import org.jboss.cx.remoting.util.CollectionUtil;
-import org.jboss.xnio.IoUtils;
-import java.util.concurrent.ConcurrentMap;
-import java.util.concurrent.atomic.AtomicInteger;
-import java.util.Iterator;
-import java.io.IOException;
-
-/**
- *
- */
-public final class ServiceRegistryImpl implements ServiceRegistry {
-
- private static final int START = 32768;
-
- private final ConcurrentMap<Integer, Handle<RequestHandlerSource>> map = CollectionUtil.concurrentMap();
- private final AtomicInteger dynamicSequence = new AtomicInteger(START);
- private final ServiceRegistry parent;
-
- public ServiceRegistryImpl(final ServiceRegistry parent) {
- this.parent = parent;
- }
-
- public ServiceRegistryImpl() {
- parent = null;
- }
-
- public int bind(final RequestHandlerSource requestHandlerSource) throws IOException {
- final Handle<RequestHandlerSource> handle = requestHandlerSource.getHandle();
- boolean ok = false;
- try {
- for (;;) {
- final int seqVal = dynamicSequence.getAndIncrement();
- if (seqVal < 0) {
- dynamicSequence.compareAndSet(seqVal, START);
- continue;
- }
- if (map.putIfAbsent(Integer.valueOf(seqVal), handle) != null) {
- ok = true;
- return seqVal;
- }
- }
- } finally {
- if (! ok) {
- IoUtils.safeClose(handle);
- }
- }
- }
-
- public void bind(final RequestHandlerSource requestHandlerSource, final int id) throws IOException {
- final Handle<RequestHandlerSource> handle = requestHandlerSource.getHandle();
- boolean ok = false;
- try {
- if (map.putIfAbsent(Integer.valueOf(id), handle) != null) {
- throw new RemotingException("Service already bound to that ID");
- }
- ok = true;
- } finally {
- if (! ok) {
- IoUtils.safeClose(handle);
- }
- }
- }
-
- public void unbind(final int id) throws RemotingException {
- map.remove(Integer.valueOf(id));
- }
-
- public void clear() {
- Iterator<Handle<RequestHandlerSource>> it = map.values().iterator();
- while (it.hasNext()) {
- IoUtils.safeClose(it.next());
- it.remove();
- }
- }
-
- public Handle<RequestHandlerSource> lookup(final int id) throws IOException {
- final Handle<RequestHandlerSource> handle = map.get(Integer.valueOf(id));
- return handle != null || parent == null ? handle.getResource().getHandle() : parent.lookup(id);
- }
-
- protected void finalize() throws Throwable {
- clear();
- super.finalize();
- }
-}
Modified: remoting3/trunk/protocol/basic/src/test/java/org/jboss/cx/remoting/protocol/basic/ConnectionTestCase.java
===================================================================
--- remoting3/trunk/protocol/basic/src/test/java/org/jboss/cx/remoting/protocol/basic/ConnectionTestCase.java 2008-08-13 06:02:45 UTC (rev 4514)
+++ remoting3/trunk/protocol/basic/src/test/java/org/jboss/cx/remoting/protocol/basic/ConnectionTestCase.java 2008-08-27 15:30:54 UTC (rev 4515)
@@ -39,6 +39,7 @@
import org.jboss.cx.remoting.ClientSource;
import org.jboss.cx.remoting.Client;
import org.jboss.cx.remoting.AbstractRequestListener;
+import org.jboss.cx.remoting.SimpleCloseable;
import org.jboss.cx.remoting.spi.remote.RequestHandlerSource;
import org.jboss.cx.remoting.spi.remote.Handle;
import org.jboss.xnio.BufferAllocator;
@@ -83,7 +84,6 @@
endpoint.setExecutor(closeableExecutor);
endpoint.start();
try {
- final ServiceRegistry serviceRegistry = new ServiceRegistryImpl();
try {
final Handle<RequestHandlerSource> requestHandlerSourceHandle = endpoint.createRequestHandlerSource(new AbstractRequestListener<Object, Object>() {
public void handleRequest(final RequestContext<Object> context, final Object request) throws RemoteExecutionException {
@@ -96,7 +96,7 @@
}, null, null);
try {
serviceRegistry.bind(requestHandlerSourceHandle.getResource(), 13);
- final IoHandlerFactory<AllocatedMessageChannel> handlerFactory = BasicProtocol.createServer(closeableExecutor, allocator, serviceRegistry);
+ final IoHandlerFactory<AllocatedMessageChannel> handlerFactory = BasicProtocol.createServer(closeableExecutor, allocator);
final IoHandlerFactory<StreamChannel> newHandlerFactory = Channels.convertStreamToAllocatedMessage(handlerFactory, 32768, 32768);
final Closeable tcpServerCloseable = xnio.createTcpServer(newHandlerFactory, new InetSocketAddress(12345)).create();
try {
@@ -104,8 +104,8 @@
try {
final TcpClient tcpClient = connector.createChannelSource(new InetSocketAddress("localhost", 12345));
final ChannelSource<AllocatedMessageChannel> channelSource = Channels.convertStreamToAllocatedMessage(tcpClient, 32768, 32768);
- final IoFuture<Connection> futureCloseable = BasicProtocol.connect(closeableExecutor, channelSource, allocator, serviceRegistry);
- final Connection connection = futureCloseable.get();
+ final IoFuture<SimpleCloseable> futureCloseable = BasicProtocol.connect(closeableExecutor, channelSource, allocator);
+ final SimpleCloseable connection = futureCloseable.get();
try {
final Handle<RequestHandlerSource> handleThirteen = connection.getServiceForId(13);
try {
Modified: remoting3/trunk/standalone/src/main/java/org/jboss/cx/remoting/Remoting.java
===================================================================
--- remoting3/trunk/standalone/src/main/java/org/jboss/cx/remoting/Remoting.java 2008-08-13 06:02:45 UTC (rev 4514)
+++ remoting3/trunk/standalone/src/main/java/org/jboss/cx/remoting/Remoting.java 2008-08-27 15:30:54 UTC (rev 4515)
@@ -41,8 +41,8 @@
}
}
- public static <I, O> ClientSource<I, O> createLocalClientSource(Endpoint endpoint, RequestListener<I, O> requestListener) throws IOException {
- final Handle<RequestHandlerSource> handle = endpoint.createRequestHandlerSource(requestListener, INIT_ME, INIT_ME);
+ public static <I, O> ClientSource<I, O> createLocalClientSource(Endpoint endpoint, RequestListener<I, O> requestListener, final String serviceType, final String groupName) throws IOException {
+ final Handle<RequestHandlerSource> handle = endpoint.createRequestHandlerSource(requestListener, serviceType, groupName);
try {
return endpoint.createClientSource(handle.getResource());
} finally {
16 years, 4 months
- 1
- 0
JBoss Remoting SVN: r4514 - remoting2/tags/2.4.0-SP1/docs/guide/en.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-08-13 02:02:45 -0400 (Wed, 13 Aug 2008)
New Revision: 4514
Modified:
remoting2/tags/2.4.0-SP1/docs/guide/en/chap15.xml
Log:
JBREM-1025: Fixed guide files mixup in tag 2.4.0.SP1.
Modified: remoting2/tags/2.4.0-SP1/docs/guide/en/chap15.xml
===================================================================
--- remoting2/tags/2.4.0-SP1/docs/guide/en/chap15.xml 2008-08-13 06:00:06 UTC (rev 4513)
+++ remoting2/tags/2.4.0-SP1/docs/guide/en/chap15.xml 2008-08-13 06:02:45 UTC (rev 4514)
@@ -1,4 +1,4 @@
- <chapter>
+ <chapter>
<title>Known issues</title>
<para>All of the known issues and road map can be found on our bug
16 years, 4 months
- 1
- 0
JBoss Remoting SVN: r4513 - remoting2/tags/2.4.0-SP1/docs/guide/en.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-08-13 02:00:06 -0400 (Wed, 13 Aug 2008)
New Revision: 4513
Modified:
remoting2/tags/2.4.0-SP1/docs/guide/en/chap10.xml
remoting2/tags/2.4.0-SP1/docs/guide/en/chap12.xml
remoting2/tags/2.4.0-SP1/docs/guide/en/chap15.xml
remoting2/tags/2.4.0-SP1/docs/guide/en/chap7.xml
Log:
JBREM-1025: Fixed guide files mixup in tag 2.4.0.SP1.
Modified: remoting2/tags/2.4.0-SP1/docs/guide/en/chap10.xml
===================================================================
--- remoting2/tags/2.4.0-SP1/docs/guide/en/chap10.xml 2008-08-12 07:23:58 UTC (rev 4512)
+++ remoting2/tags/2.4.0-SP1/docs/guide/en/chap10.xml 2008-08-13 06:00:06 UTC (rev 4513)
@@ -1,2634 +1,19 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<chapter>
- <title>How to use it - sample code</title>
+ <chapter>
+ <title>Transporters - beaming POJOs</title>
- <para>Sample code demonstrating different remoting features can be found in
- the examples directory. They can be compiled and run manually via your IDE
- or via an ant build file found in the examples directory. There are many
- sets of sample code, each with their own package. Within most of these
- packages, there will be a server and a client class that will need to be
- executed</para>
+ <para>There are many ways in which to expose a remote interface to a java
+ object. Some require a complex framework API based on a standard
+ specification and some require new technologies like annotations and AOP.
+ Each of these have their own benefits. JBoss Remoting transporters provide
+ the same behavior via a simple API without the need for any of the newer
+ technologies.</para>
- <section>
- <title>Simple invocation</title>
-
- <para>The simple invocation sample (found in the
- org.jboss.remoting.samples.simple package), has two classes; SimpleClient
- and SimpleServer. It demonstrates making a simple invocation from a
- remoting client to a remoting server. The SimpleClient class will create
- an InvokerLocator object from a simple url-like string that identifies the
- remoting server to call upon (which will be socket://localhost:5400 by
- default). Then the SimpleClient will create a remoting Client class,
- passing the newly created InvokerLocator. Next the Client will be called
- to make an invocation on the remoting server, passing the request payload
- object (which is a String with the value of "Do something"). The server
- will return a response from this call which is printed to standard
- output.</para>
-
- <para>Within the SimpleServer, a remoting server is created and started.
- This is done by first creating an InvokerLocator, just like was done in
- the SimpleClient. Then constructing a Connector, passing the
- InvokerLocator. Next, need to call create() on the Connector to initialize
- all the resources, such as the remoting server invoker. Once created, need
- to create the invocation handler. The invocation handler is the class that
- the remoting server will pass client requests on to. The invocation
- handler in this sample simply returns the simple String "This is the
- return to SampleInvocationHandler invocation". Once created, the handler
- is added to the Connector. Finally, the Connector is started and will
- start listening for incoming client requests.</para>
-
- <para>To run this example, can compile both the SimpleClient and
- SimpleServer class, then first run the SimpleServer and then the
- SimpleClient. Or can go to the examples directory and run the ant target
- 'run-simple-server' and then in another console window run the ant target
- 'run-simple-client'. For example:</para>
-
- <para><programlisting>ant run-simple-server</programlisting>ant
- then:</para>
-
- <para><programlisting>ant run-simple-client</programlisting>The output
- when running the SimpleClient should look like:</para>
-
- <programlisting>Calling remoting server with locator uri of: socket://localhost:5400
-Invoking server with request of 'Do something'
-Invocation response: This is the return to SampleInvocationHandler invocation</programlisting>
-
- <para>The output when running the SimpleServer should look like:</para>
-
- <programlisting>Starting remoting server with locator uri of: socket://localhost:5400
-Invocation request is: Do something
-Returning response of: This is the return to SampleInvocationHandler invocation</programlisting>
-
- <para>Note: will have to manually shut down the SimpleServer once
- started.</para>
- </section>
-
- <section>
- <title>HTTP invocation</title>
-
- <para>This http invocation sample (found in the
- org.jboss.remoting.samples.http package), demonstrates how the http
- invoker can be used for a variety of http based invocations. This time,
- will start with the server side. The SimpleServer class is much like the
- one from the previous simple invocation example, except that instead of
- using the 'socket' transport, will be using the 'http' transport. Also,
- instead of using the SampleInvocationHandler class as the handler, will be
- using the WebInvocationHandler (code shown below).</para>
-
- <programlisting>public class <emphasis role="bold">WebInvocationHandler</emphasis> implements <emphasis
- role="bold">ServerInvocationHandler</emphasis>
-{
- // Pre-defined returns to be sent back to client based on type of request.
- public static final String RESPONSE_VALUE = "This is the return to simple text based http invocation.";
- public static final ComplexObject OBJECT_RESPONSE_VALUE = new ComplexObject(5, "dub", false);
- public static final String HTML_PAGE_RESPONSE = "<html><head><title>Test HTML page</title></head><body>" +
- "<h1>HTTP/Servlet Test HTML page</h1><p>This is a simple page served for test." +
- "<p>Should show up in browser or via invoker client</body></html>";
-
- // Different request types that client may make
- public static final String NULL_RETURN_PARAM = "return_null";
- public static final String OBJECT_RETURN_PARAM = "return_object";
- public static final String STRING_RETURN_PARAM = "return_string";
-
-
- /**
- * called to handle a specific invocation
- *
- * @param invocation
- * @return
- * @throws Throwable
- */
- <emphasis role="bold">public Object invoke(InvocationRequest invocation) throws Throwable
- {
- // Print out the invocation request
- System.out.println("Invocation request from client is: " + invocation.getParameter());
- if(NULL_RETURN_PARAM.equals(invocation.getParameter()))
- {
- return null;
- }
- else if(invocation.getParameter() instanceof ComplexObject)
- {
- return OBJECT_RESPONSE_VALUE;
- }
- else if(STRING_RETURN_PARAM.equals(invocation.getParameter()))
- {
- Map responseMetadata = invocation.getReturnPayload();
- responseMetadata.put(HTTPMetadataConstants.RESPONSE_CODE, new Integer(207));
- responseMetadata.put(HTTPMetadataConstants.RESPONSE_CODE_MESSAGE, "Custom response code and message from remoting server");
- // Just going to return static string as this is just simple example code.
- return RESPONSE_VALUE;
- }
- else
- {
- return HTML_PAGE_RESPONSE;
- }</emphasis>
- }
-</programlisting>
-
- <para>The most interesting part of the WebInvocationHandler is its
- invoke() method implementation. First it will check to see what the
- request parameter was from the InvocationRequest and based on what the
- value is, will return different responses. The first check is to see if
- the client passed a request to return a null value. The second will check
- to see if the request parameter from the client was of type ComplexObject.
- If so, return the pre-built ComplexObject that was created as a static
- variable.</para>
-
- <para>After that, will check to see if the request parameter was for
- returning a simple String. Notice in this block, will set the desired
- response code and message to be returned to the client. In this case, are
- setting the response code to be returned to 207 and the response message
- to "Custom response code and message from remoting server". These are
- non-standard code and message, but can be anything desired.</para>
-
- <para>Last, if have not found a matching invocation request parameter,
- will just return some simple html.</para>
-
- <para>Now onto the client side for making the calls to this handler, which
- can be found in SimpleClient (code shown below).</para>
-
- <programlisting>public class <emphasis role="bold">SimpleClient</emphasis>
-{
- // Default locator values
- private static String transport = "<emphasis role="bold">http</emphasis>";
- private static String host = "localhost";
- private static int port = 5400;
-
- public void makeInvocation(String locatorURI) throws Throwable
- {
- // create InvokerLocator with the url type string
- // indicating the target remoting server to call upon.
- InvokerLocator locator = new InvokerLocator(locatorURI);
- System.out.println("Calling remoting server with locator uri of: " + locatorURI);
-
- Client remotingClient = new Client(locator);
-
- // make invocation on remoting server and send complex data object
- // by default, the remoting http client invoker will use method type of POST,
- // which is needed when ever sending objects to the server. So no metadata map needs
- // to be passed to the invoke() method.
- <emphasis role="bold">Object response = remotingClient.invoke(new ComplexObject(2, "foo", true), null);</emphasis>
-
- System.out.println("\nResponse from remoting http server when making http POST request and sending a complex data object:\n" + response);
-
-
- <emphasis role="bold">Map metadata = new HashMap();</emphasis>
- // set the metadata so remoting client knows to use http GET method type
- <emphasis role="bold">metadata.put("TYPE", "GET");</emphasis>
- // not actually sending any data to the remoting server, just want to get its response
- <emphasis role="bold">response = remotingClient.invoke((Object) null, metadata);</emphasis>
-
- System.out.println("\nResponse from remoting http server when making GET request:\n" + response);
-
- // now set type back to POST and send a plain text based request
- <emphasis role="bold">metadata.put("TYPE", "POST");</emphasis>
- <emphasis role="bold">response = remotingClient.invoke(WebInvocationHandler.STRING_RETURN_PARAM, metadata);</emphasis>
-
- System.out.println("\nResponse from remoting http server when making http POST request and sending a text based request:\n" + response);
-
- // notice are getting custom response code and message set by web invocation handler
- <emphasis role="bold">Integer responseCode = (Integer) metadata.get(HTTPMetadataConstants.RESPONSE_CODE);
- String responseMessage = (String) metadata.get(HTTPMetadataConstants.RESPONSE_CODE_MESSAGE);</emphasis>
- System.out.println("Response code from server: " + responseCode);
- System.out.println("Response message from server: " + responseMessage);
-
- }
-</programlisting>
-
- <para>This SimpleClient, like the one before in the simple invocation
- example, starts off by creating an InvokerLocator and remoting Client
- instance, except is using http transport instead of socket. The first
- invocation made is to send a newly constructed ComplexObject. If remember
- from the WebInvocationHandler above, will expect this invocation to return
- a different ComplexObject, which can be seen in the following system
- output line.</para>
-
- <para>The next invocation to be made is a simple http GET request. To do
- this, must first let the remoting client know that the method type needs
- to be changed from the default, which is POST, to be GET. Then make the
- invocation with a null payload (since not wanting to send any data, just
- get data in response) and the metadata map just populated with the GET
- type. This invocation request will return a response of html.</para>
-
- <para>Then, will change back to being a POST type request and will pass a
- simple String as the payload to the invocation request. This will return a
- simple String as the response from the WebInvocationHandler. Afterward,
- will see the specific response code and message printed to standard
- output, as well as the exception itself.</para>
-
- <para>To run this example, can compile all the classes in the package,
- then first run the SimpleServer and then the SimpleClient. Or can go to
- the examples directory and run the ant target 'run-http-server' and then
- in another console window run the ant target 'run-http-client'. For
- example:</para>
-
- <programlisting>ant run-http-server</programlisting>
-
- <para>and then:</para>
-
- <programlisting>ant run-http-client</programlisting>
-
- <para>The output when running the SimpleClient should look like:</para>
-
- <programlisting>Response from remoting http server when making http POST request and sending a complex data object:
-ComplexObject (i = 5, s = dub, b = false, bytes.length = 0)
-
-Response from remoting http server when making GET request:
-<html><head><title>Test HTML page</title></head><body><h1>HTTP/Servlet Test HTML page</h1><p>This is a simple page served for test.<p>Should show up in browser or via invoker client</body></html>
-
-Response from remoting http server when making http POST request and sending a text based request:
-This is the return to simple text based http invocation.
-Response code from server: 207
-Response message from server: Custom response code and message from remoting server</programlisting>
-
- <para>Notice that the first response is the ComplexObject from the static
- variable returned within WebInvocationHandler. The next response is html
- and then simple text from the WebInvocationHandler. Can see the specific
- response code and message set in the WebInvocationHandler.</para>
-
- <para>The output from the SimpleServer should look like:</para>
-
- <programlisting>Starting remoting server with locator uri of: http://localhost:5400
-Jan 26, 2006 11:39:53 PM org.apache.coyote.http11.Http11BaseProtocol init
-INFO: Initializing Coyote HTTP/1.1 on http-127.0.0.1-5400
-Jan 26, 2006 11:39:53 PM org.apache.coyote.http11.Http11BaseProtocol start
-INFO: Starting Coyote HTTP/1.1 on http-127.0.0.1-5400
-Invocation request from client is: ComplexObject (i = 2, s = foo, b = true, bytes.length = 0)
-Invocation request from client is: null
-Invocation request from client is: return_string</programlisting>
-
- <para>First the information for the http server invoker is written, which
- includes the locator uri used to start the server and the output from
- starting the Tomcat connector. Then will see the invocation parameter
- passed for each client request.</para>
-
- <para>Since the SimpleServer should still be running, can open a web
- browser and enter the locator uri, http://localhost:5400. This should
- cause the browser to render the html returned from the
- WebInvocationHandler.</para>
- </section>
-
- <section>
- <title>Oneway invocation</title>
-
- <para>The oneway invocation sample (found in the
- org.jboss.remoting.samples.oneway package) is very similar to the simple
- invocation example, except in this sample, the client will make
- asynchronous invocations on the server.</para>
-
- <para>The OnewayClient class sets up the remoting client as in the simple
- invocation sample, but instead of using the invoke() method, it uses the
- invokeOneway() method on the Client class. There are two basic modes when
- making a oneway invocation in remoting. The first is to have the calling
- thread to be the one that makes the actual call to the server. This allows
- the caller to ensure that the invocation request at least made it to the
- server. Once the server receives the invocation request, the call will
- return (and the request will be processed by a separate worker thread on
- the server). The other mode, which is demonstrated in the second call to
- invokeOneway, allows for the calling thread to return immediately and a
- worker thread on the client side will make the actual invocation on the
- server. This is faster of the two modes, but if there is a problem making
- the request on the server, the original caller will be unaware.</para>
-
- <para>The OnewayServer is exactly the same as the SimpleServer from the
- previous example, with the exception that invocation handler returns null
- (since even if did return a response, would not be delivered to the
- original caller).</para>
-
- <para>To run this example, can compile both the OnewayClient and
- OnewayServer class, then run the OnewayServer and then the OnewayClient.
- Or can go to the examples directory and run the ant target
- 'run-oneway-server' and then in another console window run the ant target
- 'run-oneway-client'. For example:</para>
-
- <programlisting>ant run-oneway-server</programlisting>
-
- <para>and then:</para>
-
- <programlisting>ant run-oneway-client</programlisting>
-
- <para>The output when running the OnewayClient should look like:</para>
-
- <programlisting>Calling remoting server with locator uri of: socket://localhost:5400
-Making oneway invocation with payload of 'Oneway call 1.'
-Making oneway invocation with payload of 'Oneway call 2.'</programlisting>
-
- <para>The output when running the OnewayServer should look like:</para>
-
- <programlisting>Starting remoting server with locator uri of: socket://localhost:5400
-Invocation request is: Oneway call 1.
-Invocation request is: Oneway call 2.</programlisting>
-
- <para>Note: will have to manually shut down the OnewayServer once
- started.</para>
-
- <para>Although this example only demonstrates making one way invocations,
- could include this with callbacks (see further down) to have asynchronous
- invocations with callbacks to verify was processed.</para>
- </section>
-
- <section>
- <title>Discovery and invocation</title>
-
- <para>The discovery sample (found in the
- org.jboss.remoting.samples.detection package) is similar to the simple
- invocation example in that it makes a simple invocation from the client to
- the server. However, in this example, instead of explicitly specifying the
- invoker locator to use for the target remoting server, it is discovered
- dynamically during runtime. This example is composed of two classes;
- SimpleDetectorClient and SimpleDetectorServer.</para>
-
- <para>The SimpleDetectorClient starts off by setting up the remoting
- detector. Detection on the client side requires a few components; a JMX
- MBeanServer, one or more Detectors, and a NetworkRegistry. The Detectors
- will listen for detection messages from remoting servers and then add the
- information for the detected servers to the NetworkRegistry. They use JMX
- to lookup and call on the NetworkRegistry. The NetworkRegistry uses JMX
- Notifications to emit changes in network topology (remoting servers being
- added or removed).</para>
-
- <para>In this particular example, the SimpleDetectorClient is registered
- with the NetworkRegistry as a notification listener. When it receives
- notifications from the NetworkRegistry (via the handleNotification()
- method), it will check to see if the notification is for adding or
- removing a remoting server. If it is for adding a remoting server, the
- SimpleDetectorClient will get the array of InvokerLocators from the
- NetworkNotification and make a remote call for each. If the notification
- is for removing a remoting server, the SimpleDetectorClient will simply
- print out a message saying which server has been removed.</para>
-
- <para>The biggest change between the SimpleDetectorServer and the
- SimpleServer from the first sample is that have added a method,
- setupDetector(), to create and start a remoting Detector. On the server
- side, only two components are needed for detection; the Detector and a JMX
- MBeanServer. As for the setup of the Connector, it is exactly the same as
- before. Notice that even though we have added a Detector on the server
- side, the Connector is not directly aware of either Detector or the
- MBeanServer, so no code changes for the Connector setup is
- required.</para>
-
- <para>To run this example, can compile both the SimpleDetectorClient and
- SimpleDetectorServer class, then run the SimpleDetectorServer and then the
- SimpleDetectorClient. Or can go to the examples directory and run the ant
- target 'run-detector-server' and then in another window run the ant target
- 'run-detector-client'. For example:</para>
-
- <programlisting>ant run-detector-server</programlisting>
-
- <para>and then:</para>
-
- <programlisting>ant run-detector-client</programlisting>
-
- <para>The initial output when running the SimpleDetectorClient should look
- like:</para>
-
- <programlisting>ri Jan 13 09:36:50 EST 2006: [CLIENT]: Starting JBoss/Remoting client... to stop this client, kill it manually via Control-C
-Fri Jan 13 09:36:50 EST 2006: [CLIENT]: NetworkRegistry has been created
-Fri Jan 13 09:36:50 EST 2006: [CLIENT]: NetworkRegistry has added the client as a listener
-Fri Jan 13 09:36:50 EST 2006: [CLIENT]: MulticastDetector has been created and is listening for new NetworkRegistries to come online
-Fri Jan 13 09:36:50 EST 2006: [CLIENT]: GOT A NETWORK-REGISTRY NOTIFICATION: jboss.network.server.added
-Fri Jan 13 09:36:50 EST 2006: [CLIENT]: New server(s) have been detected - getting locators and sending welcome messages
-Fri Jan 13 09:36:50 EST 2006: [CLIENT]: Sending welcome message to remoting server with locator uri of: socket://127.0.0.1:5400/
-Fri Jan 13 09:36:50 EST 2006: [CLIENT]: The newly discovered server sent this response to our welcome message: Received your welcome message. Thank you!</programlisting>
-
- <para>The output when running the SimpleDetectorServer should look
- like:</para>
-
- <programlisting>Fri Jan 13 09:36:46 EST 2006: [SERVER]: Starting JBoss/Remoting server... to stop this server, kill it manually via Control-C
-Fri Jan 13 09:36:46 EST 2006: [SERVER]: This server's endpoint will be: socket://localhost:5400
-Fri Jan 13 09:36:46 EST 2006: [SERVER]: MulticastDetector has been created and is listening for new NetworkRegistries to come online
-Fri Jan 13 09:36:46 EST 2006: [SERVER]: Starting remoting server with locator uri of: socket://localhost:5400
-Fri Jan 13 09:36:46 EST 2006: [SERVER]: Added our invocation handler; we are now ready to begin accepting messages from clients
-Fri Jan 13 09:36:50 EST 2006: [SERVER]: RECEIVED A CLIENT MESSAGE: Welcome Aboard!
-Fri Jan 13 09:36:50 EST 2006: [SERVER]: Returning the following message back to the client: Received your welcome message. Thank you!</programlisting>
-
- <para>At this point, try stopping the SimpleDetectorServer (notice that
- the SimpleDetectorClient should still be running). After a few seconds,
- the client detector should detect that the server is no longer available
- and will see something like the following appended in the
- SimpleDetectorClient console window:</para>
-
- <programlisting>Fri Jan 13 09:37:04 EST 2006: [CLIENT]: GOT A NETWORK-REGISTRY NOTIFICATION: jboss.network.server.removed
-Fri Jan 13 09:37:04 EST 2006: [CLIENT]: It has been detected that a server has gone down with a locator of: InvokerLocator [socket://127.0.0.1:5400/]</programlisting>
- </section>
-
- <section>
- <title>Callbacks</title>
-
- <para>The callback sample (found in the
- org.jboss.remoting.samples.callback package) illustrates how to perform
- callbacks from a remoting server to a remoting client. This example is
- composed of two classes; CallbackClient and CallbackServer.</para>
-
- <para>Within remoting, there are two approaches in which a callback can be
- received. The first is to actively ask for callback messages from the
- remoting server, which is called a pull callback (since are pulling the
- callbacks from the server). The second is to have the server send the
- callbacks to the client as they are generated, which is called a push
- callback. This sample demonstrates how to do both pull and push
- callbacks.</para>
-
- <para>Looking at the CallbackClient class, will see that the first thing
- done is to create a remoting Client, which is done in the same manner as
- previous examples. Next, we'll perform a pull callback, which requires the
- creation of a CallbackHandler. The CallbackHandler, which implements the
- InvokerCallbackHandler interface, is what is called upon with a Callback
- object when a callback is received. The Callback object contains
- information such as the callback message (in Object form), the server
- locator from where the callback originally came from, and a handle object
- which can help to identify callback context (similar to the handle object
- within a JMX Notification). Once created, the CallbackHandler is then
- registered as a listener within the Client. This will cause the client to
- make a call to the server to notify the server it has a callback listener
- (more on this below in the server section). Although the CallbackHandler
- is not called upon directly when doing pull callbacks, it is needed as an
- identifier for the callbacks.</para>
-
- <para>Then the client will wait a few seconds, make a simple invocation on
- the server, and then call on the remoting Client instance to get any
- callbacks that may be available for our CallbackHandler. This will return
- a list of callbacks, if any exist. The list will be iterated and each
- callback will be printed to standard output. Finally, the callback handler
- will be removed as a listener from the remoting Client (which in turns
- removes it from the remoting server).</para>
-
- <para>After performing a pull callback, will perform a push callback. This
- is a little more involved as requires creating a callback server to which
- the remoting target server can callback on when it generates a callback
- message. To do this, will need to create a remoting Connector, just as
- have seen in previous examples. For this particular example, we use the
- same locator url as our target remoting server, but increment the port to
- listen on by one. Will also notice that use the SampleInvocationHandler
- hander from the CallbackServer (more in this in a minute). After creating
- our callback server, a CallbackHandler and callback handle object is
- created. Next, remoting Client is called to add our callback listener.
- Here we pass not only the CallbackHandler, but the InvokerLocator for the
- callback server (so the target server will know where to deliver callback
- messages to), and the callback handle object (which will be included in
- all the callback messages delivered for this particular callback
- listener).</para>
-
- <para>Then the client will wait a few seconds, to allow the target server
- time to generate and deliver callback messages. After that, we remove the
- callback listener and clean up our callback server.</para>
-
- <para>The CallbackServer is pretty much the same as the previous samples
- in setting up the remoting server, via the Connector. The biggest change
- resides in the ServerInvocationHandler implementation,
- SampleInvocationHandler (which is an inner class to CallbackServer). The
- first thing to notice is now have a variable called listeners, which is a
- List to hold any callback listeners that get registered. Also, in the
- constructor of the SampleInvocationHandler, we set up a new thread to run
- in the background. This thread, executing the run() method in
- SampleInvocationHandler, will continually loop looking to see if the
- shouldGenerateCallbacks has been set. If it has been, will create a
- Callback object and loop through its list of listeners and tell each
- listener to handle the newly created callback. Have also added
- implementation to the addListener() and removeListener() methods where
- will either add or remove specified callback listener from the internal
- callback listener list and set the shouldGenerateCallbacks flag
- accordingly. The invoke() method remains the same as in previous
- samples.</para>
-
- <para>To run this example, can compile both the CallbackClient and
- CallbackServer class, then run the CallbackServer and then the
- CallbackClient. Or can go to the examples directory and run the ant target
- 'run-callback-server' and then in another window run the ant target
- 'run-callback-client. For example:</para>
-
- <programlisting>ant run-callback-server</programlisting>
-
- <para>and then:</para>
-
- <programlisting>ant run-callback-client</programlisting>
-
- <para>The output in the CallbackClient console window should look
- like:</para>
-
- <programlisting>Calling remoting server with locator uri of: socket://localhost:5400
-Invocation response: This is the return to SampleInvocationHandler invocation
-Pull Callback value = Callback 1: This is the payload of callback invocation.
-Pull Callback value = Callback 2: This is the payload of callback invocation.
-Starting remoting server with locator uri of: InvokerLocator [socket://127.0.0.1:5401/]
-Received push callback.
-Received callback value of: Callback 3: This is the payload of callback invocation.
-Received callback handle object of: myCallbackHandleObject
-Received callback server invoker of: InvokerLocator [socket://127.0.0.1:5400/]
-Received push callback.
-Received callback value of: Callback 4: This is the payload of callback invocation.
-Received callback handle object of: myCallbackHandleObject
-Received callback server invoker of: InvokerLocator [socket://127.0.0.1:5400/]</programlisting>
-
- <para>This output shows that client first pulled two callbacks generated
- from the server. Then, after creating and registering our second callback
- handler and a callback server, two callbacks were received from the target
- server.</para>
-
- <para>The output in the CallbackServer console window should look
- like:</para>
-
- <programlisting>Starting remoting server with locator uri of: socket://localhost:5400
-Adding callback listener.
-Invocation request is: Do something
-Removing callback listener.
-Adding callback listener.
-Removing callback listener. </programlisting>
-
- <para>This output shows two distinct callback handlers being added and
- removed (with an invocation request being received after the first was
- added).</para>
-
- <para>There are a few important points to mention about this example.
- First, notice that in the client, the same callback handle object in the
- push callbacks was received as was registered with the callback listener.
- However, there was no special code required to facilitate this within the
- SampleInvocationHandler. This is handled within remoting automatically.
- Also notice when the callback server was created within the client, no
- special coding was required to register the callback handler with it, both
- were simply passed to the remoting Client instance when registering the
- callback listener and was handled internally.</para>
- </section>
-
- <section>
- <title>Streaming</title>
-
- <para>The streaning sample (found in the org.jboss.remoting.samples.stream
- package) illustrates how a java.io.InputStream can be sent from a client
- and read on demand from a server. This example is composed of two classes:
- StreamingClient and StreamingServer.</para>
-
- <para>Unlike the previous examples that sent plain old java objects as the
- payload, this example will be sending a java.io.FileInputStream as the
- payload to the server. This is a special case because streams can not be
- serialized. One approach to this might be to write out the contents of a
- stream to a byte buffer and send the whole data content to the server.
- However, this approach can be dangerous because if the data content of the
- stream is large, such as an 800MB file, would run the risk of causing an
- out of memory error (since are loading all 800MB into memory). Another
- approach, which is used by JBossRemoting, is to create a proxy to the
- original stream. This proxy can then be called upon for reading, same as
- the original stream. When this happens, the proxy will call back the
- original stream for the requested data.</para>
-
- <para>Looking at the StreamingClient, the remoting Client is created as in
- previous samples. Next, will create a java.io.FileInputStream to the
- sample.txt file on disk (which is in the same directory as the test
- classes). Finally, will call the remoting Client to do its invocation,
- passing the new FileInputStream and the name of the file. The second
- parameter could be of any Object type and is meant to supply some
- meaningful context to the server in regards to the stream being passed,
- such as the file name to use when writing to disk on the server side. The
- response from the server, in this example, is the size of the file it
- wrote to disk.</para>
-
- <para>The StreamingServer sets up the remoting server as was done in
- previous examples. However, instead of using an implementation of the
- ServerInvocationHandler class as the server handler, an implementation of
- the StreamInvocationHandler (which extends the ServerInvocationHandler) is
- used. The StreamInvocationHandler includes an extra method called
- handleStream() especially for processing requests with a stream as the
- payload. In this example, the class implementing the
- StreamInvocationHandler is the TestStreamInvocationHandler class, which is
- an inner class to the StreamingServer. The handleStream() method within
- the TestStreamInvocationHandler will use the stream passed to it to write
- out its contents to a file on disk, as specified by the second parameter
- passed to the handleStream() method. Upon writing out the file to disk,
- the handleStream() method will return to the client caller the size of the
- file.</para>
-
- <para>To run this example, can compile both the StreamingClient and
- StreamingServer class, then run the StreamingServer and then the
- StreamingClient. Or can go to the examples directory and run the ant
- target 'run-stream-server' and then in another window run the ant target
- 'run-stream-client'. For example:</para>
-
- <programlisting>ant run-stream-server</programlisting>
-
- <para>and then:</para>
-
- <programlisting>ant run-stream-client</programlisting>
-
- <para>The output in the StreamingClient console window should look
- like:</para>
-
- <programlisting>Calling on remoting server with locator uri of: socket://localhost:5400
-Sending input stream for file sample.txt to server.
-Size of file sample.txt is 987
-Server returned 987 as the size of the file read.</programlisting>
-
- <para>The output in the StreamingServer console window should look
- like:</para>
-
- <programlisting>Starting remoting server with locator uri of: socket://localhost:5400
-Received input stream from client to write out to file server_sample.txt
-Read stream of size 987. Now writing to server_sample.txt
-New file server_sample.txt has been written out to C:\tmp\JBossRemoting_1_4_0_final\examples\server_sample.txt</programlisting>
-
- <para>After running this example, there should be a newly created
- server_sample.txt file in the root examples directory. The contents of the
- file should look exactly like the contents of the sample.txt file located
- in the examples\org\jboss\remoting\samples\stream directory.</para>
- </section>
-
- <section>
- <title>JBoss Serialization</title>
-
- <para>The serialization sample (found in the
- org.jboss.remoting.samples.serialization package) illustrates how JBoss
- Serialization can be used in place of the standard java serialization to
- allow for sending of invocation payload objects that do not implement the
- java.io.Serializable interface. This example is composed of three classes:
- SerializationClient, SerializationServer, and
- NonSerializablePayload.</para>
-
- <para>This example is exactly like the one from the simple example with
- two differences. The first difference is the use of JBoss Serialization to
- convert object instances to binary data format for wire transfer. This is
- accomplished by adding an extra parameter (serializationtype) to the
- locator url with a value of 'jboss'. Is important to note that use of
- JBoss Serialization requires JDK 1.5, so this example will need to be run
- using JDK 1.5. The second difference is instead of sending and receiving a
- simple String type for the remote invocation payload, will be sending and
- receiving an instance of the NonSerializablePayload class.</para>
-
- <para>There are a few important points to notice with the
- NonSerializablePayload class. The first is that it does NOT implement the
- java.io.Serializable interface. The second is that it has a void parameter
- constructor. This is a requirement of JBoss Serialization for object
- instances that do not implement the Serializable interface. However, this
- void parameter constructor can be private, as in the case of
- NonSerializablePayload, as to not change the external API of the
- class.</para>
-
- <para>To run this example, can compile both the SerializationClient and
- SerializationServer class, then run the SerializationServer and then the
- SerializationClient. Or can go to the examples directory and run the ant
- target 'run-serialization-server' and then in another window run the ant
- target 'run-serialization-client'. For example:</para>
-
- <programlisting>ant run-serialization-server</programlisting>
-
- <para>and then:</para>
-
- <programlisting>ant run-serialization-client</programlisting>
-
- <para>The output in the SerializationClient console window should look
- like:</para>
-
- <programlisting>Calling remoting server with locator uri of: socket://localhost:5400/?serializationtype=jboss
-Invoking server with request of 'NonSerializablePayload - name: foo, id: 1'
-Invocation response: NonSerializablePayload - name: bar, id: 2</programlisting>
-
- <para>The output in the SerializationServer console window should look
- like:</para>
-
- <programlisting>Starting remoting server with locator uri of: socket://localhost:5400/?serializationtype=jboss
-Invocation request is: NonSerializablePayload - name: foo, id: 1
-Returning response of: NonSerializablePayload - name: bar, id: 2</programlisting>
-
- <para>Note: will have to manually shut down the SerializationServer once
- started.</para>
- </section>
-
- <section>
- <title>Transporters</title>
-
- <section>
- <title>Transporters - beaming POJOs</title>
-
- <para>There are many ways in which to expose a remote interface to a
- java object. Some require a complex framework API based on a standard
- specification and some require new technologies like annotations and
- AOP. Each of these have their own benefits. JBoss Remoting transporters
- provide the same behavior via a simple API without the need for any of
- the newer technologies.</para>
-
- <para>When boiled down, transporters take a plain old java object (POJO)
- and expose a remote proxy to it via JBoss Remoting. Dynamic proxies and
- reflection are used to make the typed method calls on that target POJO.
- Since JBoss Remoting is used, can select from a number of different
- network transports (i.e. rmi, http, socket, multiplex, etc.), including
- support for SSL. Even clustering features can be included.</para>
-
- <bridgehead>How it works</bridgehead>
-
- <para>In this section will discuss how remoting transporters can be
- used, some requirments for usage, and a little detail on the
- implementation. For greater breath on usage, please review the
- transporter samples as most use cases are covered there.</para>
-
- <para>To start, will need to have a plain old java object that
- implements one or more interfaces that want to expose for remote method
- invocation. Then will need to create a
- <code>org.jboss.remoting.transporter.TransporterServer</code> to wrap
- around it, so that can be exposed remotely. This can be done in one of
- two basic ways. The first is to use a static
- <code>createTransporterServer()</code> method of the TransporterServer
- class. There are many of these create methods, but all basically do that
- same thing in that they take a remoting locator and target pojo and will
- return a TransporterServer instance that has been started and ready to
- receive remote invocations (see javadoc for TransporterServer for all
- the different static createTransporterServer() methods). The other way
- to create a TransporterServer for the target pojo is to construct an
- instance of it. This provides a little more flexibility as are able to
- control more aspects of the TransporterServer, such as when it will be
- started.</para>
-
- <para>When a TransporterServer is created, it will create a remoting
- Connector using the locator provided. It will generate a server
- invocation handler that wraps the target pojo provided and use
- reflection to make the calls on it based on the invocations it receives
- from clients. By default, the subsystem underwhich the server invocation
- handler is registered is the interface class name for which the target
- pojo is exposing. If the target implements multiple interfaces, and a
- specific one to use is not specified, all the interfaces will be
- registered as subsystems for the same server invocation handler.
- Whenever no long want the target pojo to receive remote method
- invocations, will need to call the <code>stop()</code> method on the
- TransporterServer for the target pojo (this is very important, as
- otherwise will never be released from memory and will continue to
- consume network and memory resources).</para>
-
- <para>On the client side, in order to be able to call on the target pojo
- remotely, will need to use the
- <code>org.jboss.remoting.transporter.TransporterClient</code>. Unlike
- the TransporterServer, can only use the static create methods of the
- TransporterClient (this is because the return to the static create
- method is a typed dynamic proxy). The static method to call on the
- TransportClient is <code>createTransporterClient()</code>, where will
- pass the locator to find the target pojo (same as one used when creating
- the TransporterServer) and the interface for the target pojo that want
- to make remote method invocations on. The return from this create call
- will be a dynamic proxy which you can cast to to same interface type
- supplied. At that point, can make typed method invocations on the
- returned object, which will then make the remote invocations under the
- covers. Note that can have multiple transporter clients to the same
- target pojo, each using different interface types for making
- calls.</para>
-
- <para>When no longer need to make invocations on the target pojo, the
- resources associated with the remoting client will need to be cleaned
- up. This is done by calling the <code>destroyTransporterClient()</code>
- method of the TransporterClient. This is important to remember to do, as
- will otherwise leave network resources active even though not in
- use.</para>
-
- <para>One of the features of using remoting transporters is location
- transparency. By this mean that client proxies returned by the
- TransporterClient can be passed over the network. For example, can have
- a target pojo that returns from a method call a client proxy (that it
- created using the TransporterClient) in which the client can call on
- directly as well. See the transporter proxy sample code to see how this
- can be done.</para>
-
- <para>Another nice feature when using transporters is the ability to
- cluster. To be more specific, can create multiple target pojos using the
- TransporterServer in clustered mode and then use the TransporterClient
- in clustered mode to create a client proxy that will discover the
- location of the target pojos are wanting to call on. Will also provide
- automatic, seemless failover of remote method invocations in the case
- that a particular target pojo instance fails. However, note that only
- provide invocation failover and does not take into account state
- transfer between target pojos (would need addition of JBoss Cache or
- some other state synchronization tool).</para>
- </section>
-
- <para>The transporter sample spans several examples showing different ways
- to use the transporter. Each specific example is within its own package
- under the org.jboss.remoting.samples.transporter package. Since each of
- the transporter examples includes common objects, as well as client and
- server classes, the common objects will be found under the main
- transporter sub-package and the client and server classes in their
- respective sub-packages (named client and server).</para>
-
- <section>
- <title>Transporters sample - simple</title>
-
- <para>The simple transporter example (found in
- org.jboss.remoting.samples.transporter.simple package) demonstrates a
- very simple example of how to use the transporters to expose a plain old
- java object for remote method invocations.</para>
-
- <para>In this simple transporter example, will be taking a class that
- formats a java.util.Date into a simple String representation and
- exposing it so can call on the remotely. The target object in this case,
- org.jboss.remoting.samples.transporter.simple.DateProcessorImpl,
- implements the
- org.jboss.remoting.samples.transporter.simple.DateProcessor interfaces
- (as shown below):</para>
-
- <programlisting>public interface DateProcessor
-{
- public String formatDate(Date dateToConvert);
-}
-
-
-public class DateProcessorImpl implements DateProcessor
-{
- public String formatDate(Date dateToConvert)
- {
- DateFormat dateFormat = DateFormat.getDateInstance(DateFormat.MEDIUM);
- return dateFormat.format(dateToConvert);
- }
-}</programlisting>
-
- <para>This is then exposed using the TransporterServer by the
- org.jboss.remoting.samples.transporter.simple.Server class.</para>
-
- <programlisting>public class Server
-{
- public static void main(String[] args) throws Exception
- {
- TransporterServer server = TransporterServer.createTransporterServer("socket://localhost:5400", new DateProcessorImpl(), DateProcessor.class.getName());
- Thread.sleep(10000);
- server.stop();
- }
-}</programlisting>
-
- <para>The Server class simply creates a TransporterServer by indicating
- the locator url would like to use for the remoting server, a newly
- created instance of DataProcessorImpl, and the interface type would like
- to expose remotely. The TransporterServer returned from the
- createTransporterServer call is live and ready to receive incoming
- method invocation requests. Will then wait 10 seconds for a request,
- then stop the server.</para>
-
- <para>Next need to have client to make the remote invocation. This can
- be found within
- org.jboss.remoting.samples.transporter.simple.Client.</para>
-
- <programlisting>public class Client
-{
- public static void main(String[] args) throws Exception
- {
- DateProcessor dateProcessor = (DateProcessor) TransporterClient.createTransporterClient("socket://localhost:5400", DateProcessor.class);
- String formattedDate = dateProcessor.formatDate(new Date());
- System.out.println("Current date: " + formattedDate);
- }
-}</programlisting>
-
- <para>In the Client class, create a TransporterClient which can be cast
- to the desired type, which is DataProcessor in this case. In calling the
- createTransporterClient, need to specify the locator ulr (same as was
- used for the TransporterServer), and the interface type will be calling
- on for the target pojo. Once have the DateProcessor variable, will make
- the call to formatDate() and pass a newly created Date object. The
- return will be a formated String of the date passed.</para>
-
- <para>To run this example, can run the Server and then the Client. Or
- can go to the examples directory and run the ant target
- 'run-transporter-simple-server' and then in another window run the ant
- target 'run-transporter-simple-client'. For example:</para>
-
- <programlisting>ant run-transporter-simple-server</programlisting>
-
- <para>and then:</para>
-
- <programlisting>ant run-transporter-simple-client</programlisting>
-
- <para>The output from the client window should look similar to:</para>
-
- <programlisting>Current date: Jul 31, 2006</programlisting>
- </section>
-
- <section>
- <title>Transporter sample - basic</title>
-
- <para>The basic transporter example (found in
- org.jboss.remoting.samples.transporter.basic package) illustrates how to
- build a simple transporter for making remote invocations on plain old
- java objects.</para>
-
- <para>In this basic transporter example, will be using a few domain
- objects; <code>Customer</code> and Address, which are just data
- objects.</para>
-
- <programlisting>public class <emphasis role="bold">Customer</emphasis> implements Serializable
-{
- private String firstName = null;
- private String lastName = null;
- private Address addr = null;
- private int customerId = -1;
-
- public String getFirstName()
- {
- return firstName;
- }
-
- public void setFirstName(String firstName)
- {
- this.firstName = firstName;
- }
-
- public String getLastName()
- {
- return lastName;
- }
-
- public void setLastName(String lastName)
- {
- this.lastName = lastName;
- }
-
- public Address getAddr()
- {
- return addr;
- }
-
- public void setAddr(Address addr)
- {
- this.addr = addr;
- }
-
- public int getCustomerId()
- {
- return customerId;
- }
-
- public void setCustomerId(int customerId)
- {
- this.customerId = customerId;
- }
-
- public String toString()
- {
- StringBuffer buffer = new StringBuffer();
- buffer.append("\nCustomer:\n");
- buffer.append("customer id: " + customerId + "\n");
- buffer.append("first name: " + firstName + "\n");
- buffer.append("last name: " + lastName + "\n");
- buffer.append("street: " + addr.getStreet() + "\n");
- buffer.append("city: " + addr.getCity() + "\n");
- buffer.append("state: " + addr.getState() + "\n");
- buffer.append("zip: " + addr.getZip() + "\n");
-
- return buffer.toString();
- }
-}</programlisting>
-
- <programlisting>public class <emphasis role="bold">Address</emphasis> implements Serializable
-{
- private String street = null;
- private String city = null;
- private String state = null;
- private int zip = -1;
-
- public String getStreet()
- {
- return street;
- }
-
- public void setStreet(String street)
- {
- this.street = street;
- }
-
- public String getCity()
- {
- return city;
- }
-
- public void setCity(String city)
- {
- this.city = city;
- }
-
- public String getState()
- {
- return state;
- }
-
- public void setState(String state)
- {
- this.state = state;
- }
-
- public int getZip()
- {
- return zip;
- }
-
- public void setZip(int zip)
- {
- this.zip = zip;
- }
-}</programlisting>
-
- <para>Next comes the POJO that we want to expose a remote proxy for,
- which is <code>CustomerProcessorImpl</code> class. This implementation
- has one method to process a <code>Customer</code> object. It also
- implements the <code>CustomerProcessor</code> interface.</para>
-
- <programlisting>public class <emphasis role="bold">CustomerProcessorImpl</emphasis> implements <emphasis
- role="bold">CustomerProcessor</emphasis>
-{
- /**
- * Takes the customer passed, and if not null and customer id
- * is less than 0, will create a new random id and set it.
- * The customer object returned will be the modified customer
- * object passed.
- *
- * @param customer
- * @return
- */
- public Customer processCustomer(Customer customer)
- {
- if(customer != null && customer.getCustomerId() < 0)
- {
- customer.setCustomerId(new Random().nextInt(1000));
- }
- System.out.println("processed customer with new id of " + customer.getCustomerId());
- return customer;
- }
-}</programlisting>
-
- <programlisting>public interface <emphasis role="bold">CustomerProcessor</emphasis>
-{
- /**
- * Process a customer object. Implementors
- * should ensure that the customer object
- * passed as parameter should have its internal
- * state changed somehow and returned.
- *
- * @param customer
- * @return
- */
- public Customer processCustomer(Customer customer);
-}</programlisting>
-
- <para>So far, nothing special, just plain old java objects. Next need to
- create the server component that will listen for remote request to
- invoke on the target POJO. This is where the transporter comes
- in.</para>
-
- <programlisting>public class <emphasis role="bold">Server</emphasis>
-{
- private String locatorURI = "socket://localhost:5400";
- private TransporterServer server = null;
-
- public void start() throws Exception
- {
- server = <emphasis role="bold">TransporterServer.createTransporterServer(locatorURI, new CustomerProcessorImpl())</emphasis>;
- }
-
- public void stop()
- {
- if(server != null)
- {
- server.stop();
- }
- }
-
- public static void main(String[] args)
- {
- Server server = new Server();
- try
- {
- server.start();
-
- Thread.currentThread().sleep(60000);
-
- }
- catch(Exception e)
- {
- e.printStackTrace();
- }
- finally
- {
- server.stop();
- }
- }
-}</programlisting>
-
- <para>The <code>Server</code> class is a pretty simple one. It calls the
- <code>TransporterServer</code> factory method to create the server
- component for the <code>CustomerProcessorImpl</code> instance using the
- specified remoting locator information.</para>
-
- <para>The <code>TransporterServer</code> returned from the
- <code>createTransporterServer() </code>call will be a running instance
- of a remoting server using the <literal>socket</literal> transport that
- is bound to <literal>localhost</literal> and listening for remote
- requests on port <literal>5400</literal>. The requests that come in will
- be forwarded to the remoting handler which will convert them into direct
- method calls on the target POJO, <code>CustomerProcessorImpl</code> in
- this case, using reflection.</para>
-
- <para>The <code>TransporterServer</code> has a <code>start()</code> and
- <code>stop()</code> method exposed to control when to start and stop the
- running of the remoting server. The <code>start()</code> method is
- called automatically within the <code>createTransporterServer()</code>
- method, so is ready to receive requests upon the return of this method.
- The <code>stop()</code> method, however, needs to be called explicitly
- when no longer wish to receive remote calls on the target POJO.</para>
-
- <para>Next up is the client side. This is represented by the
- <code>Client</code> class.</para>
-
- <programlisting>public class <emphasis role="bold">Client</emphasis>
-{
- private String locatorURI = "socket://localhost:5400";
-
- public void makeClientCall() throws Exception
- {
- Customer customer = createCustomer();
-
- <emphasis role="bold">CustomerProcessor customerProcessor = (CustomerProcessor) TransporterClient.createTransporterClient(locatorURI, CustomerProcessor.class);</emphasis>
-
- System.out.println("Customer to be processed: " + customer);
- <emphasis role="bold">Customer processedCustomer = customerProcessor.processCustomer(customer);</emphasis>
- System.out.println("Customer is now: " + processedCustomer);
-
- <emphasis role="bold">TransporterClient.destroyTransporterClient(customerProcessor);</emphasis>
- }
-
- private Customer createCustomer()
- {
- Customer cust = new Customer();
- cust.setFirstName("Bob");
- cust.setLastName("Smith");
- Address addr = new Address();
- addr.setStreet("101 Oak Street");
- addr.setCity("Atlanata");
- addr.setState("GA");
- addr.setZip(30249);
- cust.setAddr(addr);
-
- return cust;
- }
-
- public static void main(String[] args)
- {
- Client client = new Client();
- try
- {
- client.makeClientCall();
- }
- catch(Exception e)
- {
- e.printStackTrace();
- }
- }
-}</programlisting>
-
- <para>The <code>Client</code> class is also pretty simple. It creates a
- new <code>Customer</code> object instance, creates the remote proxy to
- the <code>CustomerProcessor</code>, and then calls on the
- <code>CustomerProcessor</code> to process its new <code>Customer</code>
- instance.</para>
-
- <para>To get the remote proxy for the <code>CustomerProcessor</code>,
- all that is required is to call the <code>TransporterClient</code>'s
- method <code>createTransporterClient()</code> method and pass the
- locator uri and the type of the remote proxy (and explicitly cast the
- return to that type). This will create a dynamic proxy for the specified
- type, <code>CustomerProcessor</code> in this case, which is backed by a
- remoting client which in turn makes the calls to the remote POJO's
- remoting server. Once the call to <code>createTransportClient()</code>
- has returned, the remoting client has already made its connection to the
- remoting server and is ready to make calls (will throw an exception if
- it could not connect to the specified remoting server).</para>
-
- <para>When finished making calls on the remote POJO proxy, will need to
- explicitly destroy the client by calling
- <code>destroyTransporterClient()</code> and pass the remote proxy
- instance. This allows the remoting client to disconnect from the POJO's
- remoting server and clean up any network resources previously
- used.</para>
-
- <para>To run this example, can run the Server and then the Client. Or
- can go to the examples directory and run the ant target
- 'run-transporter-basic-server' and then in another window run the ant
- target 'run-transporter-basic-client'. For example:</para>
-
- <programlisting>ant run-transporter-basic-server</programlisting>
-
- <para>and then:</para>
-
- <programlisting>ant run-transporter-basic-client</programlisting>
-
- <para>The output from the Client console should be similar to:</para>
-
- <programlisting>Customer to be processed:
-Customer:
-customer id: -1
-first name: Bob
-last name: Smith
-street: 101 Oak Street
-city: Atlanata
-state: GA
-zip: 30249
-
-Customer is now:
-Customer:
-customer id: 204
-first name: Bob
-last name: Smith
-street: 101 Oak Street
-city: Atlanata
-state: GA
-zip: 30249
-
-</programlisting>
-
- <para>and the output from the Server class should be similar to:</para>
-
- <programlisting>processed customer with new id of 204</programlisting>
-
- <para>The output shows that the <code>Customer</code> instance created
- on the client was sent to the server where it was processed (by setting
- the customer id to 204) and returned to the client (and printed out
- showing that the customer id was set to 204).</para>
- </section>
-
- <section>
- <title>Transporter sample - JBoss serialization</title>
-
- <para>The transporter serialization example (found in
- org.jboss.remoting.samples.transporter.serialization package) is very
- similar to the previous basic example, except in this one, the domain
- objects being sent over the wire will NOT be Serializable. This is
- accomplished via the use of JBoss Serialization. This can be useful when
- don't know which domain objects you may be using in remote calls or if
- adding ability for remote calls on legacy code.</para>
-
- <para>To start, there are a few more domain objects: <code>Order</code>,
- <code>OrderProcessor</code>, and <code>OrderProcessorImpl</code>. These
- will use some of the domain objects from the previous example as well,
- such as <code>Customer</code>.</para>
-
- <programlisting>public class <emphasis role="bold">Order</emphasis>
-{
- private int orderId = -1;
- private boolean isProcessed = false;
- private Customer customer = null;
- private List items = null;
-
-
- public int getOrderId()
- {
- return orderId;
- }
-
- public void setOrderId(int orderId)
- {
- this.orderId = orderId;
- }
-
- public boolean isProcessed()
- {
- return isProcessed;
- }
-
- public void setProcessed(boolean processed)
- {
- isProcessed = processed;
- }
-
- public Customer getCustomer()
- {
- return customer;
- }
-
- public void setCustomer(Customer customer)
- {
- this.customer = customer;
- }
-
- public List getItems()
- {
- return items;
- }
-
- public void setItems(List items)
- {
- this.items = items;
- }
-
- public String toString()
- {
- StringBuffer buffer = new StringBuffer();
- buffer.append("\nOrder:\n");
- buffer.append("\nIs processed: " + isProcessed);
- buffer.append("\nOrder id: " + orderId);
- buffer.append(customer.toString());
-
- buffer.append("\nItems ordered:");
- Iterator itr = items.iterator();
- while(itr.hasNext())
- {
- buffer.append("\n" + itr.next().toString());
- }
-
- return buffer.toString();
- }
-}</programlisting>
-
- <programlisting>public class <emphasis role="bold">OrderProcessorImpl</emphasis> implements <emphasis
- role="bold">OrderProcessor</emphasis>
-{
- private CustomerProcessor customerProcessor = null;
-
- public OrderProcessorImpl()
- {
- customerProcessor = new CustomerProcessorImpl();
- }
-
- public Order processOrder(Order order)
- {
- System.out.println("Incoming order to process from customer.\n" + order.getCustomer());
-
- // has this customer been processed?
- if(order.getCustomer().getCustomerId() < 0)
- {
- order.setCustomer(customerProcessor.processCustomer(order.getCustomer()));
- }
-
- List items = order.getItems();
- System.out.println("Items ordered:");
- Iterator itr = items.iterator();
- while(itr.hasNext())
- {
- System.out.println(itr.next());
- }
-
- order.setOrderId(new Random().nextInt(1000));
- order.setProcessed(true);
-
- System.out.println("Order processed. Order id now: " + order.getOrderId());
- return order;
- }
-}</programlisting>
-
- <programlisting>public interface OrderProcessor
-{
- public Order processOrder(Order order);
-}</programlisting>
-
- <para>The <code>OrderProcessorImpl</code> will take orders, via the
- <code>processOrder() </code>method, check that the customer for the
- order has been processed, and if not have the customer processor process
- the new customer. Then will place the order, which means will just set
- the order id and processed attribute to true.</para>
-
- <para>The most important point to this example is that the
- <code>Order</code> class does NOT implement
- <code>java.io.Serializable</code>.</para>
-
- <para>Now onto the <code>Server</code> class. This is just like the
- previous <code>Server</code> class in the basic example with one main
- difference: the <code>locatorURI</code> value.</para>
-
- <programlisting>public class <emphasis role="bold">Server</emphasis>
-{
- private String locatorURI = "socket://localhost:5400/?<emphasis role="bold">serializationtype=jboss</emphasis>";
- private TransporterServer server = null;
-
- public void start() throws Exception
- {
- server = TransporterServer.createTransporterServer(locatorURI, new OrderProcessorImpl());
- }
-
- public void stop()
- {
- if(server != null)
- {
- server.stop();
- }
- }
-
- public static void main(String[] args)
- {
- Server server = new Server();
- try
- {
- server.start();
-
- Thread.currentThread().sleep(60000);
-
- }
- catch(Exception e)
- {
- e.printStackTrace();
- }
- finally
- {
- server.stop();
- }
- }
-}</programlisting>
-
- <para>The addition of <literal>serializationtype=jboss</literal> tells
- the remoting framework to use JBoss Serialization in place of the
- standard java serialization.</para>
-
- <para>On the client side, there is the <code>Client</code> class, just
- as in the previous basic example.</para>
-
- <programlisting>public class <emphasis role="bold">Client</emphasis>
-{
- private String locatorURI = "socket://localhost:5400/?<emphasis role="bold">serializationtype=jboss</emphasis>";
-
- public void makeClientCall() throws Exception
- {
- Order order = createOrder();
-
- OrderProcessor orderProcessor = (OrderProcessor) TransporterClient.createTransporterClient(locatorURI, OrderProcessor.class);
-
- System.out.println("Order to be processed: " + order);
- Order changedOrder = orderProcessor.processOrder(order);
- System.out.println("Order now processed " + changedOrder);
-
- TransporterClient.destroyTransporterClient(orderProcessor);
-
- }
-
- private Order createOrder()
- {
- Order order = new Order();
- Customer customer = createCustomer();
- order.setCustomer(customer);
-
- List items = new ArrayList();
- items.add("Xbox 360");
- items.add("Wireless controller");
- items.add("Ghost Recon 3");
-
- order.setItems(items);
-
- return order;
- }
-
- private Customer createCustomer()
- {
- Customer cust = new Customer();
- cust.setFirstName("Bob");
- cust.setLastName("Smith");
- Address addr = new Address();
- addr.setStreet("101 Oak Street");
- addr.setCity("Atlanata");
- addr.setState("GA");
- addr.setZip(30249);
- cust.setAddr(addr);
-
- return cust;
- }
-
- public static void main(String[] args)
- {
- Client client = new Client();
- try
- {
- client.makeClientCall();
- }
- catch(Exception e)
- {
- e.printStackTrace();
- }
- }
-}</programlisting>
-
- <para>Again, the biggest difference to note is that have added
- <literal>serializationtype=jboss</literal> to the locator uri.</para>
-
- <para>Note: Running this example requires JDK 1.5.</para>
-
- <para>To run this example, can run the Server and then the Client. Or
- can go to the examples directory and run the ant target 'ant
- run-transporter-serialization-server' and then in another window run the
- ant target 'ant run-transporter-serialization-client'. For
- example:</para>
-
- <programlisting>ant run-transporter-serialization-server</programlisting>
-
- <para>and then:</para>
-
- <programlisting>ant run-transporter-serialization-client</programlisting>
-
- <para>When the server and client are run the output for the
- <code>Client</code> class is:</para>
-
- <programlisting>Order to be processed:
-Order:
-
-Is processed: false
-Order id: -1
-Customer:
-customer id: -1
-first name: Bob
-last name: Smith
-street: 101 Oak Street
-city: Atlanata
-state: GA
-zip: 30249
-
-Items ordered:
-Xbox 360
-Wireless controller
-Ghost Recon 3
-Order now processed
-Order:
-
-Is processed: true
-Order id: 221
-Customer:
-customer id: 861
-first name: Bob
-last name: Smith
-street: 101 Oak Street
-city: Atlanata
-state: GA
-zip: 30249
-
-Items ordered:
-Xbox 360
-Wireless controller
-Ghost Recon 3
-</programlisting>
-
- <para>The client output shows the printout of the newly created order
- before calling the <code>OrderProcessor</code> and then the processed
- order afterwards. Noticed that the processed order has its customer's id
- set, its order id set and the processed attribute is set to true.</para>
-
- <para>And the output from the <code>Server</code> is:</para>
-
- <programlisting>Incoming order to process from customer.
-
-Customer:
-customer id: -1
-first name: Bob
-last name: Smith
-street: 101 Oak Street
-city: Atlanata
-state: GA
-zip: 30249
-
-processed customer with new id of 861
-Items ordered:
-Xbox 360
-Wireless controller
-Ghost Recon 3
-Order processed. Order id now: 221
-</programlisting>
-
- <para>The server output shows the printout of the customer before being
- processed and then the order while being processed.</para>
- </section>
-
- <section>
- <title>Transporter sample - clustered</title>
-
- <para>In the previous examples, there has been one and only one target
- POJO to make calls upon. If that target POJO was not available, the
- client call would fail. In the transporter clustered example (found in
- org.jboss.remoting.samples.transporter.clustered package), will show how
- to use the transporter in clustered mode so that if one target POJO
- becomes unavailable, the client call can be seamlessly failed over to
- another available target POJO on the network, regardless of network
- transport type.</para>
-
- <para>This example uses the domain objects from the first, basic
- example, so only need to cover the client and server code. For this
- example, there are three different server classes. The first class is
- the <code>SocketServer</code> class, which is the exact same as the
- <code>Server</code> class in the basic example, except for the call to
- the <code>TransportServer</code>'s <code>createTransportServer()
- </code>method.</para>
-
- <programlisting>public class <emphasis role="bold">SocketServer</emphasis>
-{
- public static String locatorURI = "socket://localhost:5400";
- private TransporterServer server = null;
-
- public void start() throws Exception
- {
- server = <emphasis role="bold">TransporterServer.createTransporterServer(getLocatorURI(), new CustomerProcessorImpl(),
- CustomerProcessor.class.getName(), true)</emphasis>;
- }
-
- protected String getLocatorURI()
- {
- return locatorURI;
- }
-
- public void stop()
- {
- if(server != null)
- {
- server.stop();
- }
- }
-
- public static void main(String[] args)
- {
- SocketServer server = new SocketServer();
- try
- {
- server.start();
-
- Thread.currentThread().sleep(60000);
-
- }
- catch(Exception e)
- {
- e.printStackTrace();
- }
- finally
- {
- server.stop();
- }
- }
-}</programlisting>
-
- <para>Notice that are now calling on the <code>TransportServer</code> to
- create a server with the locator uri and target POJO
- (<code>CustomerProcessorImpl</code>) as before, but have also added the
- interface type of the target POJO (<code>CustomerProcessor</code>) and
- that want clustering turned on (via the last <literal>true</literal>
- parameter).</para>
-
- <para>The interface type of the target POJO is needed because this will
- be used as the subsystem within the remoting server for the target POJO.
- The subsystem value will be what the client uses to determine if
- discovered remoting server is for the target POJO they are looking
- for.</para>
-
- <sidebar>
- <para>The transporter uses the MulticastDetector from JBoss Remoting
- for automatic discovery when in clustered mode. The actual detection
- of remote servers that come online can take up to a few seconds once
- started. There is a JNDI based detector provided within JBoss
- Remoting, but has not been integrated within the transporters
- yet.</para>
- </sidebar>
-
- <para>The second server class is the <code>RMIServer</code> class. The
- <code>RMIServer</code> class extends the <code>SocketServer</code> class
- and uses a different locator uri to specify <literal>rmi</literal> as the
- transport protocol and a different port
- (<literal>5500</literal>).</para>
-
- <programlisting>public class <emphasis role="bold">RMIServer</emphasis> extends <emphasis
- role="bold">SocketServer</emphasis>
-{
- private String localLocatorURI = "<emphasis role="bold">rmi://localhost:5500</emphasis>";
-
- protected String getLocatorURI()
- {
- return localLocatorURI;
- }
-
- public static void main(String[] args)
- {
- SocketServer server = new RMIServer();
- try
- {
- server.start();
-
- Thread.currentThread().sleep(60000);
-
- }
- catch(Exception e)
- {
- e.printStackTrace();
- }
- finally
- {
- server.stop();
- }
- }
-}</programlisting>
-
- <para>The last server class is the <code>HTTPServer</code> class. The
- <code>HTTPServer</code> class also extends the <code>SocketServer</code>
- class and specifies <literal>http</literal> as the transport protocol
- and <literal>5600</literal> as the port to listen for requests
- on.</para>
-
- <programlisting>public class <emphasis role="bold">HTTPServer</emphasis> extends <emphasis
- role="bold">SocketServer</emphasis>
-{
- private String localLocatorURI = "<emphasis role="bold">http://localhost:5600</emphasis>";
-
- protected String getLocatorURI()
- {
- return localLocatorURI;
- }
-
- public static void main(String[] args)
- {
- SocketServer server = new HTTPServer();
- try
- {
- server.start();
-
- Thread.currentThread().sleep(60000);
-
- }
- catch(Exception e)
- {
- e.printStackTrace();
- }
- finally
- {
- server.stop();
- }
- }
-}</programlisting>
-
- <para>On the client side, there is only the <code>Client</code> class.
- This class is very similar to the one from the basic example. The main
- exceptions are (1) the addition of a <code>TransporterClient</code> call
- to create a transporter client and (2) the fact that it continually
- loops, making calls on its <code>customerProcessor</code> variable to
- process customers. This is done so that when we run the client, we can
- kill the different servers and see that the client continues to loop
- making its calls without any exceptions or errors.</para>
-
- <programlisting>public class <emphasis role="bold">Client</emphasis>
-{
- <emphasis role="bold">private String locatorURI = SocketServer.locatorURI;</emphasis>
-
- private CustomerProcessor customerProcessor = null;
-
- public void makeClientCall() throws Exception
- {
- Customer customer = createCustomer();
-
- System.out.println("Customer to be processed: " + customer);
- <emphasis role="bold">Customer processedCustomer = customerProcessor.processCustomer(customer);</emphasis>
- System.out.println("Customer is now: " + processedCustomer);
-
- //TransporterClient.destroyTransporterClient(customerProcessor);
- }
-
- public void getCustomerProcessor() throws Exception
- {
- customerProcessor = (CustomerProcessor) <emphasis role="bold">TransporterClient.createTransporterClient(locatorURI, CustomerProcessor.class, true)</emphasis>;
- }
-
- private Customer createCustomer()
- {
- Customer cust = new Customer();
- cust.setFirstName("Bob");
- cust.setLastName("Smith");
- Address addr = new Address();
- addr.setStreet("101 Oak Street");
- addr.setCity("Atlanata");
- addr.setState("GA");
- addr.setZip(30249);
- cust.setAddr(addr);
-
- return cust;
- }
-
- public static void main(String[] args)
- {
- Client client = new Client();
- try
- {
-<emphasis role="bold"> client.getCustomerProcessor();
- while(true)
- {
- try
- {
- client.makeClientCall();
- Thread.currentThread().sleep(5000);
- }
- catch(Exception e)
- {
- e.printStackTrace();
- }
- }
-</emphasis> }
- catch(Exception e)
- {
- e.printStackTrace();
- }
- }
-}</programlisting>
-
- <para>The first item of note is that the locator uri from the
- <code>SocketServer</code> class is being used. Technically, this is not
- required as once the clustered <code>TransporterClient</code> is
- started, it will start to discover the remoting servers that exist on
- the network. However, this process can take several seconds to occur, so
- unless it is known that no calls will be made on the remote proxy right
- away, it is best to bootstrap with a known target server.</para>
-
- <para>Can also see that in the <code>main()</code> method, the first
- call on the Client instance is to <code>getCustomerProcessor()</code>.
- This method will call the <code>TransporterClient</code>'s
- <code>createTransporterClient()</code> method and passes the locator uri
- for the target POJO server, the type of POJO's remote proxy, and that
- clustering should be enabled.</para>
-
- <para>After getting the customer processor remote proxy, will
- continually loop making calls using the remote proxy (via the
- <code>processCustomer()</code> method on the
- <code>customerProcessor</code> variable).</para>
-
- <para>To run this example, all the servers need to be started (by
- running the <code>SocketServer</code>, <code>RMIServer</code>, and
- <code>HTTPServer</code> classes). Then run the Client class. This can be
- done via ant targets as well. So for example, could open four console
- windows and enter the ant targets as follows:</para>
-
- <programlisting>ant run-transporter-clustered-socket-server</programlisting>
-
- <programlisting>ant run-transporter-clustered-http-server</programlisting>
-
- <programlisting>ant run-transporter-clustered-rmi-server</programlisting>
-
- <programlisting>ant run-transporter-clustered-client</programlisting>
-
- <para>Once the client starts running, should start to see output logged
- to the <code>SocketServer</code>, since this is the one used to
- bootstrap. This output would look like:</para>
-
- <programlisting>processed customer with new id of 378
-processed customer with new id of 487
-processed customer with new id of 980</programlisting>
-
- <para>Once the <code>SocketServer</code> instance has received a few
- calls, kill this instance. The next time the client makes a call on its
- remote proxy, which happens every five seconds, it should fail over to
- another one of the servers (and will see similar output on that server
- instance). After that server has received a few calls, kill it and
- should see it fail over once again to the last server instance that is
- still running. Then, if kill that server instance, will see a
- CannotConnectException and stack trace similar to the following:</para>
-
- <programlisting><emphasis role="bold">...
-org.jboss.remoting.CannotConnectException</emphasis>: Can not connect http client invoker.
- at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:147)
- at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:56)
- at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:112)
- at org.jboss.remoting.Client.invoke(Client.java:226)
- at org.jboss.remoting.Client.invoke(Client.java:189)
- at org.jboss.remoting.Client.invoke(Client.java:174)
- at org.jboss.remoting.transporter.TransporterClient.invoke(TransporterClient.java:219)
- at $Proxy0.processCustomer(Unknown Source)
- at org.jboss.remoting.samples.transporter3.client.Client.makeClientCall(Client.java:29)
- at org.jboss.remoting.samples.transporter3.client.Client.main(Client.java:64)
- at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
- at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
- at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
- at java.lang.reflect.Method.invoke(Method.java:585)
- at com.intellij.rt.execution.application.AppMain.main(AppMain.java:86)
-Caused by: java.net.ConnectException: Connection refused: connect
- at java.net.PlainSocketImpl.socketConnect(Native Method)
- at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
- at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
- at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
- at java.net.Socket.connect(Socket.java:507)
- at java.net.Socket.connect(Socket.java:457)
- at sun.net.NetworkClient.doConnect(NetworkClient.java:157)
- at sun.net.www.http.HttpClient.openServer(HttpClient.java:365)
- at sun.net.www.http.HttpClient.openServer(HttpClient.java:477)
- at sun.net.www.http.HttpClient.<init>(HttpClient.java:214)
- at sun.net.www.http.HttpClient.New(HttpClient.java:287)
- at sun.net.www.http.HttpClient.New(HttpClient.java:299)
- at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:792)
- at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:744)
- at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:669)
- at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:836)
- at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:117)
- ... 14 more</programlisting>
-
- <para>since there are no target servers left to make calls on. Notice
- that earlier in the client output there were no errors while was failing
- over to the different servers as they were being killed.</para>
-
- <para>Because the CannotConnectException is being caught within the
- while loop, the client will continue to try calling the remote proxy and
- getting this exception. Now re-run any of the previously killed servers
- and will see that the client will discover that server instance and
- begin to successfully call on that server. The output should look
- something like:</para>
-
- <programlisting>...
- at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:669)
- at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:836)
- at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:117)
- ... 14 more
-
-Customer to be processed:
-Customer:
-customer id: -1
-first name: Bob
-last name: Smith
-street: 101 Oak Stree
-city: Atlanata
-state: null
-zip: 30249
-
-Customer is now:
-Customer:
-customer id: 633
-first name: Bob
-last name: Smith
-street: 101 Oak Stree
-city: Atlanata
-state: null
-zip: 30249
-
-...</programlisting>
-
- <sidebar>
- <para>As demonstrated in this example, fail over can occur across any
- of the JBoss Remoting transports. Clustered transporters is also
- supported using JBoss Serialization, which was introduced in the
- previous example.</para>
-
- <para>It is important to understand that in the context of
- transporters, clustering means invocation fail over. The JBoss
- Remoting transporters themselves do not handle any form of state
- replication. If this feature were needed, could use JBoss Cache to
- store the target POJO instances so that when their state changed, that
- change would be replicated to the other target POJO instances running
- in other processes.</para>
- </sidebar>
- </section>
-
- <section>
- <title>Transporters sample - multiple</title>
-
- <para>The multiple transporter example (found in
- org.jboss.remoting.samples.transporter.multiple package) shows how can
- have a multiple target pojos exposed via the same TransporterServer. In
- this example, will be two pojos being exposed, CustomerProcessorImpl and
- AccountProcessorImpl. Since the domain objects for this example is
- similar to the others discussed in previous examples, will just focus on
- the server and client code. On the server side, need to create the
- TransporterServer so that will included both of the target pojos.</para>
-
- <programlisting>public class Server
-{
- private String locatorURI = "socket://localhost:5400";
- private TransporterServer server = null;
-
- public void start() throws Exception
- {
- server = TransporterServer.createTransporterServer(locatorURI, new CustomerProcessorImpl(), CustomerProcessor.class.getName());
- server.addHandler(new AccountProcessorImpl(), AccountProcessor.class.getName());
- }
-
- public void stop()
- {
- if(server != null)
- {
- server.stop();
- }
- }
-
- public static void main(String[] args)
- {
- Server server = new Server();
- try
- {
- server.start();
-
- Thread.currentThread().sleep(60000);
-
- }
- catch(Exception e)
- {
- e.printStackTrace();
- }
- finally
- {
- server.stop();
- }
- }
-}</programlisting>
-
- <para>The TransporterServer is created with the CustomerProcessorImpl as
- the inital target pojo. Now that have a live TransporterServer, can add
- other pojos as targets. This is done using the addHandler() method where
- the target pojo instance is passed and then the interface type to be
- exposed as.</para>
-
- <para>Next have the Client that makes the call to both pojos.</para>
-
- <programlisting>public class Client
-{
- private String locatorURI = "socket://localhost:5400";
-
- public void makeClientCall() throws Exception
- {
- Customer customer = createCustomer();
-
- CustomerProcessor customerProcessor = (CustomerProcessor) TransporterClient.createTransporterClient(locatorURI, CustomerProcessor.class);
-
- System.out.println("Customer to be processed: " + customer);
- Customer processedCustomer = customerProcessor.processCustomer(customer);
- System.out.println("Customer is now: " + processedCustomer);
-
- AccountProcessor accountProcessor = (AccountProcessor) TransporterClient.createTransporterClient(locatorURI, AccountProcessor.class);
-
- System.out.println("Asking for a new account to be created for customer.");
- Account account = accountProcessor.createAccount(processedCustomer);
- System.out.println("New account: " + account);
-
- TransporterClient.destroyTransporterClient(customerProcessor);
- TransporterClient.destroyTransporterClient(accountProcessor);
-
- }
-
- private Customer createCustomer()
- {
- Customer cust = new Customer();
- cust.setFirstName("Bob");
- cust.setLastName("Smith");
- Address addr = new Address();
- addr.setStreet("101 Oak Street");
- addr.setCity("Atlanta");
- addr.setState("GA");
- addr.setZip(30249);
- cust.setAddr(addr);
-
- return cust;
- }
-
- public static void main(String[] args)
- {
- org.jboss.remoting.samples.transporter.multiple.client.Client client = new org.jboss.remoting.samples.transporter.multiple.client.Client();
- try
- {
- client.makeClientCall();
- }
- catch (Exception e)
- {
- e.printStackTrace();
- }
- }
-
-
-}</programlisting>
-
- <para>Notice that TransporterClients are created for each target pojo
- want to call upon, they just happen to share the same locator uri. These
- are independant instances so need to both be destroyed on their own when
- finished with them.</para>
-
- <para>To run this example, run the Server class and then the Client
- class. This can be done via ant targets
- 'run-transporter-multiple-server' and then
- 'run-transporter-multiple-client'. For example:</para>
-
- <programlisting>ant run-transporter-multiple-server</programlisting>
-
- <para>and then:</para>
-
- <programlisting>ant run-transporter-multiple-client</programlisting>
-
- <para>The output for the server should look similar to:</para>
-
- <programlisting>processed customer with new id of 980
-Created new account with account number: 1 and for customer:
-
-Customer:
-customer id: 980
-first name: Bob
-last name: Smith
-street: 101 Oak Street
-city: Atlanta
-state: GA
-zip: 30249</programlisting>
-
- <para>and the output from the client should look similar to:</para>
-
- <programlisting>Customer to be processed:
-Customer:
-customer id: -1
-first name: Bob
-last name: Smith
-street: 101 Oak Street
-city: Atlanta
-state: GA
-zip: 30249
-
-Customer is now:
-Customer:
-customer id: 980
-first name: Bob
-last name: Smith
-street: 101 Oak Street
-city: Atlanta
-state: GA
-zip: 30249
-
-Asking for a new account to be created for customer.
-New account: Account - account number: 1
-Customer:
-Customer:
-customer id: 980
-first name: Bob
-last name: Smith
-street: 101 Oak Street
-city: Atlanta
-state: GA
-zip: 30249
-</programlisting>
- </section>
-
- <section>
- <title>Transporters sample - proxy</title>
-
- <para>The proxy transporter example (found in
- org.jboss.remoting.samples.transporter.proxy package) shows how can have
- a TransporterClient sent over the network and called upon. In this
- example, will have a target pojo, CustomerProcessorImpl which itself
- creates a TransporterClient to another target pojo, Customer, and return
- it as response to a method invocation.</para>
-
- <para>To start, will look at the initial target pojo,
- CustomerProcessorImpl.</para>
-
- <programlisting>public class CustomerProcessorImpl implements CustomerProcessor
-{
- private String locatorURI = "socket://localhost:5401";
-
- /**
- * Takes the customer passed, and if not null and customer id
- * is less than 0, will create a new random id and set it.
- * The customer object returned will be the modified customer
- * object passed.
- *
- * @param customer
- * @return
- */
- public ICustomer processCustomer(Customer customer)
- {
- if (customer != null && customer.getCustomerId() < 0)
- {
- customer.setCustomerId(new Random().nextInt(1000));
- }
-
- ICustomer customerProxy = null;
- try
- {
- TransporterServer server = TransporterServer.createTransporterServer(locatorURI, customer, ICustomer.class.getName());
- customerProxy = (ICustomer) TransporterClient.createTransporterClient(locatorURI, ICustomer.class);
- }
- catch (Exception e)
- {
- e.printStackTrace();
- }
-
- System.out.println("processed customer with new id of " + customerProxy.getCustomerId());
- return customerProxy;
- }
-
-}</programlisting>
-
- <para>Notice that the processCustomer() method will take a Customer
- object and set customer id on it. Then it will create a
- TransporterServer for that customer instance and also create a
- TransporterClient for the same instance and return that
- TransporterClient proxy as the return to the processCustomer()
- method.</para>
-
- <para>Next will look at the Customer class. It is a basic data object in
- that is really just stores the customer data.</para>
-
- <programlisting>public class Customer implements Serializable, ICustomer
-{
- private String firstName = null;
- private String lastName = null;
- private Address addr = null;
- private int customerId = -1;
-
- public String getFirstName()
- {
- return firstName;
- }
-
- public void setFirstName(String firstName)
- {
- this.firstName = firstName;
- }
-
- public String getLastName()
- {
- return lastName;
- }
-
- public void setLastName(String lastName)
- {
- this.lastName = lastName;
- }
-
- public Address getAddr()
- {
- return addr;
- }
-
- public void setAddr(Address addr)
- {
- this.addr = addr;
- }
-
- public int getCustomerId()
- {
- return customerId;
- }
-
- public void setCustomerId(int customerId)
- {
- this.customerId = customerId;
- }
-
- public String toString()
- {
- System.out.println("Customer.toString() being called.");
- StringBuffer buffer = new StringBuffer();
- buffer.append("\nCustomer:\n");
- buffer.append("customer id: " + customerId + "\n");
- buffer.append("first name: " + firstName + "\n");
- buffer.append("last name: " + lastName + "\n");
- buffer.append("street: " + addr.getStreet() + "\n");
- buffer.append("city: " + addr.getCity() + "\n");
- buffer.append("state: " + addr.getState() + "\n");
- buffer.append("zip: " + addr.getZip() + "\n");
-
- return buffer.toString();
- }
-
-
-}
-</programlisting>
-
- <para>Notice the toString() method and how it prints out to the standard
- out when being called. This will be important when the sample is run
- later.</para>
-
- <para>Now if look at the Server class, will see is a standard setup like
- have seen in previous samples.</para>
-
- <programlisting>public class Server
-{
- private String locatorURI = "socket://localhost:5400";
- private TransporterServer server = null;
-
- public void start() throws Exception
- {
- server = TransporterServer.createTransporterServer(locatorURI, new CustomerProcessorImpl(), CustomerProcessor.class.getName());
- }
-
- public void stop()
- {
- if (server != null)
- {
- server.stop();
- }
- }
-
- public static void main(String[] args)
- {
- Server server = new Server();
- try
- {
- server.start();
-
- Thread.currentThread().sleep(60000);
-
- }
- catch (Exception e)
- {
- e.printStackTrace();
- }
- finally
- {
- server.stop();
- }
- }
-}</programlisting>
-
- <para>It is creating a TransporterServer for the CustomerProcessImpl
- upon being started and will wait 60 seconds for invocations.</para>
-
- <para>Next is the Client class. </para>
-
- <programlisting>public class Client
-{
- private String locatorURI = "socket://localhost:5400";
-
- public void makeClientCall() throws Exception
- {
- Customer customer = createCustomer();
-
- CustomerProcessor customerProcessor = (CustomerProcessor) TransporterClient.createTransporterClient(locatorURI, CustomerProcessor.class);
-
- System.out.println("Customer to be processed: " + customer);
- ICustomer processedCustomer = customerProcessor.processCustomer(customer);
- // processedCustomer returned is actually a proxy to the Customer instnace
- // that lives on the server. So when print it out below, will actually
- // be calling back to the server to get the string (vi toString() call).
- // Notice the output of 'Customer.toString() being called.' on the server side.
- System.out.println("Customer is now: " + processedCustomer);
-
- TransporterClient.destroyTransporterClient(customerProcessor);
-
-
- }
-
- private Customer createCustomer()
- {
- Customer cust = new Customer();
- cust.setFirstName("Bob");
- cust.setLastName("Smith");
- Address addr = new Address();
- addr.setStreet("101 Oak Street");
- addr.setCity("Atlanta");
- addr.setState("GA");
- addr.setZip(30249);
- cust.setAddr(addr);
-
- return cust;
- }
-
- public static void main(String[] args)
- {
- Client client = new Client();
- try
- {
- client.makeClientCall();
- }
- catch (Exception e)
- {
- e.printStackTrace();
- }
- }
-
-
-}</programlisting>
-
- <para>The client class looks similar to the other example seen in that
- it creates a TransporterClient for the CustomerProcessor and calls on it
- to process the customer. Will then call on the ICustomer instance
- returned from the processCustomer() method call and call toString() on
- it (in the system out call). </para>
-
- <para>To run this example, run the Server class and then the Client
- class. This can be done via ant targets 'run-transporter-proxy-server'
- and then 'run-transporter-proxy-client'. For example:</para>
-
- <programlisting>ant run-transporter-proxy-server</programlisting>
-
- <para>ant then:</para>
-
- <programlisting>ant run-transporter-proxy-client</programlisting>
-
- <para>The output for the client should look similar to:</para>
-
- <programlisting>Customer.toString() being called.
-Customer to be processed:
-Customer:
-customer id: -1
-first name: Bob
-last name: Smith
-street: 101 Oak Street
-city: Atlanta
-state: GA
-zip: 30249
-
-Customer is now:
-Customer:
-customer id: 418
-first name: Bob
-last name: Smith
-street: 101 Oak Street
-city: Atlanta
-state: GA
-zip: 30249
-</programlisting>
-
- <para>The first line
- is the print out from calling the Customer's toString() method that was
- created to be passed to the CustomerProcessor's processCustomer()
- method. Then the contents of the Customer object before being processed.
- Then have the print out of the customer after has been processed. Notice
- that when the ICustomer object instance is printed out the second time,
- do not see the 'Customer.toString() being called'. This is because that
- code is no longer being executed in the client vm, but instead is a
- remote call to the customer instance living on the server (remember, the
- processCustomer() method returned a TransporterClient proxy to the
- customer living on the server side).</para>
-
- <para>Now, if look at output from the server will look similar
- to:</para>
-
- <programlisting>processed customer with new id of 418
-Customer.toString() being called.</programlisting>
-
- <para>Notice that the 'Customer.toString() being called.' printed out at
- the end. This is the result of the client's call to print out the
- contents of the customer object returned from the processCustomer()
- method, which actually lives within the server vm.</para>
-
- <para>This example has shown how can pass around TransporterClient
- proxies to target pojos. However, when doing this, is important to
- understand where the code is actually being executed as there are
- consequences to being remote verse local, which need to be
- understood.</para>
- </section>
-
- <section>
- <title>Transporter sample -complex</title>
-
- <para>The complex transporter example (found in
- org.jboss.remoting.samples.transporter.complex package) is based off a
- test case a user, Milt Grinberg, provided (thanks Milt). The example is
- similar to the previous examples, except in this case involves matching
- Doctors and Patients using the ProviderInterface and provides a more
- complex sample in which to demonstrate how to use transporters.</para>
-
- <para>This example requires JDK 1.5 to run, since is using JBoss
- Serialization (and non-serialized data objects). To run this example,
- run the Server class and then the Client class. This can be done via ant
- targets 'run-transporter-complex-server' and then
- 'run-transporter-complex-client' as well. For example:</para>
-
- <programlisting>ant run-transporter-complex-server</programlisting>
-
- <para>and then:</para>
-
- <programlisting>ant run-transporter-complex-client</programlisting>
-
- <para>The output for the client should look similar to:</para>
-
- <programlisting>*** Have a new patient that needs a doctor. The patient is:
-
-Patient:
- Name: Bill Gates
- Ailment - Type: financial, Description: Money coming out the wazoo.
-
-*** Looking for doctor that can help our patient...
-
-*** Found doctor for our patient. Doctor found is:
-Doctor:
- Name: Andy Jones
- Specialty: financial
- Patients:
-
-Patient:
- Name: Larry Ellison
- Ailment - Type: null, Description: null
- Doctor - Name: Andy Jones
-
-Patient:
- Name: Steve Jobs
- Ailment - Type: null, Description: null
- Doctor - Name: Andy Jones
-
-Patient:
- Name: Bill Gates
- Ailment - Type: financial, Description: Money coming out the wazoo.
-
-*** Set doctor as patient's doctor. Patient info is now:
-
-Patient:
- Name: Bill Gates
- Ailment - Type: financial, Description: Money coming out the wazoo.
- Doctor - Name: Andy Jones
-
-*** Have a new patient that we need to find a doctor for (remember, the previous one retired and there are no others)
-*** Could not find doctor for patient. This is an expected exception when there are not doctors available.
-org.jboss.remoting.samples.transporter.complex.NoDoctorAvailableException: No doctor available for ailment 'financial'
- at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:183)
- at org.jboss.remoting.Client.invoke(Client.java:325)
- at org.jboss.remoting.Client.invoke(Client.java:288)
- at org.jboss.remoting.Client.invoke(Client.java:273)
- at org.jboss.remoting.transporter.TransporterClient.invoke(TransporterClient.java:237)
- at $Proxy0.findDoctor(Unknown Source)
- at org.jboss.remoting.samples.transporter.complex.client.Client.makeClientCall(Client.java:72)
- at org.jboss.remoting.samples.transporter.complex.client.Client.main(Client.java:90)
- at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
- at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
- at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
- at java.lang.reflect.Method.invoke(Method.java:585)
- at com.intellij.rt.execution.application.AppMain.main(AppMain.java:86)
-</programlisting>
-
- <para>From the output see the creation of a new patient, Bill Gates, and
- the attempt to find a doctor that specializes in his ailment. For Mr.
- Gates, we were able to find a doctor, Andy Jones, and can see that he
- has been added to the list of Dr. Jones' patients. Then we have Dr.
- Jones retire. Then we create a new patient and try to find an available
- doctor for the same ailment. Since Dr. Jones has retired, and there are
- no other doctors that specialize in that particular ailment, an
- exception is thrown. This is as expected.</para>
- </section>
- </section>
-
- <section>
- <title id="section-multiplex-invokers"
- xreflabel="Multiplex invokers">Multiplex invokers</title>
-
- <para>This section illustrates the construction of multiplex invoker
- groups described in the section <xref linkend="section-multiplex-invoker" />. The
- directory</para>
-
- <blockquote>
- <para><code>examples/org/jboss/remoting/samples/multiplex/invoker</code></para>
- </blockquote>
-
- <para>contains a server class,
- <classname>MultiplexInvokerServer</classname>, which is suitable for use
- with any of the client classes described below. It may be run in an IDE or
- from the command line using ant target <code>run-multiplex-server</code>
- from the <code>build.xml</code> file found in the <code>examples</code>
- directory. The server will stay alive, processing invocation requests as
- they are presented, until it has sent two push callbacks to however many
- listeners are registered, at which time it will shut itself down.</para>
-
- <para>The sample clients are as follows. Each sample client
- <emphasis><client></emphasis> may be run in an IDE or by using the
- ant target <code>run-</code><emphasis><client></emphasis> (e.g.,
- <code>run-Client2Server1</code>).</para>
-
- <itemizedlist>
- <listitem>
- <para><classname>Client2Server1</classname>: A
- <classname>MultiplexClientInvoker</classname> starts according to
- client rule 2, after which a
- <classname>MultiplexServerInvoker</classname> is started according to
- server rule 1. Note that the <classname>Client</classname> and
- <classname>Connector</classname> are passed matching
- <emphasis>clientMultiplexId</emphasis> and
- <emphasis>serverMultiplexId</emphasis> parameters,
- respectively.</para>
- </listitem>
-
- <listitem>
- <para><classname>Client2Server2</classname>: A
- <classname>MultiplexClientInvoker</classname> starts according to
- client rule 2, after which a
- <classname>MultiplexServerInvoker</classname> is started according to
- server rule 2. Note that no <emphasis>clientMultiplexId</emphasis> is
- passed to the <classname>Client</classname> and no
- <emphasis>serverMultiplexId</emphasis> parameter is passed to the
- <classname>Connector</classname> in this example.</para>
- </listitem>
-
- <listitem>
- <para><classname>Client3Server1</classname>: A
- <classname>MultiplexClientInvoker</classname> is created, and, lacking
- binding information, finds itself governed by client rule 3.
- Subsequently, a <classname>MultiplexServerInvoker</classname> is
- started according to server rule 1, providing the binding information
- which allows the <classname>MultiplexClientInvoker</classname> to
- start. Note that the <classname>Client</classname> and
- <classname>Connector</classname> are passed matching
- <emphasis>clientMultiplexId</emphasis> and
- <emphasis>serverMultiplexId</emphasis> parameters,
- respectively.</para>
- </listitem>
-
- <listitem>
- <para><classname>Server2Client1</classname>: A
- <classname>MultiplexServerInvoker</classname> starts according to
- server rule 2, after which a
- <classname>MultiplexClientInvoker</classname> is started according to
- client rule 1. Note that the <classname>Connector</classname> and
- <classname>Client</classname> are passed matching
- <emphasis>serverMultiplexId</emphasis> and
- <emphasis>clientMultiplexId</emphasis> parameters,
- respectively.</para>
- </listitem>
-
- <listitem>
- <para><classname>Server2Client2</classname>: A
- <classname>MultiplexServerInvoker</classname> starts according to
- server rule 2, after which a
- <classname>MultiplexClientInvoker</classname> is started according to
- client rule 2. Note that no <emphasis>serverMultiplexId</emphasis> is
- passed to the <classname>Connector</classname> and no
- <emphasis>clientMultiplexId</emphasis> parameter is passed to the
- <classname>Client</classname> in this example.</para>
- </listitem>
-
- <listitem>
- <para><classname>Server3Client1</classname>: A
- <classname>MultiplexServerInvoker</classname> is created, and, lacking
- connect information, finds itself governed by server rule 3.
- Subsequently, a <classname>MultiplexClientInvoker</classname> is
- started according to client rule 1, providing the connect information
- which allows the <classname>MultiplexServerInvoker</classname> to
- start. Note that the <classname>Connector</classname> and
- <classname>Client</classname> are passed matching
- <emphasis>serverMultiplexId</emphasis> and
- <emphasis>clientMultiplexId</emphasis> parameters,
- respectively.</para>
- </listitem>
- </itemizedlist>
-
- <para>For variety, the examples in which the client invoker starts first
- use the configuration <classname>Map</classname> to pass invoker group
- parameters, and the examples in which the server invoker starts first pass
- parameters in the <classname>InvokerLocator</classname>.</para>
- </section>
-</chapter>
\ No newline at end of file
+ <para>When boiled down, transporters take a plain old java object (POJO)
+ and expose a remote proxy to it via JBoss Remoting. Dynamic proxies and
+ reflection are used to make the typed method calls on that target POJO.
+ Since JBoss Remoting is used, can select from a number of different
+ network transports (i.e. rmi, http, socket, multiplex, etc.), including
+ support for SSL. Even clustering features can be included. See the
+ transporter samples in the next chapter for detailed examples of how to
+ set up use of a transporter.</para>
+ </chapter>
\ No newline at end of file
Modified: remoting2/tags/2.4.0-SP1/docs/guide/en/chap12.xml
===================================================================
--- remoting2/tags/2.4.0-SP1/docs/guide/en/chap12.xml 2008-08-12 07:23:58 UTC (rev 4512)
+++ remoting2/tags/2.4.0-SP1/docs/guide/en/chap12.xml 2008-08-13 06:00:06 UTC (rev 4513)
@@ -1,17 +1,23 @@
<chapter>
- <title>Compatibility and versioning</title>
+ <title>Client programming model</title>
- <para>As of JBossRemoting 2.0.0 versioning has been added to guarantee
- compatibility between different versions. This is accomplished by changing
- serialization formats for certain classes and by using wire versioning. By
- wire versioning, mean that the version used by a client and server will be
- sent on the wire so that the other side will be able to adjust
- accordingly. This will be automatic for JBossRemoting 2.0.0 and later
- versions. However, since versioning was not introduced until the 2.0.0
- release, if need to have a 1.4.x version of remoting communicate to a
- later version, will need to set a system property on the 2.0.0 version so
- that knows to use the older wire protocol version. The system property to
- set is 'jboss.remoting.pre_2_0_compatible' and should be set to true.
- There are a few minor features that will not be fully compatible between
- 1.4.x release and 2.0.0, which are listed in the release notes.</para>
+ <para>The approach taken for the programming model on the client side is
+ one based on a session based model. This means that it is expected that
+ once a Client is created for a particular target server, it will be used
+ exclusively to make calls on that server. This expectation dictates some
+ of the behavior of the remoting client.</para>
+
+ <para>For example, if create a Client on the client side to make server
+ invocations, including adding callback listeners, will have to use that
+ same instance of Client to remove the callback listeners. This is because
+ the Client creates a unique session id that it passes within the calls to
+ the server. This id is used as part of the key for registering callback
+ listeners on the server. If create a new Client instance and attempt to
+ remove the callback listeners, a new session id will be passed to the
+ server invoker, who will not recognize the callback listener to be
+ removed.</para>
+
+ <para>See test case
+ <code>org.jboss.test.remoting.callback.push.MultipleCallbackServersTestCase</code>
+ .</para>
</chapter>
\ No newline at end of file
Modified: remoting2/tags/2.4.0-SP1/docs/guide/en/chap15.xml
===================================================================
--- remoting2/tags/2.4.0-SP1/docs/guide/en/chap15.xml 2008-08-12 07:23:58 UTC (rev 4512)
+++ remoting2/tags/2.4.0-SP1/docs/guide/en/chap15.xml 2008-08-13 06:00:06 UTC (rev 4513)
@@ -1,22 +1,16 @@
- <chapter>
- <title>Future plans</title>
+ <chapter>
+ <title>Known issues</title>
- <para>Full road map for JBossRemoting can be found at <!--<link linkend="???">
- http://jira.jboss.com/jira/browse/JBREM?report=com.atlassian.jira.plugin....
- </link>--> <ulink
- url="http://jira.jboss.com/jira/browse/JBREM?report=com.atlassian.jira.plugin....">
- http://jira.jboss.com/jira/browse/JBREM?report=com.atlassian.jira.plugin....
- </ulink>.</para>
-
- <para>If you have questions, comments, bugs, fixes, contributions, or
- flames, please post them to the JBoss Remoting users forum <!--<link linkend="???">http://www.jboss.com/index.html?module=bb&op=viewforum&f=222</link>-->
+ <para>All of the known issues and road map can be found on our bug
+ tracking system, Jira, at <!--<link linkend="???">http://jira.jboss.com/jira/secure/BrowseProject.jspa?id=10031</link>-->
+ <ulink
+ url="http://jira.jboss.com/jira/secure/BrowseProject.jspa?id=10031">
+ http://jira.jboss.com/jira/secure/BrowseProject.jspa?id=10031 </ulink>
+ (require member plus registration, which is free). If you find more,
+ please post them to Jira. If you have questions post them to the JBoss
+ Remoting users forum <!--<link linkend="???">http://www.jboss.com/index.html?module=bb&op=viewforum&f=222</link>-->
(<ulink
url="http://www.jboss.com/index.html?module=bb&op=viewforum&f=222">
http://www.jboss.com/index.html?module=bb&op=viewforum&f=222
- </ulink>). You can also find more information about JBoss Remoting on our
- <!--<link linkend="???">http://www.jboss.org/wiki/Wiki.jsp?page=Remoting</link>-->
- wiki (<ulink url="http://www.jboss.org/wiki/Wiki.jsp?page=Remoting">
- http://www.jboss.org/wiki/Wiki.jsp?page=Remoting </ulink> ). The wiki will
- usually contain the latest updates to doc and features that did not make
- into previous release.</para>
+ </ulink>).</para>
</chapter>
\ No newline at end of file
Modified: remoting2/tags/2.4.0-SP1/docs/guide/en/chap7.xml
===================================================================
--- remoting2/tags/2.4.0-SP1/docs/guide/en/chap7.xml 2008-08-12 07:23:58 UTC (rev 4512)
+++ remoting2/tags/2.4.0-SP1/docs/guide/en/chap7.xml 2008-08-13 06:00:06 UTC (rev 4513)
@@ -1,44 +1,121 @@
- <chapter>
- <title>Serialization</title>
+<chapter>
+ <title>Sending streams</title>
- <para>Serialization - how it works within remoting: In general, remoting
- will rely on a factory to provide the serialization implementation, or
- <code>org.jboss.remoting.serialization.SerializationManager</code>, to be
- used when doing object serialization. This factory is
- <code>org.jboss.remoting.serialization.SerializationStreamFactory</code>
- and is a (as defined by its javadoc):</para>
+ <para>Remoting supports the sending of InputStreams. It is important to
+ note that this feature DOES NOT copy the stream data directly from the
+ client to the server, but is a true on demand stream. Although this is
+ obviously slower than reading from a stream on the server that has been
+ copied locally, it does allow for true streaming on the server. It also
+ allows for better memory control by the user (versus the framework trying
+ to copy a 3 Gig file into memory and getting out of memory errors).</para>
- <literallayout>factory is for defining the Object stream implemenations to be used along with creating those implemenations for use.
-The main function will be to return instance of ObjectOutput and ObjectInput. By default, the implementations will be
-java.io.ObjectOutputStream and java.io.ObjectInputStream.
-</literallayout>
+ <para>Use of this new feature is simple. From the client side, there is a
+ method in org.jboss.remoting.Client with the signature:</para>
- <para>Currently there are only two different types of serialization
- implementations; 'java' and 'jboss'. The 'java' type uses
- <code>org.jboss.remoting.serialization.impl.java.JavaSerializationManager</code>
- as the SerializationManager implementation and is backed by standard Java
- serialization provide by the JVM, which is the default. The 'jboss' type
- uses
- <code>org.jboss.remoting.serialization.impl.jboss.JBossSerializationManager</code>
- as the SerializationManager implementation and is backed by JBoss
- Serialization.</para>
+ <programlisting>public Object invoke(InputStream inputStream, Object param) throws Throwable
+ </programlisting>
- <para>JBoss Serialization is a new project under development to provide a
- more performant implementation of object serialization. It complies with
- java serialization standard with three exceptions:</para>
+ <para>So from the client side, would just call invoke as done in the past,
+ and pass the InputStream and the payload as the parameters. An example of
+ the code from the client side would be (this is taken directly from
+ org.jboss.test.remoting.stream.StreamingTestClient):</para>
- <para>- SerialUID not needed</para>
+ <programlisting>
+ String param = "foobar";
+ File testFile = new File(fileURL.getFile());
+ ...
+ Object ret = remotingClient.invoke(fileInput, param);
+ </programlisting>
- <para>- java.io.Serializable is not required</para>
+ <para>From the server side, will need to implement
+ <code>org.jboss.remoting.stream.StreamInvocationHandler</code> instead of
+ <code>org.jboss.remoting.ServerInvocationHandler</code> .
+ StreamInvocationHandler extends ServerInvocationHandler, with the addition
+ of one new method:</para>
- <para>- different protocol</para>
+ <programlisting>public Object handleStream(InputStream stream, Object param)</programlisting>
- <para>JBoss Serialization requires JDK 1.5</para>
+ <para>The stream passed to this method can be called on just as any
+ regular local stream. Under the covers, the InputStream passed is really
+ proxy to the real input stream that exists in the client's VM. Subsequent
+ calls to the passed stream will actually be converted to calls on the real
+ stream on the client via this proxy. If the client makes an invocation on
+ the server passing an InputStream as the parameter and the server handler
+ does not implement StreamInvocationhandler, an exception will be thrown to
+ the client caller.</para>
- <para></para>
+ <para>If want to have more control over the stream server being created to
+ send the stream data back to the caller, instead of letting remoting
+ create it internally, can do this by creating a Connector to act as stream
+ server and pass it when making Client invocation.</para>
- <para>It is possible to override the default SerializationManger
- implementation to be used by setting the system property 'SERIALIZATION'
- to the fully qualified name of the class to use (which will need to
- provide a void constructor).</para>
+ <programlisting>public Object invoke(InputStream inputStream, Object param, Connector streamConnector) throws Throwable</programlisting>
+
+ <para>Note, the Connector passed must already have been started (else an
+ exception will be thrown). The stream handler will then be added to the
+ connector with the subystem 'stream'. The Connector passed will NOT be
+ stopped when the stream is closed by the server's stream proxy (which
+ happens automatically when remoting creates the stream server
+ internally).</para>
+
+ <para>Can also call <methodname>invoke()</methodname> method on client and
+ pass the invoker locator
+ would like to use and allow remoting to create the stream server using the
+ specified locator.</para>
+
+ <programlisting>public Object invoke(InputStream inputStream, Object param, InvokerLocator streamServerLocator) throws Throwable </programlisting>
+
+ <para>In this case, the Connector created internally by remoting will be
+ stopped when the stream is closed by the server's stream proxy.</para>
+
+ <para>It is VERY IMPORTANT that the StreamInvocationHandler implementation
+ close the InputStream when it finishes reading, as will close the real
+ stream that lives within the client VM.</para>
+
+ <section>
+ <title>Configuration</title>
+
+ <para>By default, the stream server which runs within the client JVM
+ uses the following values for its locator uri:</para>
+
+ <para>transport - socket</para>
+
+ <para>host - tries to first get local host name and if that fails, the
+ local ip (if that fails, localhost).</para>
+
+ <para>port - 5405</para>
+
+ <para>Currently, the only way to override these settings is to set the
+ following system properties (either via JVM arguments or via
+ <code>System.setProperty()</code> method):</para>
+
+ <para>remoting.stream.transport - sets the transport type (rmi, http,
+ socket, etc.)</para>
+
+ <para>remoting.stream.host - host name or ip address to use</para>
+
+ <para>remoting.stream.port - the port to listen on</para>
+
+ <para>These properties are important because currently the only way for
+ a target server to get the stream data from the stream server (running
+ within the client JVM) is to have the server invoker make the invocation
+ on a new connection back to the client (see issues below).</para>
+ </section>
+
+ <section>
+ <title>Issues</title>
+
+ <para>This is a first pass at the implementation and needs some work in
+ regards to optimizations and configuration. In particular, there is a
+ remoting server that is started to service requests from the stream
+ proxy on the target server for data from the original stream. This
+ raises an issue with the current transports, since the client will have
+ to accept calls for the original stream on a different socket. This may
+ be difficult when control over the client's environment (including
+ firewalls) may not be available. A bi-directional transport, called
+ multiplex, is being introduced as of 1.4.0 release which will allow
+ calls from the server to go over the same socket connection established
+ by the client to the server (JBREM-91). This will make communications
+ back to client much simpler from this standpoint.</para>
+ </section>
</chapter>
\ No newline at end of file
16 years, 4 months
- 1
- 0
JBoss Remoting SVN: r4512 - remoting2/tags.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-08-12 03:23:58 -0400 (Tue, 12 Aug 2008)
New Revision: 4512
Added:
remoting2/tags/2.4.0-SP1/
Log:
Copied: remoting2/tags/2.4.0-SP1 (from rev 4511, remoting2/branches/2.x)
16 years, 4 months
- 1
- 0
JBoss Remoting SVN: r4511 - in remoting2/branches/2.x/src/etc/lib: remoting_2_4_0_GA and 1 other directory.
by jboss-remoting-commits＠lists.jboss.org
Author: ron.sigal(a)jboss.com
Date: 2008-08-12 03:22:17 -0400 (Tue, 12 Aug 2008)
New Revision: 4511
Added:
remoting2/branches/2.x/src/etc/lib/remoting_2_4_0_GA/
remoting2/branches/2.x/src/etc/lib/remoting_2_4_0_GA/jboss-remoting.jar
Log:
JBREM-1024: Added 2.4.0.GA jboss-remoting.jar for versioning test.
Added: remoting2/branches/2.x/src/etc/lib/remoting_2_4_0_GA/jboss-remoting.jar
===================================================================
(Binary files differ)
Property changes on: remoting2/branches/2.x/src/etc/lib/remoting_2_4_0_GA/jboss-remoting.jar
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
16 years, 4 months
- 1
- 0