date:20151209

Re: [Architecture] [Dev] [ESB] Deprecated features in ESB 4.10

2015-12-09 Thread Yumani Ranaweera

Is it possible to provide sufficient documentation to help the customers
who would be migrating in future.

Thanks,
Yumani


On Wed, Dec 9, 2015 at 1:45 PM, Chanaka Fernando  wrote:

> *- Callout mediator :*
>  All the callout functionality is supported with 'call' mediator with
> blocking=true. Having two similar mediators will be create a bit of a
> confusion.
>
> It will make a lot of confusion when we have more than one mediators to do
> the same thing. Therefore, better to deprecate this mediator.
>
> *- DBReport/DBLookup mediator*
> These mediators offer very limited functionality and we always recommend
> to integrate with databases with the use of DSS (using a separate DSS or
> using DSS features inside ESB)
>
> Even though this mediator has been used by some customers, they are using
> that for very limited functionality and we always suggest them to use DSS
> as Kasun mentioned. If users really want to connect to a database, they can
> easily write a simple class mediator.
>
> *- Bean, POJOCommand, Spring* : Rarely used mediators and no active
> development happens on these.
> *- Router* : Same as filter mediator, so no use of having this.
> *- In, Out * : Rarely used and often not required with the new
> call/respond mediator approach.
>
> +1 for deprecating these mediators.
>
> With the new DAS integration, we can deprecate BAM mediator since we have
> the PublishEvent mediator.
>
> On Wed, Dec 9, 2015 at 6:41 AM, Kasun Indrasiri  wrote:
>
>> Shall we deprecate following mediators in 4.10 release.
>>
>> *- Callout mediator :*
>>  All the callout functionality is supported with 'call' mediator with
>> blocking=true. Having two similar mediators will be create a bit of a
>> confusion.
>>
>> *- DBReport/DBLookup mediator*
>> These mediators offer very limited functionality and we always recommend
>> to integrate with databases with the use of DSS (using a separate DSS or
>> using DSS features inside ESB)
>>
>> *- Bean, POJOCommand, Spring* : Rarely used mediators and no active
>> development happens on these.
>> *- Router* : Same as filter mediator, so no use of having this.
>> *- In, Out * : Rarely used and often not required with the new
>> call/respond mediator approach.
>>
>> Any comments  on these or any other features that we should deprecate
>> from 4.10 release?
>>
>> Thanks,
>> Kasun.
>>
>> --
>> Kasun Indrasiri
>> Software Architect
>> WSO2, Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> cell: +94 77 556 5206
>> Blog : http://kasunpanorama.blogspot.com/
>>
>
>
>
> --
> Thank you and Best Regards,
> 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
>
>
>
>
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 


*Yumani Ranaweera* | Technical Lead
Technical Support- Colombo
WSO2 Inc. |  http://wso2.com
Blog: http://yumani.blogspot.com/
Mob: + 94 95242
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [ESB] Deprecated features in ESB 4.10

2015-12-09 Thread Chanaka Fernando

*- Callout mediator :*
 All the callout functionality is supported with 'call' mediator with
blocking=true. Having two similar mediators will be create a bit of a
confusion.

It will make a lot of confusion when we have more than one mediators to do
the same thing. Therefore, better to deprecate this mediator.

*- DBReport/DBLookup mediator*
These mediators offer very limited functionality and we always recommend to
integrate with databases with the use of DSS (using a separate DSS or using
DSS features inside ESB)

Even though this mediator has been used by some customers, they are using
that for very limited functionality and we always suggest them to use DSS
as Kasun mentioned. If users really want to connect to a database, they can
easily write a simple class mediator.

*- Bean, POJOCommand, Spring* : Rarely used mediators and no active
development happens on these.
*- Router* : Same as filter mediator, so no use of having this.
*- In, Out * : Rarely used and often not required with the new call/respond
mediator approach.

+1 for deprecating these mediators.

With the new DAS integration, we can deprecate BAM mediator since we have
the PublishEvent mediator.

On Wed, Dec 9, 2015 at 6:41 AM, Kasun Indrasiri  wrote:

> Shall we deprecate following mediators in 4.10 release.
>
> *- Callout mediator :*
>  All the callout functionality is supported with 'call' mediator with
> blocking=true. Having two similar mediators will be create a bit of a
> confusion.
>
> *- DBReport/DBLookup mediator*
> These mediators offer very limited functionality and we always recommend
> to integrate with databases with the use of DSS (using a separate DSS or
> using DSS features inside ESB)
>
> *- Bean, POJOCommand, Spring* : Rarely used mediators and no active
> development happens on these.
> *- Router* : Same as filter mediator, so no use of having this.
> *- In, Out * : Rarely used and often not required with the new
> call/respond mediator approach.
>
> Any comments  on these or any other features that we should deprecate from
> 4.10 release?
>
> Thanks,
> Kasun.
>
> --
> Kasun Indrasiri
> Software Architect
> WSO2, Inc.; http://wso2.com
> lean.enterprise.middleware
>
> cell: +94 77 556 5206
> Blog : http://kasunpanorama.blogspot.com/
>

-- 
Thank you and Best Regards,
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

Re: [Architecture] [ESB] Deprecated features in ESB 4.10

2015-12-09 Thread Harshana Eranga Martin

Hi Kasun,

Please see the comments inline.

Thanks and Regards,
Harshana
--
Harshana Eranga Martin

Committer - Eclipse ECF: http://www.eclipse.org/ecf/
Blog: http://harshana05.blogspot.com
Profile: https://www.google.com/profiles/harshana05

On 9 December 2015 at 17:41, Kasun Indrasiri  wrote:

> Shall we deprecate following mediators in 4.10 release.
>
> *- Callout mediator :*
>  All the callout functionality is supported with 'call' mediator with
> blocking=true. Having two similar mediators will be create a bit of a
> confusion.
>

Can we use the Call mediator with blocking=true instead of Callout mediator
for the NTLM scenarios?

I have tried a NTLM scenario recently with Call mediator and blocking=true
in ESB 4.9.0 but it didn't work while the Callout mediator works fine for
the same scenario. I also assumed Call mediator would work but it didn't.
Can you please check and verify?



> *- DBReport/DBLookup mediator*
> These mediators offer very limited functionality and we always recommend
> to integrate with databases with the use of DSS (using a separate DSS or
> using DSS features inside ESB)
>
> *- Bean, POJOCommand, Spring* : Rarely used mediators and no active
> development happens on these.
> *- Router* : Same as filter mediator, so no use of having this.
> *- In, Out * : Rarely used and often not required with the new
> call/respond mediator approach.
>
> Any comments  on these or any other features that we should deprecate from
> 4.10 release?
>
> 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
> 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] [Dev] [ESB] Deprecated features in ESB 4.10

2015-12-09 Thread Kasun Indrasiri

On Wed, Dec 9, 2015 at 3:32 PM, Malaka Silva  wrote:

> +1 except  DBReport/DBLookup mediators
>
> DBReport and DBLookup only offer a very limited set of capabilities. IMO,
for any real integration scenario, we can't use them.  :).

