A small issue with this: With JMS Inbound EP's we let the users define the destination they would like to poll - if the destination doesn't exist we will create it for them (including any tenancy identifier in the destination name).
But if the user simply wants to listen to a particular destination already created, then we can't include any tenancy information in the lookup. Should we not allow the user to specify a destination name (restrictive) or should we assume if a destination is given then it will be the user's responsibility to include any tenant information (sucks from a usage POV)? On Fri, Apr 4, 2014 at 12:36 PM, Pamod Sylvester <[email protected]> wrote: > In MB we prefix the queue name with the tenant domain name. for example If > the tenant is 'wso2.com', the name of the queue is 'ordersQueue' the > queue name reflected through the tenant will be "wso2.com/ordersQueue". > > Thanks, > Pamod > > > On Fri, Apr 4, 2014 at 12:08 PM, Paul Fremantle <[email protected]> wrote: > >> We already have a multi-tenant JMS model in MB. We should use the same. >> >> Paul >> >> >> On 4 April 2014 07:25, Jeewantha Dharmaparakrama <[email protected]>wrote: >> >>> When multi tenancy is used with JMS transport it might be a good idea to >>> make the queue name unique for a tenent maybe with some format like >>> <queue-name>.<tenent-name>. This can reduce the risk of two tenants using >>> the same queue. >>> >>> >>> On Fri, Apr 4, 2014 at 10:51 AM, Kasun Indrasiri <[email protected]> wrote: >>> >>>> Hi, >>>> >>>> We have been working on the initial design for the Inbound Endpoint >>>> support for ESB. >>>> >>>> - Inbound endpoint is a dynamically configured message source for ESB. >>>> - The current axis2 based transports other than HTTP/S doesn't work in >>>> multitenant mode. The main idea is to supporting all transport (not only >>>> HTTP) in multi-tenant mode with the introduction of inbound endpoints. >>>> - The inbound endpoints will have multiple behavior based on >>>> implementation: polling, busy wait or listening. >>>> - In W/M separated setups, the coordination requirements for polling >>>> behavior is handled by taks which is based on ntasks. >>>> >>>> This is the initial syntax we came up with: >>>> >>>> <inboundEndpoint name="MyJMSListenerEP" >>>> >>>> protocol="jms" >>>> >>>> interval="1000" suspend="false"> >>>> >>>> <parameters> >>>> >>>> <parameter >>>> name="java.naming.factory.initial">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter> >>>> >>>> <parameter >>>> name="java.naming.provider.url">tcp://localhost:61616</parameter> >>>> >>>> <parameter >>>> name="jms.ConnectionFactoryJNDIName">QueueConnectionFactory</parameter> >>>> >>>> <parameter name="jms.ConnectionFactoryType">queue</parameter> >>>> >>>> <parameter name="jms.Destination">ordersQueue</parameter> >>>> >>>> </parameters> >>>> >>>> <sequence key="requestHandlerSeq" onError="inFault"/> >>>> >>>> </inboundEndpoint> >>>> >>>> >>>> The inbound endpoint will be a new construct in ESB which goes at the >>>> top level as with proxy services, APIs etc. >>>> >>>> I have completed the initial work related to inbound EP and implemented >>>> a basic JMS inbound EP. Also I've verified the functionality in super >>>> tenant and tenant mode as well. >>>> Ravi is working on getting the end to end scenario working for JMS >>>> Inbound EP. >>>> >>>> Please review the design and share your thoughts. >>>> >>>> Thanks, >>>> Kasun >>>> >>>> -- >>>> Kasun Indrasiri >>>> Software Architect >>>> WSO2, Inc.; http://wso2.com >>>> lean.enterprise.middleware >>>> >>>> cell: +94 77 556 5206 >>>> Blog : http://kasunpanorama.blogspot.com/ >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Jeewantha Dharmaparakrama >>> Software Engineer; WSO2, Inc.; http://wso2.com/ >>> Phone : (+94) 774726790 >>> Skype : prasad.jeewantha >>> LinkedIn : http://www.linkedin.com/in/jeewanthad >>> Twitter: https://twitter.com/jeewamp >>> Blog: http://jeewanthad.blogspot.com/ >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Paul Fremantle >> CTO and Co-Founder, WSO2 >> OASIS WS-RX TC Co-chair, Apache Member >> >> UK: +44 207 096 0336 >> US: +1 646 595 7614 >> >> blog: http://pzf.fremantle.org >> twitter.com/pzfreo >> [email protected] >> >> wso2.com Lean Enterprise Middleware >> >> Disclaimer: This communication may contain privileged or other >> confidential information and is intended exclusively for the addressee/s. >> If you are not the intended recipient/s, or believe that you may have >> received this communication in error, please reply to the sender indicating >> that fact and delete the copy you received and in addition, you should not >> print, copy, retransmit, disseminate, or otherwise use the information >> contained in this communication. Internet communications cannot be >> guaranteed to be timely, secure, error or virus-free. The sender does not >> accept liability for any errors or omissions. >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Pamod Sylvester * > * Software Engineer * > Integration Technologies Team, WSO2 Inc.; http://wso2.com > email: [email protected] cell: +94 77 7779495 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Ravi Undupitiya* Software Engineer; WSO2 Inc.; http://wso2.com *E-mail: [email protected] <http://wso2.com>**M: **+94 772 930 712* Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
