[Design of JBoss Web Services] - metadata integration
by scott.stark＠jboss.org
It looks like the only integration point for creation of a ObjectModelFactory based impl that hands off to a ServiceRefHandler impl from the ws spi. Can we get the ws spi to provide a jaxb annotated element ala this from the metadata project instead?
| package org.jboss.metadata.javaee.spec;
|
| import javax.xml.bind.annotation.XmlElement;
| import javax.xml.bind.annotation.XmlType;
| import javax.xml.namespace.QName;
|
| import org.jboss.metadata.javaee.support.ResourceInjectionMetaDataWithDescriptionGroup;
|
| /**
| * ServiceReferenceMetaData.
| *
| * @author <a href="adrian(a)jboss.com">Adrian Brock</a>
| * @version $Revision: 1.1 $
| */
| @XmlType(name="service-refType")
| public class ServiceReferenceMetaData extends ResourceInjectionMetaDataWithDescriptionGroup
| {
| /** The serialVersionUID */
| private static final long serialVersionUID = 5693673588576610322L;
|
| /** The service interface */
| private String serviceInterface;
|
| /** The service reference type */
| private String serviceRefType;
|
| /** The wsdl file */
| private String wsdlFile;
|
| /** The jaxrpc mapping file */
| private String jaxrpcMappingFile;
|
| /** The service qname */
| private QName serviceQname;
|
| /** The handlers */
| private ServiceReferenceHandlersMetaData handlers;
|
| /** The handler chains */
| private ServiceReferenceHandlerChainsMetaData handlerChains;
|
| /**
| * Create a new ServiceReferenceMetaData.
| */
| public ServiceReferenceMetaData()
| {
| // For serialization
| }
|
| /**
| * Get the serviceRefName.
| *
| * @return the serviceRefName.
| */
| public String getServiceRefName()
| {
| return getName();
| }
|
| /**
| * Set the serviceRefName.
| *
| * @param serviceRefName the serviceRefName.
| * @throws IllegalArgumentException for a null serviceRefName
| */
| public void setServiceRefName(String serviceRefName)
| {
| setName(serviceRefName);
| }
|
| /**
| * Get the jaxrpcMappingFile.
| *
| * @return the jaxrpcMappingFile.
| */
| public String getJaxrpcMappingFile()
| {
| return jaxrpcMappingFile;
| }
|
| /**
| * Set the jaxrpcMappingFile.
| *
| * @param jaxrpcMappingFile the jaxrpcMappingFile.
| * @throws IllegalArgumentException for a null jaxrpcMappingFile
| */
| public void setJaxrpcMappingFile(String jaxrpcMappingFile)
| {
| if (jaxrpcMappingFile == null)
| throw new IllegalArgumentException("Null jaxrpcMappingFile");
| this.jaxrpcMappingFile = jaxrpcMappingFile;
| }
|
| /**
| * Get the serviceInterface.
| *
| * @return the serviceInterface.
| */
| public String getServiceInterface()
| {
| return serviceInterface;
| }
|
| /**
| * Set the serviceInterface.
| *
| * @param serviceInterface the serviceInterface.
| * @throws IllegalArgumentException for a null serviceInterface
| */
| public void setServiceInterface(String serviceInterface)
| {
| if (serviceInterface == null)
| throw new IllegalArgumentException("Null serviceInterface");
| this.serviceInterface = serviceInterface;
| }
|
| /**
| * Get the serviceQname.
| *
| * @return the serviceQname.
| */
| public QName getServiceQname()
| {
| return serviceQname;
| }
|
| /**
| * Set the serviceQname.
| *
| * @param serviceQname the serviceQname.
| * @throws IllegalArgumentException for a null serviceQname
| */
| public void setServiceQname(QName serviceQname)
| {
| if (serviceQname == null)
| throw new IllegalArgumentException("Null serviceQname");
| this.serviceQname = serviceQname;
| }
|
| /**
| * Get the serviceRefType.
| *
| * @return the serviceRefType.
| */
| public String getServiceRefType()
| {
| return serviceRefType;
| }
|
| /**
| * Set the serviceRefType.
| *
| * @param serviceRefType the serviceRefType.
| * @throws IllegalArgumentException for a null serviceRefType
| */
| //@SchemaProperty(mandatory=false)
| @XmlElement(required=false)
| public void setServiceRefType(String serviceRefType)
| {
| if (serviceRefType == null)
| throw new IllegalArgumentException("Null serviceRefType");
| this.serviceRefType = serviceRefType;
| }
|
| /**
| * Get the wsdlFile.
| *
| * @return the wsdlFile.
| */
| public String getWsdlFile()
| {
| return wsdlFile;
| }
|
| /**
| * Set the wsdlFile.
| *
| * @param wsdlFile the wsdlFile.
| * @throws IllegalArgumentException for a null wsdlFile
| */
| public void setWsdlFile(String wsdlFile)
| {
| if (wsdlFile == null)
| throw new IllegalArgumentException("Null wsdlFile");
| this.wsdlFile = wsdlFile;
| }
|
| /**
| * Get the handlers.
| *
| * @return the handlers.
| */
| public ServiceReferenceHandlersMetaData getHandlers()
| {
| return handlers;
| }
|
| /**
| * Set the handlers.
| *
| * @param handlers the handlers.
| * @throws IllegalArgumentException for a null handlers
| */
| @XmlElement(name="handler")
| public void setHandlers(ServiceReferenceHandlersMetaData handlers)
| {
| if (handlers == null)
| throw new IllegalArgumentException("Null handlers");
| this.handlers = handlers;
| }
|
| /**
| * Get the handlerChains.
| *
| * @return the handlerChains.
| */
| public ServiceReferenceHandlerChainsMetaData getHandlerChains()
| {
| return handlerChains;
| }
|
| /**
| * Set the handlerChains.
| *
| * @param handlerChains the handlerChains.
| * @throws IllegalArgumentException for a null handlerChains
| */
| //@SchemaProperty(mandatory=false)
| @XmlElement(required=false)
| public void setHandlerChains(ServiceReferenceHandlerChainsMetaData handlerChains)
| {
| if (handlerChains == null)
| throw new IllegalArgumentException("Null handlerChains");
| this.handlerChains = handlerChains;
| }
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4091801#4091801
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4091801
18 years, 6 months
[Design of JBoss Portal] - Questions about database connections between portlets
by twalex
Currently, I am trying to find out how the portlets can share database connections among them. However, I could not get any information from the documentation, hopefully I can get some here.
The scenario is that we use dbcp to manage our db connection pool. And I guess that each portlet instance might consume a db connection, so, if a page has 10 portlets, that means 10 db connections will be used. Then what else if thousand of people visit this page, 10 times db connections will be consumed, this is horrible. Therefore, I am wondering how the db connections can be share among the portlet instances.
I read some article saying to use the datasource should be a good idea, however, to remain using dbcp is ideally first place in our consideration.
So any comment is appreciated:)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4091787#4091787
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4091787
18 years, 6 months
[Design of JBossCache] - Proxy Based POJOs (No AOP) in POJO Cache
by jason.greene＠jboss.com
In a conversation we had offline, Vincent Marquez has advocated a proxy based approach in addition to the current AOP approach for POJO Cache. Best of all, he has offered to work on the implementation. The primary use case for this is scenarios where it is impractical or undesirable to instrument classes. With Java 5 loadtime weaving this is less of an issue, but there are still cases where you might not want it, such as:
| * Your app uses conflicting bytecode modification
| * You need to cluster a class you dont know about until AFTER its been loaded, and you dont want to instrument everything
| * Your app uses a serialization framework that is sensitive to the class structure
|
The current proposal would replace conforming non-advised objects with a proxy that would intercept all method calls. One of the restrictions would be that the object must follow the JavaBean style, which allows us to determine the correct operation and attribute we are operating on. This gives us fine-grained replication, does not require the class to implement serializable, and gives us correct object identity semantics. Essentially this is the same behavior of interception used by hibernate.
In summary it would provide close to the same advantages of AOP (over serialization), but with some trade-offs for not requiring instrumentation.
They are:
| * Application code has to reget an object after attaching, so that it can use the proxy instead (this is already the case today with collections)
| * Objects must be java bean style only (getBlah/setBlah), since we can only catch method invocations. However, this is the prevalent style for domain models.
| * Not possible to intercept array access. Application code will have to *touch* the field reference to trigger a compare and update.
|
I think this exchange is worth the added benefits, so provided certain implementation details can be worked out, I am all for this. One such issue is the precedence rules for determining the correct storage handler for an object. We would essentially have 3, Advised, Proxy, and Serialized.
Thoughts?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4091777#4091777
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4091777
18 years, 6 months
[Design of JBoss Remoting, Unified Invokers] - The mad, mad world of Remoting requirements
by david.lloyd＠jboss.com
One thought I am left with after our recent design workshop is that there are a wide variety of expectations for Remoting 3. Accumulating all of my notes, emails, etc., I've discovered that there are some requirements that are in conflict or otherwise don't make a lot of sense to me. So, in no particular order... ;)
Web Services (if I understand correctly) wants to be able to use Remoting like a URLConnection. In other words, open an HTTP connection or JMS session (which one depends on the URI scheme) and shove SOAP through, and (presumably) it will interoperate with whatever is on the other side without the Web Services implementation having to know what protocol is 'really' being used. And on the receiving side, it would be able to accept requests/messages from arbitrary peers (in other words, possibly not running Remoting). In addition, using HTTP should provide a level of abstraction above the HTTP client or server, such that there is no dependency on any specific implementation library.
ESB is less picky - they don't seem to care so much about how message is carried across the protocol. What matters to them are clear semantics of delivery (namely, guaranteed delivery for one-way messages), and a wider variety of transports (including "slower" transports like FTP, Email, etc).
Messaging seems to care about performance over everything. Though AMQP was mentioned a number of times, the underlying protocol seems less important that being able to ship large numbers of messages quickly and with as little loss as possible.
So... my conclusions thus far are as follows:
An HTTP client/server facade library, with implementations wrapping HttpURLConnection/Servlet API/Tomcat/Commons/whatever is definitely a worthwhile project, and could probably be used by many other projects (Remoting included), but I don't see that as part of the core Remoting API. Rather that would be something that could (and should) be its own independent project - maybe even under the higher umbrella of a unified JBoss Connectivity project...
As far as creating a JMS "connection" via URL (JBREM-305 btw)... I'm sorry Thomas, but I don't see how that even makes sense. JMS has its own API - there are topics and queues, transactions, multiple message types... if we were to provide a wrapper API to make it look like something else, I'm certain that JBWS would be the only user (we'd be stripping out anything from the JMS API that makes it useful outside of the one problem domain). If we provide a JMS transport (and I'm not saying that we won't), it would meet the requirements for passing Remoting invocations, which I cannot guarantee will match the requirements for passing SOAP messages (unless they're tunneled within a Remoting Request). And I definitely don't want to have to deal with interoperability between Remoting 3 and whatever random SOAP-over-JMS consumer is out there.
Right now Remoting 3 focuses on invocation, and moving data from one endpoint to another in a protocol-agnostic fashion. It is not, nor can it become, a protocol-silver-bullet that allows your app to speak any protocol. If such a thing were possible, you wouldn't need separate APIs for HTTP, JMS, AMQP, CORBA, RMI, etc. The fact is that all these protocols have different semantics, and if we try to generically support them all at a low level with the same API, we're going to create a framework that does everything maybe kind of OK, but nothing particularly well.
The addition of "slow" protocols is an odd fit to be sure, but I'm pretty sure that it can be done in a way that fulfills the requirements of ESB (or WS for that matter) as long as the format of the message in transit is not important. However I suspect that a better mechanism could be devised with this specific use case in mind (that is, one-way messages only, slow transports, programmable delivery guarantee). So I'm still unsure what the right way to go with this is.
I would hope that even using the regular high-level API would perform sufficiently well for JBM. However, Remoting does serialize and deserialize every message sent back and forth, and there are other overheads as well, so it is possible that performance of Remoting will not meet the requirements of JBM no matter what we do. Only the numbers will tell I suppose.
I hope this was reasonably coherent - the main point I want to get across is that I think Remoting should be less concerned with protocol interoperability and more concerned with satisfying the requirements of the higher-level API in the most effective way possible for each underlying protocol. Systems that need protocol-specific interoperability cannot make this guarantee without using APIs that are tailored to each protocol.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4091768#4091768
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4091768
18 years, 6 months