Re: [Architecture] IBM MQ Inbound/Connector for WSO2 ESB

[Chanaka Fernando]

Hi Krishanthy,

It is always better to work with the latest stable release. My suggestion
is to go with V8.X if it is the latest.

On Wed, Sep 16, 2015 at 11:50 AM, Kirishanthy Tharmalingam <
kirishan...@wso2.com> wrote:

> Hi All,
>
>
> I have planned to develop $subject. IBM MQ facilitates the secure and
> reliable exchange of information between applications, systems, services
> and file by sending and receiving message data via messaging queues.
>
>
> There are some version in IBM MQ(IBM MQ V8.0.0, WebSphere MQ V7.5.0,
> WebSphere MQ V7.1.0 and WebSphere MQ V7.0.1).
>
>
> Can anyone suggest which version is suitable ?
>
> Please give some suggestion and guidance on this.
> --
> Thanks & Regards,
> Kirishanthy.T
> Associate Software Engineer
> Mobile : +94 778333939
> kirishan...@wso2.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
--
Chanaka Fernando
Senior Technical Lead
WSO2, Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94 773337238
Blog : http://soatutorials.blogspot.com
LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
Twitter:https://twitter.com/chanakaudaya
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] IBM MQ Inbound/Connector for WSO2 ESB

[Kirishanthy Tharmalingam]

Hi All,


I have planned to develop $subject. IBM MQ facilitates the secure and
reliable exchange of information between applications, systems, services
and file by sending and receiving message data via messaging queues.


There are some version in IBM MQ(IBM MQ V8.0.0, WebSphere MQ V7.5.0,
WebSphere MQ V7.1.0 and WebSphere MQ V7.0.1).


Can anyone suggest which version is suitable ?

Please give some suggestion and guidance on this.
-- 
Thanks & Regards,
Kirishanthy.T
Associate Software Engineer
Mobile : +94 778333939
kirishan...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Adding/Managing Sensor information on CDMF

[Dulitha Wijewantha]

On Wed, Sep 16, 2015 at 3:48 PM, Sachith Withana  wrote:

> Hi Ayoob,
>
> Just to clarify, when you said "each sensor has its own stream
> definition", you meant each sensor type ( ex: temperature, GPRS ...etc) or
> for each sensor for each device ( mobile phone temp sensor vs fire alarm
> sensor?) would have their own stream definitions?
>
> On Tue, Sep 15, 2015 at 4:50 PM, Ayyoob Hamza  wrote:
>
>> Hi,
>>
>> In IoT Server, we have a requirement of identifying the event streams
>> that a specific device-type caters (eg: Temperature, Humidity, GPRS).
>> Currently we don't have a separate way of identifying this on CDMF. At an
>> abstract level a device type can be thought of as having multiple sensors.
>> A specific sensor can exist in multiple device types.
>>
>> As a suggestion we can implement $subject by defining a sensor module
>> where each sensor has its own stream definition. Doing so we can create an
>> association between the device-type and sensors.
>>
>> eg:
>> Fire alarm has a temperature sensor and Mobile Phone has a GPRS plus a
>> temperature sensor, so we need to able to plot this information by
>> identifying corresponding sensors from each device type.
>>
>> Therefore this brings about the need of separately managing sensors and
>> device types which will ensure zero duplication of sensor information.
>>
>>
>> ​This is just a thought as to how we can extend CDMF to cater sensor
>> management. Please give us your comments and suggestions on $subject
>>
> ​I think there is a broader question to ask whether we do need to support
sensor management holistically? For example - do we consider temperature
sensors in a floor as individual sensors or a floor of sensors. My idea is
- a collection of sensors can be considered as a device. To explain it
further - I see two scenarios where sensors are in play:- a device has a
sensor (or the sensor is a smart sensor), dumb sensors connected to a
hub(device). So in that understanding - we can simplify the proposed model
to have DM_DEVICE table and SENSOR table with Device ID.
​
​

​To take my previous example where I used the floor - there is a device
(hub)​ for that particular floor. And the sensors are connected to the
device. We manage the sensor details and device details.

​Counter argument to my proposal would be - will it be useful or important
to manage sensor details without corresponding device details? ​



>> Thanks,
>> *Ayyoob Hamza*
>> *Software Engineer*
>> WSO2 Inc.; http://wso2.com
>> email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Sachith Withana
> Software Engineer; WSO2 Inc.; http://wso2.com
> E-mail: sachith AT wso2.com
> M: +94715518127
> Linked-In: 
> https://lk.linkedin.com/in/sachithwithana
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Dulitha Wijewantha (Chan)
Software Engineer - Mobile Development
WSO2 Inc
Lean.Enterprise.Middleware
 * ~Email   duli...@wso2.com *
*  ~Mobile +94712112165*
*  ~Website   dulitha.me *
*  ~Twitter @dulitharw *
  *~Github @dulichan *
  *~SO @chan *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [DAS] Modifying the migration tool to use Hector replacing CQL

[Malith Dhanushka]

Hi Sachith,

+1 for using Hector and this will be a handy utility tool for DAS as well.
Because anyone who has Cassandra raw data can use this tool to persist them
in any file store facilitated by DAL. Given the fact, is it worth the
effort implementing this as a generic tool? WDUT?

Thanks,
Malith

On Wed, Sep 16, 2015 at 10:54 AM, Sachith Withana  wrote:

> Hi all,
>
> DAS migration tool is used to migrate the data from BAM deployments to
> DAS.
>
> Basically how it works is, it reads the records from Cassandra column
> families (of BAM) and inserts them to DAS analytics tables at the Data
> Access Layer (DAL) level.
>
> BAM uses Cassandra 1.x versions and the previous iteration of the tool was
> using CQL to get all the records from a given column family and insert them
> to DAL.
>
> But for large amounts of records read from BAM caused CQL to throw an
> OutOfMemory exception from the GC, since CQL is trying to load all the
> records to memory ( using select * from *tableName* ).
>
> Therefore we had to introduce pagination support by rewriting the
> migration tool using the Hector Driver.
>
> Now the hector based implementation reads in records batch-wise ( the
> batch size is configurable) and inserts to DAL thus taking out the
> possibility of running out of memory.
>
> Thanks,
> Sachith
> --
> Sachith Withana
> Software Engineer; WSO2 Inc.; http://wso2.com
> E-mail: sachith AT wso2.com
> M: +94715518127
> Linked-In: 
> https://lk.linkedin.com/in/sachithwithana
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Malith Dhanushka
Senior Software Engineer - Data Technologies
*WSO2, Inc. : wso2.com *
*Mobile*  : +94 716 506 693
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] IBM MQ Inbound/Connector for WSO2 ESB

[Gabriel Popa]

  Hi,


I suggest to start with 7.5 version. A lot of customers are using this version 
and they are late in upgrading because of licensing price. In the end, 
everything can be tested against latest version.


Thank you,
  
  
  --
Gabriel Popa | WSO2 Partner

> On Sep 16, 2015, at 9:20 AM, Kirishanthy Tharmalingam  
> wrote:
> 
> 
> Hi All,
> 
> 
> 
> 
> I have planned to develop $subject. IBM MQ facilitates the secure and 
> reliable exchange of information between applications, systems, services and 
> file by sending and receiving message data via messaging queues.
> 
> 
> 
> 
> 
> There are some version in IBM MQ(IBM MQ V8.0.0, WebSphere MQ V7.5.0, 
> WebSphere MQ V7.1.0 and WebSphere MQ V7.0.1).
> 
> 
> 
> 
> Can anyone suggest which version is suitable ?
> 
> Please give some suggestion and guidance on this.
> 
> 
> 
> -- 
> Thanks & Regards,
> Kirishanthy.T
> 
> Associate Software Engineer
> 
> Mobile : +94 778333939
> 
> kirishan...@wso2.com
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
> 
> 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [DAS] Modifying the migration tool to use Hector replacing CQL

[Malith Dhanushka]

I mean are we shipping this with DAS as a default tool?

On Wed, Sep 16, 2015 at 1:43 PM, Sachith Withana  wrote:

