Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Isuru Perera]

+1 to remove the use of stubs to communicate with BE. But still we need to
keep layers separate. We can do that by programming to an interface [1].

[1]
http://en.wikipedia.org/wiki/Interface_%28computing%29#Programming_to_the_interface


On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez  wrote:

> With the worker-manager concept, we no longer require FE-BE separation.
> There is no need to have FE-BE separation for the management node. So, I
> think we can completely do away with that concept.
>
> What do you guys think?
>
> --
> *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
> blog: **http://blog.afkham.org* *
> twitter: **http://twitter.com/afkham_azeez*
> *
> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
> *
> *
> *Lean . Enterprise . Middleware*
>
> ___
> Architecture mailing list
> architect...@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Isuru Perera
Senior Software Engineer | WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

Twitter: http://twitter.com/chrishantha | LinkedIn:
http://lk.linkedin.com/in/chrishantha/
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Supun Malinga]

Hi Azeez,

Few things I need to clarify,
Does this mean we have to merge both BE and FE bundles together?.
AFAIU worker nodes are just BEs that doesn't require a UI. So in that case
how does removing BE-FE seperation helpful?.

thanks,


On Thu, Mar 21, 2013 at 4:18 PM, Isuru Perera  wrote:

> +1 to remove the use of stubs to communicate with BE. But still we need to
> keep layers separate. We can do that by programming to an interface [1].
>
> [1]
> http://en.wikipedia.org/wiki/Interface_%28computing%29#Programming_to_the_interface
>
>
> On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez  wrote:
>
>> With the worker-manager concept, we no longer require FE-BE separation.
>> There is no need to have FE-BE separation for the management node. So, I
>> think we can completely do away with that concept.
>>
>> What do you guys think?
>>
>> --
>> *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
>> blog: **http://blog.afkham.org* *
>> twitter: **http://twitter.com/afkham_azeez*
>> *
>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>> *
>> *
>> *Lean . Enterprise . Middleware*
>>
>> ___
>> Architecture mailing list
>> architect...@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Isuru Perera
> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
>
> Lean . Enterprise . Middleware
>
> Twitter: http://twitter.com/chrishantha | LinkedIn:
> http://lk.linkedin.com/in/chrishantha/
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Supun Malinga,

Software Engineer,
WSO2 Inc.
http://wso2.com
http://wso2.org
email - sup...@wso2.com 
mobile - 071 56 91 321
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Sagara Gunathunga]

On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez  wrote:

> With the worker-manager concept, we no longer require FE-BE separation.
> There is no need to have FE-BE separation for the management node. So, I
> think we can completely do away with that concept.
>
> What do you guys think?
>

  Great+1 !!

In fact I also wanted to bring this idea, right now maintaining FE-BE is a
extra overhead and having very little usage. Instead we should call
relevant BE services directly from JSPs/Web FEs without going through any
WS layer in other word should be a java-to-java communication.

Thanks !

>
> --
> *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
> blog: **http://blog.afkham.org* *
> twitter: **http://twitter.com/afkham_azeez*
> *
> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
> *
> *
> *Lean . Enterprise . Middleware*
>
> ___
> Architecture mailing list
> architect...@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Sagara Gunathunga

Technical Lead; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services ;  http://ws.apache.org/
Blog ;  http://ssagara.blogspot.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Afkham Azeez]

If you look at it, a management node is an AppServer which run a management
webapp. It need not have the functionality of the corresponding worker
nodes. There is no such "back-end", unless we want to expose a management
API too. With Jaggery, that is also very simple to provide, we can have the
API & app in the same Jaggery App.

Azeez

On Thu, Mar 21, 2013 at 4:18 PM, Isuru Perera  wrote:

> +1 to remove the use of stubs to communicate with BE. But still we need to
> keep layers separate. We can do that by programming to an interface [1].
>
> [1]
> http://en.wikipedia.org/wiki/Interface_%28computing%29#Programming_to_the_interface
>
>
> On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez  wrote:
>
>> With the worker-manager concept, we no longer require FE-BE separation.
>> There is no need to have FE-BE separation for the management node. So, I
>> think we can completely do away with that concept.
>>
>> What do you guys think?
>>
>> --
>> *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
>> blog: **http://blog.afkham.org* *
>> twitter: **http://twitter.com/afkham_azeez*
>> *
>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>> *
>> *
>> *Lean . Enterprise . Middleware*
>>
>> ___
>> Architecture mailing list
>> architect...@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Isuru Perera
> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
>
> Lean . Enterprise . Middleware
>
> Twitter: http://twitter.com/chrishantha | LinkedIn:
> http://lk.linkedin.com/in/chrishantha/
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*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
blog: **http://blog.afkham.org* *
twitter: **http://twitter.com/afkham_azeez*
*
linked-in: **http://lk.linkedin.com/in/afkhamazeez*
*
*
*Lean . Enterprise . Middleware*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Isuru Perera]

On Thu, Mar 21, 2013 at 4:26 PM, Sagara Gunathunga  wrote:

>
>
> On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez  wrote:
>
>> With the worker-manager concept, we no longer require FE-BE separation.
>> There is no need to have FE-BE separation for the management node. So, I
>> think we can completely do away with that concept.
>>
>> What do you guys think?
>>
>
>   Great+1 !!
>
> In fact I also wanted to bring this idea, right now maintaining FE-BE is a
> extra overhead and having very little usage.
>

Even I wanted to bring this idea!Even I wanted to bring this idea!

 Instead we should call relevant BE services directly from JSPs/Web FEs
> without going through any WS layer in other word should be a java-to-java
> communication.
>

Yes. We should get rid of calling Web Services within the same JVM. We
should still keep the FE & BE separated. If we program to an interface,
then we don't have to worry about implementation specific details. Then we
can separate FE & BE later if we really need.



>
> Thanks !
>
>>
>> --
>> *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
>> blog: **http://blog.afkham.org* *
>> twitter: **http://twitter.com/afkham_azeez*
>> *
>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>> *
>> *
>> *Lean . Enterprise . Middleware*
>>
>> ___
>> Architecture mailing list
>> architect...@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Sagara Gunathunga
>
> Technical Lead; WSO2, Inc.;  http://wso2.com
> V.P Apache Web Services ;  http://ws.apache.org/
> Blog ;  http://ssagara.blogspot.com
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Isuru Perera
Senior Software Engineer | WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

Twitter: http://twitter.com/chrishantha | LinkedIn:
http://lk.linkedin.com/in/chrishantha/
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Afkham Azeez]

worker nodes should not have any backend management functionality.

On Thu, Mar 21, 2013 at 4:25 PM, Supun Malinga  wrote:

> Hi Azeez,
>
> Few things I need to clarify,
> Does this mean we have to merge both BE and FE bundles together?.
> AFAIU worker nodes are just BEs that doesn't require a UI. So in that case
> how does removing BE-FE seperation helpful?.
>
> thanks,
>
>
> On Thu, Mar 21, 2013 at 4:18 PM, Isuru Perera  wrote:
>
>> +1 to remove the use of stubs to communicate with BE. But still we need
>> to keep layers separate. We can do that by programming to an interface [1].
>>
>> [1]
>> http://en.wikipedia.org/wiki/Interface_%28computing%29#Programming_to_the_interface
>>
>>
>> On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez  wrote:
>>
>>> With the worker-manager concept, we no longer require FE-BE separation.
>>> There is no need to have FE-BE separation for the management node. So, I
>>> think we can completely do away with that concept.
>>>
>>> What do you guys think?
>>>
>>> --
>>> *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
>>> blog: **http://blog.afkham.org* *
>>> twitter: **http://twitter.com/afkham_azeez*
>>> *
>>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>>> *
>>> *
>>> *Lean . Enterprise . Middleware*
>>>
>>> ___
>>> Architecture mailing list
>>> architect...@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Isuru Perera
>> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
>>
>> Lean . Enterprise . Middleware
>>
>> Twitter: http://twitter.com/chrishantha | LinkedIn:
>> http://lk.linkedin.com/in/chrishantha/
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Supun Malinga,
>
> Software Engineer,
> WSO2 Inc.
> http://wso2.com
> http://wso2.org
> email - sup...@wso2.com 
> mobile - 071 56 91 321
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*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
blog: **http://blog.afkham.org* *
twitter: **http://twitter.com/afkham_azeez*
*
linked-in: **http://lk.linkedin.com/in/afkhamazeez*
*
*
*Lean . Enterprise . Middleware*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Afkham Azeez]

On Thu, Mar 21, 2013 at 4:26 PM, Sagara Gunathunga  wrote:

>
>
> On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez  wrote:
>
>> With the worker-manager concept, we no longer require FE-BE separation.
>> There is no need to have FE-BE separation for the management node. So, I
>> think we can completely do away with that concept.
>>
>> What do you guys think?
>>
>
>   Great+1 !!
>
> In fact I also wanted to bring this idea, right now maintaining FE-BE is a
> extra overhead and having very little usage. Instead we should call
> relevant BE services directly from JSPs/Web FEs without going through any
> WS layer in other word should be a java-to-java communication.
>

The only major issue which we will have to fix is the authentication &
authorization mechanism. We have heavily relied on the Axis2 handler
architecture to do this. In fact, our FEs are not that secure, it is only
at the BE that we ensure strong security (authz), so when we fuse the two
together, the authz model will have to br properly thought through.

Azeez


>
> Thanks !
>
>>
>> --
>> *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
>> blog: **http://blog.afkham.org* *
>> twitter: **http://twitter.com/afkham_azeez*
>> *
>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>> *
>> *
>> *Lean . Enterprise . Middleware*
>>
>> ___
>> Architecture mailing list
>> architect...@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Sagara Gunathunga
>
> Technical Lead; WSO2, Inc.;  http://wso2.com
> V.P Apache Web Services ;  http://ws.apache.org/
> Blog ;  http://ssagara.blogspot.com
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*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
blog: **http://blog.afkham.org* *
twitter: **http://twitter.com/afkham_azeez*
*
linked-in: **http://lk.linkedin.com/in/afkhamazeez*
*
*
*Lean . Enterprise . Middleware*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Sagara Gunathunga]

On Thu, Mar 21, 2013 at 4:25 PM, Supun Malinga  wrote:

> Hi Azeez,
>
> Few things I need to clarify,
> Does this mean we have to merge both BE and FE bundles together?.
> AFAIU worker nodes are just BEs that doesn't require a UI. So in that case
> how does removing BE-FE seperation helpful?.
>

I think if we want still we can maintain BE and FE bundles the main idea
here is to remove unwanted WS layer in between FE and BE.  Ideally BE
contains back end services and FE contains JSP pages, this JSP pages
directly communicate with BE service using Java calls without going through
any WS layer ( No more serialization/ deserialization between FE-BE).

Thanks !

>
> thanks,
>
>
> On Thu, Mar 21, 2013 at 4:18 PM, Isuru Perera  wrote:
>
>> +1 to remove the use of stubs to communicate with BE. But still we need
>> to keep layers separate. We can do that by programming to an interface [1].
>>
>> [1]
>> http://en.wikipedia.org/wiki/Interface_%28computing%29#Programming_to_the_interface
>>
>>
>> On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez  wrote:
>>
>>> With the worker-manager concept, we no longer require FE-BE separation.
>>> There is no need to have FE-BE separation for the management node. So, I
>>> think we can completely do away with that concept.
>>>
>>> What do you guys think?
>>>
>>> --
>>> *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
>>> blog: **http://blog.afkham.org* *
>>> twitter: **http://twitter.com/afkham_azeez*
>>> *
>>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>>> *
>>> *
>>> *Lean . Enterprise . Middleware*
>>>
>>> ___
>>> Architecture mailing list
>>> architect...@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Isuru Perera
>> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
>>
>> Lean . Enterprise . Middleware
>>
>> Twitter: http://twitter.com/chrishantha | LinkedIn:
>> http://lk.linkedin.com/in/chrishantha/
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Supun Malinga,
>
> Software Engineer,
> WSO2 Inc.
> http://wso2.com
> http://wso2.org
> email - sup...@wso2.com 
> mobile - 071 56 91 321
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Sagara Gunathunga

Technical Lead; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services ;  http://ws.apache.org/
Blog ;  http://ssagara.blogspot.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Isuru Perera]

On Thu, Mar 21, 2013 at 4:37 PM, Sagara Gunathunga  wrote:

> I think if we want still we can maintain BE and FE bundles the main idea
> here is to remove unwanted WS layer in between FE and BE.  Ideally BE
> contains back end services and FE contains JSP pages, this JSP pages
> directly communicate with BE service using Java calls without going through
> any WS layer ( No more serialization/ deserialization between FE-BE).


Another advantage is we can get rid of JSPs, which is more than 10 years
old technology! :)

-- 
Isuru Perera
Senior Software Engineer | WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

Twitter: http://twitter.com/chrishantha | LinkedIn:
http://lk.linkedin.com/in/chrishantha/
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Sagara Gunathunga]

On Thu, Mar 21, 2013 at 4:36 PM, Afkham Azeez  wrote:

>
>
> On Thu, Mar 21, 2013 at 4:26 PM, Sagara Gunathunga wrote:
>
>>
>>
>> On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez  wrote:
>>
>>> With the worker-manager concept, we no longer require FE-BE separation.
>>> There is no need to have FE-BE separation for the management node. So, I
>>> think we can completely do away with that concept.
>>>
>>> What do you guys think?
>>>
>>
>>   Great+1 !!
>>
>> In fact I also wanted to bring this idea, right now maintaining FE-BE is
>> a extra overhead and having very little usage. Instead we should call
>> relevant BE services directly from JSPs/Web FEs without going through any
>> WS layer in other word should be a java-to-java communication.
>>
>
> The only major issue which we will have to fix is the authentication &
> authorization mechanism. We have heavily relied on the Axis2 handler
> architecture to do this. In fact, our FEs are not that secure, it is only
> at the BE that we ensure strong security (authz), so when we fuse the two
> together, the authz model will have to br properly thought through.
>

Basically our Carbon Admin is a web app run on tomcat hence naturally we
should able to provide authentication & authorization through kind of   Web
app Filter without using Axis2 stuff. In C5 there will be no Axis2 hence we
need to invent a new security model for Carbon admin console. It seems
Servlet Filter (may be valve ) model work here.

Thanks !


>
> Azeez
>
>
>>
>> Thanks !
>>
>>>
>>> --
>>> *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
>>> blog: **http://blog.afkham.org* *
>>> twitter: **http://twitter.com/afkham_azeez*
>>> *
>>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>>> *
>>> *
>>> *Lean . Enterprise . Middleware*
>>>
>>> ___
>>> Architecture mailing list
>>> architect...@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Sagara Gunathunga
>>
>> Technical Lead; WSO2, Inc.;  http://wso2.com
>> V.P Apache Web Services ;  http://ws.apache.org/
>> Blog ;  http://ssagara.blogspot.com
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *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
> blog: **http://blog.afkham.org* *
> twitter: **http://twitter.com/afkham_azeez*
> *
> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
> *
> *
> *Lean . Enterprise . Middleware*
>



-- 
Sagara Gunathunga

Technical Lead; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services ;  http://ws.apache.org/
Blog ;  http://ssagara.blogspot.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Isuru Perera]

On Thu, Mar 21, 2013 at 4:44 PM, Sagara Gunathunga  wrote:

> Basically our Carbon Admin is a web app run on tomcat hence naturally we
> should able to provide authentication & authorization through kind of   Web
> app Filter without using Axis2 stuff. In C5 there will be no Axis2 hence we
> need to invent a new security model for Carbon admin console. It seems
> Servlet Filter (may be valve ) model work here.


Even Spring Security [1] uses a Filter.

[1] http://www.springsource.org/spring-security
-- 
Isuru Perera
Senior Software Engineer | WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

Twitter: http://twitter.com/chrishantha | LinkedIn:
http://lk.linkedin.com/in/chrishantha/
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Samisa Abeysinghe]

On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez  wrote:

> With the worker-manager concept, we no longer require FE-BE separation.
> There is no need to have FE-BE separation for the management node. So, I
> think we can completely do away with that concept.


But how do we separate the worker stuff from manager stuff?
Is that not
Manger == FE + BE
Worker == BE


>
> What do you guys think?
>
> --
> *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
> blog: **http://blog.afkham.org* *
> twitter: **http://twitter.com/afkham_azeez*
> *
> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
> *
> *
> *Lean . Enterprise . Middleware*
>
> ___
> Architecture mailing list
> architect...@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
> Thanks,
Samisa...

