Hi Suho, As per the offline chat we had, we did change the design so that we can obtain the native format and we can register a handler which can build the message in to any required format. Malaka is working on applying these changes and lets do a review once we have it up and running.
On Mon, Apr 21, 2014 at 10:07 AM, Sriskandarajah Suhothayan <[email protected]>wrote: > Great :) > Please make then to work in their native form. > i.e When using the JMS Utils they will return the message received in the > native format itself (XML, JSON, Map) and it will not auto convert all > messages to XML like what axis2 JMS transport was doing etc. > > We'll work with you on the integration > > Thanks > Suho > > > On Mon, Apr 21, 2014 at 9:56 AM, Kasun Indrasiri <[email protected]> wrote: > >> Hi Suho, >> >> We are not dependent on any axis2 related transport. The generic >> functionalities related to protocols such as JMS and VFS are implemented as >> Utils. >> So, we should be able to reuse them with in CEP too. >> >> >> On Sat, Apr 19, 2014 at 10:37 AM, Sriskandarajah Suhothayan < >> [email protected]> wrote: >> >>> @Kasun >>> >>> Can you elaborate a bit on the backend. >>> Are we reusing/improving the Axis2 JMS transport or will this be a new >>> implementation or module ? >>> >>> This is because CEP also has use-cases on working with JMS Brokers so >>> its good if CEP can also reuse this implementation. >>> >>> Regards >>> Suho >>> >>> >>> On Wed, Apr 16, 2014 at 2:08 PM, Kasun Indrasiri <[email protected]> wrote: >>> >>>> We need to finalize the tooling aspect of this too. Ideally this is >>>> another entry point to ESB, which is very similar to a proxy service or a >>>> REST api. Any thoughts on how we should proceed with the tooling aspect of >>>> this? >>>> >>>> >>>> On Wed, Apr 9, 2014 at 3:01 PM, Kasun Indrasiri <[email protected]> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Mon, Apr 7, 2014 at 10:18 PM, Sanjiva Weerawarana <[email protected] >>>>> > wrote: >>>>> >>>>>> I don't understand what doesn't support MT means in this case. Lets >>>>>> take SMTP- each inbound endpoint will give its own email address and poll >>>>>> from that. Where's MTness involved? >>>>>> >>>>>> Isn't the same true or JMS? You just give a queue - its someone >>>>>> else's problem to make sure queues are properly allocated and protected. >>>>>> >>>>>> Yeah, I think if we consider a scenario where ESB and MB are >>>>> involved. A given user can create a queue in MB and MB will take care of >>>>> adding required info( such as appending tenant domain etc) in to the queue >>>>> name (similar logic should apply when we create a subscription too). Then >>>>> we create the inbound endpoint, we should give the exact same destination. >>>>> If we are using any other broker, then it is up to the broker to handle >>>>> security etc. >>>>> >>>>>> Sanjiva. >>>>>> >>>>>> >>>>>> 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/ >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Sanjiva Weerawarana, Ph.D. >>>>>> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ >>>>>> email: [email protected]; office: (+1 650 745 4499 | +94 11 214 >>>>>> 5345) x5700; cell: +94 77 787 6880 | +1 408 466 5099; voip: +1 650 >>>>>> 265 8311 >>>>>> blog: http://sanjiva.weerawarana.org/; twitter: @sanjiva >>>>>> >>>>>> Lean . Enterprise . Middleware >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Kasun Indrasiri >>>>> Software Architect >>>>> WSO2, Inc.; http://wso2.com >>>>> lean.enterprise.middleware >>>>> >>>>> cell: +94 77 556 5206 >>>>> Blog : http://kasunpanorama.blogspot.com/ >>>>> >>>> >>>> >>>> >>>> -- >>>> 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 >>>> >>>> >>> >>> >>> -- >>> >>> *S. Suhothayan* >>> Associate Technical Lead, >>> *WSO2 Inc. *http://wso2.com >>> * <http://wso2.com/>* >>> lean . enterprise . middleware >>> >>> >>> >>> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: >>> http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/> twitter: >>> http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: >>> http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>* >>> >>> >> >> >> -- >> Kasun Indrasiri >> Software Architect >> WSO2, Inc.; http://wso2.com >> lean.enterprise.middleware >> >> cell: +94 77 556 5206 >> Blog : http://kasunpanorama.blogspot.com/ >> > > > > -- > > *S. Suhothayan* > Associate Technical Lead, > *WSO2 Inc. *http://wso2.com > * <http://wso2.com/>* > lean . enterprise . middleware > > > *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: > http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/> twitter: > http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: > http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>* > > -- 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