> @Malith
> What do you mean as a generic tool?
>
> @Ramith
> I think that only works with Cassandra 2.0 onwards (If I'm not mistaken)
> and BAM uses Cassandra 1.x versions. That was the initial issue.
>
> On Wed, Sep 16, 2015 at 1:18 PM, Ramith Jayasinghe 
> wrote:
>
>> so,
>>
>> http://docs.datastax.com/en/drivers/java/2.0/com/datastax/driver/core/ResultSet.html#fetchMoreResults()
>>  doesn't work for you?
>>
>> On Wed, Sep 16, 2015 at 12:22 PM, Malith Dhanushka 
>> wrote:
>>
>>> Hi Sachith,
>>>
>>> +1 for using Hector and this will be a handy utility tool for DAS as
>>> well. Because anyone who has Cassandra raw data can use this tool to
>>> persist them in any file store facilitated by DAL. Given the fact, is it
>>> worth the effort implementing this as a generic tool? WDUT?
>>>
>>> Thanks,
>>> Malith
>>>
>>> On Wed, Sep 16, 2015 at 10:54 AM, Sachith Withana 
>>> wrote:
>>>
 Hi all,

 DAS migration tool is used to migrate the data from BAM deployments to
 DAS.

 Basically how it works is, it reads the records from Cassandra column
 families (of BAM) and inserts them to DAS analytics tables at the Data
 Access Layer (DAL) level.

 BAM uses Cassandra 1.x versions and the previous iteration of the tool
 was using CQL to get all the records from a given column family and insert
 them to DAL.

 But for large amounts of records read from BAM caused CQL to throw an
 OutOfMemory exception from the GC, since CQL is trying to load all the
 records to memory ( using select * from *tableName* ).

 Therefore we had to introduce pagination support by rewriting the
 migration tool using the Hector Driver.

 Now the hector based implementation reads in records batch-wise ( the
 batch size is configurable) and inserts to DAL thus taking out the
 possibility of running out of memory.

 Thanks,
 Sachith
 --
 Sachith Withana
 Software Engineer; WSO2 Inc.; http://wso2.com
 E-mail: sachith AT wso2.com
 M: +94715518127
 Linked-In: 
 https://lk.linkedin.com/in/sachithwithana

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>>
>>> --
>>> Malith Dhanushka
>>> Senior Software Engineer - Data Technologies
>>> *WSO2, Inc. : wso2.com *
>>> *Mobile*  : +94 716 506 693
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Ramith Jayasinghe
>> Technical Lead
>> WSO2 Inc., http://wso2.com
>> lean.enterprise.middleware
>>
>> E: ram...@wso2.com
>> P: +94 777542851
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Sachith Withana
> Software Engineer; WSO2 Inc.; http://wso2.com
> E-mail: sachith AT wso2.com
> M: +94715518127
> Linked-In: 
> https://lk.linkedin.com/in/sachithwithana
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Malith Dhanushka
Senior Software Engineer - Data Technologies
*WSO2, Inc. : wso2.com *
*Mobile*  : +94 716 506 693
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Adding/Managing Sensor information on CDMF

[Ayyoob Hamza]

@Dulitha and @ Sachith
I see both your comments ends with the same question whether we need to
have event stream definition for each sensor type or do we need to maintain
a separate event stream for each sensor type on a device type ?.

eg:  stream definition:
Use Case 1 : org.wso2.devices.temperature (within payload send the device
type and device Id)
Use Case 2 :
org.wso2.devices.firealarm.temperature, org.wso2.devices.mobile.temperature

This depends on the use case we think about and I see both scenarios can be
a valid argument. The question is to know whether we need to know the
sensor analysis within a device type or across device types. To cater both
scenario thought to have a sensor management as a separate module.

This is just a thought process to bring up the concern of the problem. This
needs to be further discussed with the team.
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [ESB-Connector] EJB Connector

[Rajjaz Mohammed]

On Wed, Sep 16, 2015 at 2:04 PM, Rajjaz Mohammed  wrote:

> Hi All,
> I have planned to Implement EJB Connector for WSO2 ESB. Currently, EJB
> mediator supports EJB3 Stateless Session Beans and Stateful Session Beans.
> Since EJB mediator have some isues EJB Connector will include the
> Functionality of  EJB mediator which calls an external Enterprise JavaBean
> (EJB) and stores the result in the message payload or in a message context
> property.
>
> This is my Basic Idea so If you have anything  to add/change in EJB
> Connector please add in this Thread. and Connector will be Separate for EJB
> 2.0 & 3.0.
>
> --
> Thank you
> Best Regards
>
> *Rajjaz HM*
> Associate Software Engineer
> WSO2 Inc. 
> lean | enterprise | middleware
> Mobile | +94752833834
> Email   | raj...@wso2.com
> LinkedIn | Blogger | WSO2 Profile
> 
>



-- 
Thank you
Best Regards

*Rajjaz HM*
Associate Software Engineer
WSO2 Inc. 
lean | enterprise | middleware
Mobile | +94752833834
Email   | raj...@wso2.com
LinkedIn | Blogger | WSO2 Profile

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [ESB-Connector] EJB Connector

[Rajjaz Mohammed]

Hi All,
I have planned to Implement EJB Connector for WSO2 ESB. Currently, EJB
mediator supports EJB3 Stateless Session Beans and Stateful Session Beans.
Since EJB mediator have some isues EJB Connector will include the
Functionality of  EJB mediator which calls an external Enterprise JavaBean
(EJB) and stores the result in the message payload or in a message context
property.

This is my Basic Idea so If you have anything  to add/change in EJB
Connector please add in this Thread. and Connector will be Separate for EJB
2.0 & 3.0.

-- 
Thank you
Best Regards

*Rajjaz HM*
Associate Software Engineer
WSO2 Inc. 
lean | enterprise | middleware
Mobile | +94752833834
Email   | raj...@wso2.com
LinkedIn | Blogger | WSO2 Profile

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Hard Throttling limit for APIs

[Amila De Silva]

On Wed, Sep 9, 2015 at 11:47 AM, Sanjeewa Malalgoda 
wrote:

> I also believe we should use existing handler without writing new one.
>
> And regarding registry decoupling, publisher may be able to push API to
> gateway as we do now.
> And just before we call rest API admin service we may call registry admin
> service(may be we need to write simple service for this as flow continue
> with super admin - super tenant deployed multi tenanted service) and push
> tiers.xml file.
> With that we may keep registry separation between gateway and publisher.
> That would be valuable when we have MZ and DMZ pattern and gateway in DMZ.
>
> Thanks,
> sanjeewa.
>
>
> On Tue, Sep 8, 2015 at 11:11 PM, Amila De Silva  wrote:
>
>> Hi Nuwan,
>>
>>
>>
>> On Tue, Sep 8, 2015 at 9:58 PM, Nuwan Dias  wrote:
>>
>>> This design brings on a hard (mandatory) dependency to the registry from
>>> the API Gateway right? If each API is to have its own policy definition,
>>> the publisher and gateway must connect to a single registry. This will
>>> cause problems in some deployment patterns which have the Gateway in DMZ
>>> and publisher in the LAN. Can our throttling engine work if we just feed it
>>> the request count and unit time without feeding it a policy definition?
>>>
>>
>> Not in a very straightforward way. The API exposed by throttle.core only
>> allows passing ThrottleContext, a key and the Tier name. When going through
>> the usages of ThrottleContext it seems that it can only be created out from
>> a policy file. But need to check if it's possible to create ThrottleContext
>> only using unit time and MaxRequest count.
>>
>>> If that works then we can survive without the registry for this.
>>>
>> We can keep max request count and unit time in the API itself. While
initialising the APIThrottleHandler, a policy.xml has to be created out of
these values and the generated policy will be used to create the
ThrottleContext. Dynamic policy won't be stored anywhere, so when moving
the API from one environment to another, there won't be a risk of losing
anything.

For the scope of this feature, should be consider about providing
capability to specify hard throttling limits per each resource verb
combination.

>
>> Another option is to use the same tiers.xml that is being used for other
>> throttling cases and refer to a role defined there. If needed to update/add
>> a new tier it will have to be done through tier edit UI. Even with this
>> approach, the problem won't be completely solved.
>>
>>>
>>> Why would we need a new handler? What would be the drawbacks of using
>>> the existing handler?
>>>
>> We can use the existing one.
>>
>>>
>>> The location to get the limit would be on the API Implement section IMO.
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>> On Tue, Sep 8, 2015 at 9:40 PM, Amila De Silva  wrote:
>>>
 Hi,

 Current Throttling capabilities of API Manager only allows defining
 user wise and Application wise Access Quotas.


 For example when considering an Application and a set of APIs
 Subscribed, like below (tier limit is shown next to the API)

 Application-1 (1000 Req/min)
 |
 +-+API-1 (10 Req/min)
 |
 +-+API-2 (1 Req/min)
 |
 +-+API-3 (5 Req/min)

 each new token would allow end-users to make the number of requests
 defined by the tier. Using a token generated for Application-1, API1 can be
 invoked at a rate of 10 Req/min, API-2 - 1Req/min and likewise. So when a
 new user signs in, there'd be a potential increase in the traffic on the
 API.

 As of now there isn't a way to limit the total number of calls made on
 an API. Tiers defined at the API Level, doesn't reflect the global limit of
 the backend; which means that, as an API keeps gathering users, hits on the
 Backend would also keep increasing without being controlled.

 With API Manager 1.10.0, the plan is to provide the capability to
 define Hard Throttling limits for APIs. The limit will be defined per API
 basis, and this usually will reflect the number of requests the actual
 backend can handle.

 This feature warrants several changes on API Designing UI, and those
 can be discussed in detail in mails to follow.

 If giving a high level idea about the flow.
 1. API creator logs into the publisher and creates an API.
 2. API Creator enables Hard Limit throttling for the API.
 3. Number of requests allowed and Unit Time is specified.
 4. Changes are saved and Published to the Gateway.

 When saving the API, a throttling policy specific to the API will be
 created and saved in the registry.

 For enforcing throttling limit, a new handler will be written, which
 would only appear for those APIs on which Hard limit is enabled. The
 handler would refer to the policy saved to the registry and would apply the
 

Re: [Architecture] [DAS] Modifying the migration tool to use Hector replacing CQL

[Sachith Withana]

Yes. We are shipping the tool with DAS.

On Wed, Sep 16, 2015 at 1:52 PM, Malith Dhanushka  wrote:

> I mean are we shipping this with DAS as a default tool?
>
> On Wed, Sep 16, 2015 at 1:43 PM, Sachith Withana  wrote:
>
>> @Malith
>> What do you mean as a generic tool?
>>
>> @Ramith
>> I think that only works with Cassandra 2.0 onwards (If I'm not mistaken)
>> and BAM uses Cassandra 1.x versions. That was the initial issue.
>>
>> On Wed, Sep 16, 2015 at 1:18 PM, Ramith Jayasinghe 
>> wrote:
>>
>>> so,
>>>
>>> http://docs.datastax.com/en/drivers/java/2.0/com/datastax/driver/core/ResultSet.html#fetchMoreResults()
>>>  doesn't work for you?
>>>
>>> On Wed, Sep 16, 2015 at 12:22 PM, Malith Dhanushka 
>>> wrote:
>>>
 Hi Sachith,

 +1 for using Hector and this will be a handy utility tool for DAS as
 well. Because anyone who has Cassandra raw data can use this tool to
 persist them in any file store facilitated by DAL. Given the fact, is it
 worth the effort implementing this as a generic tool? WDUT?

 Thanks,
 Malith

 On Wed, Sep 16, 2015 at 10:54 AM, Sachith Withana 
 wrote:

> Hi all,
>
> DAS migration tool is used to migrate the data from BAM deployments to
> DAS.
>
> Basically how it works is, it reads the records from Cassandra column
> families (of BAM) and inserts them to DAS analytics tables at the Data
> Access Layer (DAL) level.
>
> BAM uses Cassandra 1.x versions and the previous iteration of the tool
> was using CQL to get all the records from a given column family and insert
> them to DAL.
>
> But for large amounts of records read from BAM caused CQL to throw an
> OutOfMemory exception from the GC, since CQL is trying to load all the
> records to memory ( using select * from *tableName* ).
>
> Therefore we had to introduce pagination support by rewriting the
> migration tool using the Hector Driver.
>
> Now the hector based implementation reads in records batch-wise ( the
> batch size is configurable) and inserts to DAL thus taking out the
> possibility of running out of memory.
>
> Thanks,
> Sachith
> --
> Sachith Withana
> Software Engineer; WSO2 Inc.; http://wso2.com
> E-mail: sachith AT wso2.com
> M: +94715518127
> Linked-In: 
> https://lk.linkedin.com/in/sachithwithana
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


 --
 Malith Dhanushka
 Senior Software Engineer - Data Technologies
 *WSO2, Inc. : wso2.com *
 *Mobile*  : +94 716 506 693

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>>
>>> --
>>> Ramith Jayasinghe
>>> Technical Lead
>>> WSO2 Inc., http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> E: ram...@wso2.com
>>> P: +94 777542851
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Sachith Withana
>> Software Engineer; WSO2 Inc.; http://wso2.com
>> E-mail: sachith AT wso2.com
>> M: +94715518127
>> Linked-In: 
>> https://lk.linkedin.com/in/sachithwithana
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Malith Dhanushka
> Senior Software Engineer - Data Technologies
> *WSO2, Inc. : wso2.com *
> *Mobile*  : +94 716 506 693
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Sachith Withana
Software Engineer; WSO2 Inc.; http://wso2.com
E-mail: sachith AT wso2.com
M: +94715518127
Linked-In: https://lk.linkedin.com/in/sachithwithana
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Hard Throttling limit for APIs

[Amila De Silva]

On Wed, Sep 16, 2015 at 1:42 PM, Amila De Silva  wrote:

>
> On Wed, Sep 9, 2015 at 11:47 AM, Sanjeewa Malalgoda 
> wrote:
>
>> I also believe we should use existing handler without writing new one.
>>
>> And regarding registry decoupling, publisher may be able to push API to
>> gateway as we do now.
>> And just before we call rest API admin service we may call registry admin
>> service(may be we need to write simple service for this as flow continue
>> with super admin - super tenant deployed multi tenanted service) and push
>> tiers.xml file.
>> With that we may keep registry separation between gateway and publisher.
>> That would be valuable when we have MZ and DMZ pattern and gateway in DMZ.
>>
>> Thanks,
>> sanjeewa.
>>
>>
>> On Tue, Sep 8, 2015 at 11:11 PM, Amila De Silva  wrote:
>>
>>> Hi Nuwan,
>>>
>>>
>>>
>>> On Tue, Sep 8, 2015 at 9:58 PM, Nuwan Dias  wrote:
>>>
 This design brings on a hard (mandatory) dependency to the registry
 from the API Gateway right? If each API is to have its own policy
 definition, the publisher and gateway must connect to a single registry.
 This will cause problems in some deployment patterns which have the Gateway
 in DMZ and publisher in the LAN. Can our throttling engine work if we just
 feed it the request count and unit time without feeding it a policy
 definition?

>>>
>>> Not in a very straightforward way. The API exposed by throttle.core only
>>> allows passing ThrottleContext, a key and the Tier name. When going through
>>> the usages of ThrottleContext it seems that it can only be created out from
>>> a policy file. But need to check if it's possible to create ThrottleContext
>>> only using unit time and MaxRequest count.
>>>
 If that works then we can survive without the registry for this.

>>> We can keep max request count and unit time in the API itself. While
> initialising the APIThrottleHandler, a policy.xml has to be created out of
> these values and the generated policy will be used to create the
> ThrottleContext. Dynamic policy won't be stored anywhere, so when moving
> the API from one environment to another, there won't be a risk of losing
> anything.
>
> For the scope of this feature, should be consider about providing
> capability to specify hard throttling limits per each resource verb
> combination.
>

Accidentally sent the mail halfway :)

What I was going to highlight was need of having different hard limits for
each resource + verb combination.

Not every resource of an API, consume the same amount of server resources.
For example, when sending response to an OPTIONS call, the backend might be
sending a cached (or a static) response, whilst when responding to a POST,
it might be doing several DB calls back and forth. Actually, it might be an
overflow of POST requests that can take the back-end down. So while
specifying a quota, heavy weight resources should be given less quota, and
lightweight (but more frequently accessed resources) should be given a
higher quota.

Another option is to use the same tiers.xml that is being used for other
>>> throttling cases and refer to a role defined there. If needed to update/add
>>> a new tier it will have to be done through tier edit UI. Even with this
>>> approach, the problem won't be completely solved.
>>>

 Why would we need a new handler? What would be the drawbacks of using
 the existing handler?

>>> We can use the existing one.
>>>

 The location to get the limit would be on the API Implement section IMO.

 Thanks,
 NuwanD.

 On Tue, Sep 8, 2015 at 9:40 PM, Amila De Silva  wrote:

> Hi,
>
> Current Throttling capabilities of API Manager only allows defining
> user wise and Application wise Access Quotas.
>
>
> For example when considering an Application and a set of APIs
> Subscribed, like below (tier limit is shown next to the API)
>
> Application-1 (1000 Req/min)
> |
> +-+API-1 (10 Req/min)
> |
> +-+API-2 (1 Req/min)
> |
> +-+API-3 (5 Req/min)
>
> each new token would allow end-users to make the number of requests
> defined by the tier. Using a token generated for Application-1, API1 can 
> be
> invoked at a rate of 10 Req/min, API-2 - 1Req/min and likewise. So when a
> new user signs in, there'd be a potential increase in the traffic on the
> API.
>
> As of now there isn't a way to limit the total number of calls made on
> an API. Tiers defined at the API Level, doesn't reflect the global limit 
> of
> the backend; which means that, as an API keeps gathering users, hits on 
> the
> Backend would also keep increasing without being controlled.
>
> With API Manager 1.10.0, the plan is to provide the capability to
> define Hard Throttling limits for APIs. The limit will be defined per API

Re: [Architecture] [DAS] Modifying the migration tool to use Hector replacing CQL

[Sachith Withana]

@Malith
What do you mean as a generic tool?

@Ramith
I think that only works with Cassandra 2.0 onwards (If I'm not mistaken)
and BAM uses Cassandra 1.x versions. That was the initial issue.

On Wed, Sep 16, 2015 at 1:18 PM, Ramith Jayasinghe  wrote:

> so,
>
> http://docs.datastax.com/en/drivers/java/2.0/com/datastax/driver/core/ResultSet.html#fetchMoreResults()
>  doesn't work for you?
>
> On Wed, Sep 16, 2015 at 12:22 PM, Malith Dhanushka 
> wrote:
>
>> Hi Sachith,
>>
>> +1 for using Hector and this will be a handy utility tool for DAS as
>> well. Because anyone who has Cassandra raw data can use this tool to
>> persist them in any file store facilitated by DAL. Given the fact, is it
>> worth the effort implementing this as a generic tool? WDUT?
>>
>> Thanks,
>> Malith
>>
>> On Wed, Sep 16, 2015 at 10:54 AM, Sachith Withana 
>> wrote:
>>
>>> Hi all,
>>>
>>> DAS migration tool is used to migrate the data from BAM deployments to
>>> DAS.
>>>
>>> Basically how it works is, it reads the records from Cassandra column
>>> families (of BAM) and inserts them to DAS analytics tables at the Data
>>> Access Layer (DAL) level.
>>>
>>> BAM uses Cassandra 1.x versions and the previous iteration of the tool
>>> was using CQL to get all the records from a given column family and insert
>>> them to DAL.
>>>
>>> But for large amounts of records read from BAM caused CQL to throw an
>>> OutOfMemory exception from the GC, since CQL is trying to load all the
>>> records to memory ( using select * from *tableName* ).
>>>
>>> Therefore we had to introduce pagination support by rewriting the
>>> migration tool using the Hector Driver.
>>>
>>> Now the hector based implementation reads in records batch-wise ( the
>>> batch size is configurable) and inserts to DAL thus taking out the
>>> possibility of running out of memory.
>>>
>>> Thanks,
>>> Sachith
>>> --
>>> Sachith Withana
>>> Software Engineer; WSO2 Inc.; http://wso2.com
>>> E-mail: sachith AT wso2.com
>>> M: +94715518127
>>> Linked-In: 
>>> https://lk.linkedin.com/in/sachithwithana
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Malith Dhanushka
>> Senior Software Engineer - Data Technologies
>> *WSO2, Inc. : wso2.com *
>> *Mobile*  : +94 716 506 693
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Ramith Jayasinghe
> Technical Lead
> WSO2 Inc., http://wso2.com
> lean.enterprise.middleware
>
> E: ram...@wso2.com
> P: +94 777542851
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Sachith Withana
Software Engineer; WSO2 Inc.; http://wso2.com
E-mail: sachith AT wso2.com
M: +94715518127
Linked-In: https://lk.linkedin.com/in/sachithwithana
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] IBM MQ Inbound/Connector for WSO2 ESB

[Dinithi De Silva]

Hi Krishanthy,

IBM MQ V8.0.0 is the latest stable release. As Chanaka suggested better to
go with the latest.

Thanks.

On Wed, Sep 16, 2015 at 12:02 PM, Chanaka Fernando 
wrote:

> Hi Krishanthy,
>
> It is always better to work with the latest stable release. My suggestion
> is to go with V8.X if it is the latest.
>
> On Wed, Sep 16, 2015 at 11:50 AM, Kirishanthy Tharmalingam <
> kirishan...@wso2.com> wrote:
>
>> Hi All,
>>
>>
>> I have planned to develop $subject. IBM MQ facilitates the secure and
>> reliable exchange of information between applications, systems, services
>> and file by sending and receiving message data via messaging queues.
>>
>>
>> There are some version in IBM MQ(IBM MQ V8.0.0, WebSphere MQ V7.5.0,
>> WebSphere MQ V7.1.0 and WebSphere MQ V7.0.1).
>>
>>
>> Can anyone suggest which version is suitable ?
>>
>> Please give some suggestion and guidance on this.
>> --
>> Thanks & Regards,
>> Kirishanthy.T
>> Associate Software Engineer
>> Mobile : +94 778333939
>> kirishan...@wso2.com
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> --
> Chanaka Fernando
> Senior Technical Lead
> WSO2, Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 773337238
> Blog : http://soatutorials.blogspot.com
> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
> Twitter:https://twitter.com/chanakaudaya
>
>
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Dinithi De Silva*
Associate Software Engineer, WSO2 Inc.
m:+94716667655 | e:dinit...@wso2.com | w: www.wso2.com
| a: #20, Palm Grove, Colombo 03
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [DAS] Modifying the migration tool to use Hector replacing CQL

[Ramith Jayasinghe]

so,

http://docs.datastax.com/en/drivers/java/2.0/com/datastax/driver/core/ResultSet.html#fetchMoreResults()
 doesn't work for you?

On Wed, Sep 16, 2015 at 12:22 PM, Malith Dhanushka  wrote:

> Hi Sachith,
>
> +1 for using Hector and this will be a handy utility tool for DAS as well.
> Because anyone who has Cassandra raw data can use this tool to persist them
> in any file store facilitated by DAL. Given the fact, is it worth the
> effort implementing this as a generic tool? WDUT?
>
> Thanks,
> Malith
>
> On Wed, Sep 16, 2015 at 10:54 AM, Sachith Withana 
> wrote:
>
>> Hi all,
>>
>> DAS migration tool is used to migrate the data from BAM deployments to
>> DAS.
>>
>> Basically how it works is, it reads the records from Cassandra column
>> families (of BAM) and inserts them to DAS analytics tables at the Data
>> Access Layer (DAL) level.
>>
>> BAM uses Cassandra 1.x versions and the previous iteration of the tool
>> was using CQL to get all the records from a given column family and insert
>> them to DAL.
>>
>> But for large amounts of records read from BAM caused CQL to throw an
>> OutOfMemory exception from the GC, since CQL is trying to load all the
>> records to memory ( using select * from *tableName* ).
>>
>> Therefore we had to introduce pagination support by rewriting the
>> migration tool using the Hector Driver.
>>
>> Now the hector based implementation reads in records batch-wise ( the
>> batch size is configurable) and inserts to DAL thus taking out the
>> possibility of running out of memory.
>>
>> Thanks,
>> Sachith
>> --
>> Sachith Withana
>> Software Engineer; WSO2 Inc.; http://wso2.com
>> E-mail: sachith AT wso2.com
>> M: +94715518127
>> Linked-In: 
>> https://lk.linkedin.com/in/sachithwithana
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Malith Dhanushka
> Senior Software Engineer - Data Technologies
> *WSO2, Inc. : wso2.com *
> *Mobile*  : +94 716 506 693
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: ram...@wso2.com
P: +94 777542851
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Adding/Managing Sensor information on CDMF

[Viraj Senevirathne]

Hi all,

In my experience I think it is important to identify each sensor in the
system separately if there are several of similar sensors exists. If each
sensor and device in the system can be distinguish separately it is very
easy to integrate any system.

For example: Think about a behavior analysis system or a smart building or
 a robot arm that uses IMU sensors for orientation recognition. All these
scenarios require us to detect measurements coming from each sensor to
identify separately.

Even an application that doesn't require unique identification of sensors
or devices will work fine with above capability.

I think if dumb devices are connected to a smart device(A) and all such
devices are connected to central system (B). Device A should be responsible
of separating each data steams coming from dumb devices when sending data
to B (It can use data frames when sending data [1]). Then if admin using
those streams in B he can identify each sensor stream separately and do
processing as needed.

[1] Data Frame may be like this [Device ID|-Sensor
ID--|-Data--]

Thanks,


On Wed, Sep 16, 2015 at 2:43 PM, Ayyoob Hamza  wrote:

> @Dulitha and @ Sachith
> I see both your comments ends with the same question whether we need to
> have event stream definition for each sensor type or do we need to maintain
> a separate event stream for each sensor type on a device type ?.
>
> eg:  stream definition:
> Use Case 1 : org.wso2.devices.temperature (within payload send the device
> type and device Id)
> Use Case 2 :
> org.wso2.devices.firealarm.temperature, org.wso2.devices.mobile.temperature
>
> This depends on the use case we think about and I see both scenarios can
> be a valid argument. The question is to know whether we need to know the
> sensor analysis within a device type or across device types. To cater both
> scenario thought to have a sensor management as a separate module.
>
> This is just a thought process to bring up the concern of the problem.
> This needs to be further discussed with the team.
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Viraj Senevirathne
Software Engineer; WSO2, Inc.

Mobile : +94 71 958 0269
Email : vir...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Hard Throttling limit for APIs

[Amila De Silva]

On Wed, Sep 16, 2015 at 5:08 PM, Sanjeewa Malalgoda 
wrote:

> Yes what you said have value actually.
> But wont it make things complicated? For the initial implementation we may
> go with configuration per API/Endpoint.
> May be later we need to implement something to have multiple back end
> services for same API(endpoint per resource).
> And at that point we need to have something like you mentioned.
>
> And did we checked DMZ/MZ problem here.
> What do you mean by having max count inside API. Is it meant in synapse
> configuration?
>
Yes, as two properties of APIThrottleHandler.

>
> Thanks,
> sanjeewa.
>
> On Wed, Sep 16, 2015 at 2:11 PM, Amila De Silva  wrote:
>
>>
>>
>> On Wed, Sep 16, 2015 at 1:42 PM, Amila De Silva  wrote:
>>
>>>
>>> On Wed, Sep 9, 2015 at 11:47 AM, Sanjeewa Malalgoda 
>>> wrote:
>>>
 I also believe we should use existing handler without writing new one.

 And regarding registry decoupling, publisher may be able to push API to
 gateway as we do now.
 And just before we call rest API admin service we may call registry
 admin service(may be we need to write simple service for this as flow
 continue with super admin - super tenant deployed multi tenanted service)
 and push tiers.xml file.
 With that we may keep registry separation between gateway and publisher.
 That would be valuable when we have MZ and DMZ pattern and gateway in
 DMZ.

 Thanks,
 sanjeewa.


 On Tue, Sep 8, 2015 at 11:11 PM, Amila De Silva 
 wrote:

> Hi Nuwan,
>
>
>
> On Tue, Sep 8, 2015 at 9:58 PM, Nuwan Dias  wrote:
>
>> This design brings on a hard (mandatory) dependency to the registry
>> from the API Gateway right? If each API is to have its own policy
>> definition, the publisher and gateway must connect to a single registry.
>> This will cause problems in some deployment patterns which have the 
>> Gateway
>> in DMZ and publisher in the LAN. Can our throttling engine work if we 
>> just
>> feed it the request count and unit time without feeding it a policy
>> definition?
>>
>
> Not in a very straightforward way. The API exposed by throttle.core
> only allows passing ThrottleContext, a key and the Tier name. When going
> through the usages of ThrottleContext it seems that it can only be created
> out from a policy file. But need to check if it's possible to create
> ThrottleContext only using unit time and MaxRequest count.
>
>> If that works then we can survive without the registry for this.
>>
> We can keep max request count and unit time in the API itself. While
>>> initialising the APIThrottleHandler, a policy.xml has to be created out of
>>> these values and the generated policy will be used to create the
>>> ThrottleContext. Dynamic policy won't be stored anywhere, so when moving
>>> the API from one environment to another, there won't be a risk of losing
>>> anything.
>>>
>>> For the scope of this feature, should be consider about providing
>>> capability to specify hard throttling limits per each resource verb
>>> combination.
>>>
>>
>> Accidentally sent the mail halfway :)
>>
>> What I was going to highlight was need of having different hard limits
>> for each resource + verb combination.
>>
>> Not every resource of an API, consume the same amount of server
>> resources. For example, when sending response to an OPTIONS call, the
>> backend might be sending a cached (or a static) response, whilst when
>> responding to a POST, it might be doing several DB calls back and forth.
>> Actually, it might be an overflow of POST requests that can take the
>> back-end down. So while specifying a quota, heavy weight resources should
>> be given less quota, and lightweight (but more frequently accessed
>> resources) should be given a higher quota.
>>
>> Another option is to use the same tiers.xml that is being used for other
> throttling cases and refer to a role defined there. If needed to 
> update/add
> a new tier it will have to be done through tier edit UI. Even with this
> approach, the problem won't be completely solved.
>
>>
>> Why would we need a new handler? What would be the drawbacks of using
>> the existing handler?
>>
> We can use the existing one.
>
>>
>> The location to get the limit would be on the API Implement section
>> IMO.
>>
>> Thanks,
>> NuwanD.
>>
>> On Tue, Sep 8, 2015 at 9:40 PM, Amila De Silva 
>> wrote:
>>
>>> Hi,
>>>
>>> Current Throttling capabilities of API Manager only allows defining
>>> user wise and Application wise Access Quotas.
>>>
>>>
>>> For example when considering an Application and a set of APIs
>>> Subscribed, like below (tier limit is shown next to the 

Re: [Architecture] [APIM] Hard Throttling limit for APIs

[Amila De Silva]

For displaying at Publisher, throttling limits have to persisted on a DB in
some format (either in the registry artifact, in the swagger definition or
in AM_API table). But at the runtime, values will be picked from the
synapse definition.

Plan is to enforce the hard limit on a particular version of the API. For
example if there are two APIs having two versions v1 and v2, the hard limit
defined on v1 only ensures requests flowing through v1 version doesn't
exceed the specified limit.

On Wed, Sep 16, 2015 at 5:11 PM, Amila De Silva  wrote:

>
>
> On Wed, Sep 16, 2015 at 5:08 PM, Sanjeewa Malalgoda 
> wrote:
>
>> Yes what you said have value actually.
>> But wont it make things complicated? For the initial implementation we
>> may go with configuration per API/Endpoint.
>> May be later we need to implement something to have multiple back end
>> services for same API(endpoint per resource).
>> And at that point we need to have something like you mentioned.
>>
>> And did we checked DMZ/MZ problem here.
>> What do you mean by having max count inside API. Is it meant in synapse
>> configuration?
>>
> Yes, as two properties of APIThrottleHandler.
>
>>
>> Thanks,
>> sanjeewa.
>>
>> On Wed, Sep 16, 2015 at 2:11 PM, Amila De Silva  wrote:
>>
>>>
>>>
>>> On Wed, Sep 16, 2015 at 1:42 PM, Amila De Silva  wrote:
>>>

 On Wed, Sep 9, 2015 at 11:47 AM, Sanjeewa Malalgoda 
 wrote:

> I also believe we should use existing handler without writing new one.
>
> And regarding registry decoupling, publisher may be able to push API
> to gateway as we do now.
> And just before we call rest API admin service we may call registry
> admin service(may be we need to write simple service for this as flow
> continue with super admin - super tenant deployed multi tenanted service)
> and push tiers.xml file.
> With that we may keep registry separation between gateway and
> publisher.
> That would be valuable when we have MZ and DMZ pattern and gateway in
> DMZ.
>
> Thanks,
> sanjeewa.
>
>
> On Tue, Sep 8, 2015 at 11:11 PM, Amila De Silva 
> wrote:
>
>> Hi Nuwan,
>>
>>
>>
>> On Tue, Sep 8, 2015 at 9:58 PM, Nuwan Dias  wrote:
>>
>>> This design brings on a hard (mandatory) dependency to the registry
>>> from the API Gateway right? If each API is to have its own policy
>>> definition, the publisher and gateway must connect to a single registry.
>>> This will cause problems in some deployment patterns which have the 
>>> Gateway
>>> in DMZ and publisher in the LAN. Can our throttling engine work if we 
>>> just
>>> feed it the request count and unit time without feeding it a policy
>>> definition?
>>>
>>
>> Not in a very straightforward way. The API exposed by throttle.core
>> only allows passing ThrottleContext, a key and the Tier name. When going
>> through the usages of ThrottleContext it seems that it can only be 
>> created
>> out from a policy file. But need to check if it's possible to create
>> ThrottleContext only using unit time and MaxRequest count.
>>
>>> If that works then we can survive without the registry for this.
>>>
>> We can keep max request count and unit time in the API itself. While
 initialising the APIThrottleHandler, a policy.xml has to be created out of
 these values and the generated policy will be used to create the
 ThrottleContext. Dynamic policy won't be stored anywhere, so when moving
 the API from one environment to another, there won't be a risk of losing
 anything.

 For the scope of this feature, should be consider about providing
 capability to specify hard throttling limits per each resource verb
 combination.

>>>
>>> Accidentally sent the mail halfway :)
>>>
>>> What I was going to highlight was need of having different hard limits
>>> for each resource + verb combination.
>>>
>>> Not every resource of an API, consume the same amount of server
>>> resources. For example, when sending response to an OPTIONS call, the
>>> backend might be sending a cached (or a static) response, whilst when
>>> responding to a POST, it might be doing several DB calls back and forth.
>>> Actually, it might be an overflow of POST requests that can take the
>>> back-end down. So while specifying a quota, heavy weight resources should
>>> be given less quota, and lightweight (but more frequently accessed
>>> resources) should be given a higher quota.
>>>
>>> Another option is to use the same tiers.xml that is being used for other
>> throttling cases and refer to a role defined there. If needed to 
>> update/add
>> a new tier it will have to be done through tier edit UI. Even with this
>> approach, the problem won't be completely solved.
>>