> On Wed, Dec 9, 2015 at 2:00 PM, Yumani Ranaweera  wrote:
>
>> Is it possible to provide sufficient documentation to help the customers
>> who would be migrating in future.
>>
>> Thanks,
>> Yumani
>>
>>
>> On Wed, Dec 9, 2015 at 1:45 PM, Chanaka Fernando 
>> wrote:
>>
>>> *- Callout mediator :*
>>>  All the callout functionality is supported with 'call' mediator with
>>> blocking=true. Having two similar mediators will be create a bit of a
>>> confusion.
>>>
>>> It will make a lot of confusion when we have more than one mediators to
>>> do the same thing. Therefore, better to deprecate this mediator.
>>>
>>> *- DBReport/DBLookup mediator*
>>> These mediators offer very limited functionality and we always recommend
>>> to integrate with databases with the use of DSS (using a separate DSS or
>>> using DSS features inside ESB)
>>>
>>> Even though this mediator has been used by some customers, they are
>>> using that for very limited functionality and we always suggest them to use
>>> DSS as Kasun mentioned. If users really want to connect to a database, they
>>> can easily write a simple class mediator.
>>>
>>> *- Bean, POJOCommand, Spring* : Rarely used mediators and no active
>>> development happens on these.
>>> *- Router* : Same as filter mediator, so no use of having this.
>>> *- In, Out * : Rarely used and often not required with the new
>>> call/respond mediator approach.
>>>
>>> +1 for deprecating these mediators.
>>>
>>> With the new DAS integration, we can deprecate BAM mediator since we
>>> have the PublishEvent mediator.
>>>
>>> On Wed, Dec 9, 2015 at 6:41 AM, Kasun Indrasiri  wrote:
>>>
 Shall we deprecate following mediators in 4.10 release.

 *- Callout mediator :*
  All the callout functionality is supported with 'call' mediator with
 blocking=true. Having two similar mediators will be create a bit of a
 confusion.

 *- DBReport/DBLookup mediator*
 These mediators offer very limited functionality and we always
 recommend to integrate with databases with the use of DSS (using a separate
 DSS or using DSS features inside ESB)

 *- Bean, POJOCommand, Spring* : Rarely used mediators and no active
 development happens on these.
 *- Router* : Same as filter mediator, so no use of having this.
 *- In, Out * : Rarely used and often not required with the new
 call/respond mediator approach.

 Any comments  on these or any other features that we should deprecate
 from 4.10 release?

 Thanks,
 Kasun.

 --
 Kasun Indrasiri
 Software Architect
 WSO2, Inc.; http://wso2.com
 lean.enterprise.middleware

 cell: +94 77 556 5206
 Blog : http://kasunpanorama.blogspot.com/

>>>
>>>
>>>
>>> --
>>> Thank you and Best Regards,
>>> 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
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> Dev mailing list
>>> d...@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>>
>>
>> *Yumani Ranaweera* | Technical Lead
>> Technical Support- Colombo
>> WSO2 Inc. |  http://wso2.com
>> Blog: http://yumani.blogspot.com/
>> Mob: + 94 95242
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> Best Regards,
>
> Malaka Silva
> Senior Tech Lead
> M: +94 777 219 791
> Tel : 94 11 214 5345
> Fax :94 11 2145300
> Skype : malaka.sampath.silva
> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77
> Blog : http://mrmalakasilva.blogspot.com/
>
> WSO2, Inc.
> lean . enterprise . middleware
> http://www.wso2.com/
> http://www.wso2.com/about/team/malaka-silva/
> 
> https://store.wso2.com/store/
>
> Save a tree -Conserve nature & Save the world for your future. Print this
> email only if it is absolutely necessary.
>



-- 
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
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [ESB] Deprecated features in ESB 4.10

2015-12-09 Thread Malaka Silva

In my experience using DB mediator we can cover some of the use cases
using ESB out of the box, which I find very handy.

Also use case of integrating with stored procs can easily covered with
this.

However there are limits like batch update or getting multiple rows.

I guess we can argue both ways. IMO we should keep these mediators since
it'll become handy for some use cases :)

On Wed, Dec 9, 2015 at 4:58 PM, Kasun Indrasiri  wrote:

>
>
> On Wed, Dec 9, 2015 at 3:32 PM, Malaka Silva  wrote:
>
>> +1 except  DBReport/DBLookup mediators
>>
>> DBReport and DBLookup only offer a very limited set of capabilities. IMO,
> for any real integration scenario, we can't use them.  :).
>
>> On Wed, Dec 9, 2015 at 2:00 PM, Yumani Ranaweera  wrote:
>>
>>> Is it possible to provide sufficient documentation to help the customers
>>> who would be migrating in future.
>>>
>>> Thanks,
>>> Yumani
>>>
>>>
>>> On Wed, Dec 9, 2015 at 1:45 PM, Chanaka Fernando 
>>> wrote:
>>>
 *- Callout mediator :*
  All the callout functionality is supported with 'call' mediator with
 blocking=true. Having two similar mediators will be create a bit of a
 confusion.

 It will make a lot of confusion when we have more than one mediators to
 do the same thing. Therefore, better to deprecate this mediator.

 *- DBReport/DBLookup mediator*
 These mediators offer very limited functionality and we always
 recommend to integrate with databases with the use of DSS (using a separate
 DSS or using DSS features inside ESB)

 Even though this mediator has been used by some customers, they are
 using that for very limited functionality and we always suggest them to use
 DSS as Kasun mentioned. If users really want to connect to a database, they
 can easily write a simple class mediator.

 *- Bean, POJOCommand, Spring* : Rarely used mediators and no active
 development happens on these.
 *- Router* : Same as filter mediator, so no use of having this.
 *- In, Out * : Rarely used and often not required with the new
 call/respond mediator approach.

 +1 for deprecating these mediators.

 With the new DAS integration, we can deprecate BAM mediator since we
 have the PublishEvent mediator.

 On Wed, Dec 9, 2015 at 6:41 AM, Kasun Indrasiri  wrote:

> Shall we deprecate following mediators in 4.10 release.
>
> *- Callout mediator :*
>  All the callout functionality is supported with 'call' mediator with
> blocking=true. Having two similar mediators will be create a bit of a
> confusion.
>
> *- DBReport/DBLookup mediator*
> These mediators offer very limited functionality and we always
> recommend to integrate with databases with the use of DSS (using a 
> separate
> DSS or using DSS features inside ESB)
>
> *- Bean, POJOCommand, Spring* : Rarely used mediators and no active
> development happens on these.
> *- Router* : Same as filter mediator, so no use of having this.
> *- In, Out * : Rarely used and often not required with the new
> call/respond mediator approach.
>
> Any comments  on these or any other features that we should deprecate
> from 4.10 release?
>
> Thanks,
> Kasun.
>
> --
> Kasun Indrasiri
> Software Architect
> WSO2, Inc.; http://wso2.com
> lean.enterprise.middleware
>
> cell: +94 77 556 5206
> Blog : http://kasunpanorama.blogspot.com/
>



 --
 Thank you and Best Regards,
 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





 ___
 Dev mailing list
 d...@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev


>>>
>>>
>>> --
>>>
>>>
>>> *Yumani Ranaweera* | Technical Lead
>>> Technical Support- Colombo
>>> WSO2 Inc. |  http://wso2.com
>>> Blog: http://yumani.blogspot.com/
>>> Mob: + 94 95242
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>>
>> Best Regards,
>>
>> Malaka Silva
>> Senior Tech Lead
>> M: +94 777 219 791
>> Tel : 94 11 214 5345
>> Fax :94 11 2145300
>> Skype : malaka.sampath.silva
>> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77
>> Blog : http://mrmalakasilva.blogspot.com/
>>
>> WSO2, Inc.
>> lean . enterprise . middleware
>> http://www.wso2.com/
>> http://www.wso2.com/about/team/malaka-silva/
>> 
>>

Re: [Architecture] [ESB] Deprecated features in ESB 4.10

2015-12-09 Thread Vanjikumaran Sivajothy

Is it going to be complete functional Deprecate? If yes, there will be not
forward compatibility during the upgrades.

On Wed, Dec 9, 2015 at 10:23 AM, Isuru Udana  wrote:

> Hi Harshana,
>
> On Wed, Dec 9, 2015 at 6:46 PM, Harshana Eranga Martin <
> harshan...@gmail.com> wrote:
>
>> Hi Kasun,
>>
>> Please see the comments inline.
>>
>> Thanks and Regards,
>> Harshana
>> --
>> Harshana Eranga Martin
>>
>> Committer - Eclipse ECF: http://www.eclipse.org/ecf/
>> Blog: http://harshana05.blogspot.com
>> Profile: https://www.google.com/profiles/harshana05
>>
>> On 9 December 2015 at 17:41, Kasun Indrasiri  wrote:
>>
>>> Shall we deprecate following mediators in 4.10 release.
>>>
>>> *- Callout mediator :*
>>>  All the callout functionality is supported with 'call' mediator with
>>> blocking=true. Having two similar mediators will be create a bit of a
>>> confusion.
>>>
>>
>> Can we use the Call mediator with blocking=true instead of Callout
>> mediator for the NTLM scenarios?
>>
>> I have tried a NTLM scenario recently with Call mediator and
>> blocking=true in ESB 4.9.0 but it didn't work while the Callout mediator
>> works fine for the same scenario. I also assumed Call mediator would work
>> but it didn't. Can you please check and verify?
>>
>> If that the case, we need to fix that bug.
>
>>
>>
>>> *- DBReport/DBLookup mediator*
>>> These mediators offer very limited functionality and we always recommend
>>> to integrate with databases with the use of DSS (using a separate DSS or
>>> using DSS features inside ESB)
>>>
>>> *- Bean, POJOCommand, Spring* : Rarely used mediators and no active
>>> development happens on these.
>>> *- Router* : Same as filter mediator, so no use of having this.
>>> *- In, Out * : Rarely used and often not required with the new
>>> call/respond mediator approach.
>>>
>>> Any comments  on these or any other features that we should deprecate
>>> from 4.10 release?
>>>
>>> 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
>>> 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
>>
>>
>
>
> --
> *Isuru Udana*
> Associate Technical Lead
> WSO2 Inc.; http://wso2.com
> email: isu...@wso2.com cell: +94 77 3791887
> blog: http://mytecheye.blogspot.com/
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Vanjikumaran Sivajothy
*Associate Technical Lead*
*WSO2 Inc. http://wso2.com *
*USA Mobile **+1-812-361-1286*
*Srilanka Mobile:+94-777-219-209*
[image: Facebook]  [image: Twitter]
 [image: LinkedIn]
 [image:
Blogger]  [image: SlideShare]


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, re-transmit, 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
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [ESB] Deprecated features in ESB 4.10

2015-12-09 Thread Isuru Udana

Hi Harshana,

On Wed, Dec 9, 2015 at 6:46 PM, Harshana Eranga Martin  wrote:

> Hi Kasun,
>
> Please see the comments inline.
>
> Thanks and Regards,
> Harshana
> --
> Harshana Eranga Martin
>
> Committer - Eclipse ECF: http://www.eclipse.org/ecf/
> Blog: http://harshana05.blogspot.com
> Profile: https://www.google.com/profiles/harshana05
>
> On 9 December 2015 at 17:41, Kasun Indrasiri  wrote:
>
>> Shall we deprecate following mediators in 4.10 release.
>>
>> *- Callout mediator :*
>>  All the callout functionality is supported with 'call' mediator with
>> blocking=true. Having two similar mediators will be create a bit of a
>> confusion.
>>
>
> Can we use the Call mediator with blocking=true instead of Callout
> mediator for the NTLM scenarios?
>
> I have tried a NTLM scenario recently with Call mediator and blocking=true
> in ESB 4.9.0 but it didn't work while the Callout mediator works fine for
> the same scenario. I also assumed Call mediator would work but it didn't.
> Can you please check and verify?
>
> If that the case, we need to fix that bug.

>
>
>> *- DBReport/DBLookup mediator*
>> These mediators offer very limited functionality and we always recommend
>> to integrate with databases with the use of DSS (using a separate DSS or
>> using DSS features inside ESB)
>>
>> *- Bean, POJOCommand, Spring* : Rarely used mediators and no active
>> development happens on these.
>> *- Router* : Same as filter mediator, so no use of having this.
>> *- In, Out * : Rarely used and often not required with the new
>> call/respond mediator approach.
>>
>> Any comments  on these or any other features that we should deprecate
>> from 4.10 release?
>>
>> 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
>> 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
>
>


-- 
*Isuru Udana*
Associate Technical Lead
WSO2 Inc.; http://wso2.com
email: isu...@wso2.com cell: +94 77 3791887
blog: http://mytecheye.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [BPS][BPMN] New REST API for BPMN statistics

2015-12-09 Thread Dinithi De Silva

Hi Natasha,

How are you going to ensure the security of the APIs? Have you thought of
using any security models?

You can use  permission/role based model in order to achieve this. Just
make sure which APIs need the administrative privileges.

Thanks.

On Wed, Dec 9, 2015 at 9:30 PM, Nuwan Pallewela  wrote:

> Hi Natasha,
>
> Great work.
> What happens if an invalid request or request with an illegal argument
> sent to the API ?
> It is better to have those response messages or response status code also
> in the documentation.
>
> Thanks,
> Nuwan
>
> On Wed, Dec 9, 2015 at 5:08 PM, Natasha Wijesekara 
> wrote:
>
>> Hi,
>>
>> I  documented a user guide which contains details about the new rest API
>> implemented to generate the statistics for bpmn.
>> Appreciate any suggestions and comments.
>>
>> Thanks,
>> Natasha
>>
>> On Tue, Dec 8, 2015 at 4:44 PM, Vinod Kavinda  wrote:
>>
>>> [Adding Architecture group]
>>>
>>> On Tue, Dec 8, 2015 at 2:45 PM, Natasha Wijesekara 
>>> wrote:
>>>
 Hi ,

 Currently the statistics generated for the bpmn-explorer is generated
 using jaggery. When the work load is high, the  bpmn-explorer takes a
 longer time to generate these statistics which causes performance issues.

 As a solution I am working a new stats REST api  to generate these
 statistics at the back-end. This reduces the work load  and thereby solves
 the performance issues caused during peak times (when the workload is at
 its maximum).

 After taking in data about  the bpmn processes, tasks  and users
 involved, the api  processes these data into meaningful statistics.These
 statistics generated is used in the bpmn-explorer reporting dashboard to
 generate the statistical graphs.

 The statistics generated includes:

 1) Average time duration for all completed processes.
 The user has the option to either view all completed processes or the
 top 10 processes which finished within a short time duration or the top 10
 processes which took a long time duration to finish.

 2) Average time duration of tasks of a  completed process.
 The user can select the completed process from the combo box and view
 the average time duration.

 3) User and the no. of tasks he/she has completed upto now.

 4) Average time taken by each user to complete the tasks assigned to
 him/her.

 5) Task demand variation over time i.e. no. of tasks started and no. of
 tasks completed in each month. This is useful for resource allocation
 purposes.

 6) Process demand variation over time i.e. no. of processes started and
 no. of processes completed in each month regardless of a specific user.
 This is useful for resource allocation purposes.

 7) User Performance i.e. Task demand variation of users separately over
 time i.e. no. of tasks started and no. of tasks completed in each month.
 This is useful for resource allocation purposes.

 I have attached the class diagram of the REST api. The new stats REST
 api will be integrated with the existing bpmn REST api.
 Appreciate any suggestions and comments.

 Thanks,
 --
 *Natasha Wijesekare*

 *Software Engineering Intern, WSO2  Inc:  http://wso2.com
 *
 *email  : nata...@wso2.com *
 *mobile: +94 771358651 <%2B94%20771358651>*

>>>
>>>
>>>
>>> --
>>> Vinod Kavinda
>>> Software Engineer
>>> *WSO2 Inc. - lean . enterprise . middleware .*
>>> Mobile : +94 (0) 712 415544
>>> Blog : http://soatechflicks.blogspot.com/
>>>
>>>
>>
>>
>> --
>> *Natasha Wijesekare*
>>
>> *Software Engineering Intern, WSO2  Inc:  http://wso2.com
>> *
>> *email  : nata...@wso2.com *
>> *mobile: +94 771358651 <%2B94%20771358651>*
>>
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> --
>
> *Nuwan Chamara Pallewela*
>
>
> *Software Engineer*
>
> *WSO2, Inc. *http://wso2.com
> *lean . enterprise . middleware*
>
> Email   *nuw...@wso2.com *
> Mobile  *+94719079739 <%2B94719079739>@*
>
>
>
> ___
> 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] [ESB] Deprecated features in ESB 4.10

2015-12-09 Thread Viraj Senevirathne

Hi,

I think we will have to test call mediator in blocking mode for some
different use cases. Then we will have to update Documentation about
blocking capability of call mediator. For example the Call Mediator
Documentation for ESB 4.9.0 [1] does not contain any information about
blocking behavior of the call mediator. I think most of the people do not
know about this feature because of that. In any case we will have to test
blocking behavior more as there are some complains about it.

[1] https://docs.wso2.com/display/ESB490/Call+Mediator
Thank you,

On Thu, Dec 10, 2015 at 10:39 AM, Kathees Rajendram 
wrote:

> +1 to deprecate Callout mediator since we have the Callout mediator
> functionalities in Call mediator.
>
> On Thu, Dec 10, 2015 at 1:18 AM, Vidura Gamini Abhaya 
> wrote:
>
>> I've found DBReport / DBLookup to be quite useful for simple DB
>> operations as they are easy to do OOTB. While DB Lookup mediator maybe
>> limited in it's ability to only being able to return a single row of data,
>> DB Report mediator is still quite useful in writing to a database,
>> especially when we use a DB as part of the mediation sequences.
>>
>> I also feel it is worth continuing with POJOCommand, as it is the most
>> simplest way of executing some custom code as part of a sequence. Although
>> it is possible to do the same with a Class mediator, one doesn't have to
>> worry about adding the proper jars, working with MessageContext etc. with
>> the POJOCommand. I think we should retain it for the sake of simplicity of
>> use.
>>
>> I'm +1 to deprecate the rest of the mediators.
>>
>> Thanks,
>>
>> Vidura
>>
>>
>>
>> On 9 December 2015 at 12:11, Kasun Indrasiri  wrote:
>>
>>> Shall we deprecate following mediators in 4.10 release.
>>>
>>> *- Callout mediator :*
>>>  All the callout functionality is supported with 'call' mediator with
>>> blocking=true. Having two similar mediators will be create a bit of a
>>> confusion.
>>>
>>> *- DBReport/DBLookup mediator*
>>> These mediators offer very limited functionality and we always recommend
>>> to integrate with databases with the use of DSS (using a separate DSS or
>>> using DSS features inside ESB)
>>>
>>> *- Bean, POJOCommand, Spring* : Rarely used mediators and no active
>>> development happens on these.
>>> *- Router* : Same as filter mediator, so no use of having this.
>>> *- In, Out * : Rarely used and often not required with the new
>>> call/respond mediator approach.
>>>
>>> Any comments  on these or any other features that we should deprecate
>>> from 4.10 release?
>>>
>>> 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
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Vidura Gamini Abhaya, Ph.D.
>> Director of Engineering
>> M:+94 77 034 7754
>> E: vid...@wso2.com
>>
>> WSO2 Inc. (http://wso2.com)
>> lean.enterprise.middleware
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Kathees
> Software Engineer,
> email: kath...@wso2.com
> mobile: +94772596173
>
> ___
> 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] We no longer need $CARBON_HOME/repository/deployment/server

2015-12-09 Thread Sameera Jayasoma

+1. We need to do this change in C5 :)

Thanks,
Sameera

On Thu, Dec 10, 2015 at 11:37 AM, Afkham Azeez  wrote:

> For example, the MSS deployment dir is
> $CARBON_HOME/repository/deployment/server/mss
>
> We no longer need the server part because this was a concept to do with
> Axis2 server & client ConfigContext creation, which we no longer have in
> Carbon 5.
>
> So the MSS deployment directory should be;
> $CARBON_HOME/repository/deployment/mss
>
> Same should be noted for Gateway.
>
>
> --
> *Afkham Azeez*
> Director of Architecture; WSO2, Inc.; http://wso2.com
> Member; Apache Software Foundation; http://www.apache.org/
> * *
> *email: **az...@wso2.com* 
> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: *
> *http://blog.afkham.org* 
> *twitter: **http://twitter.com/afkham_azeez*
> 
> *linked-in: **http://lk.linkedin.com/in/afkhamazeez
> *
>
> *Lean . Enterprise . Middleware*
>