Samisa Abeysinghe
VP Engineering
WSO2 Inc.
http://wso2.com
http://wso2.org
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Afkham Azeez]

On Thu, Mar 21, 2013 at 5:56 PM, Samisa Abeysinghe  wrote:

>
>
> On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez  wrote:
>
>> With the worker-manager concept, we no longer require FE-BE separation.
>> There is no need to have FE-BE separation for the management node. So, I
>> think we can completely do away with that concept.
>
>
> But how do we separate the worker stuff from manager stuff?
> Is that not
> Manger == FE + BE
> Worker == BE
>
>

No, FE is the front end of the management admin client. BE is the
management service/API. Worker provides the runtime to run services, apps,
processes, mediation etc. We have made the mistake of calling this runtime
as BE as well. Management nodes will not ideally require this runtime, but
we may need to have some parts of it. e.g. validating the Synapse config
will require Synapse to be in the management node. We will never have a
case where a FE talks to a BE in a worker node. When it comes to the mgt
node, there is no need for separating the FE & BE.


>
>> What do you guys think?
>>
>> --
>> *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
>> blog: **http://blog.afkham.org* *
>> twitter: **http://twitter.com/afkham_azeez*
>> *
>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>> *
>> *
>> *Lean . Enterprise . Middleware*
>>
>> ___
>> Architecture mailing list
>> architect...@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>> Thanks,
> Samisa...
>
> Samisa Abeysinghe
> VP Engineering
> WSO2 Inc.
> http://wso2.com
> http://wso2.org
>
>
>
> ___
> Architecture mailing list
> architect...@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*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
blog: **http://blog.afkham.org* *
twitter: **http://twitter.com/afkham_azeez*
*
linked-in: **http://lk.linkedin.com/in/afkhamazeez*
*
*
*Lean . Enterprise . Middleware*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Sanjiva Weerawarana]

Azeez don't we need the management API in worker nodes? I assume the answer
is yes ..

So in that case the worker contains the runtime container logic plus a
management API (running at a separate port etc. and enabled by request).
The management node contains an admin app that talks to the worker nodes
via the API and other means (such as ADC). Right?

+1 as long as we can still ship a multi-profile distro by default where all
of this is in one JVM and then you give the personalty at boot time.

Sanjiva.


On Thu, Mar 21, 2013 at 6:03 PM, Afkham Azeez  wrote:

>
>
> On Thu, Mar 21, 2013 at 5:56 PM, Samisa Abeysinghe wrote:
>
>>
>>
>> On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez  wrote:
>>
>>> With the worker-manager concept, we no longer require FE-BE separation.
>>> There is no need to have FE-BE separation for the management node. So, I
>>> think we can completely do away with that concept.
>>
>>
>> But how do we separate the worker stuff from manager stuff?
>> Is that not
>> Manger == FE + BE
>> Worker == BE
>>
>>
>
> No, FE is the front end of the management admin client. BE is the
> management service/API. Worker provides the runtime to run services, apps,
> processes, mediation etc. We have made the mistake of calling this runtime
> as BE as well. Management nodes will not ideally require this runtime, but
> we may need to have some parts of it. e.g. validating the Synapse config
> will require Synapse to be in the management node. We will never have a
> case where a FE talks to a BE in a worker node. When it comes to the mgt
> node, there is no need for separating the FE & BE.
>
>
>>
>>> What do you guys think?
>>>
>>> --
>>> *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
>>> blog: **http://blog.afkham.org* *
>>> twitter: **http://twitter.com/afkham_azeez*
>>> *
>>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>>> *
>>> *
>>> *Lean . Enterprise . Middleware*
>>>
>>> ___
>>> Architecture mailing list
>>> architect...@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>> Thanks,
>> Samisa...
>>
>> Samisa Abeysinghe
>> VP Engineering
>> WSO2 Inc.
>> http://wso2.com
>> http://wso2.org
>>
>>
>>
>> ___
>> Architecture mailing list
>> architect...@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *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
> blog: **http://blog.afkham.org* *
> twitter: **http://twitter.com/afkham_azeez*
> *
> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
> *
> *
> *Lean . Enterprise . Middleware*
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Sanjiva Weerawarana, Ph.D.
Founder, Chairman & CEO; WSO2, Inc.;  http://wso2.com/
email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1
650 265 8311
blog: http://sanjiva.weerawarana.org/

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

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Samisa Abeysinghe]

On Thu, Mar 21, 2013 at 6:03 PM, Afkham Azeez  wrote:

>
>
> On Thu, Mar 21, 2013 at 5:56 PM, Samisa Abeysinghe wrote:
>
>>
>>
>> On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez  wrote:
>>
>>> With the worker-manager concept, we no longer require FE-BE separation.
>>> There is no need to have FE-BE separation for the management node. So, I
>>> think we can completely do away with that concept.
>>
>>
>> But how do we separate the worker stuff from manager stuff?
>> Is that not
>> Manger == FE + BE
>> Worker == BE
>>
>>
>
> No, FE is the front end of the management admin client. BE is the
> management service/API. Worker provides the runtime to run services, apps,
> processes, mediation etc. We have made the mistake of calling this runtime
> as BE as well. Management nodes will not ideally require this runtime, but
> we may need to have some parts of it. e.g. validating the Synapse config
> will require Synapse to be in the management node. We will never have a
> case where a FE talks to a BE in a worker node. When it comes to the mgt
> node, there is no need for separating the FE & BE.
>

So we are getting rid of FE/BE separation  but need to bring in
Worker/Manager separation into component design.


>
>>
>>> What do you guys think?
>>>
>>> --
>>> *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
>>> blog: **http://blog.afkham.org* *
>>> twitter: **http://twitter.com/afkham_azeez*
>>> *
>>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>>> *
>>> *
>>> *Lean . Enterprise . Middleware*
>>>
>>> ___
>>> Architecture mailing list
>>> architect...@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>> Thanks,
>> Samisa...
>>
>> Samisa Abeysinghe
>> VP Engineering
>> WSO2 Inc.
>> http://wso2.com
>> http://wso2.org
>>
>>
>>
>> ___
>> Architecture mailing list
>> architect...@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *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
> blog: **http://blog.afkham.org* *
> twitter: **http://twitter.com/afkham_azeez*
> *
> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
> *
> *
> *Lean . Enterprise . Middleware*
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
> Thanks,
Samisa...

Samisa Abeysinghe
VP Engineering
WSO2 Inc.
http://wso2.com
http://wso2.org
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Afkham Azeez]

On Thu, Mar 21, 2013 at 6:16 PM, Sanjiva Weerawarana wrote:

> Azeez don't we need the management API in worker nodes? I assume the
> answer is yes ..
>

If you look at the current worker-manager separated setup, we don't have a
single instance where the management node BE or FE calls into the worker
node BE.


>
> So in that case the worker contains the runtime container logic plus a
> management API (running at a separate port etc. and enabled by request).
> The management node contains an admin app that talks to the worker nodes
> via the API and other means (such as ADC). Right?
>
> +1 as long as we can still ship a multi-profile distro by default where
> all of this is in one JVM and then you give the personalty at boot time.
>
> Sanjiva.
>
>
> On Thu, Mar 21, 2013 at 6:03 PM, Afkham Azeez  wrote:
>
>>
>>
>> On Thu, Mar 21, 2013 at 5:56 PM, Samisa Abeysinghe wrote:
>>
>>>
>>>
>>> On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez  wrote:
>>>
 With the worker-manager concept, we no longer require FE-BE separation.
 There is no need to have FE-BE separation for the management node. So, I
 think we can completely do away with that concept.
>>>
>>>
>>> But how do we separate the worker stuff from manager stuff?
>>> Is that not
>>> Manger == FE + BE
>>> Worker == BE
>>>
>>>
>>
>> No, FE is the front end of the management admin client. BE is the
>> management service/API. Worker provides the runtime to run services, apps,
>> processes, mediation etc. We have made the mistake of calling this runtime
>> as BE as well. Management nodes will not ideally require this runtime, but
>> we may need to have some parts of it. e.g. validating the Synapse config
>> will require Synapse to be in the management node. We will never have a
>> case where a FE talks to a BE in a worker node. When it comes to the mgt
>> node, there is no need for separating the FE & BE.
>>
>>
>>>
 What do you guys think?

 --
 *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
 blog: **http://blog.afkham.org* *
 twitter: 
 **http://twitter.com/afkham_azeez*
 *
 linked-in: **http://lk.linkedin.com/in/afkhamazeez*
 *
 *
 *Lean . Enterprise . Middleware*

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

 Thanks,
>>> Samisa...
>>>
>>> Samisa Abeysinghe
>>> VP Engineering
>>> WSO2 Inc.
>>> http://wso2.com
>>> http://wso2.org
>>>
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> architect...@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *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
>> blog: **http://blog.afkham.org* *
>> twitter: **http://twitter.com/afkham_azeez*
>> *
>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>> *
>> *
>> *Lean . Enterprise . Middleware*
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder, Chairman & CEO; WSO2, Inc.;  http://wso2.com/
> email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1
> 650 265 8311
> blog: http://sanjiva.weerawarana.org/
>
>
> Lean . Enterprise . Middleware
>



-- 
*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
blog: **http://blog.afkham.org* *
twitter: **http://twitter.com/afkham_azeez*
*
linked-in: **http://lk.linkedin.com/in/afkhamazeez*
*
*
*Lean . Enterprise . Middleware*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Afkham Azeez]

On Thu, Mar 21, 2013 at 4:18 PM, Isuru Perera  wrote:

> +1 to remove the use of stubs to communicate with BE. But still we need to
> keep layers separate. We can do that by programming to an interface [1].
>
> [1]
> http://en.wikipedia.org/wiki/Interface_%28computing%29#Programming_to_the_interface
>

Not related, but if you are interested go through
http://www.youtube.com/watch?v=aAb7hSCtvGw


>
>
>
> On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez  wrote:
>
>> With the worker-manager concept, we no longer require FE-BE separation.
>> There is no need to have FE-BE separation for the management node. So, I
>> think we can completely do away with that concept.
>>
>> What do you guys think?
>>
>> --
>> *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
>> blog: **http://blog.afkham.org* *
>> twitter: **http://twitter.com/afkham_azeez*
>> *
>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>> *
>> *
>> *Lean . Enterprise . Middleware*
>>
>> ___
>> Architecture mailing list
>> architect...@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Isuru Perera
> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
>
> Lean . Enterprise . Middleware
>
> Twitter: http://twitter.com/chrishantha | LinkedIn:
> http://lk.linkedin.com/in/chrishantha/
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*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
blog: **http://blog.afkham.org* *
twitter: **http://twitter.com/afkham_azeez*
*
linked-in: **http://lk.linkedin.com/in/afkhamazeez*
*
*
*Lean . Enterprise . Middleware*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Afkham Azeez]

On Thu, Mar 21, 2013 at 4:40 PM, Isuru Perera  wrote:

>
> On Thu, Mar 21, 2013 at 4:37 PM, Sagara Gunathunga wrote:
>
>> I think if we want still we can maintain BE and FE bundles the main idea
>> here is to remove unwanted WS layer in between FE and BE.  Ideally BE
>> contains back end services and FE contains JSP pages, this JSP pages
>> directly communicate with BE service using Java calls without going through
>> any WS layer ( No more serialization/ deserialization between FE-BE).
>
>
> Another advantage is we can get rid of JSPs, which is more than 10 years
> old technology! :)
>
> Technology choices are not made taking into consideration only the age.
Soem of the core technologies we are using still, e.g. SQL are about 40-50
years old! :D
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Isuru Perera]

On Thu, Mar 21, 2013 at 6:33 PM, Afkham Azeez  wrote:

> Not related, but if you are interested go through
> http://www.youtube.com/watch?v=aAb7hSCtvGw
>

Why is it not related? What I meant was to keep the layers separated. For
example, we can use Inversion of Control. Then we even add a layer in
between if required, similar to stubs + web services we have.

Thanks for the youtube link! :)

-- 
Isuru Perera
Senior Software Engineer | WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

Twitter: http://twitter.com/chrishantha | LinkedIn:
http://lk.linkedin.com/in/chrishantha/
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Isuru Perera]

On Thu, Mar 21, 2013 at 6:43 PM, Afkham Azeez  wrote:

> Technology choices are not made taking into consideration only the age.
> Soem of the core technologies we are using still, e.g. SQL are about 40-50
> years old! :D


But JSP is replaced by JSF + Facelets. SQL story is different :)


-- 
Isuru Perera
Senior Software Engineer | WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

Twitter: http://twitter.com/chrishantha | LinkedIn:
http://lk.linkedin.com/in/chrishantha/
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Amila Suriarachchi]

+1 to what Azeez has proposed.

I was thinking a design like this,

Admin services | FE

 OSGI services


Front end directly call OSGI services through OSGI service interfaces.
Admin services also does that. At the worker nodes we remove FE components.
(or may be admin services if required)

But the question is security. We can secure Admin services. For FE we need
to go ahead with some servlet level security.

thanks,
Amila.

On Thu, Mar 21, 2013 at 6:16 PM, Sanjiva Weerawarana wrote:

> Azeez don't we need the management API in worker nodes? I assume the
> answer is yes ..
>
> So in that case the worker contains the runtime container logic plus a
> management API (running at a separate port etc. and enabled by request).
> The management node contains an admin app that talks to the worker nodes
> via the API and other means (such as ADC). Right?
>
> +1 as long as we can still ship a multi-profile distro by default where
> all of this is in one JVM and then you give the personalty at boot time.
>
> Sanjiva.
>
>
> On Thu, Mar 21, 2013 at 6:03 PM, Afkham Azeez  wrote:
>
>>
>>
>> On Thu, Mar 21, 2013 at 5:56 PM, Samisa Abeysinghe wrote:
>>
>>>
>>>
>>> On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez  wrote:
>>>
 With the worker-manager concept, we no longer require FE-BE separation.
 There is no need to have FE-BE separation for the management node. So, I
 think we can completely do away with that concept.
>>>
>>>
>>> But how do we separate the worker stuff from manager stuff?
>>> Is that not
>>> Manger == FE + BE
>>> Worker == BE
>>>
>>>
>>
>> No, FE is the front end of the management admin client. BE is the
>> management service/API. Worker provides the runtime to run services, apps,
>> processes, mediation etc. We have made the mistake of calling this runtime
>> as BE as well. Management nodes will not ideally require this runtime, but
>> we may need to have some parts of it. e.g. validating the Synapse config
>> will require Synapse to be in the management node. We will never have a
>> case where a FE talks to a BE in a worker node. When it comes to the mgt
>> node, there is no need for separating the FE & BE.
>>
>>
>>>
 What do you guys think?

 --
 *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
 blog: **http://blog.afkham.org* *
 twitter: 
 **http://twitter.com/afkham_azeez*
 *
 linked-in: **http://lk.linkedin.com/in/afkhamazeez*
 *
 *
 *Lean . Enterprise . Middleware*

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

 Thanks,
>>> Samisa...
>>>
>>> Samisa Abeysinghe
>>> VP Engineering
>>> WSO2 Inc.
>>> http://wso2.com
>>> http://wso2.org
>>>
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> architect...@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *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
>> blog: **http://blog.afkham.org* *
>> twitter: **http://twitter.com/afkham_azeez*
>> *
>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>> *
>> *
>> *Lean . Enterprise . Middleware*
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder, Chairman & CEO; WSO2, Inc.;  http://wso2.com/
> email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1
> 650 265 8311
> blog: http://sanjiva.weerawarana.org/
>
>
> Lean . Enterprise . Middleware
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Amila Suriarachchi*

Software Architect
WSO2 Inc. ; http://wso2.com
lean . enterprise . middleware

phone : +94 71 3082805
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Sagara Gunathunga]

On Thu, Mar 21, 2013 at 6:55 PM, Isuru Perera  wrote:

>
> On Thu, Mar 21, 2013 at 6:43 PM, Afkham Azeez  wrote:
>
>> Technology choices are not made taking into consideration only the age.
>> Soem of the core technologies we are using still, e.g. SQL are about 40-50
>> years old! :D
>
>
> But JSP is replaced by JSF + Facelets. SQL story is different :)
>

 Isuru, can you please provide me a reliable reference about this
*replacement* ?

Thanks !


>
>
> --
> Isuru Perera
> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> Twitter: http://twitter.com/chrishantha | LinkedIn:
> http://lk.linkedin.com/in/chrishantha/
>



-- 
Sagara Gunathunga

Technical Lead; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services ;  http://ws.apache.org/
Blog ;  http://ssagara.blogspot.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Isuru Perera]