Re: [Architecture] [ESB-Connector] EJB Connector

[Dushan Abeyruwan]

Hi
  I guess there are many improvements to be made if you writing connector,
and would certainly looking forward to see new design rather what we
currently have in EJB mediator [1] (it seems original doc is corrupted)

Existing problems

   -  EJB mediator binds with Bean mediator when we need to initialize
   instances for binding responses or requests for complex object IMV its too
   much overhead and feels we need to normalize this.
   -  We need to get rid from 'beanstalks' way of communicating via
   synapse.propertis (it is must) it should be flexible.
   - Then we must test this with least multiple application servers (Jboss,
   Glassfish) there are tons of class loader issues (and we had to create
   split packages to get rid)

 With all above concerns please do come up with the design we can continue
to discuss.


[1] http://www.dushantech.com/search?q=ejb


Cheers,
Dushan

On Wed, Sep 16, 2015 at 10:42 AM, Chanaka Fernando 
wrote:

> Hi Rajjaz,
>
> Well, if you see any issue with the EJB mediator, please report them and
> help us to improve the existing mediator. It is not required to repeat the
> functionality of the EJB mediator in the new connector which you are going
> to develop. Could you elaborate on a use case for this EJB connector?
>
> On Wed, Sep 16, 2015 at 2:04 PM, Rajjaz Mohammed  wrote:
>
>>
>>
>> On Wed, Sep 16, 2015 at 2:04 PM, Rajjaz Mohammed  wrote:
>>
>>> Hi All,
>>> I have planned to Implement EJB Connector for WSO2 ESB. Currently, EJB
>>> mediator supports EJB3 Stateless Session Beans and Stateful Session Beans.
>>> Since EJB mediator have some isues EJB Connector will include the
>>> Functionality of  EJB mediator which calls an external Enterprise JavaBean
>>> (EJB) and stores the result in the message payload or in a message context
>>> property.
>>>
>>> This is my Basic Idea so If you have anything  to add/change in EJB
>>> Connector please add in this Thread. and Connector will be Separate for EJB
>>> 2.0 & 3.0.
>>>
>>> --
>>> Thank you
>>> Best Regards
>>>
>>> *Rajjaz HM*
>>> Associate Software Engineer
>>> WSO2 Inc. 
>>> lean | enterprise | middleware
>>> Mobile | +94752833834
>>> Email   | raj...@wso2.com
>>> LinkedIn | Blogger | WSO2 Profile
>>> 
>>>
>>
>>
>>
>> --
>> Thank you
>> Best Regards
>>
>> *Rajjaz HM*
>> Associate Software Engineer
>> WSO2 Inc. 
>> lean | enterprise | middleware
>> Mobile | +94752833834
>> Email   | raj...@wso2.com
>> LinkedIn | Blogger | WSO2 Profile
>> 
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> --
> Chanaka Fernando
> Senior Technical Lead
> WSO2, Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 773337238
> Blog : http://soatutorials.blogspot.com
> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
> Twitter:https://twitter.com/chanakaudaya
>
>
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Dushan Abeyruwan | Technical Lead
Technical Support-Bloomington US
PMC Member Apache Synpase
WSO2 Inc. http://wso2.com/
Blog:*http://www.dushantech.com/ *
Mobile:(001)812-391-7441
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] ITERATE MEDIATOR

