Re: [Architecture] OSGI Service and Admin Services

2014-11-13 Thread Roshan Deniyage 
+1 for the option no : 03. Admin services are web services and those need
to got to a separate layer. In that layer no business logic is required.

Roshan Deniyage
Associate Technical Lead
WSO2, Inc: http://wso2.com

Mobile:  +94 777636406
Twitter:  *https://twitter.com/roshku *
LinkedIn :  https://www.linkedin.com/in/roshandeniyage


On Thu, Nov 13, 2014 at 10:36 PM, Godwin Amila Shrimal 
wrote:

> Hi,
>
> We have Admin Services in carbon products which are needed to access as
> OSGI Services in the carbon context. Most of the time in Admin Services, it
> check weather user is authorized in the method, So we cannot register same
> Admin Service as a OSGI Service and access it. Since there are cases user
> is not authorized when we access as a OSGI Service. What is the best way to
> reuse the code and create OSGI Service and Admin Service.
>
> After discussing with some folks, i thought following mechanism to
> implement it.
>
> 1. Create an interface for the Service
> 2. Create an Implementation as OSGI Service
> 3. Create Admin Service which reuse the OSGI Service and apply additional
> security. (Here there will be no business logic and additional security
> will only applied.)
>
>
> Please give feedback on this.
>
>
> Thanks
> Godwin
>
>
>
> --
> *Godwin Amila Shrimal*
> Senior Software Engineer
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: *+94772264165*
> linkedin: *http://lnkd.in/KUum6D *
> twitter: https://twitter.com/godwinamila
>
> ___
> 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] OSGI Service and Admin Services

2014-11-13 Thread Srinath Perera 
#3 is the answer, but need to verify carefully this works (with Prabath and
(Sameera or Kishanthan))

If this works, this is a common pattern we can used at other places.

On Fri, Nov 14, 2014 at 9:53 AM, Roshan Deniyage  wrote:

> +1 for the option no : 03. Admin services are web services and those need
> to got to a separate layer. In that layer no business logic is required.
>
> Roshan Deniyage
> Associate Technical Lead
> WSO2, Inc: http://wso2.com
>
> Mobile:  +94 777636406
> Twitter:  *https://twitter.com/roshku *
> LinkedIn :  https://www.linkedin.com/in/roshandeniyage
>
>
> On Thu, Nov 13, 2014 at 10:36 PM, Godwin Amila Shrimal 
> wrote:
>
>> Hi,
>>
>> We have Admin Services in carbon products which are needed to access as
>> OSGI Services in the carbon context. Most of the time in Admin Services, it
>> check weather user is authorized in the method, So we cannot register same
>> Admin Service as a OSGI Service and access it. Since there are cases user
>> is not authorized when we access as a OSGI Service. What is the best way to
>> reuse the code and create OSGI Service and Admin Service.
>>
>> After discussing with some folks, i thought following mechanism to
>> implement it.
>>
>> 1. Create an interface for the Service
>> 2. Create an Implementation as OSGI Service
>> 3. Create Admin Service which reuse the OSGI Service and apply additional
>> security. (Here there will be no business logic and additional security
>> will only applied.)
>>
>>
>> Please give feedback on this.
>>
>>
>> Thanks
>> Godwin
>>
>>
>>
>> --
>> *Godwin Amila Shrimal*
>> Senior Software Engineer
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: *+94772264165*
>> linkedin: *http://lnkd.in/KUum6D *
>> twitter: https://twitter.com/godwinamila
>>
>> ___
>> 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
>
>


-- 

Srinath Perera, Ph.D.
   http://people.apache.org/~hemapani/
   http://srinathsview.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] OSGI Service and Admin Services

2014-11-13 Thread Godwin Amila Shrimal 
Copying Prabath, Sameera and Kishantha.

On Fri, Nov 14, 2014 at 10:07 AM, Srinath Perera  wrote:

> #3 is the answer, but need to verify carefully this works (with Prabath
> and (Sameera or Kishanthan))
>
> If this works, this is a common pattern we can used at other places.
>
> On Fri, Nov 14, 2014 at 9:53 AM, Roshan Deniyage  wrote:
>
>> +1 for the option no : 03. Admin services are web services and those need
>> to got to a separate layer. In that layer no business logic is required.
>>
>> Roshan Deniyage
>> Associate Technical Lead
>> WSO2, Inc: http://wso2.com
>>
>> Mobile:  +94 777636406
>> Twitter:  *https://twitter.com/roshku *
>> LinkedIn :  https://www.linkedin.com/in/roshandeniyage
>>
>>
>> On Thu, Nov 13, 2014 at 10:36 PM, Godwin Amila Shrimal 
>> wrote:
>>
>>> Hi,
>>>
>>> We have Admin Services in carbon products which are needed to access as
>>> OSGI Services in the carbon context. Most of the time in Admin Services, it
>>> check weather user is authorized in the method, So we cannot register same
>>> Admin Service as a OSGI Service and access it. Since there are cases user
>>> is not authorized when we access as a OSGI Service. What is the best way to
>>> reuse the code and create OSGI Service and Admin Service.
>>>
>>> After discussing with some folks, i thought following mechanism to
>>> implement it.
>>>
>>> 1. Create an interface for the Service
>>> 2. Create an Implementation as OSGI Service
>>> 3. Create Admin Service which reuse the OSGI Service and apply
>>> additional security. (Here there will be no business logic and additional
>>> security will only applied.)
>>>
>>>
>>> Please give feedback on this.
>>>
>>>
>>> Thanks
>>> Godwin
>>>
>>>
>>>
>>> --
>>> *Godwin Amila Shrimal*
>>> Senior Software Engineer
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: *+94772264165*
>>> linkedin: *http://lnkd.in/KUum6D *
>>> twitter: https://twitter.com/godwinamila
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> 
> Srinath Perera, Ph.D.
>http://people.apache.org/~hemapani/
>http://srinathsview.blogspot.com/
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Godwin Amila Shrimal*
Senior Software Engineer
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94772264165*
linkedin: *http://lnkd.in/KUum6D *
twitter: https://twitter.com/godwinamila
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] OSGI Service and Admin Services

2014-11-13 Thread Sameera Jayasoma 
Hi Godwin,

We tried the approach sometime back, but had to drop this coz of some
complexities.
*  Some admin services needs to access the axis2 context hierarchy e.g.
MessageContext, properties set in Handlers etc.   So you cannot put all
business logic to a OSGi Service.
* Admin services can define permissions required to access them and the
Security handlers checks whether the user is allowed access admin
services.  OSGi services which gives the same functionality as admin
services allows components to use them freely without and security
restrictions. AFAIR we faced such issues sometime back.

This approach is okay for some OSGi services/admin services, but not for
all. So we need to carefully think before exposing an Admin service as an
OSGi service.

Thanks,
Sameera.

On Thu, Nov 13, 2014 at 10:36 PM, Godwin Amila Shrimal 
wrote:

> Hi,
>
> We have Admin Services in carbon products which are needed to access as
> OSGI Services in the carbon context. Most of the time in Admin Services, it
> check weather user is authorized in the method, So we cannot register same
> Admin Service as a OSGI Service and access it. Since there are cases user
> is not authorized when we access as a OSGI Service. What is the best way to
> reuse the code and create OSGI Service and Admin Service.
>
> After discussing with some folks, i thought following mechanism to
> implement it.
>
> 1. Create an interface for the Service
> 2. Create an Implementation as OSGI Service
> 3. Create Admin Service which reuse the OSGI Service and apply additional
> security. (Here there will be no business logic and additional security
> will only applied.)
>
>
> Please give feedback on this.
>
>
> Thanks
> Godwin
>
>
>
> --
> *Godwin Amila Shrimal*
> Senior Software Engineer
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: *+94772264165*
> linkedin: *http://lnkd.in/KUum6D *
> twitter: https://twitter.com/godwinamila
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Sameera Jayasoma,
Software Architect,