On Thu, Mar 21, 2013 at 8:35 PM, Sagara Gunathunga  wrote:

>  Isuru, can you please provide me a reliable reference about this
> *replacement* ?


I'm not sure what you mean by a "reliable reference". But what I said is
that JSF + Facelets is the standard web framework in Java EE. We cannot
really compare JSF and JSP directly since JSP can be used as a view
technology in JSF. But Facelets is the standard view technology for JSF now.

That's why I said "JSF + Facelets" replaces "JSP". In other words, we can
use JSF + Facelets for building web applications instead of using JSP.

My personal opinion is that we shouldn't use JSP and it's old! But that's
just my way of looking at JSP.

-- 
Isuru Perera
Senior Software Engineer | WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

Twitter: http://twitter.com/chrishantha | LinkedIn:
http://lk.linkedin.com/in/chrishantha/
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Afkham Azeez]

On Thu, Mar 21, 2013 at 8:55 PM, Isuru Perera  wrote:

>
> On Thu, Mar 21, 2013 at 8:35 PM, Sagara Gunathunga wrote:
>
>>  Isuru, can you please provide me a reliable reference about this
>> *replacement* ?
>
>
> I'm not sure what you mean by a "reliable reference". But what I said is
> that JSF + Facelets is the standard web framework in Java EE. We cannot
> really compare JSF and JSP directly since JSP can be used as a view
> technology in JSF. But Facelets is the standard view technology for JSF now.
>
> That's why I said "JSF + Facelets" replaces "JSP". In other words, we can
> use JSF + Facelets for building web applications instead of using JSP.
>
> My personal opinion is that we shouldn't use JSP and it's old! But that's
> just my way of looking at JSP.
>

Throw away all JavaEE technology and use Jaggery :)

>
> --
> Isuru Perera
> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> Twitter: http://twitter.com/chrishantha | LinkedIn:
> http://lk.linkedin.com/in/chrishantha/
>



-- 
*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
blog: **http://blog.afkham.org* *
twitter: **http://twitter.com/afkham_azeez*
*
linked-in: **http://lk.linkedin.com/in/afkhamazeez*
*
*
*Lean . Enterprise . Middleware*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Sagara Gunathunga]

On Thu, Mar 21, 2013 at 9:00 PM, Afkham Azeez  wrote:

>
>
> On Thu, Mar 21, 2013 at 8:55 PM, Isuru Perera  wrote:
>
>>
>> On Thu, Mar 21, 2013 at 8:35 PM, Sagara Gunathunga wrote:
>>
>>>  Isuru, can you please provide me a reliable reference about this
>>> *replacement* ?
>>
>>
>> I'm not sure what you mean by a "reliable reference". But what I said is
>> that JSF + Facelets is the standard web framework in Java EE. We cannot
>> really compare JSF and JSP directly since JSP can be used as a view
>> technology in JSF. But Facelets is the standard view technology for JSF now.
>>
>> That's why I said "JSF + Facelets" replaces "JSP". In other words, we can
>> use JSF + Facelets for building web applications instead of using JSP.
>>
>> My personal opinion is that we shouldn't use JSP and it's old! But that's
>> just my way of looking at JSP.
>>
>
> Throw away all JavaEE technology and use Jaggery :)
>

 Absolutely !!  :)

Thanks !



>
>> --
>> Isuru Perera
>> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> Twitter: http://twitter.com/chrishantha | LinkedIn:
>> http://lk.linkedin.com/in/chrishantha/
>>
>
>
>
> --
> *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
> blog: **http://blog.afkham.org* *
> twitter: **http://twitter.com/afkham_azeez*
> *
> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
> *
> *
> *Lean . Enterprise . Middleware*
>



-- 
Sagara Gunathunga

Technical Lead; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services ;  http://ws.apache.org/
Blog ;  http://ssagara.blogspot.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Supun Malinga]

On Thu, Mar 21, 2013 at 9:03 PM, Sagara Gunathunga  wrote:

>
>
> On Thu, Mar 21, 2013 at 9:00 PM, Afkham Azeez  wrote:
>
>>
>>
>> On Thu, Mar 21, 2013 at 8:55 PM, Isuru Perera  wrote:
>>
>>>
>>> On Thu, Mar 21, 2013 at 8:35 PM, Sagara Gunathunga wrote:
>>>
  Isuru, can you please provide me a reliable reference about this
 *replacement* ?
>>>
>>>
>>> I'm not sure what you mean by a "reliable reference". But what I said is
>>> that JSF + Facelets is the standard web framework in Java EE. We cannot
>>> really compare JSF and JSP directly since JSP can be used as a view
>>> technology in JSF. But Facelets is the standard view technology for JSF now.
>>>
>>> That's why I said "JSF + Facelets" replaces "JSP". In other words, we
>>> can use JSF + Facelets for building web applications instead of using JSP.
>>>
>>> My personal opinion is that we shouldn't use JSP and it's old! But
>>> that's just my way of looking at JSP.
>>>
>>
>> Throw away all JavaEE technology and use Jaggery :)
>>
>
+1 for Jaggery :)
I also do think our UI have gone bit old and dull, either we need to
complete redesign our jsps, tlds, css, etc or move something else. So
jaggery would fit the purpose fine.
Guess this is dragging off the topic now, so stopping at here. :)


>
>  Absolutely !!  :)
>
> Thanks !
>
>
>
>>
>>> --
>>> Isuru Perera
>>> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> Twitter: http://twitter.com/chrishantha | LinkedIn:
>>> http://lk.linkedin.com/in/chrishantha/
>>>
>>
>>
>>
>> --
>> *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
>> blog: **http://blog.afkham.org* *
>> twitter: **http://twitter.com/afkham_azeez*
>> *
>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>> *
>> *
>> *Lean . Enterprise . Middleware*
>>
>
>
>
> --
> Sagara Gunathunga
>
> Technical Lead; WSO2, Inc.;  http://wso2.com
> V.P Apache Web Services ;  http://ws.apache.org/
> Blog ;  http://ssagara.blogspot.com
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Supun Malinga,

Software Engineer,
WSO2 Inc.
http://wso2.com
http://wso2.org
email - sup...@wso2.com 
mobile - 071 56 91 321
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Tharindu Mathew]

Shall we re-do the worker-manager separation? The better approach would be
a ring configuration, where everyone shares the master/slave role as well.
This will simplify configuration as well.

+1 for getting rid of the FE-BE separation. It's too much weight, for
nothing gained.

On Thu, Mar 21, 2013 at 11:33 AM, Sagara Gunathunga  wrote:

>
>
> On Thu, Mar 21, 2013 at 9:00 PM, Afkham Azeez  wrote:
>
>>
>>
>> On Thu, Mar 21, 2013 at 8:55 PM, Isuru Perera  wrote:
>>
>>>
>>> On Thu, Mar 21, 2013 at 8:35 PM, Sagara Gunathunga wrote:
>>>
  Isuru, can you please provide me a reliable reference about this
 *replacement* ?
>>>
>>>
>>> I'm not sure what you mean by a "reliable reference". But what I said is
>>> that JSF + Facelets is the standard web framework in Java EE. We cannot
>>> really compare JSF and JSP directly since JSP can be used as a view
>>> technology in JSF. But Facelets is the standard view technology for JSF now.
>>>
>>> That's why I said "JSF + Facelets" replaces "JSP". In other words, we
>>> can use JSF + Facelets for building web applications instead of using JSP.
>>>
>>> My personal opinion is that we shouldn't use JSP and it's old! But
>>> that's just my way of looking at JSP.
>>>
>>
>> Throw away all JavaEE technology and use Jaggery :)
>>
>
>  Absolutely !!  :)
>
> Thanks !
>
>
>
>>
>>> --
>>> Isuru Perera
>>> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> Twitter: http://twitter.com/chrishantha | LinkedIn:
>>> http://lk.linkedin.com/in/chrishantha/
>>>
>>
>>
>>
>> --
>> *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
>> blog: **http://blog.afkham.org* *
>> twitter: **http://twitter.com/afkham_azeez*
>> *
>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>> *
>> *
>> *Lean . Enterprise . Middleware*
>>
>
>
>
> --
> Sagara Gunathunga
>
> Technical Lead; WSO2, Inc.;  http://wso2.com
> V.P Apache Web Services ;  http://ws.apache.org/
> Blog ;  http://ssagara.blogspot.com
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Regards,

Tharindu Mathew

Associate Technical Lead, WSO2 BAM
Member - Data Mgmt. Committee

blog: http://tharindumathew.com/
M: +9459908
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Sagara Gunathunga]

On Thu, Mar 21, 2013 at 8:55 PM, Isuru Perera  wrote:

>
> On Thu, Mar 21, 2013 at 8:35 PM, Sagara Gunathunga wrote:
>
>>  Isuru, can you please provide me a reliable reference about this
>> *replacement* ?
>
>
> I'm not sure what you mean by a "reliable reference".
>

 I meant according to this
http://en.wikipedia.org/wiki/Wikipedia:Identifying_reliable_sources


> But what I said is that JSF + Facelets is the standard web framework in
> Java EE. We cannot really compare JSF and JSP directly since JSP can be
> used as a view technology in JSF. But Facelets is the standard view
> technology for JSF now.
>
> That's why I said "JSF + Facelets" replaces "JSP". In other words, we can
> use JSF + Facelets for building web applications instead of using JSP.
>
> My personal opinion is that we shouldn't use JSP and it's old! But that's
> just my way of looking at JSP.
>

 In my POV when someone says "JSP is replaced by JSF + Facelets" it
impliesneutral point of view [1]  :)

 Ok let's see what Wikipedia have to say 

"* JSF* is a request-driven MVC web *framework* based on component driven
UI design model, using XML files called view templates or *Facelets* views.
"  [2]

"JavaServer Pages (*JSP*) is a Java technology that helps software
developers serve dynamically generated web pages based on HTML, XML,
, or other document types "[3]

In my POV we can't compare or can't say replaced  JSP by JSF because both
serve different requirements where JSF is a MVC framework and JSP is a
dynamic page generation technology.  We can compare JSF with other MVC F/W
like Structs, Spring MVC etc.

Taking a different example,  we can say JAX-RPC is replaced  by JAX-WS
because JCP spec itself claimed  so [4].

"The JAX-WS 2.0 specification is the next generation web services API *
replacing* JAX-RPC 1.0." [4]

Having said I'm more than happy to accept your claims as your personal
view, just wanted to mention neutral point of view on above matters because
there are lot of new people on this list.

[1] - http://en.wikipedia.org/wiki/Wikipedia:Neutral_point_of_view
[2] - http://en.wikipedia.org/wiki/JavaServer_Faces
[3] - http://en.wikipedia.org/wiki/JavaServer_Pages
[4] - http://jcp.org/en/jsr/detail?id=224

Thanks !




> --
> Isuru Perera
> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> Twitter: http://twitter.com/chrishantha | LinkedIn:
> http://lk.linkedin.com/in/chrishantha/
>



-- 
Sagara Gunathunga

Technical Lead; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services ;  http://ws.apache.org/
Blog ;  http://ssagara.blogspot.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Afkham Azeez]

On Thu, Mar 21, 2013 at 9:32 PM, Tharindu Mathew  wrote:

> Shall we re-do the worker-manager separation? The better approach would be
> a ring configuration, where everyone shares the master/slave role as well.
> This will simplify configuration as well.
>
> +1 for getting rid of the FE-BE separation. It's too much weight, for
> nothing gained.
>
>
I think eventually everything will boil down to Operations Center + worker
clusters

Azeez


> On Thu, Mar 21, 2013 at 11:33 AM, Sagara Gunathunga wrote:
>
>>
>>
>> On Thu, Mar 21, 2013 at 9:00 PM, Afkham Azeez  wrote:
>>
>>>
>>>
>>> On Thu, Mar 21, 2013 at 8:55 PM, Isuru Perera  wrote:
>>>

 On Thu, Mar 21, 2013 at 8:35 PM, Sagara Gunathunga wrote:

>  Isuru, can you please provide me a reliable reference about this
> *replacement* ?


 I'm not sure what you mean by a "reliable reference". But what I said
 is that JSF + Facelets is the standard web framework in Java EE. We cannot
 really compare JSF and JSP directly since JSP can be used as a view
 technology in JSF. But Facelets is the standard view technology for JSF 
 now.

 That's why I said "JSF + Facelets" replaces "JSP". In other words, we
 can use JSF + Facelets for building web applications instead of using JSP.

 My personal opinion is that we shouldn't use JSP and it's old! But
 that's just my way of looking at JSP.

>>>
>>> Throw away all JavaEE technology and use Jaggery :)
>>>
>>
>>  Absolutely !!  :)
>>
>> Thanks !
>>
>>
>>
>>>
 --
 Isuru Perera
 Senior Software Engineer | WSO2, Inc. | http://wso2.com/
 Lean . Enterprise . Middleware

 Twitter: http://twitter.com/chrishantha | LinkedIn:
 http://lk.linkedin.com/in/chrishantha/

>>>
>>>
>>>
>>> --
>>> *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
>>> blog: **http://blog.afkham.org* *
>>> twitter: **http://twitter.com/afkham_azeez*
>>> *
>>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>>> *
>>> *
>>> *Lean . Enterprise . Middleware*
>>>
>>
>>
>>
>> --
>> Sagara Gunathunga
>>
>> Technical Lead; WSO2, Inc.;  http://wso2.com
>> V.P Apache Web Services ;  http://ws.apache.org/
>> Blog ;  http://ssagara.blogspot.com
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Regards,
>
> Tharindu Mathew
>
> Associate Technical Lead, WSO2 BAM
> Member - Data Mgmt. Committee
>
> blog: http://tharindumathew.com/
> M: +9459908
>



-- 
*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
blog: **http://blog.afkham.org* *
twitter: **http://twitter.com/afkham_azeez*
*
linked-in: **http://lk.linkedin.com/in/afkhamazeez*
*
*
*Lean . Enterprise . Middleware*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Isuru Perera]

On Thu, Mar 21, 2013 at 9:48 PM, Sagara Gunathunga  wrote:

>
>
> On Thu, Mar 21, 2013 at 8:55 PM, Isuru Perera  wrote:
>
>>
>> On Thu, Mar 21, 2013 at 8:35 PM, Sagara Gunathunga wrote:
>>
>>>  Isuru, can you please provide me a reliable reference about this
>>> *replacement* ?
>>
>>
>> I'm not sure what you mean by a "reliable reference".
>>
>
>  I meant according to this
> http://en.wikipedia.org/wiki/Wikipedia:Identifying_reliable_sources
>
>
>> But what I said is that JSF + Facelets is the standard web framework in
>> Java EE. We cannot really compare JSF and JSP directly since JSP can be
>> used as a view technology in JSF. But Facelets is the standard view
>> technology for JSF now.
>>
>> That's why I said "JSF + Facelets" replaces "JSP". In other words, we can
>> use JSF + Facelets for building web applications instead of using JSP.
>>
>> My personal opinion is that we shouldn't use JSP and it's old! But that's
>> just my way of looking at JSP.
>>
>
>  In my POV when someone says "JSP is replaced by JSF + Facelets" it 
> impliesneutral point of view [1]  :)
>
>  Ok let's see what Wikipedia have to say 
>
> "* JSF* is a request-driven MVC web *framework* based on component driven
> UI design model, using XML files called view templates or *Facelets*views. "  
> [2]
>
> "JavaServer Pages (*JSP*) is a Java technology that helps software
> developers serve dynamically generated web pages based on HTML, XML,
> , or other document types "[3]
>
> In my POV we can't compare or can't say replaced  JSP by JSF because both
> serve different requirements where JSF is a MVC framework and JSP is a
> dynamic page generation technology.  We can compare JSF with other MVC F/W
> like Structs, Spring MVC etc.
>

So, I was trying to say basically the same thing.


> Taking a different example,  we can say JAX-RPC is replaced  by JAX-WS
> because JCP spec itself claimed  so [4].
>
> "The JAX-WS 2.0 specification is the next generation web services API *
> replacing* JAX-RPC 1.0." [4]
>
> Having said I'm more than happy to accept your claims as your personal
> view, just wanted to mention neutral point of view on above matters
> because there are lot of new people on this list.
>

So, no need to take this conversation further. Facts are there on the
internet. I agree that my view is different from neutral point of view. :)