[Colin Roy-Ehri]

Hi John Q,

The aggregate mediator is used for exactly this purpose (1).

(1) https://docs.wso2.com/display/ESB481/Aggregate+Mediator

Thanks,
Colin Roy-Ehri
Software Engineer
*WSO2, Inc. : wso2.com *
*Mobile*  : 812-219-6517

On Wed, Sep 16, 2015 at 12:56 PM, John Q  wrote:

> Hello, I´m beginner and I need some help with the ESB.
>
> This is my situation:
>
> I will receive a message with many items, I need to iterate the items list
> and call a service for creating each item. At the end of all of the calls,
> I need to call another service to notify the end of items creation.
>
> how can I do it? I have used the iterate mediator and I have iterated the
> items well, but I don´t know how to wait until the last item is created and
> call the notify service only once. I have called the notify service outside
> the iterator mediator, but it is invoked once per each item iterated.
>
> can any body give me a clue?
>
> best regards...
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] ITERATE MEDIATOR

[John Q]

Thanks for your answer, those have been very useful,

On Wed, Sep 16, 2015 at 1:24 PM, Colin Roy-Ehri  wrote:

> Hi John,
> Inside the Iterate mediator, use a  mediator, then use the
>  mediator in the OutSequence.  For reference, please see this
> iterate/aggregate sample (1) or the EIP guide here (2).  In the EIP
> example, a clone mediator is used instead of iterate, but the aggregate
> functions in the same way.
>
> (1)
> http://susinda.blogspot.com/2015/02/wso2-esb-iterateaggregate-sample.html
> (2) https://docs.wso2.com/display/IntegrationPatterns/Aggregator
>
> Thanks,
> Colin Roy-Ehri
> Software Engineer
> *WSO2, Inc. : wso2.com *
> *Mobile*  : 812-219-6517
>
> On Wed, Sep 16, 2015 at 1:15 PM, John Q  wrote:
>
>> Colin, thanks for your answer, actually I am using the iterate mediator,
>> the problem is that I want to receive the original message, iterate over
>> all the items calling the service for each one and finally call another
>> service onlye once, but the service is invoked many times.
>>
>> this is what I have now:
>>
>> 
>>  
>>here I call the service for the item...
>> 
>> 
>> here I call the service to notify
>>
>> the notify service is been invoked per each item...
>>
>> On Wed, Sep 16, 2015 at 1:11 PM, Colin Roy-Ehri  wrote:
>>
>>> Hi John Q,
>>>
>>> The aggregate mediator is used for exactly this purpose (1).
>>>
>>> (1) https://docs.wso2.com/display/ESB481/Aggregate+Mediator
>>>
>>> Thanks,
>>> Colin Roy-Ehri
>>> Software Engineer
>>> *WSO2, Inc. : wso2.com *
>>> *Mobile*  : 812-219-6517
>>>
>>> On Wed, Sep 16, 2015 at 12:56 PM, John Q  wrote:
>>>
 Hello, I´m beginner and I need some help with the ESB.

 This is my situation:

 I will receive a message with many items, I need to iterate the items
 list and call a service for creating each item. At the end of all of the
 calls, I need to call another service to notify the end of items creation.

 how can I do it? I have used the iterate mediator and I have iterated
 the items well, but I don´t know how to wait until the last item is created
 and call the notify service only once. I have called the notify service
 outside the iterator mediator, but it is invoked once per each item
 iterated.

 can any body give me a clue?

 best regards...

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [AppFactory][GSoC] CLI Tool for App Factory