-- 
Sameera Jayasoma,
Software Architect,

WSO2, Inc. (http://wso2.com)
email: same...@wso2.com
blog: http://blog.sameera.org
twitter: https://twitter.com/sameerajayasoma
flickr: http://www.flickr.com/photos/sameera-jayasoma/collections
Mobile: 0094776364456

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

Re: [Architecture] [ESB] Deprecated features in ESB 4.10

2015-12-09 Thread Vidura Gamini Abhaya

Hi Isuru,

I've used it in a mediation sequence where I use a POJO to generate a
unique customer id given a couple of parameters and there's a checksum
added to the end. I already had written this code and it was quite simple
and straightforward to reuse it with a POJOCommand mediator. I feel the
simplicity of it is a welcome feature, where reading and setting values in
MessageContext is automatically handled for me.

I don't know whether a single usage case is enough to make the case to keep
it. However, if we decide to keep it though, I suggest that we improve the
documentation on it. I had to dig around to find out how the what the
different actions mean. It wasn't clear to me in the docs (I believe most
of the content is carried forward from Syanpse).

Thanks and Regards,

Vidura



On 10 December 2015 at 10:57, Isuru Udana  wrote:

> Hi Kathees,
>
> I think we should do a comparison once more to make sure that we have
> covered everything before removing Callout. NTLM one which Harshana pointed
> out may be due to absence of initClientOptions configuration option.
>
> Hi Vidura,
> Point you raised on the POJOCommand mediator is really interesting. We
> haven't seen any usage of that over years. But now we found at least one
> user who has found it useful. Thanks for pointing that out. So we should
> reconsider how useful it is.
>
> Thanks.
>
>
>
> On Thu, Dec 10, 2015 at 10:39 AM, Kathees Rajendram 
> wrote:
>
>> +1 to deprecate Callout mediator since we have the Callout mediator
>> functionalities in Call mediator.
>>
>> On Thu, Dec 10, 2015 at 1:18 AM, Vidura Gamini Abhaya 
>> wrote:
>>
>>> I've found DBReport / DBLookup to be quite useful for simple DB
>>> operations as they are easy to do OOTB. While DB Lookup mediator maybe
>>> limited in it's ability to only being able to return a single row of data,
>>> DB Report mediator is still quite useful in writing to a database,
>>> especially when we use a DB as part of the mediation sequences.
>>>
>>> I also feel it is worth continuing with POJOCommand, as it is the most
>>> simplest way of executing some custom code as part of a sequence. Although
>>> it is possible to do the same with a Class mediator, one doesn't have to
>>> worry about adding the proper jars, working with MessageContext etc. with
>>> the POJOCommand. I think we should retain it for the sake of simplicity of
>>> use.
>>>
>>> I'm +1 to deprecate the rest of the mediators.
>>>
>>> Thanks,
>>>
>>> Vidura
>>>
>>>
>>>
>>> On 9 December 2015 at 12:11, Kasun Indrasiri  wrote:
>>>
 Shall we deprecate following mediators in 4.10 release.

 *- Callout mediator :*
  All the callout functionality is supported with 'call' mediator with
 blocking=true. Having two similar mediators will be create a bit of a
 confusion.

 *- DBReport/DBLookup mediator*
 These mediators offer very limited functionality and we always
 recommend to integrate with databases with the use of DSS (using a separate
 DSS or using DSS features inside ESB)

 *- Bean, POJOCommand, Spring* : Rarely used mediators and no active
 development happens on these.
 *- Router* : Same as filter mediator, so no use of having this.
 *- In, Out * : Rarely used and often not required with the new
 call/respond mediator approach.

 Any comments  on these or any other features that we should deprecate
 from 4.10 release?

 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
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>>
>>> --
>>> Vidura Gamini Abhaya, Ph.D.
>>> Director of Engineering
>>> M:+94 77 034 7754
>>> E: vid...@wso2.com
>>>
>>> WSO2 Inc. (http://wso2.com)
>>> lean.enterprise.middleware
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Kathees
>> Software Engineer,
>> email: kath...@wso2.com
>> mobile: +94772596173
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Isuru Udana*
> Associate Technical Lead
> WSO2 Inc.; http://wso2.com
> email: isu...@wso2.com cell: +94 77 3791887
> blog: http://mytecheye.blogspot.com/
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Vidura Gamini Abhaya, Ph.D.
Director of Engineering
M:+94 77 034 7754
E: vid...@wso2.com

WSO2

[Architecture] We no longer need $CARBON_HOME/repository/deployment/server

2015-12-09 Thread Afkham Azeez

For example, the MSS deployment dir is
$CARBON_HOME/repository/deployment/server/mss

We no longer need the server part because this was a concept to do with
Axis2 server & client ConfigContext creation, which we no longer have in
Carbon 5.

So the MSS deployment directory should be;
$CARBON_HOME/repository/deployment/mss

Same should be noted for Gateway.


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* *
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*

*twitter: **http://twitter.com/afkham_azeez*

*linked-in: **http://lk.linkedin.com/in/afkhamazeez
*

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

Re: [Architecture] [Dev] [BPS][BPMN] New REST API for BPMN statistics

2015-12-09 Thread Vinod Kavinda

Hi Natasha,
You can use the format used in Activiti rest api documentations [1] for
this also. It includes response codes and sample success responses.

@Dinithi, we are doing basic authentication using the security handler [2]
AFAIK.

[1] - http://www.activiti.org/userguide/#_get_a_deployment
[2] -
https://github.com/wso2/carbon-business-process/blob/master/components/bpmn/bpmn-rest/src/main/java/org/wso2/carbon/bpmn/rest/security/AuthenticationHandler.java

Regards,
Vinod Kavinda

On Thu, Dec 10, 2015 at 7:30 AM, Dinithi De Silva  wrote:

> Hi Natasha,
>
> How are you going to ensure the security of the APIs? Have you thought of
> using any security models?
>
> You can use  permission/role based model in order to achieve this. Just
> make sure which APIs need the administrative privileges.
>
> Thanks.
>
>
> On Wed, Dec 9, 2015 at 9:30 PM, Nuwan Pallewela  wrote:
>
>> Hi Natasha,
>>
>> Great work.
>> What happens if an invalid request or request with an illegal argument
>> sent to the API ?
>> It is better to have those response messages or response status code also
>> in the documentation.
>>
>> Thanks,
>> Nuwan
>>
>> On Wed, Dec 9, 2015 at 5:08 PM, Natasha Wijesekara 
>> wrote:
>>
>>> Hi,
>>>
>>> I  documented a user guide which contains details about the new rest API
>>> implemented to generate the statistics for bpmn.
>>> Appreciate any suggestions and comments.
>>>
>>> Thanks,
>>> Natasha
>>>
>>> On Tue, Dec 8, 2015 at 4:44 PM, Vinod Kavinda  wrote:
>>>
 [Adding Architecture group]

 On Tue, Dec 8, 2015 at 2:45 PM, Natasha Wijesekara 
 wrote:

> Hi ,
>
> Currently the statistics generated for the bpmn-explorer is generated
> using jaggery. When the work load is high, the  bpmn-explorer takes a
> longer time to generate these statistics which causes performance issues.
>
> As a solution I am working a new stats REST api  to generate these
> statistics at the back-end. This reduces the work load  and thereby solves
> the performance issues caused during peak times (when the workload is at
> its maximum).
>
> After taking in data about  the bpmn processes, tasks  and users
> involved, the api  processes these data into meaningful statistics.These
> statistics generated is used in the bpmn-explorer reporting dashboard to
> generate the statistical graphs.
>
> The statistics generated includes:
>
> 1) Average time duration for all completed processes.
> The user has the option to either view all completed processes or the
> top 10 processes which finished within a short time duration or the top 10
> processes which took a long time duration to finish.
>
> 2) Average time duration of tasks of a  completed process.
> The user can select the completed process from the combo box and view
> the average time duration.
>
> 3) User and the no. of tasks he/she has completed upto now.
>
> 4) Average time taken by each user to complete the tasks assigned to
> him/her.
>
> 5) Task demand variation over time i.e. no. of tasks started and no.
> of tasks completed in each month. This is useful for resource allocation
> purposes.
>
> 6) Process demand variation over time i.e. no. of processes started
> and no. of processes completed in each month regardless of a specific 
> user.
> This is useful for resource allocation purposes.
>
> 7) User Performance i.e. Task demand variation of users separately
> over time i.e. no. of tasks started and no. of tasks completed in each
> month. This is useful for resource allocation purposes.
>
> I have attached the class diagram of the REST api. The new stats REST
> api will be integrated with the existing bpmn REST api.
> Appreciate any suggestions and comments.
>
> Thanks,
> --
> *Natasha Wijesekare*
>
> *Software Engineering Intern, WSO2  Inc:  http://wso2.com
> *
> *email  : nata...@wso2.com *
> *mobile: +94 771358651 <%2B94%20771358651>*
>



 --
 Vinod Kavinda
 Software Engineer
 *WSO2 Inc. - lean . enterprise . middleware .*
 Mobile : +94 (0) 712 415544
 Blog : http://soatechflicks.blogspot.com/