> [1] - http://en.wikipedia.org/wiki/Wikipedia:Neutral_point_of_view
> [2] - http://en.wikipedia.org/wiki/JavaServer_Faces
> [3] - http://en.wikipedia.org/wiki/JavaServer_Pages
> [4] - http://jcp.org/en/jsr/detail?id=224
>
> Thanks !
>
>
>
>
>> --
>>  Isuru Perera
>> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> Twitter: http://twitter.com/chrishantha | LinkedIn:
>> http://lk.linkedin.com/in/chrishantha/
>>
>
>
>
> --
> Sagara Gunathunga
>
> Technical Lead; WSO2, Inc.;  http://wso2.com
> V.P Apache Web Services ;  http://ws.apache.org/
> Blog ;  http://ssagara.blogspot.com
>



-- 
Isuru Perera
Senior Software Engineer | WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

Twitter: http://twitter.com/chrishantha | LinkedIn:
http://lk.linkedin.com/in/chrishantha/
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Nuwan Bandara]

Hi Azeez,

I do like this approach, however isn't this mean that we are going to
re-write most of the stuff we have right now. Yes we can keep the runtime
components as it is, but we will have to basically re-write all the
management related bundles, which is like half of carbon components. Am I
missing something here ?

Also this means we can ditch soap services we have ? and just build simple
management jaggery modules that has an API as well as an Application part. ?

Also +1, for using Jaggery, but don't use jaggery because the current UI is
dull looking, Jaggery doesn't solve that :) If we are using Jaggery lets
use it for the right reasons. You can easily build an API as well as an APP
that has to be the main reason, and of-cause the ease of
deployment/packaging etc etc.

Regards,
/Nuwan


On Thu, Mar 21, 2013 at 10:23 PM, Afkham Azeez  wrote:

>
>
> On Thu, Mar 21, 2013 at 9:32 PM, Tharindu Mathew wrote:
>
>> Shall we re-do the worker-manager separation? The better approach would
>> be a ring configuration, where everyone shares the master/slave role as
>> well. This will simplify configuration as well.
>>
>> +1 for getting rid of the FE-BE separation. It's too much weight, for
>> nothing gained.
>>
>>
> I think eventually everything will boil down to Operations Center + worker
> clusters
>
> Azeez
>
>
>> On Thu, Mar 21, 2013 at 11:33 AM, Sagara Gunathunga wrote:
>>
>>>
>>>
>>> On Thu, Mar 21, 2013 at 9:00 PM, Afkham Azeez  wrote:
>>>


 On Thu, Mar 21, 2013 at 8:55 PM, Isuru Perera  wrote:

>
> On Thu, Mar 21, 2013 at 8:35 PM, Sagara Gunathunga wrote:
>
>>  Isuru, can you please provide me a reliable reference about this
>> *replacement* ?
>
>
> I'm not sure what you mean by a "reliable reference". But what I said
> is that JSF + Facelets is the standard web framework in Java EE. We cannot
> really compare JSF and JSP directly since JSP can be used as a view
> technology in JSF. But Facelets is the standard view technology for JSF 
> now.
>
> That's why I said "JSF + Facelets" replaces "JSP". In other words, we
> can use JSF + Facelets for building web applications instead of using JSP.
>
> My personal opinion is that we shouldn't use JSP and it's old! But
> that's just my way of looking at JSP.
>

 Throw away all JavaEE technology and use Jaggery :)

>>>
>>>  Absolutely !!  :)
>>>
>>> Thanks !
>>>
>>>
>>>

> --
> Isuru Perera
> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> Twitter: http://twitter.com/chrishantha | LinkedIn:
> http://lk.linkedin.com/in/chrishantha/
>



 --
 *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
 blog: **http://blog.afkham.org* *
 twitter: 
 **http://twitter.com/afkham_azeez*
 *
 linked-in: **http://lk.linkedin.com/in/afkhamazeez*
 *
 *
 *Lean . Enterprise . Middleware*

>>>
>>>
>>>
>>> --
>>> Sagara Gunathunga
>>>
>>> Technical Lead; WSO2, Inc.;  http://wso2.com
>>> V.P Apache Web Services ;  http://ws.apache.org/
>>> Blog ;  http://ssagara.blogspot.com
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Regards,
>>
>> Tharindu Mathew
>>
>> Associate Technical Lead, WSO2 BAM
>> Member - Data Mgmt. Committee
>>
>> blog: http://tharindumathew.com/
>> M: +9459908
>>
>
>
>
> --
> *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
> blog: **http://blog.afkham.org* *
> twitter: **http://twitter.com/afkham_azeez*
> *
> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
> *
> *
> *Lean . Enterprise . Middleware*
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Thanks & Regards,

Nuwan Bandara
Associate Technical Lead & Member, MC, Development Technologies
WSO2 Inc. - lean . enterprise . middleware |  http://wso2.com
blog : http://nuwanbando.com; email: nu...@wso2.com; phone: +94 11 763 9629
*

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

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Afkham Azeez]

Yeah, all UI/management stuff will have to be redesigned & rewritten using
JAXRS, Jaggery or something else.

Azeez

On Thu, Mar 21, 2013 at 10:55 PM, Nuwan Bandara  wrote:

> Hi Azeez,
>
> I do like this approach, however isn't this mean that we are going to
> re-write most of the stuff we have right now. Yes we can keep the runtime
> components as it is, but we will have to basically re-write all the
> management related bundles, which is like half of carbon components. Am I
> missing something here ?
>
> Also this means we can ditch soap services we have ? and just build simple
> management jaggery modules that has an API as well as an Application part. ?
>
> Also +1, for using Jaggery, but don't use jaggery because the current UI
> is dull looking, Jaggery doesn't solve that :) If we are using Jaggery lets
> use it for the right reasons. You can easily build an API as well as an APP
> that has to be the main reason, and of-cause the ease of
> deployment/packaging etc etc.
>
> Regards,
> /Nuwan
>
>
> On Thu, Mar 21, 2013 at 10:23 PM, Afkham Azeez  wrote:
>
>>
>>
>> On Thu, Mar 21, 2013 at 9:32 PM, Tharindu Mathew wrote:
>>
>>> Shall we re-do the worker-manager separation? The better approach would
>>> be a ring configuration, where everyone shares the master/slave role as
>>> well. This will simplify configuration as well.
>>>
>>> +1 for getting rid of the FE-BE separation. It's too much weight, for
>>> nothing gained.
>>>
>>>
>> I think eventually everything will boil down to Operations Center +
>> worker clusters
>>
>> Azeez
>>
>>
>>> On Thu, Mar 21, 2013 at 11:33 AM, Sagara Gunathunga wrote:
>>>


 On Thu, Mar 21, 2013 at 9:00 PM, Afkham Azeez  wrote:

>
>
> On Thu, Mar 21, 2013 at 8:55 PM, Isuru Perera  wrote:
>
>>
>> On Thu, Mar 21, 2013 at 8:35 PM, Sagara Gunathunga 
>> wrote:
>>
>>>  Isuru, can you please provide me a reliable reference about this
>>> *replacement* ?
>>
>>
>> I'm not sure what you mean by a "reliable reference". But what I said
>> is that JSF + Facelets is the standard web framework in Java EE. We 
>> cannot
>> really compare JSF and JSP directly since JSP can be used as a view
>> technology in JSF. But Facelets is the standard view technology for JSF 
>> now.
>>
>> That's why I said "JSF + Facelets" replaces "JSP". In other words, we
>> can use JSF + Facelets for building web applications instead of using 
>> JSP.
>>
>> My personal opinion is that we shouldn't use JSP and it's old! But
>> that's just my way of looking at JSP.
>>
>
> Throw away all JavaEE technology and use Jaggery :)
>

  Absolutely !!  :)

 Thanks !



>
>> --
>> Isuru Perera
>> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> Twitter: http://twitter.com/chrishantha | LinkedIn:
>> http://lk.linkedin.com/in/chrishantha/
>>
>
>
>
> --
> *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
> blog: **http://blog.afkham.org* *
> twitter: 
> **http://twitter.com/afkham_azeez*
> *
> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
> *
> *
> *Lean . Enterprise . Middleware*
>



 --
 Sagara Gunathunga

 Technical Lead; WSO2, Inc.;  http://wso2.com
 V.P Apache Web Services ;  http://ws.apache.org/
 Blog ;  http://ssagara.blogspot.com

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


>>>
>>>
>>> --
>>> Regards,
>>>
>>> Tharindu Mathew
>>>
>>> Associate Technical Lead, WSO2 BAM
>>> Member - Data Mgmt. Committee
>>>
>>> blog: http://tharindumathew.com/
>>> M: +9459908
>>>
>>
>>
>>
>> --
>> *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
>> blog: **http://blog.afkham.org* *
>> twitter: **http://twitter.com/afkham_azeez*
>> *
>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>> *
>> *
>> *Lean . Enterprise . Middleware*
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Thanks & Regards,
>
> Nuwan Bandara
> Associate Technical Lead & Member, MC, Development Technologies
> WSO2 Inc. - lean . enterprise . middleware |  http://wso2.com
> blog : http://nuwanbando.com; email: nu...@wso2.com; phone: +94 11 763
> 9629
> *
> 

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Nuwan Bandara]

On Thu, Mar 21, 2013 at 11:02 PM, Afkham Azeez  wrote:

> Yeah, all UI/management stuff will have to be redesigned & rewritten using
> JAXRS, Jaggery or something else.


Okey got it. Its about time we do some major re-writing :) am in

Regards,
/Nuwan


>
> Azeez
>
>
> On Thu, Mar 21, 2013 at 10:55 PM, Nuwan Bandara  wrote:
>
>> Hi Azeez,
>>
>> I do like this approach, however isn't this mean that we are going to
>> re-write most of the stuff we have right now. Yes we can keep the runtime
>> components as it is, but we will have to basically re-write all the
>> management related bundles, which is like half of carbon components. Am I
>> missing something here ?
>>
>> Also this means we can ditch soap services we have ? and just build
>> simple management jaggery modules that has an API as well as an Application
>> part. ?
>>
>> Also +1, for using Jaggery, but don't use jaggery because the current UI
>> is dull looking, Jaggery doesn't solve that :) If we are using Jaggery lets
>> use it for the right reasons. You can easily build an API as well as an APP
>> that has to be the main reason, and of-cause the ease of
>> deployment/packaging etc etc.
>>
>> Regards,
>> /Nuwan
>>
>>
>> On Thu, Mar 21, 2013 at 10:23 PM, Afkham Azeez  wrote:
>>
>>>
>>>
>>> On Thu, Mar 21, 2013 at 9:32 PM, Tharindu Mathew wrote:
>>>
 Shall we re-do the worker-manager separation? The better approach would
 be a ring configuration, where everyone shares the master/slave role as
 well. This will simplify configuration as well.

 +1 for getting rid of the FE-BE separation. It's too much weight, for
 nothing gained.


>>> I think eventually everything will boil down to Operations Center +
>>> worker clusters
>>>
>>> Azeez
>>>
>>>
 On Thu, Mar 21, 2013 at 11:33 AM, Sagara Gunathunga wrote:

>
>
> On Thu, Mar 21, 2013 at 9:00 PM, Afkham Azeez  wrote:
>
>>
>>
>> On Thu, Mar 21, 2013 at 8:55 PM, Isuru Perera wrote:
>>
>>>
>>> On Thu, Mar 21, 2013 at 8:35 PM, Sagara Gunathunga 
>>> wrote:
>>>
  Isuru, can you please provide me a reliable reference about this
 *replacement* ?
>>>
>>>
>>> I'm not sure what you mean by a "reliable reference". But what I
>>> said is that JSF + Facelets is the standard web framework in Java EE. We
>>> cannot really compare JSF and JSP directly since JSP can be used as a 
>>> view
>>> technology in JSF. But Facelets is the standard view technology for JSF 
>>> now.
>>>
>>> That's why I said "JSF + Facelets" replaces "JSP". In other words,
>>> we can use JSF + Facelets for building web applications instead of using
>>> JSP.
>>>
>>> My personal opinion is that we shouldn't use JSP and it's old! But
>>> that's just my way of looking at JSP.
>>>
>>
>> Throw away all JavaEE technology and use Jaggery :)
>>
>
>  Absolutely !!  :)
>
> Thanks !
>
>
>
>>
>>> --
>>> Isuru Perera
>>> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> Twitter: http://twitter.com/chrishantha | LinkedIn:
>>> http://lk.linkedin.com/in/chrishantha/
>>>
>>
>>
>>
>> --
>> *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
>> blog: **http://blog.afkham.org* *
>> twitter: 
>> **http://twitter.com/afkham_azeez*
>> *
>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>> *
>> *
>> *Lean . Enterprise . Middleware*
>>
>
>
>
> --
> Sagara Gunathunga
>
> Technical Lead; WSO2, Inc.;  http://wso2.com
> V.P Apache Web Services ;  http://ws.apache.org/
> Blog ;  http://ssagara.blogspot.com
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


 --
 Regards,

 Tharindu Mathew

 Associate Technical Lead, WSO2 BAM
 Member - Data Mgmt. Committee

 blog: http://tharindumathew.com/
 M: +9459908

>>>
>>>
>>>
>>> --
>>> *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
>>> blog: **http://blog.afkham.org* *
>>> twitter: **http://twitter.com/afkham_azeez*
>>> *
>>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>>> *
>>> *
>>> *Lean . Enterprise . Middleware*
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http:/

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Sameera Jayasoma]

Hi Azeez,



On Thu, Mar 21, 2013 at 5:49 AM, Afkham Azeez  wrote:

>
>
> On Thu, Mar 21, 2013 at 6:16 PM, Sanjiva Weerawarana wrote:
>
>> Azeez don't we need the management API in worker nodes? I assume the
>> answer is yes ..
>>
>
> If you look at the current worker-manager separated setup, we don't have a
> single instance where the management node BE or FE calls into the worker
> node BE.
>


I agree that worker nodes do not require administrative services. But for
Management node, we need to maintain the BE/FE separation. I.e we need to
keep the administration services as its. This would user to write their own
UI layer to interact with our server. This exactly what AppFactory is doing
right? In some of the project I've worked, we developed completely
different UI to interact with Mgt nodes. So IMV, we still need that BE
services.

Thanks,
Sameera.

>
>
>>
>> So in that case the worker contains the runtime container logic plus a
>> management API (running at a separate port etc. and enabled by request).
>> The management node contains an admin app that talks to the worker nodes
>> via the API and other means (such as ADC). Right?
>>
>> +1 as long as we can still ship a multi-profile distro by default where
>> all of this is in one JVM and then you give the personalty at boot time.
>>
>> Sanjiva.
>>
>>
>> On Thu, Mar 21, 2013 at 6:03 PM, Afkham Azeez  wrote:
>>
>>>
>>>
>>> On Thu, Mar 21, 2013 at 5:56 PM, Samisa Abeysinghe wrote:
>>>


 On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez  wrote:

> With the worker-manager concept, we no longer require FE-BE
> separation. There is no need to have FE-BE separation for the management
> node. So, I think we can completely do away with that concept.


 But how do we separate the worker stuff from manager stuff?
 Is that not
 Manger == FE + BE
 Worker == BE


>>>
>>> No, FE is the front end of the management admin client. BE is the
>>> management service/API. Worker provides the runtime to run services, apps,
>>> processes, mediation etc. We have made the mistake of calling this runtime
>>> as BE as well. Management nodes will not ideally require this runtime, but
>>> we may need to have some parts of it. e.g. validating the Synapse config
>>> will require Synapse to be in the management node. We will never have a
>>> case where a FE talks to a BE in a worker node. When it comes to the mgt
>>> node, there is no need for separating the FE & BE.
>>>
>>>

> What do you guys think?
>
> --
> *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
> blog: **http://blog.afkham.org* *
> twitter: 
> **http://twitter.com/afkham_azeez*
> *
> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
> *
> *
> *Lean . Enterprise . Middleware*
>
> ___
> Architecture mailing list
> architect...@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
> Thanks,
 Samisa...

 Samisa Abeysinghe
 VP Engineering
 WSO2 Inc.
 http://wso2.com
 http://wso2.org



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


>>>
>>>
>>> --
>>> *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
>>> blog: **http://blog.afkham.org* *
>>> twitter: **http://twitter.com/afkham_azeez*
>>> *
>>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>>> *
>>> *
>>> *Lean . Enterprise . Middleware*
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Sanjiva Weerawarana, Ph.D.
>> Founder, Chairman & CEO; WSO2, Inc.;  http://wso2.com/
>> email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1
>> 650 265 8311
>> blog: http://sanjiva.weerawarana.org/
>>
>>
>> Lean . Enterprise . Middleware
>>
>
>
>
> --
> *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
> blog: **http://blog.afkham.org* *
> twitter: **http://twitter.com/afkham_azeez*
> *
> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
> *
> *
> *Lean . Enterprise . Middleware*
>
> _

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Afkham Azeez]