[Dmitry Sotnikov]

All these proposals sound good to me.
On Sep 15, 2015 10:08 PM, "Anuruddha Premalal"  wrote:

> Hi Dmitry,
>
> On Tue, Sep 15, 2015 at 2:27 AM, Dmitry Sotnikov  wrote:
>
>> For App Cloud scenarios, should we have the executable available for
>> download from Settings? Another alternative is to have both the executable
>> and source code referenced from the corresponding tutorial (which we need
>> to be created by the way :))
>>
>> IMO it's best if we can host the CLI details and installation
> instructions in a separate page, may be in the Docs and point to a
> downloadable url.  Here's how other have done it [1], [2].
>
> And we need it to be preconfigured to run against App Cloud, and make sure
>> it works against the cloud identity system.
>>
>> Yes
>
>> Also, might need to rename the executable for App Cloud - otherwise
>> appfac might not be understood as the name.
>>
>> Perhaps we could use 'appc' ?
>
> [1] https://devcenter.heroku.com/articles/heroku-command
> [2] https://docs.cloudfoundry.org/devguide/installcf/
>
> Dmitry
>>
>> P.S. I loved the video. Great way to present the results of work, and
>> very impressive work creating the CLI tool itself!
>>
>> On Sun, Sep 13, 2015 at 5:51 PM, Fathima Dilhasha > > wrote:
>>
>>> Hi Anuruddha, Manjula & Appfactory team,
>>>
>>> Thanks for all the support you gave to complete this successfully.
>>> +1. I will send a pull request with the necessary updates.
>>>
>>> Thank You.
>>> Regards,
>>> Dilhasha
>>>
>>> Fathima Dilhasha Nazeer 
>>> (M.N.F.Dilhasha)
>>> Undergraduate | Department of Computer Science and Engineering
>>> University of Moratuwa
>>> Sri Lanka
>>>
>>> On Thu, Sep 10, 2015 at 10:42 AM, Manjula Rathnayake 
>>> wrote:
>>>
 Hi Fathima,

 +1, Great job on the CLI tool. Lets release it with AF-2.2.0-M5 release
 as Anuruddha mentioned.

 thank you.

 On Thu, Sep 10, 2015 at 10:39 AM, Anuruddha Premalal <
 anurud...@wso2.com> wrote:

> Hi Fathima,
>
> Great work. We are looking forward to merge the CLI tool code the main
> AppFactory repo.
>
> Can you send a pull request with necessary updates?. It's god if you
> place the code under product-af/modules/tools.
>
> Also you'll have to update product distribution scripts and related
> pom files to build the CLI tool when   building the product. Since this
> requires GO run-time to build, make sure to add a pre-requisite section to
> the README.
>
> Regards,
> Anuruddha.
>
>
> On Sat, Aug 22, 2015 at 9:42 AM, Fathima Dilhasha <
> dilhasha@gmail.com> wrote:
>
>> Hi,
>>
>> I have completed the main requirements for $subject.
>> You can find a demo for the CLI Tool at [1]
>> 
>> The presentation can be found at [2]
>> 
>> Project Documentation can be found at [3]
>> 
>>
>> [1]
>> https://drive.google.com/file/d/0B5jf9n7hxy8YV1VQMTJGZ3ZKeU0/view?usp=sharing
>> [2]
>> https://docs.google.com/presentation/d/1yNojFbikh09V57tMtcoaacyc_17Ev1xQrraQCBxjezY/edit?usp=sharing
>> [3]
>> https://docs.google.com/document/d/1bD9ouBR2HeDWQ-bmx7OxKQ9q8Km4u6S6UyqlFx0ASfQ/edit?usp=sharing
>>
>> There were few suggestions pointed out during the demo,
>>  -To make the base url configurable from the tool itself.
>>  -To add auto-complete functionality.
>>
>> I will work on these improvements as an extension of this project.
>> Please point out any further suggestions.
>>
>> Thanks.
>> Regards,
>> Dilhasha
>>
>>
>> Fathima Dilhasha Nazeer 
>> (M.N.F.Dilhasha)
>> Undergraduate | Department of Computer Science and Engineering
>> University of Moratuwa
>> Sri Lanka
>>
>> On Thu, Jun 11, 2015 at 7:59 PM, Fathima Dilhasha <
>> dilhasha@gmail.com> wrote:
>>
>>> Hi Anuruddha,
>>>
>>> Please find my suggestions in line.
>>>
>>> Regards,
>>> Dilhasha
>>>
>>> Fathima Dilhasha Nazeer 
>>> (M.N.F.Dilhasha)
>>> Undergraduate | Department of Computer Science and Engineering
>>> University of Moratuwa
>>> Sri Lanka
>>>
>>> On Thu, Jun 11, 2015 at 4:51 AM, Anuruddha Premalal <
>>> anurud...@wso2.com> wrote:
>>>
 Hi Fathima,

 Few questions.

 1. What will be the command template for general and app specifics?