WSO2, Inc. (http://wso2.com)
email: same...@wso2.com
blog: http://sameera.adahas.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] OSGI Service and Admin Services

2014-11-13 Thread Godwin Amila Shrimal 
Hi All,

Thanks for the feedback, I think I described it wrongly, I didn't mentioned
3 options to do this, I mentioned 3 steps to overcome the issue. Sorry for
my bad.

@Sameera : As you have mentioned we'll be have issues when admin services
use axis2 context hierarchy e.g. MessageContext, properties set in Handlers
etc, In that case what is the best way to implement, Do we have to keep
separate business logic implementations for OSGIService and AdminService ?


Thanks
Godwin




On Fri, Nov 14, 2014 at 11:22 AM, Sameera Jayasoma  wrote:

> Hi Godwin,
>
> We tried the approach sometime back, but had to drop this coz of some
> complexities.
> *  Some admin services needs to access the axis2 context hierarchy e.g.
> MessageContext, properties set in Handlers etc.   So you cannot put all
> business logic to a OSGi Service.
> * Admin services can define permissions required to access them and the
> Security handlers checks whether the user is allowed access admin
> services.  OSGi services which gives the same functionality as admin
> services allows components to use them freely without and security
> restrictions. AFAIR we faced such issues sometime back.
>
> This approach is okay for some OSGi services/admin services, but not for
> all. So we need to carefully think before exposing an Admin service as an
> OSGi service.
>
> Thanks,
> Sameera.
>
> On Thu, Nov 13, 2014 at 10:36 PM, Godwin Amila Shrimal 
> wrote:
>
>> Hi,
>>
>> We have Admin Services in carbon products which are needed to access as
>> OSGI Services in the carbon context. Most of the time in Admin Services, it
>> check weather user is authorized in the method, So we cannot register same
>> Admin Service as a OSGI Service and access it. Since there are cases user
>> is not authorized when we access as a OSGI Service. What is the best way to
>> reuse the code and create OSGI Service and Admin Service.
>>
>> After discussing with some folks, i thought following mechanism to
>> implement it.
>>
>> 1. Create an interface for the Service
>> 2. Create an Implementation as OSGI Service
>> 3. Create Admin Service which reuse the OSGI Service and apply additional
>> security. (Here there will be no business logic and additional security
>> will only applied.)
>>
>>
>> Please give feedback on this.
>>
>>
>> Thanks
>> Godwin
>>
>>
>>
>> --
>> *Godwin Amila Shrimal*
>> Senior Software Engineer
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: *+94772264165*
>> linkedin: *http://lnkd.in/KUum6D *
>> twitter: https://twitter.com/godwinamila
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Sameera Jayasoma,
> Software Architect,
>
> WSO2, Inc. (http://wso2.com)
> email: same...@wso2.com
> blog: http://sameera.adahas.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
>
>


-- 
*Godwin Amila Shrimal*
Senior Software Engineer
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94772264165*
linkedin: *http://lnkd.in/KUum6D *
twitter: https://twitter.com/godwinamila
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] OSGI Service and Admin Services

2014-11-14 Thread Harshan Liyanage 
Hi Godwin,

IMO keeping the business logic separate from the services will be more
appropriate. So that you can change the business logic later without
breaking the service contract.

Thanks,

Lakshitha Harshan
Software Engineer
Mobile: *+94724423048*
Email: hars...@wso2.com
Blog : http://harshanliyanage.blogspot.com/
*WSO2, Inc. :** wso2.com *
lean.enterprise.middleware.

On Fri, Nov 14, 2014 at 11:29 AM, Godwin Amila Shrimal 
wrote:

> Hi All,
>
> Thanks for the feedback, I think I described it wrongly, I didn't
> mentioned 3 options to do this, I mentioned 3 steps to overcome the issue.
> Sorry for my bad.
>
> @Sameera : As you have mentioned we'll be have issues when admin services
> use axis2 context hierarchy e.g. MessageContext, properties set in
> Handlers etc, In that case what is the best way to implement, Do we have to
> keep separate business logic implementations for OSGIService and
> AdminService ?
>
>
> Thanks
> Godwin
>
>
>
>
> On Fri, Nov 14, 2014 at 11:22 AM, Sameera Jayasoma 
> wrote:
>
>> Hi Godwin,
>>
>> We tried the approach sometime back, but had to drop this coz of some
>> complexities.
>> *  Some admin services needs to access the axis2 context hierarchy e.g.
>> MessageContext, properties set in Handlers etc.   So you cannot put all
>> business logic to a OSGi Service.
>> * Admin services can define permissions required to access them and the
>> Security handlers checks whether the user is allowed access admin
>> services.  OSGi services which gives the same functionality as admin
>> services allows components to use them freely without and security
>> restrictions. AFAIR we faced such issues sometime back.
>>
>> This approach is okay for some OSGi services/admin services, but not for
>> all. So we need to carefully think before exposing an Admin service as an
>> OSGi service.
>>
>> Thanks,
>> Sameera.
>>
>> On Thu, Nov 13, 2014 at 10:36 PM, Godwin Amila Shrimal 
>> wrote:
>>
>>> Hi,
>>>
>>> We have Admin Services in carbon products which are needed to access as
>>> OSGI Services in the carbon context. Most of the time in Admin Services, it
>>> check weather user is authorized in the method, So we cannot register same
>>> Admin Service as a OSGI Service and access it. Since there are cases user
>>> is not authorized when we access as a OSGI Service. What is the best way to
>>> reuse the code and create OSGI Service and Admin Service.
>>>
>>> After discussing with some folks, i thought following mechanism to
>>> implement it.
>>>
>>> 1. Create an interface for the Service
>>> 2. Create an Implementation as OSGI Service
>>> 3. Create Admin Service which reuse the OSGI Service and apply
>>> additional security. (Here there will be no business logic and additional
>>> security will only applied.)
>>>
>>>
>>> Please give feedback on this.
>>>
>>>
>>> Thanks
>>> Godwin
>>>
>>>
>>>
>>> --
>>> *Godwin Amila Shrimal*
>>> Senior Software Engineer
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: *+94772264165*
>>> linkedin: *http://lnkd.in/KUum6D *
>>> twitter: https://twitter.com/godwinamila
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Sameera Jayasoma,
>> Software Architect,
>>
>> WSO2, Inc. (http://wso2.com)
>> email: same...@wso2.com
>> blog: http://sameera.adahas.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
>>
>>
>
>
> --
> *Godwin Amila Shrimal*
> Senior Software Engineer
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: *+94772264165*
> linkedin: *http://lnkd.in/KUum6D *
> twitter: https://twitter.com/godwinamila
>
> ___
> 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] OSGI Service and Admin Services

2014-11-16 Thread Godwin Amila Shrimal 
Hi Harshan,

Correct, I had a offline discussion with Sameera on this. But there are
some cases inside the business logic it requires axis2 context hierarchy
which only can access from admin service and cannot access from OSGI
Service level. In that case we cannot use this pattern in all the time. But
if we can find a solution for that, it'll be more versatile approach.

Thanks
Godwin



On Sat, Nov 15, 2014 at 11:09 AM, Harshan Liyanage  wrote:

> Hi Godwin,
>
> IMO keeping the business logic separate from the services will be more
> appropriate. So that you can change the business logic later without
> breaking the service contract.
>
> Thanks,
>
> Lakshitha Harshan
> Software Engineer
> Mobile: *+94724423048*
> Email: hars...@wso2.com
> Blog : http://harshanliyanage.blogspot.com/
> *WSO2, Inc. :** wso2.com *
> lean.enterprise.middleware.
>
> On Fri, Nov 14, 2014 at 11:29 AM, Godwin Amila Shrimal 
> wrote:
>
>> Hi All,
>>
>> Thanks for the feedback, I think I described it wrongly, I didn't
>> mentioned 3 options to do this, I mentioned 3 steps to overcome the issue.
>> Sorry for my bad.
>>
>> @Sameera : As you have mentioned we'll be have issues when admin services
>> use axis2 context hierarchy e.g. MessageContext, properties set in
>> Handlers etc, In that case what is the best way to implement, Do we have to
>> keep separate business logic implementations for OSGIService and
>> AdminService ?
>>
>>
>> Thanks
>> Godwin
>>
>>
>>
>>
>> On Fri, Nov 14, 2014 at 11:22 AM, Sameera Jayasoma 
>> wrote:
>>
>>> Hi Godwin,
>>>
>>> We tried the approach sometime back, but had to drop this coz of some
>>> complexities.
>>> *  Some admin services needs to access the axis2 context hierarchy e.g.
>>> MessageContext, properties set in Handlers etc.   So you cannot put all
>>> business logic to a OSGi Service.
>>> * Admin services can define permissions required to access them and the
>>> Security handlers checks whether the user is allowed access admin
>>> services.  OSGi services which gives the same functionality as admin
>>> services allows components to use them freely without and security
>>> restrictions. AFAIR we faced such issues sometime back.
>>>
>>> This approach is okay for some OSGi services/admin services, but not for
>>> all. So we need to carefully think before exposing an Admin service as an
>>> OSGi service.
>>>
>>> Thanks,
>>> Sameera.
>>>
>>> On Thu, Nov 13, 2014 at 10:36 PM, Godwin Amila Shrimal 
>>> wrote:
>>>
 Hi,

 We have Admin Services in carbon products which are needed to access as
 OSGI Services in the carbon context. Most of the time in Admin Services, it
 check weather user is authorized in the method, So we cannot register same
 Admin Service as a OSGI Service and access it. Since there are cases user
 is not authorized when we access as a OSGI Service. What is the best way to
 reuse the code and create OSGI Service and Admin Service.

 After discussing with some folks, i thought following mechanism to
 implement it.

 1. Create an interface for the Service
 2. Create an Implementation as OSGI Service
 3. Create Admin Service which reuse the OSGI Service and apply
 additional security. (Here there will be no business logic and additional
 security will only applied.)


 Please give feedback on this.


 Thanks
 Godwin



 --
 *Godwin Amila Shrimal*
 Senior Software Engineer
 WSO2 Inc.; http://wso2.com
 lean.enterprise.middleware

 mobile: *+94772264165*
 linkedin: *http://lnkd.in/KUum6D *
 twitter: https://twitter.com/godwinamila

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


>>>
>>>
>>> --
>>> Sameera Jayasoma,
>>> Software Architect,
>>>
>>> WSO2, Inc. (http://wso2.com)
>>> email: same...@wso2.com
>>> blog: http://sameera.adahas.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
>>>
>>>
>>
>>
>> --
>> *Godwin Amila Shrimal*
>> Senior Software Engineer
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: *+94772264165*
>> linkedin: *http://lnkd.in/KUum6D *
>> twitter: https://twitter.com/godwinamila
>>
>> ___
>> 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/mail