>>>
>>>
>>> --
>>> *Natasha Wijesekare*
>>>
>>> *Software Engineering Intern, WSO2  Inc:  http://wso2.com
>>> *
>>> *email  : nata...@wso2.com *
>>> *mobile: +94 771358651 <%2B94%20771358651>*
>>>
>>> ___
>>> Dev mailing list
>>> d...@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> --
>>
>> *Nuwan Chamara Pallewela*
>>
>>
>> *Software Engineer*
>>
>> *WSO2, Inc. *http://wso2.com
>>

Re: [Architecture] [ESB] Deprecated features in ESB 4.10

2015-12-09 Thread Isuru Udana

Hi Kathees,

I think we should do a comparison once more to make sure that we have
covered everything before removing Callout. NTLM one which Harshana pointed
out may be due to absence of initClientOptions configuration option.

Hi Vidura,
Point you raised on the POJOCommand mediator is really interesting. We
haven't seen any usage of that over years. But now we found at least one
user who has found it useful. Thanks for pointing that out. So we should
reconsider how useful it is.

Thanks.



On Thu, Dec 10, 2015 at 10:39 AM, Kathees Rajendram 
wrote:

> +1 to deprecate Callout mediator since we have the Callout mediator
> functionalities in Call mediator.
>
> On Thu, Dec 10, 2015 at 1:18 AM, Vidura Gamini Abhaya 
> wrote:
>
>> I've found DBReport / DBLookup to be quite useful for simple DB
>> operations as they are easy to do OOTB. While DB Lookup mediator maybe
>> limited in it's ability to only being able to return a single row of data,
>> DB Report mediator is still quite useful in writing to a database,
>> especially when we use a DB as part of the mediation sequences.
>>
>> I also feel it is worth continuing with POJOCommand, as it is the most
>> simplest way of executing some custom code as part of a sequence. Although
>> it is possible to do the same with a Class mediator, one doesn't have to
>> worry about adding the proper jars, working with MessageContext etc. with
>> the POJOCommand. I think we should retain it for the sake of simplicity of
>> use.
>>
>> I'm +1 to deprecate the rest of the mediators.
>>
>> Thanks,
>>
>> Vidura
>>
>>
>>
>> On 9 December 2015 at 12:11, Kasun Indrasiri  wrote:
>>
>>> Shall we deprecate following mediators in 4.10 release.
>>>
>>> *- Callout mediator :*
>>>  All the callout functionality is supported with 'call' mediator with
>>> blocking=true. Having two similar mediators will be create a bit of a
>>> confusion.
>>>
>>> *- DBReport/DBLookup mediator*
>>> These mediators offer very limited functionality and we always recommend
>>> to integrate with databases with the use of DSS (using a separate DSS or
>>> using DSS features inside ESB)
>>>
>>> *- Bean, POJOCommand, Spring* : Rarely used mediators and no active
>>> development happens on these.
>>> *- Router* : Same as filter mediator, so no use of having this.
>>> *- In, Out * : Rarely used and often not required with the new
>>> call/respond mediator approach.
>>>
>>> Any comments  on these or any other features that we should deprecate
>>> from 4.10 release?
>>>
>>> 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
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Vidura Gamini Abhaya, Ph.D.
>> Director of Engineering
>> M:+94 77 034 7754
>> E: vid...@wso2.com
>>
>> WSO2 Inc. (http://wso2.com)
>> lean.enterprise.middleware
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Kathees
> Software Engineer,
> email: kath...@wso2.com
> mobile: +94772596173
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Isuru Udana*
Associate Technical Lead
WSO2 Inc.; http://wso2.com
email: isu...@wso2.com cell: +94 77 3791887
blog: http://mytecheye.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [ESB] Deprecated features in ESB 4.10

2015-12-09 Thread Malaka Silva

IMO best option in that case is have connectors supporting different spring
versions, similar to what we are doing for EJBs. Having a mediator will
only limit for single version.

On Thu, Dec 10, 2015 at 11:35 AM, Maheeka Jayasuriya 
wrote:

> Hi,
>
> I've observed spring mediator being used extensively in situations where
> maintaining the domain model useful (class mediators are the alternative
> with a POJO domain model). This allows maintainability and is easily
> extensible. However, Spring mediator right now does not explore best of
> Spring capabilities, also because we are using spring 1.2.8 where as latest
> is 4.2.X.
>
> It might be worthwhile to retain Spring mediator if we can upgrade the
> framework and explore more options, but depends on the validity of use
> cases.
>
> Thanks,
> Maheeka
>
>
> Maheeka Jayasuriya
> Software Engineer
> Mobile : +9450661
>
> On Thu, Dec 10, 2015 at 11:03 AM, Viraj Senevirathne 
> wrote:
>
>> Hi,
>>
>> I think we will have to test call mediator in blocking mode for some
>> different use cases. Then we will have to update Documentation about
>> blocking capability of call mediator. For example the Call Mediator
>> Documentation for ESB 4.9.0 [1] does not contain any information about
>> blocking behavior of the call mediator. I think most of the people do not
>> know about this feature because of that. In any case we will have to test
>> blocking behavior more as there are some complains about it.
>>
>> [1] https://docs.wso2.com/display/ESB490/Call+Mediator
>> Thank you,
>>
>> On Thu, Dec 10, 2015 at 10:39 AM, Kathees Rajendram 
>> wrote:
>>
>>> +1 to deprecate Callout mediator since we have the Callout mediator
>>> functionalities in Call mediator.
>>>
>>> On Thu, Dec 10, 2015 at 1:18 AM, Vidura Gamini Abhaya 
>>> wrote:
>>>
 I've found DBReport / DBLookup to be quite useful for simple DB
 operations as they are easy to do OOTB. While DB Lookup mediator maybe
 limited in it's ability to only being able to return a single row of data,
 DB Report mediator is still quite useful in writing to a database,
 especially when we use a DB as part of the mediation sequences.

 I also feel it is worth continuing with POJOCommand, as it is the most
 simplest way of executing some custom code as part of a sequence. Although
 it is possible to do the same with a Class mediator, one doesn't have to
 worry about adding the proper jars, working with MessageContext etc. with
 the POJOCommand. I think we should retain it for the sake of simplicity of
 use.

 I'm +1 to deprecate the rest of the mediators.

 Thanks,

 Vidura



 On 9 December 2015 at 12:11, Kasun Indrasiri  wrote:

> Shall we deprecate following mediators in 4.10 release.
>
> *- Callout mediator :*
>  All the callout functionality is supported with 'call' mediator with
> blocking=true. Having two similar mediators will be create a bit of a
> confusion.
>
> *- DBReport/DBLookup mediator*
> These mediators offer very limited functionality and we always
> recommend to integrate with databases with the use of DSS (using a 
> separate
> DSS or using DSS features inside ESB)
>
> *- Bean, POJOCommand, Spring* : Rarely used mediators and no active
> development happens on these.
> *- Router* : Same as filter mediator, so no use of having this.
> *- In, Out * : Rarely used and often not required with the new
> call/respond mediator approach.
>
> Any comments  on these or any other features that we should deprecate
> from 4.10 release?
>
> 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
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


 --
 Vidura Gamini Abhaya, Ph.D.
 Director of Engineering
 M:+94 77 034 7754
 E: vid...@wso2.com

 WSO2 Inc. (http://wso2.com)
 lean.enterprise.middleware

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


>>>
>>>
>>> --
>>> Kathees
>>> Software Engineer,
>>> email: kath...@wso2.com
>>> mobile: +94772596173
>>>
>>> ___
>>> 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
>>
>>

Re: [Architecture] [ESB] Deprecated features in ESB 4.10

2015-12-09 Thread Kathees Rajendram

+1 to deprecate Callout mediator since we have the Callout mediator
functionalities in Call mediator.

On Thu, Dec 10, 2015 at 1:18 AM, Vidura Gamini Abhaya 
wrote:

> I've found DBReport / DBLookup to be quite useful for simple DB operations
> as they are easy to do OOTB. While DB Lookup mediator maybe limited in it's
> ability to only being able to return a single row of data, DB Report
> mediator is still quite useful in writing to a database, especially when we
> use a DB as part of the mediation sequences.
>
> I also feel it is worth continuing with POJOCommand, as it is the most
> simplest way of executing some custom code as part of a sequence. Although
> it is possible to do the same with a Class mediator, one doesn't have to
> worry about adding the proper jars, working with MessageContext etc. with
> the POJOCommand. I think we should retain it for the sake of simplicity of
> use.
>
> I'm +1 to deprecate the rest of the mediators.
>
> Thanks,
>
> Vidura
>
>
>
> On 9 December 2015 at 12:11, Kasun Indrasiri  wrote:
>
>> Shall we deprecate following mediators in 4.10 release.
>>
>> *- Callout mediator :*
>>  All the callout functionality is supported with 'call' mediator with
>> blocking=true. Having two similar mediators will be create a bit of a
>> confusion.
>>
>> *- DBReport/DBLookup mediator*
>> These mediators offer very limited functionality and we always recommend
>> to integrate with databases with the use of DSS (using a separate DSS or
>> using DSS features inside ESB)
>>
>> *- Bean, POJOCommand, Spring* : Rarely used mediators and no active
>> development happens on these.
>> *- Router* : Same as filter mediator, so no use of having this.
>> *- In, Out * : Rarely used and often not required with the new
>> call/respond mediator approach.
>>
>> Any comments  on these or any other features that we should deprecate
>> from 4.10 release?
>>
>> 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
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Vidura Gamini Abhaya, Ph.D.
> Director of Engineering
> M:+94 77 034 7754
> E: vid...@wso2.com
>
> WSO2 Inc. (http://wso2.com)
> lean.enterprise.middleware
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Kathees
Software Engineer,
email: kath...@wso2.com
mobile: +94772596173
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [ESB] Deprecated features in ESB 4.10

2015-12-09 Thread Maheeka Jayasuriya

Hi,

I've observed spring mediator being used extensively in situations where
maintaining the domain model useful (class mediators are the alternative
with a POJO domain model). This allows maintainability and is easily
extensible. However, Spring mediator right now does not explore best of
Spring capabilities, also because we are using spring 1.2.8 where as latest
is 4.2.X.

It might be worthwhile to retain Spring mediator if we can upgrade the
framework and explore more options, but depends on the validity of use
cases.

Thanks,
Maheeka


Maheeka Jayasuriya
Software Engineer
Mobile : +9450661

On Thu, Dec 10, 2015 at 11:03 AM, Viraj Senevirathne 
wrote:

> Hi,
>
> I think we will have to test call mediator in blocking mode for some
> different use cases. Then we will have to update Documentation about
> blocking capability of call mediator. For example the Call Mediator
> Documentation for ESB 4.9.0 [1] does not contain any information about
> blocking behavior of the call mediator. I think most of the people do not
> know about this feature because of that. In any case we will have to test
> blocking behavior more as there are some complains about it.
>
> [1] https://docs.wso2.com/display/ESB490/Call+Mediator
> Thank you,
>
> On Thu, Dec 10, 2015 at 10:39 AM, Kathees Rajendram 
> wrote:
>
>> +1 to deprecate Callout mediator since we have the Callout mediator
>> functionalities in Call mediator.
>>
>> On Thu, Dec 10, 2015 at 1:18 AM, Vidura Gamini Abhaya 
>> wrote:
>>
>>> I've found DBReport / DBLookup to be quite useful for simple DB
>>> operations as they are easy to do OOTB. While DB Lookup mediator maybe
>>> limited in it's ability to only being able to return a single row of data,
>>> DB Report mediator is still quite useful in writing to a database,
>>> especially when we use a DB as part of the mediation sequences.
>>>
>>> I also feel it is worth continuing with POJOCommand, as it is the most
>>> simplest way of executing some custom code as part of a sequence. Although
>>> it is possible to do the same with a Class mediator, one doesn't have to
>>> worry about adding the proper jars, working with MessageContext etc. with
>>> the POJOCommand. I think we should retain it for the sake of simplicity of
>>> use.
>>>
>>> I'm +1 to deprecate the rest of the mediators.
>>>
>>> Thanks,
>>>
>>> Vidura
>>>
>>>
>>>
>>> On 9 December 2015 at 12:11, Kasun Indrasiri  wrote:
>>>
 Shall we deprecate following mediators in 4.10 release.

 *- Callout mediator :*
  All the callout functionality is supported with 'call' mediator with
 blocking=true. Having two similar mediators will be create a bit of a
 confusion.

 *- DBReport/DBLookup mediator*
 These mediators offer very limited functionality and we always
 recommend to integrate with databases with the use of DSS (using a separate
 DSS or using DSS features inside ESB)

 *- Bean, POJOCommand, Spring* : Rarely used mediators and no active
 development happens on these.
 *- Router* : Same as filter mediator, so no use of having this.
 *- In, Out * : Rarely used and often not required with the new
 call/respond mediator approach.

 Any comments  on these or any other features that we should deprecate
 from 4.10 release?

 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
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>>
>>> --
>>> Vidura Gamini Abhaya, Ph.D.
>>> Director of Engineering
>>> M:+94 77 034 7754
>>> E: vid...@wso2.com
>>>
>>> WSO2 Inc. (http://wso2.com)
>>> lean.enterprise.middleware
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Kathees
>> Software Engineer,
>> email: kath...@wso2.com
>> mobile: +94772596173
>>
>> ___
>> 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
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] We no longer need $CARBON_HOME/repository/deployment/server

2015-12-09 Thread Aruna Karunarathna

On Thu, Dec 10, 2015 at 11:57 AM, Sameera Jayasoma  wrote:

> +1. We need to do this change in C5 :)
>

Noted. Created a jira to track this [1]

[1]. https://wso2.org/jira/browse/CARBON-15723

>
> Thanks,
> Sameera
>
> On Thu, Dec 10, 2015 at 11:37 AM, Afkham Azeez  wrote:
>
>> For example, the MSS deployment dir is
>> $CARBON_HOME/repository/deployment/server/mss
>>
>> We no longer need the server part because this was a concept to do with
>> Axis2 server & client ConfigContext creation, which we no longer have in
>> Carbon 5.
>>
>> So the MSS deployment directory should be;
>> $CARBON_HOME/repository/deployment/mss
>>
>> Same should be noted for Gateway.
>>
>>
>> --
>> *Afkham Azeez*
>> Director of Architecture; WSO2, Inc.; http://wso2.com
>> Member; Apache Software Foundation; http://www.apache.org/
>> * *
>> *email: **az...@wso2.com* 
>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: *
>> *http://blog.afkham.org* 
>> *twitter: **http://twitter.com/afkham_azeez*
>> 
>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez
>> *
>>
>> *Lean . Enterprise . Middleware*
>>
>
>
>
> --
> Sameera Jayasoma,
> Software Architect,
>
> WSO2, Inc. (http://wso2.com)
> email: same...@wso2.com
> blog: http://blog.sameera.org
> twitter: https://twitter.com/sameerajayasoma
> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections
> Mobile: 0094776364456
>
> Lean . Enterprise . Middleware
>
>


-- 

*Aruna Sujith Karunarathna *| Software Engineer
WSO2, Inc | lean. enterprise. middleware.
#20, Palm Grove, Colombo 03, Sri Lanka
Mobile: +94 71 9040362 | Work: +94 112145345
Email: ar...@wso2.com | Web: www.wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [ESB] Deprecated features in ESB 4.10

2015-12-09 Thread Vidura Gamini Abhaya

I've found DBReport / DBLookup to be quite useful for simple DB operations
as they are easy to do OOTB. While DB Lookup mediator maybe limited in it's
ability to only being able to return a single row of data, DB Report
mediator is still quite useful in writing to a database, especially when we
use a DB as part of the mediation sequences.

I also feel it is worth continuing with POJOCommand, as it is the most
simplest way of executing some custom code as part of a sequence. Although
it is possible to do the same with a Class mediator, one doesn't have to
worry about adding the proper jars, working with MessageContext etc. with
the POJOCommand. I think we should retain it for the sake of simplicity of
use.

I'm +1 to deprecate the rest of the mediators.

Thanks,

Vidura

On 9 December 2015 at 12:11, Kasun Indrasiri  wrote:

> Shall we deprecate following mediators in 4.10 release.
>
> *- Callout mediator :*
>  All the callout functionality is supported with 'call' mediator with
> blocking=true. Having two similar mediators will be create a bit of a
> confusion.
>
> *- DBReport/DBLookup mediator*
> These mediators offer very limited functionality and we always recommend
> to integrate with databases with the use of DSS (using a separate DSS or
> using DSS features inside ESB)
>
> *- Bean, POJOCommand, Spring* : Rarely used mediators and no active
> development happens on these.
> *- Router* : Same as filter mediator, so no use of having this.
> *- In, Out * : Rarely used and often not required with the new
> call/respond mediator approach.
>
> Any comments  on these or any other features that we should deprecate from
> 4.10 release?
>
> 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
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>

-- 
Vidura Gamini Abhaya, Ph.D.
Director of Engineering
M:+94 77 034 7754
E: vid...@wso2.com

WSO2 Inc. (http://wso2.com)
lean.enterprise.middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [ESB] Deprecated features in ESB 4.10

Re: [Architecture] [ESB] Deprecated features in ESB 4.10

Re: [Architecture] [ESB] Deprecated features in ESB 4.10

Re: [Architecture] [Dev] [ESB] Deprecated features in ESB 4.10

Re: [Architecture] [Dev] [ESB] Deprecated features in ESB 4.10

Re: [Architecture] [ESB] Deprecated features in ESB 4.10

Re: [Architecture] [ESB] Deprecated features in ESB 4.10

Re: [Architecture] [Dev] [BPS][BPMN] New REST API for BPMN statistics

Re: [Architecture] [ESB] Deprecated features in ESB 4.10

Re: [Architecture] We no longer need $CARBON_HOME/repository/deployment/server

Re: [Architecture] [ESB] Deprecated features in ESB 4.10

[Architecture] We no longer need $CARBON_HOME/repository/deployment/server

Re: [Architecture] [Dev] [BPS][BPMN] New REST API for BPMN statistics

Re: [Architecture] [ESB] Deprecated features in ESB 4.10

Re: [Architecture] [Dev] [ESB] Deprecated features in ESB 4.10

Re: [Architecture] [ESB] Deprecated features in ESB 4.10

Re: [Architecture] [Dev] [ESB] Deprecated features in ESB 4.10

Re: [Architecture] We no longer need $CARBON_HOME/repository/deployment/server

Re: [Architecture] [ESB] Deprecated features in ESB 4.10

19 matches

Site Navigation

Mail list logo

Footer information