On Thu, Mar 21, 2013 at 11:49 PM, Sameera Jayasoma  wrote:

> Hi Azeez,
>
>
>
> On Thu, Mar 21, 2013 at 5:49 AM, Afkham Azeez  wrote:
>
>>
>>
>> On Thu, Mar 21, 2013 at 6:16 PM, Sanjiva Weerawarana wrote:
>>
>>> Azeez don't we need the management API in worker nodes? I assume the
>>> answer is yes ..
>>>
>>
>> If you look at the current worker-manager separated setup, we don't have
>> a single instance where the management node BE or FE calls into the worker
>> node BE.
>>
>
>
> I agree that worker nodes do not require administrative services. But for
> Management node, we need to maintain the BE/FE separation. I.e we need to
> keep the administration services as its. This would user to write their own
> UI layer to interact with our server. This exactly what AppFactory is doing
> right? In some of the project I've worked, we developed completely
> different UI to interact with Mgt nodes. So IMV, we still need that BE
> services.
>

FE-BE separation means from the UI components we make service calls to the
BE components. What we need is management APIs. Our UI can simply use these
management APIs. We don't need FE-BE separation. External apps can also
call these management APIs.


>
> Thanks,
> Sameera.
>
>>
>>
>>>
>>> So in that case the worker contains the runtime container logic plus a
>>> management API (running at a separate port etc. and enabled by request).
>>> The management node contains an admin app that talks to the worker nodes
>>> via the API and other means (such as ADC). Right?
>>>
>>> +1 as long as we can still ship a multi-profile distro by default where
>>> all of this is in one JVM and then you give the personalty at boot time.
>>>
>>> Sanjiva.
>>>
>>>
>>> On Thu, Mar 21, 2013 at 6:03 PM, Afkham Azeez  wrote:
>>>


 On Thu, Mar 21, 2013 at 5:56 PM, Samisa Abeysinghe wrote:

>
>
> On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez  wrote:
>
>> With the worker-manager concept, we no longer require FE-BE
>> separation. There is no need to have FE-BE separation for the management
>> node. So, I think we can completely do away with that concept.
>
>
> But how do we separate the worker stuff from manager stuff?
> Is that not
> Manger == FE + BE
> Worker == BE
>
>

 No, FE is the front end of the management admin client. BE is the
 management service/API. Worker provides the runtime to run services, apps,
 processes, mediation etc. We have made the mistake of calling this runtime
 as BE as well. Management nodes will not ideally require this runtime, but
 we may need to have some parts of it. e.g. validating the Synapse config
 will require Synapse to be in the management node. We will never have a
 case where a FE talks to a BE in a worker node. When it comes to the mgt
 node, there is no need for separating the FE & BE.


>
>> What do you guys think?
>>
>> --
>> *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
>> blog: **http://blog.afkham.org* *
>> twitter: 
>> **http://twitter.com/afkham_azeez*
>> *
>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>> *
>> *
>> *Lean . Enterprise . Middleware*
>>
>> ___
>> Architecture mailing list
>> architect...@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>> Thanks,
> Samisa...
>
> Samisa Abeysinghe
> VP Engineering
> WSO2 Inc.
> http://wso2.com
> http://wso2.org
>
>
>
> ___
> Architecture mailing list
> architect...@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


 --
 *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
 blog: **http://blog.afkham.org* *
 twitter: 
 **http://twitter.com/afkham_azeez*
 *
 linked-in: **http://lk.linkedin.com/in/afkhamazeez*
 *
 *
 *Lean . Enterprise . Middleware*

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


>>>
>>>
>>> --
>>> Sanjiva Weerawarana, Ph.D.
>>> Founder, Chairman & CEO; WSO2, Inc.;  http://wso2.com/
>>> email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880| +1
>>> 650 265 8311
>>> blog: http://sanjiva.weerawarana.org/
>>>
>>>
>>> Lean . Enterprise . Middleware
>>>
>>
>>
>>

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Sameera Jayasoma]

See my comments inline.


On Thu, Mar 21, 2013 at 11:25 AM, Afkham Azeez  wrote:

>
>
> On Thu, Mar 21, 2013 at 11:49 PM, Sameera Jayasoma wrote:
>
>> Hi Azeez,
>>
>>
>>
>> On Thu, Mar 21, 2013 at 5:49 AM, Afkham Azeez  wrote:
>>
>>>
>>>
>>> On Thu, Mar 21, 2013 at 6:16 PM, Sanjiva Weerawarana 
>>> wrote:
>>>
 Azeez don't we need the management API in worker nodes? I assume the
 answer is yes ..

>>>
>>> If you look at the current worker-manager separated setup, we don't have
>>> a single instance where the management node BE or FE calls into the worker
>>> node BE.
>>>
>>
>>
>> I agree that worker nodes do not require administrative services. But for
>> Management node, we need to maintain the BE/FE separation. I.e we need to
>> keep the administration services as its. This would user to write their own
>> UI layer to interact with our server. This exactly what AppFactory is doing
>> right? In some of the project I've worked, we developed completely
>> different UI to interact with Mgt nodes. So IMV, we still need that BE
>> services.
>>
>
> FE-BE separation means from the UI components we make service calls to the
> BE components. What we need is management APIs. Our UI can simply use these
> management APIs. We don't need FE-BE separation. External apps can also
> call these management APIs.
>

 Okay. so anyway we need to expose our management APIs as service right?.

I was under the impression that FE-BE separation means a clear separation
of UI layer from the BE layer. some how we ended up connecting FE layer to
BE layer via web services communication. But we tried to connect FE to BE
via Java calls via OSGi services approach. Thats didn't work due to some
security issues.

Anyway still we need to clearly separate FE components from the management
APIs right? But we need to figure out an efficient  and secure way to
connect the FE to BE.

Thanks,
Sameera.

>
>
>>
>> Thanks,
>> Sameera.
>>
>>>
>>>

 So in that case the worker contains the runtime container logic plus a
 management API (running at a separate port etc. and enabled by request).
 The management node contains an admin app that talks to the worker nodes
 via the API and other means (such as ADC). Right?

 +1 as long as we can still ship a multi-profile distro by default where
 all of this is in one JVM and then you give the personalty at boot time.

 Sanjiva.


 On Thu, Mar 21, 2013 at 6:03 PM, Afkham Azeez  wrote:

>
>
> On Thu, Mar 21, 2013 at 5:56 PM, Samisa Abeysinghe wrote:
>
>>
>>
>> On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez  wrote:
>>
>>> With the worker-manager concept, we no longer require FE-BE
>>> separation. There is no need to have FE-BE separation for the management
>>> node. So, I think we can completely do away with that concept.
>>
>>
>> But how do we separate the worker stuff from manager stuff?
>> Is that not
>> Manger == FE + BE
>> Worker == BE
>>
>>
>
> No, FE is the front end of the management admin client. BE is the
> management service/API. Worker provides the runtime to run services, apps,
> processes, mediation etc. We have made the mistake of calling this runtime
> as BE as well. Management nodes will not ideally require this runtime, but
> we may need to have some parts of it. e.g. validating the Synapse config
> will require Synapse to be in the management node. We will never have a
> case where a FE talks to a BE in a worker node. When it comes to the mgt
> node, there is no need for separating the FE & BE.
>
>
>>
>>> What do you guys think?
>>>
>>> --
>>> *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
>>> blog: **http://blog.afkham.org* *
>>> twitter: 
>>> **http://twitter.com/afkham_azeez*
>>> *
>>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>>> *
>>> *
>>> *Lean . Enterprise . Middleware*
>>>
>>> ___
>>> Architecture mailing list
>>> architect...@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>> Thanks,
>> Samisa...
>>
>> Samisa Abeysinghe
>> VP Engineering
>> WSO2 Inc.
>> http://wso2.com
>> http://wso2.org
>>
>>
>>
>> ___
>> Architecture mailing list
>> architect...@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Afkham Azeez*
> Director of Architecture; WSO2, Inc.; http://wso2.com
> Member; Apache Software Foundation; http://www.apache.org/

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Afkham Azeez]

On Fri, Mar 22, 2013 at 12:05 AM, Sameera Jayasoma  wrote:

> See my comments inline.
>
>
> On Thu, Mar 21, 2013 at 11:25 AM, Afkham Azeez  wrote:
>
>>
>>
>> On Thu, Mar 21, 2013 at 11:49 PM, Sameera Jayasoma wrote:
>>
>>> Hi Azeez,
>>>
>>>
>>>
>>> On Thu, Mar 21, 2013 at 5:49 AM, Afkham Azeez  wrote:
>>>


 On Thu, Mar 21, 2013 at 6:16 PM, Sanjiva Weerawarana 
 wrote:

> Azeez don't we need the management API in worker nodes? I assume the
> answer is yes ..
>

 If you look at the current worker-manager separated setup, we don't
 have a single instance where the management node BE or FE calls into the
 worker node BE.

>>>
>>>
>>> I agree that worker nodes do not require administrative services. But
>>> for Management node, we need to maintain the BE/FE separation. I.e we need
>>> to keep the administration services as its. This would user to write their
>>> own UI layer to interact with our server. This exactly what AppFactory is
>>> doing right? In some of the project I've worked, we developed completely
>>> different UI to interact with Mgt nodes. So IMV, we still need that BE
>>> services.
>>>
>>
>> FE-BE separation means from the UI components we make service calls to
>> the BE components. What we need is management APIs. Our UI can simply use
>> these management APIs. We don't need FE-BE separation. External apps can
>> also call these management APIs.
>>
>
>  Okay. so anyway we need to expose our management APIs as service right?.
>
> I was under the impression that FE-BE separation means a clear separation
> of UI layer from the BE layer. some how we ended up connecting FE layer to
> BE layer via web services communication. But we tried to connect FE to BE
> via Java calls via OSGi services approach. Thats didn't work due to some
> security issues.
>
> Anyway still we need to clearly separate FE components from the management
> APIs right? But we need to figure out an efficient  and secure way to
> connect the FE to BE.
>

I guess where I am getting at is, we have RESTful APIs, which will be
called by code running in the Web Browser. Yes, I am suggesting that we go
back to the old AJAX based UI model we had, but without the pain of XSLT
(in the old model).

FE = jquery + HTML+ (Jaggery?)
BE= RESTful APIs (Jaggery?)

FE  <--- JSON --> BE

>
> Thanks,
> Sameera.
>
>>
>>
>>>
>>> Thanks,
>>> Sameera.
>>>


>
> So in that case the worker contains the runtime container logic plus a
> management API (running at a separate port etc. and enabled by request).
> The management node contains an admin app that talks to the worker nodes
> via the API and other means (such as ADC). Right?
>
> +1 as long as we can still ship a multi-profile distro by default
> where all of this is in one JVM and then you give the personalty at boot
> time.
>
> Sanjiva.
>
>
> On Thu, Mar 21, 2013 at 6:03 PM, Afkham Azeez  wrote:
>
>>
>>
>> On Thu, Mar 21, 2013 at 5:56 PM, Samisa Abeysinghe 
>> wrote:
>>
>>>
>>>
>>> On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez wrote:
>>>
 With the worker-manager concept, we no longer require FE-BE
 separation. There is no need to have FE-BE separation for the 
 management
 node. So, I think we can completely do away with that concept.
>>>
>>>
>>> But how do we separate the worker stuff from manager stuff?
>>> Is that not
>>> Manger == FE + BE
>>> Worker == BE
>>>
>>>
>>
>> No, FE is the front end of the management admin client. BE is the
>> management service/API. Worker provides the runtime to run services, 
>> apps,
>> processes, mediation etc. We have made the mistake of calling this 
>> runtime
>> as BE as well. Management nodes will not ideally require this runtime, 
>> but
>> we may need to have some parts of it. e.g. validating the Synapse config
>> will require Synapse to be in the management node. We will never have a
>> case where a FE talks to a BE in a worker node. When it comes to the mgt
>> node, there is no need for separating the FE & BE.
>>
>>
>>>
 What do you guys think?

 --
 *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
 blog: **http://blog.afkham.org* *
 twitter: 
 **http://twitter.com/afkham_azeez*
 *
 linked-in: **http://lk.linkedin.com/in/afkhamazeez*
 *
 *
 *Lean . Enterprise . Middleware*

 ___
 Architecture mailing list
 architect...@wso2.org
 https://mail.wso2.org/cgi-bin/

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Afkham Azeez]

On Fri, Mar 22, 2013 at 12:12 AM, Afkham Azeez  wrote:

>
>
> On Fri, Mar 22, 2013 at 12:05 AM, Sameera Jayasoma wrote:
>
>> See my comments inline.
>>
>>
>> On Thu, Mar 21, 2013 at 11:25 AM, Afkham Azeez  wrote:
>>
>>>
>>>
>>> On Thu, Mar 21, 2013 at 11:49 PM, Sameera Jayasoma wrote:
>>>
 Hi Azeez,



 On Thu, Mar 21, 2013 at 5:49 AM, Afkham Azeez  wrote:

>
>
> On Thu, Mar 21, 2013 at 6:16 PM, Sanjiva Weerawarana  > wrote:
>
>> Azeez don't we need the management API in worker nodes? I assume the
>> answer is yes ..
>>
>
> If you look at the current worker-manager separated setup, we don't
> have a single instance where the management node BE or FE calls into the
> worker node BE.
>


 I agree that worker nodes do not require administrative services. But
 for Management node, we need to maintain the BE/FE separation. I.e we need
 to keep the administration services as its. This would user to write their
 own UI layer to interact with our server. This exactly what AppFactory is
 doing right? In some of the project I've worked, we developed completely
 different UI to interact with Mgt nodes. So IMV, we still need that BE
 services.

>>>
>>> FE-BE separation means from the UI components we make service calls to
>>> the BE components. What we need is management APIs. Our UI can simply use
>>> these management APIs. We don't need FE-BE separation. External apps can
>>> also call these management APIs.
>>>
>>
>>  Okay. so anyway we need to expose our management APIs as service right?.
>>
>>
>> I was under the impression that FE-BE separation means a clear separation
>> of UI layer from the BE layer. some how we ended up connecting FE layer to
>> BE layer via web services communication. But we tried to connect FE to BE
>> via Java calls via OSGi services approach. Thats didn't work due to some
>> security issues.
>>
>> Anyway still we need to clearly separate FE components from the
>> management APIs right? But we need to figure out an efficient  and secure
>> way to connect the FE to BE.
>>
>
> I guess where I am getting at is, we have RESTful APIs, which will be
> called by code running in the Web Browser. Yes, I am suggesting that we go
> back to the old AJAX based UI model we had, but without the pain of XSLT
> (in the old model).
>
> FE = jquery + HTML+ (Jaggery?)
> BE= RESTful APIs (Jaggery?)
>
> FE  <--- JSON --> BE
>

Does this make sense? This is not FE-BE separation. FE-BE separation meant
that the FE runs on one JVM & BE runs on another. My argument is that with
the management-worker node concept, we don't need that anymore. Nobody will
run the FE on a separate JVM.

>
>> Thanks,
>> Sameera.
>>
>>>
>>>

 Thanks,
 Sameera.

>
>
>>
>> So in that case the worker contains the runtime container logic plus
>> a management API (running at a separate port etc. and enabled by 
>> request).
>> The management node contains an admin app that talks to the worker nodes
>> via the API and other means (such as ADC). Right?
>>
>> +1 as long as we can still ship a multi-profile distro by default
>> where all of this is in one JVM and then you give the personalty at boot
>> time.
>>
>> Sanjiva.
>>
>>
>> On Thu, Mar 21, 2013 at 6:03 PM, Afkham Azeez  wrote:
>>
>>>
>>>
>>> On Thu, Mar 21, 2013 at 5:56 PM, Samisa Abeysinghe 
>>> wrote:
>>>


 On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez wrote:

> With the worker-manager concept, we no longer require FE-BE
> separation. There is no need to have FE-BE separation for the 
> management
> node. So, I think we can completely do away with that concept.


 But how do we separate the worker stuff from manager stuff?
 Is that not
 Manger == FE + BE
 Worker == BE


>>>
>>> No, FE is the front end of the management admin client. BE is the
>>> management service/API. Worker provides the runtime to run services, 
>>> apps,
>>> processes, mediation etc. We have made the mistake of calling this 
>>> runtime
>>> as BE as well. Management nodes will not ideally require this runtime, 
>>> but
>>> we may need to have some parts of it. e.g. validating the Synapse config
>>> will require Synapse to be in the management node. We will never have a
>>> case where a FE talks to a BE in a worker node. When it comes to the mgt
>>> node, there is no need for separating the FE & BE.
>>>
>>>