>>>
>>>My Idea of the command template is that both general and app
>>> 

Re: [Architecture] Adding/Managing Sensor information on CDMF

[Dulitha Wijewantha]

On Wed, Sep 16, 2015 at 7:45 PM, Viraj Senevirathne  wrote:

> Hi all,
>
> In my experience I think it is important to identify each sensor in the
> system separately if there are several of similar sensors exists. If each
> sensor and device in the system can be distinguish separately it is very
> easy to integrate any system.
>
> For example: Think about a behavior analysis system or a smart building or
>  a robot arm that uses IMU sensors for orientation recognition. All these
> scenarios require us to detect measurements coming from each sensor to
> identify separately.
>
> Even an application that doesn't require unique identification of sensors
> or devices will work fine with above capability.
>
> I think if dumb devices are connected to a smart device(A) and all such
> devices are connected to central system (B). Device A should be responsible
> of separating each data steams coming from dumb devices when sending data
> to B (It can use data frames when sending data [1]). Then if admin using
> those streams in B he can identify each sensor stream separately and do
> processing as needed.
>
> [1] Data Frame may be like this [Device ID|-Sensor
> ID--|-Data--]
>

​I like this idea. ​This way our approach is device based rather than
sensor based. In definition, if a sensor can stand by itself it's
effectively a device. An example would be a smart light bulb that doesn't
need a hub. A light bulb that needs a hub, will be a sensor (taking the LDR
in a light bulb since the light itself is an actuator :) )

Thanks,
>
>
> On Wed, Sep 16, 2015 at 2:43 PM, Ayyoob Hamza  wrote:
>
>> @Dulitha and @ Sachith
>> I see both your comments ends with the same question whether we need to
>> have event stream definition for each sensor type or do we need to maintain
>> a separate event stream for each sensor type on a device type ?.
>>
>> eg:  stream definition:
>> Use Case 1 : org.wso2.devices.temperature (within payload send the device
>> type and device Id)
>> Use Case 2 :
>> org.wso2.devices.firealarm.temperature, org.wso2.devices.mobile.temperature
>>
>> This depends on the use case we think about and I see both scenarios can
>> be a valid argument. The question is to know whether we need to know the
>> sensor analysis within a device type or across device types. To cater both
>> scenario thought to have a sensor management as a separate module.
>>
>> This is just a thought process to bring up the concern of the problem.
>> This needs to be further discussed with the team.
>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Viraj Senevirathne
> Software Engineer; WSO2, Inc.
>
> Mobile : +94 71 958 0269
> Email : vir...@wso2.com
>



-- 
Dulitha Wijewantha (Chan)
Software Engineer - Mobile Development
WSO2 Inc
Lean.Enterprise.Middleware
 * ~Email   duli...@wso2.com *
*  ~Mobile +94712112165*
*  ~Website   dulitha.me *
*  ~Twitter @dulitharw *
  *~Github @dulichan *
  *~SO @chan *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] ITERATE MEDIATOR

[John Q]

Colin, thanks for your answer, actually I am using the iterate mediator,
the problem is that I want to receive the original message, iterate over
all the items calling the service for each one and finally call another
service onlye once, but the service is invoked many times.

this is what I have now:


 
   here I call the service for the item...


here I call the service to notify

the notify service is been invoked per each item...

On Wed, Sep 16, 2015 at 1:11 PM, Colin Roy-Ehri  wrote:

> Hi John Q,
>
> The aggregate mediator is used for exactly this purpose (1).
>
> (1) https://docs.wso2.com/display/ESB481/Aggregate+Mediator
>
> Thanks,
> Colin Roy-Ehri
> Software Engineer
> *WSO2, Inc. : wso2.com *
> *Mobile*  : 812-219-6517
>
> On Wed, Sep 16, 2015 at 12:56 PM, John Q  wrote:
>
>> Hello, I´m beginner and I need some help with the ESB.
>>
>> This is my situation:
>>
>> I will receive a message with many items, I need to iterate the items
>> list and call a service for creating each item. At the end of all of the
>> calls, I need to call another service to notify the end of items creation.
>>
>> how can I do it? I have used the iterate mediator and I have iterated the
>> items well, but I don´t know how to wait until the last item is created and
>> call the notify service only once. I have called the notify service outside
>> the iterator mediator, but it is invoked once per each item iterated.
>>
>> can any body give me a clue?
>>
>> best regards...
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] ITERATE MEDIATOR