> What do you guys think?
>
> --
> *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 33

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Sameera Jayasoma]

On Thu, Mar 21, 2013 at 11:45 AM, Afkham Azeez  wrote:

>
>
> On Fri, Mar 22, 2013 at 12:12 AM, Afkham Azeez  wrote:
>
>>
>>
>> On Fri, Mar 22, 2013 at 12:05 AM, Sameera Jayasoma wrote:
>>
>>> See my comments inline.
>>>
>>>
>>> On Thu, Mar 21, 2013 at 11:25 AM, Afkham Azeez  wrote:
>>>


 On Thu, Mar 21, 2013 at 11:49 PM, Sameera Jayasoma wrote:

> Hi Azeez,
>
>
>
> On Thu, Mar 21, 2013 at 5:49 AM, Afkham Azeez  wrote:
>
>>
>>
>> On Thu, Mar 21, 2013 at 6:16 PM, Sanjiva Weerawarana <
>> sanj...@wso2.com> wrote:
>>
>>> Azeez don't we need the management API in worker nodes? I assume the
>>> answer is yes ..
>>>
>>
>> If you look at the current worker-manager separated setup, we don't
>> have a single instance where the management node BE or FE calls into the
>> worker node BE.
>>
>
>
> I agree that worker nodes do not require administrative services. But
> for Management node, we need to maintain the BE/FE separation. I.e we need
> to keep the administration services as its. This would user to write their
> own UI layer to interact with our server. This exactly what AppFactory is
> doing right? In some of the project I've worked, we developed completely
> different UI to interact with Mgt nodes. So IMV, we still need that BE
> services.
>

 FE-BE separation means from the UI components we make service calls to
 the BE components. What we need is management APIs. Our UI can simply use
 these management APIs. We don't need FE-BE separation. External apps can
 also call these management APIs.

>>>
>>>  Okay. so anyway we need to expose our management APIs as service
>>> right?.
>>>
>>> I was under the impression that FE-BE separation means a clear
>>> separation of UI layer from the BE layer. some how we ended up connecting
>>> FE layer to BE layer via web services communication. But we tried to
>>> connect FE to BE via Java calls via OSGi services approach. Thats didn't
>>> work due to some security issues.
>>>
>>> Anyway still we need to clearly separate FE components from the
>>> management APIs right? But we need to figure out an efficient  and secure
>>> way to connect the FE to BE.
>>>
>>
>> I guess where I am getting at is, we have RESTful APIs, which will be
>> called by code running in the Web Browser. Yes, I am suggesting that we go
>> back to the old AJAX based UI model we had, but without the pain of XSLT
>> (in the old model).
>>
>> FE = jquery + HTML+ (Jaggery?)
>> BE= RESTful APIs (Jaggery?)
>>
>> FE  <--- JSON --> BE
>>
>
> Does this make sense? This is not FE-BE separation. FE-BE separation meant
> that the FE runs on one JVM & BE runs on another. My argument is that with
> the management-worker node concept, we don't need that anymore. Nobody will
> run the FE on a separate JVM.
>

Wonderful!!! Big +1 from me.

I like this approach.  I wrote couple of web applications in some projects
which follow this approach. I in fact used Jersey to build the server-side
RESTful APIs. UI layer is designed with  HTML + Jquery (AJAX).

If we are exposed our management APIs via Jaggery, we might end up writing
bunch of host objects. As an alternative, we can use the framework that
AmilaS is implementing to build REST APIs.

Thanks,
Sameera.



>
>>> Thanks,
>>> Sameera.
>>>


>
> Thanks,
> Sameera.
>
>>
>>
>>>
>>> So in that case the worker contains the runtime container logic plus
>>> a management API (running at a separate port etc. and enabled by 
>>> request).
>>> The management node contains an admin app that talks to the worker nodes
>>> via the API and other means (such as ADC). Right?
>>>
>>> +1 as long as we can still ship a multi-profile distro by default
>>> where all of this is in one JVM and then you give the personalty at boot
>>> time.
>>>
>>> Sanjiva.
>>>
>>>
>>> On Thu, Mar 21, 2013 at 6:03 PM, Afkham Azeez wrote:
>>>


 On Thu, Mar 21, 2013 at 5:56 PM, Samisa Abeysinghe >>> > wrote:

>
>
> On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez wrote:
>
>> With the worker-manager concept, we no longer require FE-BE
>> separation. There is no need to have FE-BE separation for the 
>> management
>> node. So, I think we can completely do away with that concept.
>
>
> But how do we separate the worker stuff from manager stuff?
> Is that not
> Manger == FE + BE
> Worker == BE
>
>

 No, FE is the front end of the management admin client. BE is the
 management service/API. Worker provides the runtime to run services, 
 apps,
 processes, mediation etc. We have made the mistake of calling this 
 runtime
 as BE as well. Management nodes will not 

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Sagara Gunathunga]

On Fri, Mar 22, 2013 at 12:12 AM, Afkham Azeez  wrote:

>
>
> On Fri, Mar 22, 2013 at 12:05 AM, Sameera Jayasoma wrote:
>
>> See my comments inline.
>>
>>
>> On Thu, Mar 21, 2013 at 11:25 AM, Afkham Azeez  wrote:
>>
>>>
>>>
>>> On Thu, Mar 21, 2013 at 11:49 PM, Sameera Jayasoma wrote:
>>>
 Hi Azeez,



 On Thu, Mar 21, 2013 at 5:49 AM, Afkham Azeez  wrote:

>
>
> On Thu, Mar 21, 2013 at 6:16 PM, Sanjiva Weerawarana  > wrote:
>
>> Azeez don't we need the management API in worker nodes? I assume the
>> answer is yes ..
>>
>
> If you look at the current worker-manager separated setup, we don't
> have a single instance where the management node BE or FE calls into the
> worker node BE.
>


 I agree that worker nodes do not require administrative services. But
 for Management node, we need to maintain the BE/FE separation. I.e we need
 to keep the administration services as its. This would user to write their
 own UI layer to interact with our server. This exactly what AppFactory is
 doing right? In some of the project I've worked, we developed completely
 different UI to interact with Mgt nodes. So IMV, we still need that BE
 services.

>>>
>>> FE-BE separation means from the UI components we make service calls to
>>> the BE components. What we need is management APIs. Our UI can simply use
>>> these management APIs. We don't need FE-BE separation. External apps can
>>> also call these management APIs.
>>>
>>
>>  Okay. so anyway we need to expose our management APIs as service right?.
>>
>>
>> I was under the impression that FE-BE separation means a clear separation
>> of UI layer from the BE layer. some how we ended up connecting FE layer to
>> BE layer via web services communication. But we tried to connect FE to BE
>> via Java calls via OSGi services approach. Thats didn't work due to some
>> security issues.
>>
>> Anyway still we need to clearly separate FE components from the
>> management APIs right? But we need to figure out an efficient  and secure
>> way to connect the FE to BE.
>>
>
> I guess where I am getting at is, we have RESTful APIs, which will be
> called by code running in the Web Browser. Yes, I am suggesting that we go
> back to the old AJAX based UI model we had, but without the pain of XSLT
> (in the old model).
>
> FE = jquery + HTML+ (Jaggery?)
> BE= RESTful APIs (Jaggery?)
>
> FE  <--- JSON --> BE
>

 One question, what is the transport protocol which carries JSON messages
from FE to BE ?

Thanks !


>
>> Thanks,
>> Sameera.
>>
>>>
>>>

 Thanks,
 Sameera.

>
>
>>
>> So in that case the worker contains the runtime container logic plus
>> a management API (running at a separate port etc. and enabled by 
>> request).
>> The management node contains an admin app that talks to the worker nodes
>> via the API and other means (such as ADC). Right?
>>
>> +1 as long as we can still ship a multi-profile distro by default
>> where all of this is in one JVM and then you give the personalty at boot
>> time.
>>
>> Sanjiva.
>>
>>
>> On Thu, Mar 21, 2013 at 6:03 PM, Afkham Azeez  wrote:
>>
>>>
>>>
>>> On Thu, Mar 21, 2013 at 5:56 PM, Samisa Abeysinghe 
>>> wrote:
>>>


 On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez wrote:

> With the worker-manager concept, we no longer require FE-BE
> separation. There is no need to have FE-BE separation for the 
> management
> node. So, I think we can completely do away with that concept.


 But how do we separate the worker stuff from manager stuff?
 Is that not
 Manger == FE + BE
 Worker == BE


>>>
>>> No, FE is the front end of the management admin client. BE is the
>>> management service/API. Worker provides the runtime to run services, 
>>> apps,
>>> processes, mediation etc. We have made the mistake of calling this 
>>> runtime
>>> as BE as well. Management nodes will not ideally require this runtime, 
>>> but
>>> we may need to have some parts of it. e.g. validating the Synapse config
>>> will require Synapse to be in the management node. We will never have a
>>> case where a FE talks to a BE in a worker node. When it comes to the mgt
>>> node, there is no need for separating the FE & BE.
>>>
>>>

> What do you guys think?
>
> --
> *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
> blog: **http://blog.afkham.org* *
> twitter: 
> **http://twitter.com/afkham_azeez*

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Sameera Jayasoma]

On Thu, Mar 21, 2013 at 12:00 PM, Sagara Gunathunga  wrote:

>
>
> On Fri, Mar 22, 2013 at 12:12 AM, Afkham Azeez  wrote:
>
>>
>>
>> On Fri, Mar 22, 2013 at 12:05 AM, Sameera Jayasoma wrote:
>>
>>> See my comments inline.
>>>
>>>
>>> On Thu, Mar 21, 2013 at 11:25 AM, Afkham Azeez  wrote:
>>>


 On Thu, Mar 21, 2013 at 11:49 PM, Sameera Jayasoma wrote:

> Hi Azeez,
>
>
>
> On Thu, Mar 21, 2013 at 5:49 AM, Afkham Azeez  wrote:
>
>>
>>
>> On Thu, Mar 21, 2013 at 6:16 PM, Sanjiva Weerawarana <
>> sanj...@wso2.com> wrote:
>>
>>> Azeez don't we need the management API in worker nodes? I assume the
>>> answer is yes ..
>>>
>>
>> If you look at the current worker-manager separated setup, we don't
>> have a single instance where the management node BE or FE calls into the
>> worker node BE.
>>
>
>
> I agree that worker nodes do not require administrative services. But
> for Management node, we need to maintain the BE/FE separation. I.e we need
> to keep the administration services as its. This would user to write their
> own UI layer to interact with our server. This exactly what AppFactory is
> doing right? In some of the project I've worked, we developed completely
> different UI to interact with Mgt nodes. So IMV, we still need that BE
> services.
>

 FE-BE separation means from the UI components we make service calls to
 the BE components. What we need is management APIs. Our UI can simply use
 these management APIs. We don't need FE-BE separation. External apps can
 also call these management APIs.

>>>
>>>  Okay. so anyway we need to expose our management APIs as service
>>> right?.
>>>
>>> I was under the impression that FE-BE separation means a clear
>>> separation of UI layer from the BE layer. some how we ended up connecting
>>> FE layer to BE layer via web services communication. But we tried to
>>> connect FE to BE via Java calls via OSGi services approach. Thats didn't
>>> work due to some security issues.
>>>
>>> Anyway still we need to clearly separate FE components from the
>>> management APIs right? But we need to figure out an efficient  and secure
>>> way to connect the FE to BE.
>>>
>>
>> I guess where I am getting at is, we have RESTful APIs, which will be
>> called by code running in the Web Browser. Yes, I am suggesting that we go
>> back to the old AJAX based UI model we had, but without the pain of XSLT
>> (in the old model).
>>
>> FE = jquery + HTML+ (Jaggery?)
>> BE= RESTful APIs (Jaggery?)
>>
>> FE  <--- JSON --> BE
>>
>
>  One question, what is the transport protocol which carries JSON messages
> from FE to BE ?
>

Obviously HTTPS. :)

Thanks,
Sameera.

>
> Thanks !
>
>
>>
>>> Thanks,
>>> Sameera.
>>>


>
> Thanks,
> Sameera.
>
>>
>>
>>>
>>> So in that case the worker contains the runtime container logic plus
>>> a management API (running at a separate port etc. and enabled by 
>>> request).
>>> The management node contains an admin app that talks to the worker nodes
>>> via the API and other means (such as ADC). Right?
>>>
>>> +1 as long as we can still ship a multi-profile distro by default
>>> where all of this is in one JVM and then you give the personalty at boot
>>> time.
>>>
>>> Sanjiva.
>>>
>>>
>>> On Thu, Mar 21, 2013 at 6:03 PM, Afkham Azeez wrote:
>>>


 On Thu, Mar 21, 2013 at 5:56 PM, Samisa Abeysinghe >>> > wrote:

>
>
> On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez wrote:
>
>> With the worker-manager concept, we no longer require FE-BE
>> separation. There is no need to have FE-BE separation for the 
>> management
>> node. So, I think we can completely do away with that concept.
>
>
> But how do we separate the worker stuff from manager stuff?
> Is that not
> Manger == FE + BE
> Worker == BE
>
>

 No, FE is the front end of the management admin client. BE is the
 management service/API. Worker provides the runtime to run services, 
 apps,
 processes, mediation etc. We have made the mistake of calling this 
 runtime
 as BE as well. Management nodes will not ideally require this runtime, 
 but
 we may need to have some parts of it. e.g. validating the Synapse 
 config
 will require Synapse to be in the management node. We will never have a
 case where a FE talks to a BE in a worker node. When it comes to the 
 mgt
 node, there is no need for separating the FE & BE.


>
>> What do you guys think?
>>
>> --
>> *Afkham Azeez*
>> Director of Architecture; WSO2, Inc.; http://wso2.com
>> Memb

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Sagara Gunathunga]

On Fri, Mar 22, 2013 at 12:36 AM, Sameera Jayasoma  wrote:

>
>
>
> On Thu, Mar 21, 2013 at 12:00 PM, Sagara Gunathunga wrote:
>
>>
>>
>> On Fri, Mar 22, 2013 at 12:12 AM, Afkham Azeez  wrote:
>>
>>>
>>>
>>> On Fri, Mar 22, 2013 at 12:05 AM, Sameera Jayasoma wrote:
>>>
 See my comments inline.


 On Thu, Mar 21, 2013 at 11:25 AM, Afkham Azeez  wrote:

>
>
> On Thu, Mar 21, 2013 at 11:49 PM, Sameera Jayasoma 
> wrote:
>
>> Hi Azeez,
>>
>>
>>
>> On Thu, Mar 21, 2013 at 5:49 AM, Afkham Azeez  wrote:
>>
>>>
>>>
>>> On Thu, Mar 21, 2013 at 6:16 PM, Sanjiva Weerawarana <
>>> sanj...@wso2.com> wrote:
>>>
 Azeez don't we need the management API in worker nodes? I assume
 the answer is yes ..

>>>
>>> If you look at the current worker-manager separated setup, we don't
>>> have a single instance where the management node BE or FE calls into the
>>> worker node BE.
>>>
>>
>>
>> I agree that worker nodes do not require administrative services. But
>> for Management node, we need to maintain the BE/FE separation. I.e we 
>> need
>> to keep the administration services as its. This would user to write 
>> their
>> own UI layer to interact with our server. This exactly what AppFactory is
>> doing right? In some of the project I've worked, we developed completely
>> different UI to interact with Mgt nodes. So IMV, we still need that BE
>> services.
>>
>
> FE-BE separation means from the UI components we make service calls to
> the BE components. What we need is management APIs. Our UI can simply use
> these management APIs. We don't need FE-BE separation. External apps can
> also call these management APIs.
>

  Okay. so anyway we need to expose our management APIs as service
 right?.

 I was under the impression that FE-BE separation means a clear
 separation of UI layer from the BE layer. some how we ended up connecting
 FE layer to BE layer via web services communication. But we tried to
 connect FE to BE via Java calls via OSGi services approach. Thats didn't
 work due to some security issues.

 Anyway still we need to clearly separate FE components from the
 management APIs right? But we need to figure out an efficient  and secure
 way to connect the FE to BE.

>>>
>>> I guess where I am getting at is, we have RESTful APIs, which will be
>>> called by code running in the Web Browser. Yes, I am suggesting that we go
>>> back to the old AJAX based UI model we had, but without the pain of XSLT
>>> (in the old model).
>>>
>>> FE = jquery + HTML+ (Jaggery?)
>>> BE= RESTful APIs (Jaggery?)
>>>
>>> FE  <--- JSON --> BE
>>>
>>
>>  One question, what is the transport protocol which carries JSON messages
>> from FE to BE ?
>>
>
> Obviously HTTPS. :)
>

Given the fact that both FE and BE run on same JVM do we really need to use
transport level protocols here ?  isn't it make sense to use Java call
within the JVM ?

Thanks !


>
> Thanks,
> Sameera.
>
>>
>> Thanks !
>>
>>
>>>
 Thanks,
 Sameera.

>
>
>>
>> Thanks,
>> Sameera.
>>
>>>
>>>

 So in that case the worker contains the runtime container logic
 plus a management API (running at a separate port etc. and enabled by
 request). The management node contains an admin app that talks to the
 worker nodes via the API and other means (such as ADC). Right?

 +1 as long as we can still ship a multi-profile distro by default
 where all of this is in one JVM and then you give the personalty at 
 boot
 time.

 Sanjiva.


 On Thu, Mar 21, 2013 at 6:03 PM, Afkham Azeez wrote:

>
>
> On Thu, Mar 21, 2013 at 5:56 PM, Samisa Abeysinghe <
> sam...@wso2.com> wrote:
>
>>
>>
>> On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez wrote:
>>
>>> With the worker-manager concept, we no longer require FE-BE
>>> separation. There is no need to have FE-BE separation for the 
>>> management
>>> node. So, I think we can completely do away with that concept.
>>
>>
>> But how do we separate the worker stuff from manager stuff?
>> Is that not
>> Manger == FE + BE
>> Worker == BE
>>
>>
>
> No, FE is the front end of the management admin client. BE is the
> management service/API. Worker provides the runtime to run services, 
> apps,
> processes, mediation etc. We have made the mistake of calling this 
> runtime
> as BE as well. Management nodes will not ideally require this 
> runtime, but
> we may need to have some parts of it. e.g. validating the Synapse 
>>>

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Afkham Azeez]

On Fri, Mar 22, 2013 at 12:47 AM, Sagara Gunathunga  wrote:

>
>
> On Fri, Mar 22, 2013 at 12:36 AM, Sameera Jayasoma wrote:
>
>>
>>
>>
>> On Thu, Mar 21, 2013 at 12:00 PM, Sagara Gunathunga wrote:
>>
>>>
>>>
>>> On Fri, Mar 22, 2013 at 12:12 AM, Afkham Azeez  wrote:
>>>


 On Fri, Mar 22, 2013 at 12:05 AM, Sameera Jayasoma wrote:

> See my comments inline.
>
>
> On Thu, Mar 21, 2013 at 11:25 AM, Afkham Azeez  wrote:
>
>>
>>
>> On Thu, Mar 21, 2013 at 11:49 PM, Sameera Jayasoma 
>> wrote:
>>
>>> Hi Azeez,
>>>
>>>
>>>
>>> On Thu, Mar 21, 2013 at 5:49 AM, Afkham Azeez wrote:
>>>


 On Thu, Mar 21, 2013 at 6:16 PM, Sanjiva Weerawarana <
 sanj...@wso2.com> wrote:

> Azeez don't we need the management API in worker nodes? I assume
> the answer is yes ..
>

 If you look at the current worker-manager separated setup, we don't
 have a single instance where the management node BE or FE calls into 
 the
 worker node BE.

>>>
>>>
>>> I agree that worker nodes do not require administrative services.
>>> But for Management node, we need to maintain the BE/FE separation. I.e 
>>> we
>>> need to keep the administration services as its. This would user to 
>>> write
>>> their own UI layer to interact with our server. This exactly what
>>> AppFactory is doing right? In some of the project I've worked, we 
>>> developed
>>> completely different UI to interact with Mgt nodes. So IMV, we still 
>>> need
>>> that BE services.
>>>
>>
>> FE-BE separation means from the UI components we make service calls
>> to the BE components. What we need is management APIs. Our UI can simply
>> use these management APIs. We don't need FE-BE separation. External apps
>> can also call these management APIs.
>>
>
>  Okay. so anyway we need to expose our management APIs as service
> right?.
>
> I was under the impression that FE-BE separation means a clear
> separation of UI layer from the BE layer. some how we ended up connecting
> FE layer to BE layer via web services communication. But we tried to
> connect FE to BE via Java calls via OSGi services approach. Thats didn't
> work due to some security issues.
>
> Anyway still we need to clearly separate FE components from the
> management APIs right? But we need to figure out an efficient  and secure
> way to connect the FE to BE.
>

 I guess where I am getting at is, we have RESTful APIs, which will be
 called by code running in the Web Browser. Yes, I am suggesting that we go
 back to the old AJAX based UI model we had, but without the pain of XSLT
 (in the old model).

 FE = jquery + HTML+ (Jaggery?)
 BE= RESTful APIs (Jaggery?)

 FE  <--- JSON --> BE

>>>
>>>  One question, what is the transport protocol which carries JSON
>>> messages from FE to BE ?
>>>
>>
>> Obviously HTTPS. :)
>>
>
> Given the fact that both FE and BE run on same JVM do we really need to
> use transport level protocols here ?  isn't it make sense to use Java call
> within the JVM ?
>
>
FE (running on Web Browser)  <--- JSON/HTTP --> BE (RESTful API running in
JVM)
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Ruchira Wageesha]

On Fri, Mar 22, 2013 at 12:20 AM, Sameera Jayasoma  wrote:

>
>
>
> On Thu, Mar 21, 2013 at 11:45 AM, Afkham Azeez  wrote:
>
>>
>>
>> On Fri, Mar 22, 2013 at 12:12 AM, Afkham Azeez  wrote:
>>
>>>
>>>
>>> On Fri, Mar 22, 2013 at 12:05 AM, Sameera Jayasoma wrote:
>>>
 See my comments inline.


 On Thu, Mar 21, 2013 at 11:25 AM, Afkham Azeez  wrote:

>
>
> On Thu, Mar 21, 2013 at 11:49 PM, Sameera Jayasoma 
> wrote:
>
>> Hi Azeez,
>>
>>
>>
>> On Thu, Mar 21, 2013 at 5:49 AM, Afkham Azeez  wrote:
>>
>>>
>>>
>>> On Thu, Mar 21, 2013 at 6:16 PM, Sanjiva Weerawarana <
>>> sanj...@wso2.com> wrote:
>>>
 Azeez don't we need the management API in worker nodes? I assume
 the answer is yes ..

>>>
>>> If you look at the current worker-manager separated setup, we don't
>>> have a single instance where the management node BE or FE calls into the
>>> worker node BE.
>>>
>>
>>
>> I agree that worker nodes do not require administrative services. But
>> for Management node, we need to maintain the BE/FE separation. I.e we 
>> need
>> to keep the administration services as its. This would user to write 
>> their
>> own UI layer to interact with our server. This exactly what AppFactory is
>> doing right? In some of the project I've worked, we developed completely
>> different UI to interact with Mgt nodes. So IMV, we still need that BE
>> services.
>>
>
> FE-BE separation means from the UI components we make service calls to
> the BE components. What we need is management APIs. Our UI can simply use
> these management APIs. We don't need FE-BE separation. External apps can
> also call these management APIs.
>

  Okay. so anyway we need to expose our management APIs as service
 right?.

 I was under the impression that FE-BE separation means a clear
 separation of UI layer from the BE layer. some how we ended up connecting
 FE layer to BE layer via web services communication. But we tried to
 connect FE to BE via Java calls via OSGi services approach. Thats didn't
 work due to some security issues.

 Anyway still we need to clearly separate FE components from the
 management APIs right? But we need to figure out an efficient  and secure
 way to connect the FE to BE.

>>>
>>> I guess where I am getting at is, we have RESTful APIs, which will be
>>> called by code running in the Web Browser. Yes, I am suggesting that we go
>>> back to the old AJAX based UI model we had, but without the pain of XSLT
>>> (in the old model).
>>>
>>> FE = jquery + HTML+ (Jaggery?)
>>> BE= RESTful APIs (Jaggery?)
>>>
>>> FE  <--- JSON --> BE
>>>
>>
>> Does this make sense? This is not FE-BE separation. FE-BE separation
>> meant that the FE runs on one JVM & BE runs on another. My argument is that
>> with the management-worker node concept, we don't need that anymore. Nobody
>> will run the FE on a separate JVM.
>>
>
> Wonderful!!! Big +1 from me.
>
> I like this approach.  I wrote couple of web applications in some projects
> which follow this approach. I in fact used Jersey to build the server-side
> RESTful APIs. UI layer is designed with  HTML + Jquery (AJAX).
>
> If we are exposed our management APIs via Jaggery, we might end up writing
> bunch of host objects. As an alternative, we can use the framework that
> AmilaS is implementing to build REST APIs.
>
Nope Sameera, Hostobject concept is being deprecated. So, you won't need to
write any hostobject, rather directly use whatever the Java libs
available[1] and get it done.

[1]
https://github.com/wso2/jaggery/blob/master/modules/carbon/scripts/osgi.js
[2] https://developer.mozilla.org/en-US/docs/Scripting_Java

>
> Thanks,
> Sameera.
>
>
>
>>
 Thanks,
 Sameera.

>
>
>>
>> Thanks,
>> Sameera.
>>
>>>
>>>

 So in that case the worker contains the runtime container logic
 plus a management API (running at a separate port etc. and enabled by
 request). The management node contains an admin app that talks to the
 worker nodes via the API and other means (such as ADC). Right?

 +1 as long as we can still ship a multi-profile distro by default
 where all of this is in one JVM and then you give the personalty at 
 boot
 time.

 Sanjiva.


 On Thu, Mar 21, 2013 at 6:03 PM, Afkham Azeez wrote:

>
>
> On Thu, Mar 21, 2013 at 5:56 PM, Samisa Abeysinghe <
> sam...@wso2.com> wrote:
>
>>
>>
>> On Thu, Mar 21, 2013 at 3:35 PM, Afkham Azeez wrote:
>>
>>> With the worker-manager concept, we no longer require FE-BE
>>> separation. There is no need to have FE-BE separation for the 
>>> management
>>>

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Sanjiva Weerawarana]

I agree with all of this *but*, I still don't get why the workers don't
need APIs. How do we:
- ask it to update itself for deployment type stuff
- ask it to change some config
- ask it to send BAM events to a particular place
- do JMX to it
etc. etc..

All of those require that the OC or the mgmt node or ADC be able to talk to
the server. Maybe the communication is cluster-wide (broadcast) or maybe
its point-to-point ... depends on the scenario. I am confused why we don't
need some way to interact with the worker remotely.

Obviously I'm missing some crucial thought here ... what is it?

Sanjiva.


On Fri, Mar 22, 2013 at 12:52 AM, Afkham Azeez  wrote:

>
>
> On Fri, Mar 22, 2013 at 12:47 AM, Sagara Gunathunga wrote:
>
>>
>>
>> On Fri, Mar 22, 2013 at 12:36 AM, Sameera Jayasoma wrote:
>>
>>>
>>>
>>>
>>> On Thu, Mar 21, 2013 at 12:00 PM, Sagara Gunathunga wrote:
>>>


 On Fri, Mar 22, 2013 at 12:12 AM, Afkham Azeez  wrote:

>
>
> On Fri, Mar 22, 2013 at 12:05 AM, Sameera Jayasoma 
> wrote:
>
>> See my comments inline.
>>
>>
>> On Thu, Mar 21, 2013 at 11:25 AM, Afkham Azeez wrote:
>>
>>>
>>>
>>> On Thu, Mar 21, 2013 at 11:49 PM, Sameera Jayasoma >> > wrote:
>>>
 Hi Azeez,



 On Thu, Mar 21, 2013 at 5:49 AM, Afkham Azeez wrote:

>
>
> On Thu, Mar 21, 2013 at 6:16 PM, Sanjiva Weerawarana <
> sanj...@wso2.com> wrote:
>
>> Azeez don't we need the management API in worker nodes? I assume
>> the answer is yes ..
>>
>
> If you look at the current worker-manager separated setup, we
> don't have a single instance where the management node BE or FE calls 
> into
> the worker node BE.
>


 I agree that worker nodes do not require administrative services.
 But for Management node, we need to maintain the BE/FE separation. I.e 
 we
 need to keep the administration services as its. This would user to 
 write
 their own UI layer to interact with our server. This exactly what
 AppFactory is doing right? In some of the project I've worked, we 
 developed
 completely different UI to interact with Mgt nodes. So IMV, we still 
 need
 that BE services.

>>>
>>> FE-BE separation means from the UI components we make service calls
>>> to the BE components. What we need is management APIs. Our UI can simply
>>> use these management APIs. We don't need FE-BE separation. External apps
>>> can also call these management APIs.
>>>
>>
>>  Okay. so anyway we need to expose our management APIs as service
>> right?.
>>
>> I was under the impression that FE-BE separation means a clear
>> separation of UI layer from the BE layer. some how we ended up connecting
>> FE layer to BE layer via web services communication. But we tried to
>> connect FE to BE via Java calls via OSGi services approach. Thats didn't
>> work due to some security issues.
>>
>> Anyway still we need to clearly separate FE components from the
>> management APIs right? But we need to figure out an efficient  and secure
>> way to connect the FE to BE.
>>
>
> I guess where I am getting at is, we have RESTful APIs, which will be
> called by code running in the Web Browser. Yes, I am suggesting that we go
> back to the old AJAX based UI model we had, but without the pain of XSLT
> (in the old model).
>
> FE = jquery + HTML+ (Jaggery?)
> BE= RESTful APIs (Jaggery?)
>
> FE  <--- JSON --> BE
>

  One question, what is the transport protocol which carries JSON
 messages from FE to BE ?

>>>
>>> Obviously HTTPS. :)
>>>
>>
>> Given the fact that both FE and BE run on same JVM do we really need to
>> use transport level protocols here ?  isn't it make sense to use Java call
>> within the JVM ?
>>
>>
> FE (running on Web Browser)  <--- JSON/HTTP --> BE (RESTful API running in
> JVM)
>
> ___
> Architecture mailing list
> architect...@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Sanjiva Weerawarana, Ph.D.
Founder, Chairman & CEO; WSO2, Inc.;  http://wso2.com/
email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1
650 265 8311
blog: http://sanjiva.weerawarana.org/

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

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Afkham Azeez]

On Fri, Mar 22, 2013 at 8:38 AM, Sanjiva Weerawarana wrote:

> I agree with all of this *but*, I still don't get why the workers don't
> need APIs. How do we:
> - ask it to update itself for deployment type stuff
> - ask it to change some config
> - ask it to send BAM events to a particular place
> - do JMX to it
> etc. etc..
>
> All of those require that the OC or the mgmt node or ADC be able to talk
> to the server. Maybe the communication is cluster-wide (broadcast) or maybe
> its point-to-point ... depends on the scenario. I am confused why we don't
> need some way to interact with the worker remotely.
>

We may require some APIs at the worker level to do certain stuff (we have
not required this so far) once we have OC, but those APIs will be different
from the management APIs in the management node/OC. The UI will not talk to
the worker nodes ever.

I think we need to have a meeting to make some crucial decisions because
what we build could be used for the next 5 years. The Carbon UI framework
we built in 2008 is still in use.


>
> Obviously I'm missing some crucial thought here ... what is it?
>
> Sanjiva.
>
>
> On Fri, Mar 22, 2013 at 12:52 AM, Afkham Azeez  wrote:
>
>>
>>
>> On Fri, Mar 22, 2013 at 12:47 AM, Sagara Gunathunga wrote:
>>
>>>
>>>
>>> On Fri, Mar 22, 2013 at 12:36 AM, Sameera Jayasoma wrote:
>>>



 On Thu, Mar 21, 2013 at 12:00 PM, Sagara Gunathunga wrote:

>
>
> On Fri, Mar 22, 2013 at 12:12 AM, Afkham Azeez  wrote:
>
>>
>>
>> On Fri, Mar 22, 2013 at 12:05 AM, Sameera Jayasoma 
>> wrote:
>>
>>> See my comments inline.
>>>
>>>
>>> On Thu, Mar 21, 2013 at 11:25 AM, Afkham Azeez wrote:
>>>


 On Thu, Mar 21, 2013 at 11:49 PM, Sameera Jayasoma <
 same...@wso2.com> wrote:

> Hi Azeez,
>
>
>
> On Thu, Mar 21, 2013 at 5:49 AM, Afkham Azeez wrote:
>
>>
>>
>> On Thu, Mar 21, 2013 at 6:16 PM, Sanjiva Weerawarana <
>> sanj...@wso2.com> wrote:
>>
>>> Azeez don't we need the management API in worker nodes? I assume
>>> the answer is yes ..
>>>
>>
>> If you look at the current worker-manager separated setup, we
>> don't have a single instance where the management node BE or FE 
>> calls into
>> the worker node BE.
>>
>
>
> I agree that worker nodes do not require administrative services.
> But for Management node, we need to maintain the BE/FE separation. 
> I.e we
> need to keep the administration services as its. This would user to 
> write
> their own UI layer to interact with our server. This exactly what
> AppFactory is doing right? In some of the project I've worked, we 
> developed
> completely different UI to interact with Mgt nodes. So IMV, we still 
> need
> that BE services.
>

 FE-BE separation means from the UI components we make service calls
 to the BE components. What we need is management APIs. Our UI can 
 simply
 use these management APIs. We don't need FE-BE separation. External 
 apps
 can also call these management APIs.

>>>
>>>  Okay. so anyway we need to expose our management APIs as service
>>> right?.
>>>
>>> I was under the impression that FE-BE separation means a clear
>>> separation of UI layer from the BE layer. some how we ended up 
>>> connecting
>>> FE layer to BE layer via web services communication. But we tried to
>>> connect FE to BE via Java calls via OSGi services approach. Thats didn't
>>> work due to some security issues.
>>>
>>> Anyway still we need to clearly separate FE components from the
>>> management APIs right? But we need to figure out an efficient  and 
>>> secure
>>> way to connect the FE to BE.
>>>
>>
>> I guess where I am getting at is, we have RESTful APIs, which will be
>> called by code running in the Web Browser. Yes, I am suggesting that we 
>> go
>> back to the old AJAX based UI model we had, but without the pain of XSLT
>> (in the old model).
>>
>> FE = jquery + HTML+ (Jaggery?)
>> BE= RESTful APIs (Jaggery?)
>>
>> FE  <--- JSON --> BE
>>
>
>  One question, what is the transport protocol which carries JSON
> messages from FE to BE ?
>

 Obviously HTTPS. :)

>>>
>>> Given the fact that both FE and BE run on same JVM do we really need to
>>> use transport level protocols here ?  isn't it make sense to use Java call
>>> within the JVM ?
>>>
>>>
>> FE (running on Web Browser)  <--- JSON/HTTP --> BE (RESTful API running
>> in JVM)
>>
>> ___
>> Architecture mailing list
>> architect...@wso2.org
>> https://mail.wso2.or

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Nuwan Bandara]

On Fri, Mar 22, 2013 at 10:59 AM, Afkham Azeez  wrote:

>
>
> On Fri, Mar 22, 2013 at 8:38 AM, Sanjiva Weerawarana wrote:
>
>> I agree with all of this *but*, I still don't get why the workers don't
>> need APIs. How do we:
>> - ask it to update itself for deployment type stuff
>> - ask it to change some config
>> - ask it to send BAM events to a particular place
>> - do JMX to it
>> etc. etc..
>>
>> All of those require that the OC or the mgmt node or ADC be able to talk
>> to the server. Maybe the communication is cluster-wide (broadcast) or maybe
>> its point-to-point ... depends on the scenario. I am confused why we don't
>> need some way to interact with the worker remotely.
>>
>
> We may require some APIs at the worker level to do certain stuff (we have
> not required this so far) once we have OC, but those APIs will be different
> from the management APIs in the management node/OC. The UI will not talk to
> the worker nodes ever.
>
> I think we need to have a meeting to make some crucial decisions because
> what we build could be used for the next 5 years. The Carbon UI framework
> we built in 2008 is still in use.
>

Yeah better to have a meeting on the subject


>
>
>>
>> Obviously I'm missing some crucial thought here ... what is it?
>>
>> Sanjiva.
>>
>>
>> On Fri, Mar 22, 2013 at 12:52 AM, Afkham Azeez  wrote:
>>
>>>
>>>
>>> On Fri, Mar 22, 2013 at 12:47 AM, Sagara Gunathunga wrote:
>>>


 On Fri, Mar 22, 2013 at 12:36 AM, Sameera Jayasoma wrote:

>
>
>
> On Thu, Mar 21, 2013 at 12:00 PM, Sagara Gunathunga 
> wrote:
>
>>
>>
>> On Fri, Mar 22, 2013 at 12:12 AM, Afkham Azeez wrote:
>>
>>>
>>>
>>> On Fri, Mar 22, 2013 at 12:05 AM, Sameera Jayasoma >> > wrote:
>>>
 See my comments inline.


 On Thu, Mar 21, 2013 at 11:25 AM, Afkham Azeez wrote:

>
>
> On Thu, Mar 21, 2013 at 11:49 PM, Sameera Jayasoma <
> same...@wso2.com> wrote:
>
>> Hi Azeez,
>>
>>
>>
>> On Thu, Mar 21, 2013 at 5:49 AM, Afkham Azeez wrote:
>>
>>>
>>>
>>> On Thu, Mar 21, 2013 at 6:16 PM, Sanjiva Weerawarana <
>>> sanj...@wso2.com> wrote:
>>>
 Azeez don't we need the management API in worker nodes? I
 assume the answer is yes ..

>>>
>>> If you look at the current worker-manager separated setup, we
>>> don't have a single instance where the management node BE or FE 
>>> calls into
>>> the worker node BE.
>>>
>>
>>
>> I agree that worker nodes do not require administrative services.
>> But for Management node, we need to maintain the BE/FE separation. 
>> I.e we
>> need to keep the administration services as its. This would user to 
>> write
>> their own UI layer to interact with our server. This exactly what
>> AppFactory is doing right? In some of the project I've worked, we 
>> developed
>> completely different UI to interact with Mgt nodes. So IMV, we still 
>> need
>> that BE services.
>>
>
> FE-BE separation means from the UI components we make service
> calls to the BE components. What we need is management APIs. Our UI 
> can
> simply use these management APIs. We don't need FE-BE separation. 
> External
> apps can also call these management APIs.
>

  Okay. so anyway we need to expose our management APIs as service
 right?.

 I was under the impression that FE-BE separation means a clear
 separation of UI layer from the BE layer. some how we ended up 
 connecting
 FE layer to BE layer via web services communication. But we tried to
 connect FE to BE via Java calls via OSGi services approach. Thats 
 didn't
 work due to some security issues.

 Anyway still we need to clearly separate FE components from the
 management APIs right? But we need to figure out an efficient  and 
 secure
 way to connect the FE to BE.

>>>
>>> I guess where I am getting at is, we have RESTful APIs, which will
>>> be called by code running in the Web Browser. Yes, I am suggesting that 
>>> we
>>> go back to the old AJAX based UI model we had, but without the pain of 
>>> XSLT
>>> (in the old model).
>>>
>>> FE = jquery + HTML+ (Jaggery?)
>>> BE= RESTful APIs (Jaggery?)
>>>
>>> FE  <--- JSON --> BE
>>>
>>
>>  One question, what is the transport protocol which carries JSON
>> messages from FE to BE ?
>>
>
> Obviously HTTPS. :)
>

 Given the fact that both FE and BE run on same JVM do we really need to
 use transport level protocols he

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Sameera Jayasoma]

On Thu, Mar 21, 2013 at 10:52 PM, Nuwan Bandara  wrote:

>
> On Fri, Mar 22, 2013 at 10:59 AM, Afkham Azeez  wrote:
>
>>
>>
>> On Fri, Mar 22, 2013 at 8:38 AM, Sanjiva Weerawarana wrote:
>>
>>> I agree with all of this *but*, I still don't get why the workers don't
>>> need APIs. How do we:
>>> - ask it to update itself for deployment type stuff
>>> - ask it to change some config
>>> - ask it to send BAM events to a particular place
>>> - do JMX to it
>>> etc. etc..
>>>
>>> All of those require that the OC or the mgmt node or ADC be able to talk
>>> to the server. Maybe the communication is cluster-wide (broadcast) or maybe
>>> its point-to-point ... depends on the scenario. I am confused why we don't
>>> need some way to interact with the worker remotely.
>>>
>>
>> We may require some APIs at the worker level to do certain stuff (we have
>> not required this so far) once we have OC, but those APIs will be different
>> from the management APIs in the management node/OC. The UI will not talk to
>> the worker nodes ever.
>>
>> I think we need to have a meeting to make some crucial decisions because
>> what we build could be used for the next 5 years. The Carbon UI framework
>> we built in 2008 is still in use.
>>
>
> Yeah better to have a meeting on the subject
>

+1. I would like to join as well.

Thanks,
Sameera.

>
>
>>
>>
>>>
>>> Obviously I'm missing some crucial thought here ... what is it?
>>>
>>> Sanjiva.
>>>
>>>
>>> On Fri, Mar 22, 2013 at 12:52 AM, Afkham Azeez  wrote:
>>>


 On Fri, Mar 22, 2013 at 12:47 AM, Sagara Gunathunga wrote:

>
>
> On Fri, Mar 22, 2013 at 12:36 AM, Sameera Jayasoma 
> wrote:
>
>>
>>
>>
>> On Thu, Mar 21, 2013 at 12:00 PM, Sagara Gunathunga 
>> wrote:
>>
>>>
>>>
>>> On Fri, Mar 22, 2013 at 12:12 AM, Afkham Azeez wrote:
>>>


 On Fri, Mar 22, 2013 at 12:05 AM, Sameera Jayasoma <
 same...@wso2.com> wrote:

> See my comments inline.
>
>
> On Thu, Mar 21, 2013 at 11:25 AM, Afkham Azeez wrote:
>
>>
>>
>> On Thu, Mar 21, 2013 at 11:49 PM, Sameera Jayasoma <
>> same...@wso2.com> wrote:
>>
>>> Hi Azeez,
>>>
>>>
>>>
>>> On Thu, Mar 21, 2013 at 5:49 AM, Afkham Azeez wrote:
>>>


 On Thu, Mar 21, 2013 at 6:16 PM, Sanjiva Weerawarana <
 sanj...@wso2.com> wrote:

> Azeez don't we need the management API in worker nodes? I
> assume the answer is yes ..
>

 If you look at the current worker-manager separated setup, we
 don't have a single instance where the management node BE or FE 
 calls into
 the worker node BE.

>>>
>>>
>>> I agree that worker nodes do not require administrative
>>> services. But for Management node, we need to maintain the BE/FE
>>> separation. I.e we need to keep the administration services as its. 
>>> This
>>> would user to write their own UI layer to interact with our server. 
>>> This
>>> exactly what AppFactory is doing right? In some of the project I've 
>>> worked,
>>> we developed completely different UI to interact with Mgt nodes. So 
>>> IMV, we
>>> still need that BE services.
>>>
>>
>> FE-BE separation means from the UI components we make service
>> calls to the BE components. What we need is management APIs. Our UI 
>> can
>> simply use these management APIs. We don't need FE-BE separation. 
>> External
>> apps can also call these management APIs.
>>
>
>  Okay. so anyway we need to expose our management APIs as service
> right?.
>
> I was under the impression that FE-BE separation means a clear
> separation of UI layer from the BE layer. some how we ended up 
> connecting
> FE layer to BE layer via web services communication. But we tried to
> connect FE to BE via Java calls via OSGi services approach. Thats 
> didn't
> work due to some security issues.
>
> Anyway still we need to clearly separate FE components from the
> management APIs right? But we need to figure out an efficient  and 
> secure
> way to connect the FE to BE.
>

 I guess where I am getting at is, we have RESTful APIs, which will
 be called by code running in the Web Browser. Yes, I am suggesting 
 that we
 go back to the old AJAX based UI model we had, but without the pain of 
 XSLT
 (in the old model).

 FE = jquery + HTML+ (Jaggery?)
 BE= RESTful APIs (Jaggery?)

 FE  <--- JSON 

Re: [Dev] [Architecture] [Carbon 5] Scrap front-end & back-end separation?

[Senaka Fernando]

Hi all,

On Sat, Mar 23, 2013 at 10:41 PM, Sameera Jayasoma  wrote:

>
>
>
> On Thu, Mar 21, 2013 at 10:52 PM, Nuwan Bandara  wrote:
>
>>
>> On Fri, Mar 22, 2013 at 10:59 AM, Afkham Azeez  wrote:
>>
>>>
>>>
>>> On Fri, Mar 22, 2013 at 8:38 AM, Sanjiva Weerawarana 
>>> wrote:
>>>
 I agree with all of this *but*, I still don't get why the workers don't
 need APIs. How do we:
 - ask it to update itself for deployment type stuff
 - ask it to change some config
 - ask it to send BAM events to a particular place
 - do JMX to it
 etc. etc..

 All of those require that the OC or the mgmt node or ADC be able to
 talk to the server. Maybe the communication is cluster-wide (broadcast) or
 maybe its point-to-point ... depends on the scenario. I am confused why we
 don't need some way to interact with the worker remotely.

>>>
>>> We may require some APIs at the worker level to do certain stuff (we
>>> have not required this so far) once we have OC, but those APIs will be
>>> different from the management APIs in the management node/OC. The UI will
>>> not talk to the worker nodes ever.
>>>
>>> I think we need to have a meeting to make some crucial decisions because
>>> what we build could be used for the next 5 years. The Carbon UI framework
>>> we built in 2008 is still in use.
>>>
>>
>> Yeah better to have a meeting on the subject
>>
>
> +1. I would like to join as well.
>

+1, add me too.

Thanks,
Senaka.

>
> Thanks,
> Sameera.
>
>>
>>
>>>
>>>

 Obviously I'm missing some crucial thought here ... what is it?

 Sanjiva.


 On Fri, Mar 22, 2013 at 12:52 AM, Afkham Azeez  wrote:

>
>
> On Fri, Mar 22, 2013 at 12:47 AM, Sagara Gunathunga 
> wrote:
>
>>
>>
>> On Fri, Mar 22, 2013 at 12:36 AM, Sameera Jayasoma 
>> wrote:
>>
>>>
>>>
>>>
>>> On Thu, Mar 21, 2013 at 12:00 PM, Sagara Gunathunga >> > wrote:
>>>


 On Fri, Mar 22, 2013 at 12:12 AM, Afkham Azeez wrote:

>
>
> On Fri, Mar 22, 2013 at 12:05 AM, Sameera Jayasoma <
> same...@wso2.com> wrote:
>
>> See my comments inline.
>>
>>
>> On Thu, Mar 21, 2013 at 11:25 AM, Afkham Azeez wrote:
>>
>>>
>>>
>>> On Thu, Mar 21, 2013 at 11:49 PM, Sameera Jayasoma <
>>> same...@wso2.com> wrote:
>>>
 Hi Azeez,



 On Thu, Mar 21, 2013 at 5:49 AM, Afkham Azeez 
 wrote:

>
>
> On Thu, Mar 21, 2013 at 6:16 PM, Sanjiva Weerawarana <
> sanj...@wso2.com> wrote:
>
>> Azeez don't we need the management API in worker nodes? I
>> assume the answer is yes ..
>>
>
> If you look at the current worker-manager separated setup, we
> don't have a single instance where the management node BE or FE 
> calls into
> the worker node BE.
>


 I agree that worker nodes do not require administrative
 services. But for Management node, we need to maintain the BE/FE
 separation. I.e we need to keep the administration services as 
 its. This
 would user to write their own UI layer to interact with our 
 server. This
 exactly what AppFactory is doing right? In some of the project 
 I've worked,
 we developed completely different UI to interact with Mgt nodes. 
 So IMV, we
 still need that BE services.

>>>
>>> FE-BE separation means from the UI components we make service
>>> calls to the BE components. What we need is management APIs. Our UI 
>>> can
>>> simply use these management APIs. We don't need FE-BE separation. 
>>> External
>>> apps can also call these management APIs.
>>>
>>
>>  Okay. so anyway we need to expose our management APIs as service
>> right?.
>>
>> I was under the impression that FE-BE separation means a clear
>> separation of UI layer from the BE layer. some how we ended up 
>> connecting
>> FE layer to BE layer via web services communication. But we tried to
>> connect FE to BE via Java calls via OSGi services approach. Thats 
>> didn't
>> work due to some security issues.
>>
>> Anyway still we need to clearly separate FE components from the
>> management APIs right? But we need to figure out an efficient  and 
>> secure
>> way to connect the FE to BE.
>>
>
> I guess where I am getting at is, we have RESTful APIs, which will
> be called by code running in the Web