[Keerthika Mahendralingam]

Hi John,
You can use a property to count the number of iterations and invoke the
next service once all iterations are finished.
For example,



   

   --
   
  



  
   -call service---
   


Thanks,

On Wed, Sep 16, 2015 at 10:45 PM, John Q  wrote:

> Colin, thanks for your answer, actually I am using the iterate mediator,
> the problem is that I want to receive the original message, iterate over
> all the items calling the service for each one and finally call another
> service onlye once, but the service is invoked many times.
>
> this is what I have now:
>
> 
>  
>here I call the service for the item...
> 
> 
> here I call the service to notify
>
> the notify service is been invoked per each item...
>
> On Wed, Sep 16, 2015 at 1:11 PM, Colin Roy-Ehri  wrote:
>
>> Hi John Q,
>>
>> The aggregate mediator is used for exactly this purpose (1).
>>
>> (1) https://docs.wso2.com/display/ESB481/Aggregate+Mediator
>>
>> Thanks,
>> Colin Roy-Ehri
>> Software Engineer
>> *WSO2, Inc. : wso2.com *
>> *Mobile*  : 812-219-6517
>>
>> On Wed, Sep 16, 2015 at 12:56 PM, John Q  wrote:
>>
>>> Hello, I´m beginner and I need some help with the ESB.
>>>
>>> This is my situation:
>>>
>>> I will receive a message with many items, I need to iterate the items
>>> list and call a service for creating each item. At the end of all of the
>>> calls, I need to call another service to notify the end of items creation.
>>>
>>> how can I do it? I have used the iterate mediator and I have iterated
>>> the items well, but I don´t know how to wait until the last item is created
>>> and call the notify service only once. I have called the notify service
>>> outside the iterator mediator, but it is invoked once per each item
>>> iterated.
>>>
>>> can any body give me a clue?
>>>
>>> best regards...
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

Keerthika Mahendralingam
Associate Software Engineer
Mobile :+94 (0) 776 121144
keerth...@wso2.com
WSO2, Inc.
lean . enterprise . middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] ITERATE MEDIATOR

[Colin Roy-Ehri]

Hi John,
Inside the Iterate mediator, use a  mediator, then use the
 mediator in the OutSequence.  For reference, please see this
iterate/aggregate sample (1) or the EIP guide here (2).  In the EIP
example, a clone mediator is used instead of iterate, but the aggregate
functions in the same way.

(1)
http://susinda.blogspot.com/2015/02/wso2-esb-iterateaggregate-sample.html
(2) https://docs.wso2.com/display/IntegrationPatterns/Aggregator

Thanks,
Colin Roy-Ehri
Software Engineer
*WSO2, Inc. : wso2.com *
*Mobile*  : 812-219-6517

On Wed, Sep 16, 2015 at 1:15 PM, John Q  wrote:

> Colin, thanks for your answer, actually I am using the iterate mediator,
> the problem is that I want to receive the original message, iterate over
> all the items calling the service for each one and finally call another
> service onlye once, but the service is invoked many times.
>
> this is what I have now:
>
> 
>  
>here I call the service for the item...
> 
> 
> here I call the service to notify
>
> the notify service is been invoked per each item...
>
> On Wed, Sep 16, 2015 at 1:11 PM, Colin Roy-Ehri  wrote:
>
>> Hi John Q,
>>
>> The aggregate mediator is used for exactly this purpose (1).
>>
>> (1) https://docs.wso2.com/display/ESB481/Aggregate+Mediator
>>
>> Thanks,
>> Colin Roy-Ehri
>> Software Engineer
>> *WSO2, Inc. : wso2.com *
>> *Mobile*  : 812-219-6517
>>
>> On Wed, Sep 16, 2015 at 12:56 PM, John Q  wrote:
>>
>>> Hello, I´m beginner and I need some help with the ESB.
>>>
>>> This is my situation:
>>>
>>> I will receive a message with many items, I need to iterate the items
>>> list and call a service for creating each item. At the end of all of the
>>> calls, I need to call another service to notify the end of items creation.
>>>
>>> how can I do it? I have used the iterate mediator and I have iterated
>>> the items well, but I don´t know how to wait until the last item is created
>>> and call the notify service only once. I have called the notify service
>>> outside the iterator mediator, but it is invoked once per each item
>>> iterated.
>>>
>>> can any body give me a clue?
>>>
>>> best regards...
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [ESB-Connector] EJB Connector

[Rajjaz Mohammed]

Hi Chanaka/Dushan,
Thank you to add some ideas on this Thread. I’m Currently searching on
implement new EJB Connector with Current EJB Mediator Functions and
possibilities to add more features. So i will add your ideas also in the
development.

On Wed, Sep 16, 2015 at 10:27 PM, Dushan Abeyruwan  wrote:

> Hi
>   I guess there are many improvements to be made if you writing connector,
> and would certainly looking forward to see new design rather what we
> currently have in EJB mediator [1] (it seems original doc is corrupted)
>
> Existing problems
>
>-  EJB mediator binds with Bean mediator when we need to initialize
>instances for binding responses or requests for complex object IMV its too
>much overhead and feels we need to normalize this.
>-  We need to get rid from 'beanstalks' way of communicating via
>synapse.propertis (it is must) it should be flexible.
>- Then we must test this with least multiple application servers
>(Jboss, Glassfish) there are tons of class loader issues (and we had to
>create split packages to get rid)
>
>  With all above concerns please do come up with the design we can continue
> to discuss.
>
>
> [1] http://www.dushantech.com/search?q=ejb
>
>
> Cheers,
> Dushan
>
> On Wed, Sep 16, 2015 at 10:42 AM, Chanaka Fernando 
> wrote:
>
>> Hi Rajjaz,
>>
>> Well, if you see any issue with the EJB mediator, please report them and
>> help us to improve the existing mediator. It is not required to repeat the
>> functionality of the EJB mediator in the new connector which you are going
>> to develop. Could you elaborate on a use case for this EJB connector?
>>
>> On Wed, Sep 16, 2015 at 2:04 PM, Rajjaz Mohammed  wrote:
>>
>>>
>>>
>>> On Wed, Sep 16, 2015 at 2:04 PM, Rajjaz Mohammed 
>>> wrote:
>>>
 Hi All,
 I have planned to Implement EJB Connector for WSO2 ESB. Currently, EJB
 mediator supports EJB3 Stateless Session Beans and Stateful Session Beans.
 Since EJB mediator have some isues EJB Connector will include the
 Functionality of  EJB mediator which calls an external Enterprise JavaBean
 (EJB) and stores the result in the message payload or in a message context
 property.

 This is my Basic Idea so If you have anything  to add/change in EJB
 Connector please add in this Thread. and Connector will be Separate for EJB
 2.0 & 3.0.

 --
 Thank you
 Best Regards

 *Rajjaz HM*
 Associate Software Engineer
 WSO2 Inc. 
 lean | enterprise | middleware
 Mobile | +94752833834
 Email   | raj...@wso2.com
 LinkedIn | Blogger | WSO2 Profile
 

>>>
>>>
>>>
>>> --
>>> Thank you
>>> Best Regards
>>>
>>> *Rajjaz HM*
>>> Associate Software Engineer
>>> WSO2 Inc. 
>>> lean | enterprise | middleware
>>> Mobile | +94752833834
>>> Email   | raj...@wso2.com
>>> LinkedIn | Blogger | WSO2 Profile
>>> 
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> --
>> Chanaka Fernando
>> Senior Technical Lead
>> WSO2, Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: +94 773337238
>> Blog : http://soatutorials.blogspot.com
>> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
>> Twitter:https://twitter.com/chanakaudaya
>>
>>
>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Dushan Abeyruwan | Technical Lead
> Technical Support-Bloomington US
> PMC Member Apache Synpase
> WSO2 Inc. http://wso2.com/
> Blog:*http://www.dushantech.com/ *
> Mobile:(001)812-391-7441
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thank you
Best Regards

*Rajjaz HM*
Associate Software Engineer
WSO2 Inc. 
lean | enterprise | middleware
Mobile | +94752833834
Email   | raj...@wso2.com
LinkedIn | Blogger | WSO2 Profile

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture