Re: [Architecture] Process center- Multiple predecessor/successor support for chevron diagram editor

[Chathura Ekanayake]

Hi Frank,

Yes, it is better to let users to draw chevron diagrams without arrows
whenever possible. However, if there is a scenario where only some chevrons
in a column succeeds a chevron in its previous column, we can let users to
indicate that using arrows. Therefore, we can support a combination of
column ordering and arrows to capture predecessor/successor relationships.
i.e. if arrows are not drawn, all chevrons in a column are in successor
relationship with all chevrons in its previous column.

Regards,
Chathura

On Thu, Dec 11, 2014 at 11:50 PM, Frank Leymann  wrote:

> Hi Himasha,
>
> very good idea :-)Let me suggest a little variation:
>
> People modeling Chevron Diagrams are not really used to use arrows to
> connect the individual chevrons to indicate (control or data) flow. The
> flow is defined by the orientation of the diagram (i.e. horizontal or
> vertical). This would imply to avoid arrows as long as possible - but folks
> MAY use arrows if they want e.g. because of clarity and comprehensibility.
>
> Let's assume a horizontal orientation:  each chevron in a column of your
> grid will be a successor of all chevrons in the immediate preceding column.
> And all chevrons in the same column can be performed in parallel. And all
> chevrons of certain column must be "ready" before the chevrons of the
> succeeding column can be activated. And, yes, this is not really
> satisfactory because not all chevrons in a certain column have to be
> performed - but that's an inherent imprecision of Chevron Diagrams because
> they don't have an operational semantics (by will ;-)).
>
> Thus, the Chevron Diagram you draw would be equivalent to the following
> (ChevronRelations):
>
>
>
>
>
> Best regards,
> Frank
>
> 2014-12-11 7:45 GMT+01:00 Himasha Guruge :
>
>> Hi All,
>>
>> The idea is to support multiple relations for the chevrons in initial
>> chevron diagram editor. As the initial step, the editor canvas will include
>> a virtual grid [1] where the chevron elements can be dropped into.
>>
>> When a chevron is dropped to the canvas most suitable cell location will
>> be retrieved by checking the center position of the chevron.  In such a
>> scenario where the most suitable cell is already occupied by another
>> chevron element, it will be placed in the next most suitable location.
>> Once a chevron element is added, it can be swapped between different
>> cells as long as they are not already occupied.
>>
>> Any suggestion/feedback on building the virtual grid would be appreciated.
>>
>> [1] chevronEditor_virtualGrid_mockup
>> 
>>
>> Thanks & Regards,
>>
>> Himasha Guruge
>> *Software Engineer*
>> WS*O2* *Inc.*
>> Mobile: +94 777459299
>> himas...@wso2.com
>>
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Fast Track Training Project] ESB Connector for Teamwork

[Kesavan Yogarajah]

Hi all,

The update Milestone operation will not available on this release due to
ESB throws MalformedURLException when service returns a relative URL with
the 'Location' header.
I added a Jira for ESB.

Regards,



Kesavan Yogarajah
Associate Software Engineer
WSO2 Inc.

Mob: +94 779758021

On Tue, Dec 9, 2014 at 2:18 PM, Kesavan Yogarajah  wrote:
>
> Noted.
> Thank you.
>
> Regards
>
> Kesavan Yogarajah
> Associate Software Engineer
> WSO2 Inc.
>
> Mob: +94 779758021
>
> On Tue, Dec 9, 2014 at 2:01 PM, Vanjikumaran Sivajothy 
> wrote:
>
>> Hi,
>>
>> In future, Please identify the dependent methods before concluding the
>> final methods.
>>
>> Best Regards,
>> vanji
>>
>> On Tue, Dec 9, 2014 at 1:42 PM, Kesavan Yogarajah 
>> wrote:
>>
>>> Hi,
>>> I included Upload the file operation. Because add a file to a
>>> project,add a new file version  operations contain pendingFileRef  as a
>>> mandatory parameter which generated by this operation.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Kesavan Yogarajah
>>> Associate Software Engineer
>>> WSO2 Inc.
>>>
>>> Mob: +94 779758021
>>>
>>> On Tue, Nov 25, 2014 at 6:41 PM, Kesavan Yogarajah 
>>> wrote:
>>>
 Hi,

 Please find the  use case for Teamwork​​ ESB connector below.

 ​
  Usecase for teamwork ESB Connector
 
 ​


 Regards,

 Kesavan Yogarajah
 Associate Software Engineer
 WSO2 Inc.

 Mob: +94 779758021

 On Tue, Nov 25, 2014 at 6:30 AM, Samisa Abeysinghe 
 wrote:

> Milestone plan looks good.
>
> Thanks,
> Samisa...
>
>
> Samisa Abeysinghe
>
> Vice President Delivery
>
> WSO2 Inc.
> http://wso2.com
>
>
> On Mon, Nov 24, 2014 at 4:46 PM, Kesavan Yogarajah 
> wrote:
>
>>
>> Hi Samisa,
>>
>> I have selected the $subject as my fast track training project.
>>
>> Herewith I have attached my milestone plan for your kind review.​
>>
>> ​
>>  Milestone Plan - Teamwork Connector
>> 
>> ​
>>
>> Regards, ​
>>
>> Kesavan Yogarajah
>> Associate Software Engineer
>> WSO2 Inc.
>>
>> Mob: +94 779758021
>>
>
>

>>>
>>
>>
>> --
>> Sivajothy Vanjikumaran
>> *Senior Software Engineer*
>> *Integration Technologies Team*
>> *WSO2 Inc. http://wso2.com *
>> *Mobile:(+94)777219209*
>> [image: Facebook]  [image:
>> Twitter]  [image: LinkedIn]
>>  [image:
>> Blogger]  [image: SlideShare]
>> 
>>
>> This communication may contain privileged or other
>> confidential information and is intended exclusively for the addressee/s.
>> If you are not the intended recipient/s, or believe that you may
>> have received this communication in error, please reply to the
>> sender indicating that fact and delete the copy you received and in
>> addition, you should not print, copy, re-transmit, disseminate, or
>> otherwise use the information contained in this communication.
>> Internet communications cannot be guaranteed to be timely, secure, error
>> or virus-free. The sender does not accept liability for any errors
>> or omissions
>>
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Process center- Multiple predecessor/successor support for chevron diagram editor

[Himasha Guruge]

Hi Frank,

Thanks for the suggestion. As Chathura mentioned, will support both
approaches depending on the scenario.

Thanks & Regards,
Himasha

On Fri, Dec 12, 2014 at 1:57 PM, Chathura Ekanayake 
wrote:
>
> Hi Frank,
>
> Yes, it is better to let users to draw chevron diagrams without arrows
> whenever possible. However, if there is a scenario where only some chevrons
> in a column succeeds a chevron in its previous column, we can let users to
> indicate that using arrows. Therefore, we can support a combination of
> column ordering and arrows to capture predecessor/successor relationships.
> i.e. if arrows are not drawn, all chevrons in a column are in successor
> relationship with all chevrons in its previous column.
>
> Regards,
> Chathura
>
> On Thu, Dec 11, 2014 at 11:50 PM, Frank Leymann  wrote:
>
>> Hi Himasha,
>>
>> very good idea :-)Let me suggest a little variation:
>>
>> People modeling Chevron Diagrams are not really used to use arrows to
>> connect the individual chevrons to indicate (control or data) flow. The
>> flow is defined by the orientation of the diagram (i.e. horizontal or
>> vertical). This would imply to avoid arrows as long as possible - but folks
>> MAY use arrows if they want e.g. because of clarity and comprehensibility.
>>
>> Let's assume a horizontal orientation:  each chevron in a column of your
>> grid will be a successor of all chevrons in the immediate preceding column.
>> And all chevrons in the same column can be performed in parallel. And all
>> chevrons of certain column must be "ready" before the chevrons of the
>> succeeding column can be activated. And, yes, this is not really
>> satisfactory because not all chevrons in a certain column have to be
>> performed - but that's an inherent imprecision of Chevron Diagrams because
>> they don't have an operational semantics (by will ;-)).
>>
>> Thus, the Chevron Diagram you draw would be equivalent to the following
>> (ChevronRelations):
>>
>>
>>
>>
>>
>> Best regards,
>> Frank
>>
>> 2014-12-11 7:45 GMT+01:00 Himasha Guruge :
>>
>>> Hi All,
>>>
>>> The idea is to support multiple relations for the chevrons in initial
>>> chevron diagram editor. As the initial step, the editor canvas will include
>>> a virtual grid [1] where the chevron elements can be dropped into.
>>>
>>> When a chevron is dropped to the canvas most suitable cell location will
>>> be retrieved by checking the center position of the chevron.  In such a
>>> scenario where the most suitable cell is already occupied by another
>>> chevron element, it will be placed in the next most suitable location.
>>> Once a chevron element is added, it can be swapped between different
>>> cells as long as they are not already occupied.
>>>
>>> Any suggestion/feedback on building the virtual grid would be
>>> appreciated.
>>>
>>> [1] chevronEditor_virtualGrid_mockup
>>> 
>>>
>>> Thanks & Regards,
>>>
>>> Himasha Guruge
>>> *Software Engineer*
>>> WS*O2* *Inc.*
>>> Mobile: +94 777459299
>>> himas...@wso2.com
>>>
>>
>>
>

-- 
Himasha Guruge
*Software Engineer*
WS*O2* *Inc.*
Mobile: +94 777459299
himas...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Fast Track Training Project] ESB Connector for Teamwork

[Vanjikumaran Sivajothy]

Please refer your JIRA in this mail thread.

Thanks,
Vanji

On Fri, Dec 12, 2014 at 2:06 PM, Kesavan Yogarajah 
wrote:
>
> Hi all,
>
> The update Milestone operation will not available on this release due to
> ESB throws MalformedURLException when service returns a relative URL with
> the 'Location' header.
> I added a Jira for ESB.
>
> Regards,
>
>
>
> Kesavan Yogarajah
> Associate Software Engineer
> WSO2 Inc.
>
> Mob: +94 779758021
>
> On Tue, Dec 9, 2014 at 2:18 PM, Kesavan Yogarajah 
> wrote:
>>
>> Noted.
>> Thank you.
>>
>> Regards
>>
>> Kesavan Yogarajah
>> Associate Software Engineer
>> WSO2 Inc.
>>
>> Mob: +94 779758021
>>
>> On Tue, Dec 9, 2014 at 2:01 PM, Vanjikumaran Sivajothy 
>> wrote:
>>
>>> Hi,
>>>
>>> In future, Please identify the dependent methods before concluding the
>>> final methods.
>>>
>>> Best Regards,
>>> vanji
>>>
>>> On Tue, Dec 9, 2014 at 1:42 PM, Kesavan Yogarajah 
>>> wrote:
>>>
 Hi,
 I included Upload the file operation. Because add a file to a
 project,add a new file version  operations contain pendingFileRef  as a
 mandatory parameter which generated by this operation.



 Regards,

 Kesavan Yogarajah
 Associate Software Engineer
 WSO2 Inc.

 Mob: +94 779758021

 On Tue, Nov 25, 2014 at 6:41 PM, Kesavan Yogarajah 
 wrote:

> Hi,
>
> Please find the  use case for Teamwork​​ ESB connector below.
>
> ​
>  Usecase for teamwork ESB Connector
> 
> ​
>
>
> Regards,
>
> Kesavan Yogarajah
> Associate Software Engineer
> WSO2 Inc.
>
> Mob: +94 779758021
>
> On Tue, Nov 25, 2014 at 6:30 AM, Samisa Abeysinghe 
> wrote:
>
>> Milestone plan looks good.
>>
>> Thanks,
>> Samisa...
>>
>>
>> Samisa Abeysinghe
>>
>> Vice President Delivery
>>
>> WSO2 Inc.
>> http://wso2.com
>>
>>
>> On Mon, Nov 24, 2014 at 4:46 PM, Kesavan Yogarajah > > wrote:
>>
>>>
>>> Hi Samisa,
>>>
>>> I have selected the $subject as my fast track training project.
>>>
>>> Herewith I have attached my milestone plan for your kind review.​
>>>
>>> ​
>>>  Milestone Plan - Teamwork Connector
>>> 
>>> ​
>>>
>>> Regards, ​
>>>
>>> Kesavan Yogarajah
>>> Associate Software Engineer
>>> WSO2 Inc.
>>>
>>> Mob: +94 779758021
>>>
>>
>>
>

>>>
>>>
>>> --
>>> Sivajothy Vanjikumaran
>>> *Senior Software Engineer*
>>> *Integration Technologies Team*
>>> *WSO2 Inc. http://wso2.com *
>>> *Mobile:(+94)777219209*
>>> [image: Facebook]  [image:
>>> Twitter]  [image: LinkedIn]
>>>  [image:
>>> Blogger]  [image: SlideShare]
>>> 
>>>
>>> This communication may contain privileged or other
>>> confidential information and is intended exclusively for the addressee/s.
>>> If you are not the intended recipient/s, or believe that you may
>>> have received this communication in error, please reply to the
>>> sender indicating that fact and delete the copy you received and in
>>> addition, you should not print, copy, re-transmit, disseminate, or
>>> otherwise use the information contained in this communication.
>>> Internet communications cannot be guaranteed to be timely, secure, error
>>> or virus-free. The sender does not accept liability for any errors
>>> or omissions
>>>
>>
>>

-- 
Sivajothy Vanjikumaran
*Senior Software Engineer*
*Integration Technologies Team*
*WSO2 Inc. http://wso2.com *
*Mobile:(+94)777219209*
[image: Facebook]  [image: Twitter]
 [image: LinkedIn]
 [image:
Blogger]  [image: SlideShare]


This communication may contain privileged or other confidential information
and is intended exclusively for the addressee/s. If you are not the
intended recipient/s, or believe that you may have received this
communication in error, please reply to the sender indicating that fact and
delete the copy you received and in addition, you should not print,
copy, re-transmit, disseminate, or otherwise use the information contained
in this communication. Internet communications cannot be guaranteed to be
timely, secure, error or virus-free. The sender does not accept liability
for any errors or omissions
___
Architecture 

Re: [Architecture] [Fast Track Training Project] ESB Connector for Teamwork

[Kesavan Yogarajah]

ESB throws MalformedURLException when service returns 200 ok response with
a relative URL with the 'Location' header.
https://wso2.org/jira/browse/ESBJAVA-3461



Kesavan Yogarajah
Associate Software Engineer
WSO2 Inc.

Mob: +94 779758021

On Fri, Dec 12, 2014 at 2:26 PM, Vanjikumaran Sivajothy 
wrote:
>
> Please refer your JIRA in this mail thread.
>
> Thanks,
> Vanji
>
> On Fri, Dec 12, 2014 at 2:06 PM, Kesavan Yogarajah 
> wrote:
>>
>> Hi all,
>>
>> The update Milestone operation will not available on this release due to
>> ESB throws MalformedURLException when service returns a relative URL with
>> the 'Location' header.
>> I added a Jira for ESB.
>>
>> Regards,
>>
>>
>>
>> Kesavan Yogarajah
>> Associate Software Engineer
>> WSO2 Inc.
>>
>> Mob: +94 779758021
>>
>> On Tue, Dec 9, 2014 at 2:18 PM, Kesavan Yogarajah 
>> wrote:
>>>
>>> Noted.
>>> Thank you.
>>>
>>> Regards
>>>
>>> Kesavan Yogarajah
>>> Associate Software Engineer
>>> WSO2 Inc.
>>>
>>> Mob: +94 779758021
>>>
>>> On Tue, Dec 9, 2014 at 2:01 PM, Vanjikumaran Sivajothy 
>>> wrote:
>>>
 Hi,

 In future, Please identify the dependent methods before concluding the
 final methods.

 Best Regards,
 vanji

 On Tue, Dec 9, 2014 at 1:42 PM, Kesavan Yogarajah 
 wrote:

> Hi,
> I included Upload the file operation. Because add a file to a
> project,add a new file version  operations contain pendingFileRef  as a
> mandatory parameter which generated by this operation.
>
>
>
> Regards,
>
> Kesavan Yogarajah
> Associate Software Engineer
> WSO2 Inc.
>
> Mob: +94 779758021
>
> On Tue, Nov 25, 2014 at 6:41 PM, Kesavan Yogarajah 
> wrote:
>
>> Hi,
>>
>> Please find the  use case for Teamwork​​ ESB connector below.
>>
>> ​
>>  Usecase for teamwork ESB Connector
>> 
>> ​
>>
>>
>> Regards,
>>
>> Kesavan Yogarajah
>> Associate Software Engineer
>> WSO2 Inc.
>>
>> Mob: +94 779758021
>>
>> On Tue, Nov 25, 2014 at 6:30 AM, Samisa Abeysinghe 
>> wrote:
>>
>>> Milestone plan looks good.
>>>
>>> Thanks,
>>> Samisa...
>>>
>>>
>>> Samisa Abeysinghe
>>>
>>> Vice President Delivery
>>>
>>> WSO2 Inc.
>>> http://wso2.com
>>>
>>>
>>> On Mon, Nov 24, 2014 at 4:46 PM, Kesavan Yogarajah <
>>> kesav...@wso2.com> wrote:
>>>

 Hi Samisa,

 I have selected the $subject as my fast track training project.

 Herewith I have attached my milestone plan for your kind review.​

 ​
  Milestone Plan - Teamwork Connector
 
 ​

 Regards, ​

 Kesavan Yogarajah
 Associate Software Engineer
 WSO2 Inc.

 Mob: +94 779758021

>>>
>>>
>>
>


 --
 Sivajothy Vanjikumaran
 *Senior Software Engineer*
 *Integration Technologies Team*
 *WSO2 Inc. http://wso2.com *
 *Mobile:(+94)777219209*
 [image: Facebook]  [image:
 Twitter]  [image: LinkedIn]
  [image:
 Blogger]  [image: SlideShare]
 

 This communication may contain privileged or other
 confidential information and is intended exclusively for the addressee/s.
 If you are not the intended recipient/s, or believe that you may
 have received this communication in error, please reply to the
 sender indicating that fact and delete the copy you received and in
 addition, you should not print, copy, re-transmit, disseminate, or
 otherwise use the information contained in this communication.
 Internet communications cannot be guaranteed to be timely, secure, error
 or virus-free. The sender does not accept liability for any errors
 or omissions

>>>
>>>
>
> --
> Sivajothy Vanjikumaran
> *Senior Software Engineer*
> *Integration Technologies Team*
> *WSO2 Inc. http://wso2.com *
> *Mobile:(+94)777219209*
> [image: Facebook]  [image: Twitter]
>  [image: LinkedIn]
>  [image:
> Blogger]  [image: SlideShare]
> 
>
> This communication may contain privileged or other
> confidential information and is intended exclusively for the addressee/s.
> If you are not the i

[Architecture] Supporting OpenId-Connect Session Management

[Asela Pathberiya]

Hi Prabath/Johann,

It seems to be that we are supporting only the openid connect core
specification.  Is there any idea to support other profiles such as
session management [1] ?  If we are supporting this [1] profile..  I
hope that we can easily implement end to end web SSO with OpenID
connect with out using SAML?  Also.I think, It would be easy to
support this [1] profile in Identity Server. I am sorry... I can not
find any OpenId connect profiles in Identity Server road map except
the core. It seems to be that most of the other Identity Providers are
supporting them.  Any idea to add this in to Identity Server's road
map soon?

[1] http://openid.net/specs/openid-connect-session-1_0.html
[2] 
http://stackoverflow.com/questions/21248519/openid-connect-will-eventually-replace-saml-as-the-dominant-protocol-for-sso

Thanks,
Asela.

-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Supporting OpenId-Connect Session Management

[Gayan Gunawardana]

+1 for adding openid connect session management for Identity Server road
map also there are other profiles like Discovery and Registration which are
need to be implemented in near future. Currently we have a limitation to
provide public key to client side without Discovery and Registration
profiles.

[3]http://openid.net/specs/openid-connect-discovery-1_0.html
[4]http://openid.net/specs/openid-connect-registration-1_0.html

On Fri, Dec 12, 2014 at 3:45 PM, Asela Pathberiya  wrote:
>
> Hi Prabath/Johann,
>
> It seems to be that we are supporting only the openid connect core
> specification.  Is there any idea to support other profiles such as
> session management [1] ?  If we are supporting this [1] profile..  I
> hope that we can easily implement end to end web SSO with OpenID
> connect with out using SAML?  Also.I think, It would be easy to
> support this [1] profile in Identity Server. I am sorry... I can not
> find any OpenId connect profiles in Identity Server road map except
> the core. It seems to be that most of the other Identity Providers are
> supporting them.  Any idea to add this in to Identity Server's road
> map soon?
>
> [1] http://openid.net/specs/openid-connect-session-1_0.html
> [2]
> http://stackoverflow.com/questions/21248519/openid-connect-will-eventually-replace-saml-as-the-dominant-protocol-for-sso
>
> Thanks,
> Asela.
>
> --
> Thanks & Regards,
> Asela
>
> ATL
> Mobile : +94 777 625 933
>  +358 449 228 979
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
Gayan Gunawardana
Software Engineer; WSO2 Inc.; http://wso2.com/
Email: ga...@wso2.com
Mobile: +94 (71) 8020933
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Associating multiple lifecycles to a registry resource

[Eranda Sooriyabandara]

Hi Senaka,


> There is a use-case. For example, even in the case of a service, you can
> push it to the ES at anytime after it has been created. There is no concept
> of a service needs to be in Production or Testing for it to be available on
> the Store. But, for a service to be published on the store, you need it to
> be reviewed and also it needs to have an endpoint. So, the service has a
> Store-lifecycle. But, it has a separate development lifecycle. Similarly it
> can have other lifecycles for other concepts.
>

I got it. I had a confusion where I thought there will be separate stores
for dev, testing and production and there will be separate services in dev,
testing and prod which done by the current service lifecycle. Are we going
to change them? If the plan is for no separate stores for dev, qa and
production and one service maintain for across all lifecycle, it does make
sense  to have a separate lifecycle. Please correct me if I am wrong.

thanks
Eranda


>
> Thanks,
> Senaka
>
>
> On Friday, December 12, 2014, Eranda Sooriyabandara 
> wrote:
>
>> Hi Senaka,
>>
>>
>>> Lets take your example. Say we have both ES-LC and Dev-LC. Ideally,
>>> there will be two independent lifecycles. There needs to be some
>>> implementation or configuration that will tie these two lifecycles
>>> together. For example, like there are some checklist rules that need to be
>>> statisfied for being able to Promote from X to Y, you might also need to
>>> satisfy some other conditions in different lifecycles in order retain your
>>> existing state or promote from current to next and vice versa.
>>>
>>
>>> So, the user can define/extend how the lifecycles depends on each other,
>>> but from the framework level you can have two or more completely
>>> independent lifecycles.
>>>
>>
>> Is there any usecase where there can be two independent lifecycles per
>> resource? AFAIU, can't be. My logic is in our environment if we have two
>> lifecycle bind together then the scope of combining lifecycle is bound to a
>> state.
>>
>> For example
>> When when we promote Dev to Test will the state of ES lifecycle should
>> remain the same? (may be it's in Published state)
>>
>> If it bound to a state why can't we specify one lifecycle as a part of
>> other lifecycle. We can define it as below
>>
>> 
>> 
>>
>> Please correct me if I am on wrong way.
>>
>> thanks
>> Eranda
>>
>>
>>>
>>> Thanks,
>>> Senaka.
>>>
>>> On Fri, Dec 12, 2014 at 1:21 AM, Eranda Sooriyabandara 
>>> wrote:
>>>
 @Sagara, Senaka, Shazni,

 Here I am bit worried about the lifecycle state combinations we are
 getting.
 Let's take the example of Service. In service lifecycle we have
 Development, Test, Production and then we have a ES lifecycle which
 contains Created, Published, Retired. Think we associate both lifecycle to
 a service where we need to promote the service to the service store while
 keep it in the development. We can do it by changing the ES lifecycle to
 published. Then we promoting the service lifecycle to QA and still we see
 ES lifecycle is in published state which is bit confusing. Please correct
 me if I am wrong.

 If you look closely to the use case provided by Sagara, Service
 lifecycle is the main lifecycle and the ES lifecycle is a state specific
 lifecycle where when we promoting Dev to Test we should not transfer the
 state of ES lifecycle. So I hope we should have a main lifecycle and we
 should be able to define state specific lifecycles where we can select
 existing lifecycles.
 WDYT?

 thanks
 Eranda



>>>
>>>
>>> --
>>>
>>>
>>> *[image: http://wso2.com] Senaka Fernando*
>>> Solutions Architect; WSO2 Inc.; http://wso2.com
>>>
>>>
>>>
>>> *Member; Apache Software Foundation; http://apache.org
>>> E-mail: senaka AT wso2.com **P: +1
>>> 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*;
>>>
>>>
>>> *M: +44 782 741 1966 <%2B44%20782%20741%201966>Linked-In:
>>> http://linkedin.com/in/senakafernando
>>> *Lean . Enterprise . Middleware
>>>
>>
>>
>>
>> --
>>
>> *Eranda Sooriyabandara*Senior Software Engineer;
>> Integration Technologies Team;
>> WSO2 Inc.; http://wso2.com
>> Lean . Enterprise . Middleware
>>
>> E-mail: eranda AT wso2.com
>> Mobile: (812) 964-9032
>> Linked-In: http://www.linkedin.com/in/erandasooriyabandara
>> Blog: http://emsooriyabandara.blogspot.com/
>>
>>
>>
>>
>>
>
> --
>
>
> *[image: http://wso2.com] Senaka Fernando*
> Solutions Architect; WSO2 Inc.; http://wso2.com
>
>
>
> *Member; Apache Software Foundation; http://apache.org
> E-mail: senaka AT wso2.com **P: +1
> 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*;
>
>
> *M: +44 782 741 1966 <%2B44%20782%20741%201966>Linked-In:
> http://linkedin.com/in/senakafernando
> *Lean . Enterpr

Re: [Architecture] Associating multiple lifecycles to a registry resource

[Senaka Fernando]

Hi Eranda,

Alright I see where you are coming from now, :).

Well if we "always" have a separate store-model, your model of having a
strong tie up between the lifecycles would have made sense. But that is not
necessarily the case. There can be a single store, a couple or even 3
separate. If you want that kind of flexibility or even beyond that, the
lifecycles themselves have to be independent of each other.

So, in summary, the answer to your question is that it will not always be
separate stores and therefore a rigid lifecycle model which you are
proposing here won't be ideally fitting.

Thanks,
Senaka.

On Fri, Dec 12, 2014 at 8:04 PM, Eranda Sooriyabandara 
wrote:

> Hi Senaka,
>
>
>> There is a use-case. For example, even in the case of a service, you can
>> push it to the ES at anytime after it has been created. There is no concept
>> of a service needs to be in Production or Testing for it to be available on
>> the Store. But, for a service to be published on the store, you need it to
>> be reviewed and also it needs to have an endpoint. So, the service has a
>> Store-lifecycle. But, it has a separate development lifecycle. Similarly it
>> can have other lifecycles for other concepts.
>>
>
> I got it. I had a confusion where I thought there will be separate stores
> for dev, testing and production and there will be separate services in dev,
> testing and prod which done by the current service lifecycle. Are we going
> to change them? If the plan is for no separate stores for dev, qa and
> production and one service maintain for across all lifecycle, it does make
> sense  to have a separate lifecycle. Please correct me if I am wrong.
>
> thanks
> Eranda
>
>
>>
>> Thanks,
>> Senaka
>>
>>
>> On Friday, December 12, 2014, Eranda Sooriyabandara 
>> wrote:
>>
>>> Hi Senaka,
>>>
>>>
 Lets take your example. Say we have both ES-LC and Dev-LC. Ideally,
 there will be two independent lifecycles. There needs to be some
 implementation or configuration that will tie these two lifecycles
 together. For example, like there are some checklist rules that need to be
 statisfied for being able to Promote from X to Y, you might also need to
 satisfy some other conditions in different lifecycles in order retain your
 existing state or promote from current to next and vice versa.

>>>
 So, the user can define/extend how the lifecycles depends on each
 other, but from the framework level you can have two or more completely
 independent lifecycles.

>>>
>>> Is there any usecase where there can be two independent lifecycles per
>>> resource? AFAIU, can't be. My logic is in our environment if we have two
>>> lifecycle bind together then the scope of combining lifecycle is bound to a
>>> state.
>>>
>>> For example
>>> When when we promote Dev to Test will the state of ES lifecycle should
>>> remain the same? (may be it's in Published state)
>>>
>>> If it bound to a state why can't we specify one lifecycle as a part of
>>> other lifecycle. We can define it as below
>>>
>>> 
>>> 
>>>
>>> Please correct me if I am on wrong way.
>>>
>>> thanks
>>> Eranda
>>>
>>>

 Thanks,
 Senaka.

 On Fri, Dec 12, 2014 at 1:21 AM, Eranda Sooriyabandara >>> > wrote:

> @Sagara, Senaka, Shazni,
>
> Here I am bit worried about the lifecycle state combinations we are
> getting.
> Let's take the example of Service. In service lifecycle we have
> Development, Test, Production and then we have a ES lifecycle which
> contains Created, Published, Retired. Think we associate both lifecycle to
> a service where we need to promote the service to the service store while
> keep it in the development. We can do it by changing the ES lifecycle to
> published. Then we promoting the service lifecycle to QA and still we see
> ES lifecycle is in published state which is bit confusing. Please correct
> me if I am wrong.
>
> If you look closely to the use case provided by Sagara, Service
> lifecycle is the main lifecycle and the ES lifecycle is a state specific
> lifecycle where when we promoting Dev to Test we should not transfer the
> state of ES lifecycle. So I hope we should have a main lifecycle and we
> should be able to define state specific lifecycles where we can select
> existing lifecycles.
> WDYT?
>
> thanks
> Eranda
>
>
>


 --


 *[image: http://wso2.com] Senaka Fernando*
 Solutions Architect; WSO2 Inc.; http://wso2.com



 *Member; Apache Software Foundation; http://apache.org
 E-mail: senaka AT wso2.com **P: +1
 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*;


 *M: +44 782 741 1966 <%2B44%20782%20741%201966>Linked-In:
 http://linkedin.com/in/senakafernando
 *Lean . Enterprise . Middleware

>>>
>>>
>>>
>>> -

Re: [Architecture] Associating multiple lifecycles to a registry resource

[Eranda Sooriyabandara]

Hi Senaka,

Well if we "always" have a separate store-model, your model of having a
> strong tie up between the lifecycles would have made sense. But that is not
> necessarily the case. There can be a single store, a couple or even 3
> separate.
>

Here I am trying to get the overall picture. When there are 2+ stores are
we attaching 2+ lifecycles to a single service, one per each store? If this
is the case these stores should be independent of the Service lifecycle
isn't it?

thanks
Eranda


> If you want that kind of flexibility or even beyond that, the lifecycles
> themselves have to be independent of each other.
>
> So, in summary, the answer to your question is that it will not always be
> separate stores and therefore a rigid lifecycle model which you are
> proposing here won't be ideally fitting.
>
> Thanks,
> Senaka.
>
> On Fri, Dec 12, 2014 at 8:04 PM, Eranda Sooriyabandara 
> wrote:
>
>> Hi Senaka,
>>
>>
>>> There is a use-case. For example, even in the case of a service, you can
>>> push it to the ES at anytime after it has been created. There is no concept
>>> of a service needs to be in Production or Testing for it to be available on
>>> the Store. But, for a service to be published on the store, you need it to
>>> be reviewed and also it needs to have an endpoint. So, the service has a
>>> Store-lifecycle. But, it has a separate development lifecycle. Similarly it
>>> can have other lifecycles for other concepts.
>>>
>>
>> I got it. I had a confusion where I thought there will be separate stores
>> for dev, testing and production and there will be separate services in dev,
>> testing and prod which done by the current service lifecycle. Are we going
>> to change them? If the plan is for no separate stores for dev, qa and
>> production and one service maintain for across all lifecycle, it does make
>> sense  to have a separate lifecycle. Please correct me if I am wrong.
>>
>> thanks
>> Eranda
>>
>>
>>>
>>> Thanks,
>>> Senaka
>>>
>>>
>>> On Friday, December 12, 2014, Eranda Sooriyabandara 
>>> wrote:
>>>
 Hi Senaka,


> Lets take your example. Say we have both ES-LC and Dev-LC. Ideally,
> there will be two independent lifecycles. There needs to be some
> implementation or configuration that will tie these two lifecycles
> together. For example, like there are some checklist rules that need to be
> statisfied for being able to Promote from X to Y, you might also need to
> satisfy some other conditions in different lifecycles in order retain your
> existing state or promote from current to next and vice versa.
>

> So, the user can define/extend how the lifecycles depends on each
> other, but from the framework level you can have two or more completely
> independent lifecycles.
>

 Is there any usecase where there can be two independent lifecycles per
 resource? AFAIU, can't be. My logic is in our environment if we have two
 lifecycle bind together then the scope of combining lifecycle is bound to a
 state.

 For example
 When when we promote Dev to Test will the state of ES lifecycle should
 remain the same? (may be it's in Published state)

 If it bound to a state why can't we specify one lifecycle as a part of
 other lifecycle. We can define it as below

 
 

 Please correct me if I am on wrong way.

 thanks
 Eranda


>
> Thanks,
> Senaka.
>
> On Fri, Dec 12, 2014 at 1:21 AM, Eranda Sooriyabandara <
> era...@wso2.com> wrote:
>
>> @Sagara, Senaka, Shazni,
>>
>> Here I am bit worried about the lifecycle state combinations we are
>> getting.
>> Let's take the example of Service. In service lifecycle we have
>> Development, Test, Production and then we have a ES lifecycle which
>> contains Created, Published, Retired. Think we associate both lifecycle 
>> to
>> a service where we need to promote the service to the service store while
>> keep it in the development. We can do it by changing the ES lifecycle to
>> published. Then we promoting the service lifecycle to QA and still we see
>> ES lifecycle is in published state which is bit confusing. Please correct
>> me if I am wrong.
>>
>> If you look closely to the use case provided by Sagara, Service
>> lifecycle is the main lifecycle and the ES lifecycle is a state specific
>> lifecycle where when we promoting Dev to Test we should not transfer the
>> state of ES lifecycle. So I hope we should have a main lifecycle and we
>> should be able to define state specific lifecycles where we can select
>> existing lifecycles.
>> WDYT?
>>
>> thanks
>> Eranda
>>
>>
>>
>
>
> --
>
>
> *[image: http://wso2.com] Senaka Fernando*
> Solutions Architect; WSO2 Inc.; http://wso2.com
>
>
>
> *Member; Apache Software Foundatio

Re: [Architecture] Associating multiple lifecycles to a registry resource

[Senaka Fernando]

On Fri, Dec 12, 2014 at 8:39 PM, Eranda Sooriyabandara 
wrote:

> Hi Senaka,
>
> Well if we "always" have a separate store-model, your model of having a
>> strong tie up between the lifecycles would have made sense. But that is not
>> necessarily the case. There can be a single store, a couple or even 3
>> separate.
>>
>
> Here I am trying to get the overall picture. When there are 2+ stores are
> we attaching 2+ lifecycles to a single service, one per each store? If this
> is the case these stores should be independent of the Service lifecycle
> isn't it?
>

Sorry no. It would be a single lifecycle for the development of the service
and a single lifecycle for being published on a Store or not. What you
describe is a situation where these two lifecycles are "linked" for certain
kinds of transitions. Lets assume one store for Dev/Test and another Store
for Prod. When you move from Dev to Test, you just change the State of the
Development lifecycle, but the issue is when you move from Test to Prod.

Now the relationship between the two lifecycles can be one of the three
models below or even something completely different:

   - When you move from Test to Prod the Store lifecycle simply resets
   itself (i.e. you start from scratch).
   - Your Store lifecycle includes additional states to capture being
   published on the Dev/Test store as well as the Prod Store.
   - If your Dev/Test and Prod versions of the service do run in parallel
   and you also want to manage the Published state of the service is these two
   stores separately from each other, then obviously you will be needing two
   Store lifecycles.

This is exactly why you need the independence between these lifecycles.

Thanks,
Senaka.

>
> thanks
> Eranda
>
>
>> If you want that kind of flexibility or even beyond that, the lifecycles
>> themselves have to be independent of each other.
>>
>> So, in summary, the answer to your question is that it will not always be
>> separate stores and therefore a rigid lifecycle model which you are
>> proposing here won't be ideally fitting.
>>
>> Thanks,
>> Senaka.
>>
>> On Fri, Dec 12, 2014 at 8:04 PM, Eranda Sooriyabandara 
>> wrote:
>>
>>> Hi Senaka,
>>>
>>>
 There is a use-case. For example, even in the case of a service, you
 can push it to the ES at anytime after it has been created. There is no
 concept of a service needs to be in Production or Testing for it to be
 available on the Store. But, for a service to be published on the store,
 you need it to be reviewed and also it needs to have an endpoint. So, the
 service has a Store-lifecycle. But, it has a separate development
 lifecycle. Similarly it can have other lifecycles for other concepts.

>>>
>>> I got it. I had a confusion where I thought there will be separate
>>> stores for dev, testing and production and there will be separate services
>>> in dev, testing and prod which done by the current service lifecycle. Are
>>> we going to change them? If the plan is for no separate stores for dev, qa
>>> and production and one service maintain for across all lifecycle, it does
>>> make sense  to have a separate lifecycle. Please correct me if I am wrong.
>>>
>>> thanks
>>> Eranda
>>>
>>>

 Thanks,
 Senaka


 On Friday, December 12, 2014, Eranda Sooriyabandara 
 wrote:

> Hi Senaka,
>
>
>> Lets take your example. Say we have both ES-LC and Dev-LC. Ideally,
>> there will be two independent lifecycles. There needs to be some
>> implementation or configuration that will tie these two lifecycles
>> together. For example, like there are some checklist rules that need to 
>> be
>> statisfied for being able to Promote from X to Y, you might also need to
>> satisfy some other conditions in different lifecycles in order retain 
>> your
>> existing state or promote from current to next and vice versa.
>>
>
>> So, the user can define/extend how the lifecycles depends on each
>> other, but from the framework level you can have two or more completely
>> independent lifecycles.
>>
>
> Is there any usecase where there can be two independent lifecycles per
> resource? AFAIU, can't be. My logic is in our environment if we have two
> lifecycle bind together then the scope of combining lifecycle is bound to 
> a
> state.
>
> For example
> When when we promote Dev to Test will the state of ES lifecycle should
> remain the same? (may be it's in Published state)
>
> If it bound to a state why can't we specify one lifecycle as a part of
> other lifecycle. We can define it as below
>
> 
> 
>
> Please correct me if I am on wrong way.
>
> thanks
> Eranda
>
>
>>
>> Thanks,
>> Senaka.
>>
>> On Fri, Dec 12, 2014 at 1:21 AM, Eranda Sooriyabandara <
>> era...@wso2.com> wrote:
>>
>>> @Sagara, Senaka, Shazni,
>>>
>>> Here 

Re: [Architecture] Process center- Multiple predecessor/successor support for chevron diagram editor

[Frank Leymann]

Hi Chathura,

yes, I fully agree: that's what I meant :-)  We keep it simple and use
"column ordering" as default but allow separate arrows to override the
former semantics.

But we need to refine now what the "successor relationship" means (see next
figure "Chevron Relations and Arrows"):

   1. Chevrons 1 and 3 succeed chevron 4, but 2 does not succeed 4.
  1. Does that mean that 2 can take place in parallel to 4?
  2. Does that mean that 2 is not required to execute in order to
  perform 4?
  3. Does not mean that 2 is not required to complete (but must be
  performed and may fail) before 4?
   2. Chevron 5 precedes chevron 6, but 5 does not precede 7. Similar as
   before:
   1. Does that mean that 7 may happen even in case 5 (a) did not take
  place; (b) took place but failed?
  2. May 6 take place even if 5 failed?

We need to understand this in order to support the correct refinement in
case the chevrons are substituted by executable process models at the next
level of refinement.  Thus, we have to describe what the semantics is even
if we don't support refinement into executable process models in our first
release


How are arrows considered when a chevron is refined:

   1. If chevron 4 is refined, will the incoming arrows (logically) target
   all chevrons of the first column of the refined diagram?
   2. Or may the modeler decide that only a subset of the chevrons of the
   first column of the refined diagram become target?
   3. May the modeler target the arrows at any chevron of the refined
   diagram or only at chevrons of the first column of the refined diagram?
   4. ...and similar questions for refining chevron 5, but now for the
   source ends of the arrows...

Thus, arrows are very helpful but raise the bar in terms of their
semantics...


Best regards,
Frank

2014-12-12 9:27 GMT+01:00 Chathura Ekanayake :
>
> Hi Frank,
>
> Yes, it is better to let users to draw chevron diagrams without arrows
> whenever possible. However, if there is a scenario where only some chevrons
> in a column succeeds a chevron in its previous column, we can let users to
> indicate that using arrows. Therefore, we can support a combination of
> column ordering and arrows to capture predecessor/successor relationships.
> i.e. if arrows are not drawn, all chevrons in a column are in successor
> relationship with all chevrons in its previous column.
>
> Regards,
> Chathura
>
> On Thu, Dec 11, 2014 at 11:50 PM, Frank Leymann  wrote:
>
>> Hi Himasha,
>>
>> very good idea :-)Let me suggest a little variation:
>>
>> People modeling Chevron Diagrams are not really used to use arrows to
>> connect the individual chevrons to indicate (control or data) flow. The
>> flow is defined by the orientation of the diagram (i.e. horizontal or
>> vertical). This would imply to avoid arrows as long as possible - but folks
>> MAY use arrows if they want e.g. because of clarity and comprehensibility.
>>
>> Let's assume a horizontal orientation:  each chevron in a column of your
>> grid will be a successor of all chevrons in the immediate preceding column.
>> And all chevrons in the same column can be performed in parallel. And all
>> chevrons of certain column must be "ready" before the chevrons of the
>> succeeding column can be activated. And, yes, this is not really
>> satisfactory because not all chevrons in a certain column have to be
>> performed - but that's an inherent imprecision of Chevron Diagrams because
>> they don't have an operational semantics (by will ;-)).
>>
>> Thus, the Chevron Diagram you draw would be equivalent to the following
>> (ChevronRelations):
>>
>>
>>
>>
>>
>> Best regards,
>> Frank
>>
>> 2014-12-11 7:45 GMT+01:00 Himasha Guruge :
>>
>>> Hi All,
>>>
>>> The idea is to support multiple relations for the chevrons in initial
>>> chevron diagram editor. As the initial step, the editor canvas will include
>>> a virtual grid [1] where the chevron elements can be dropped into.
>>>
>>> When a chevron is dropped to the canvas most suitable cell location will
>>> be retrieved by checking the center position of the chevron.  In such a
>>> scenario where the most suitable cell is already occupied by another
>>> chevron element, it will be placed in the next most suitable location.
>>> Once a chevron element is added, it can be swapped between different
>>> cells as long as they are not already occupied.
>>>
>>> Any suggestion/feedback on building the virtual grid would be
>>> appreciated.
>>>
>>> [1] chevronEditor_virtualGrid_mockup
>>> 
>>>
>>> Thanks & Regards,
>>>
>>> Himasha Guruge
>>> *Software Engineer*
>>> WS*O2* *Inc.*
>>> Mobile: +94 777459299
>>> himas...@wso2.com
>>>
>>
>>
>


Chevron Relations and Arrows.pptx
Description: MS-Powerpoint 2007 presentation
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.or

Re: [Architecture] Process center- Multiple predecessor/successor support for chevron diagram editor

[Frank Leymann]

Hi Himasha,

in case you have an initial version of your code running, I would be glad
to get a brief demo :-)


Best regards,
Frank

2014-12-12 9:44 GMT+01:00 Himasha Guruge :
>
> Hi Frank,
>
> Thanks for the suggestion. As Chathura mentioned, will support both
> approaches depending on the scenario.
>
> Thanks & Regards,
> Himasha
>
> On Fri, Dec 12, 2014 at 1:57 PM, Chathura Ekanayake 
> wrote:
>>
>> Hi Frank,
>>
>> Yes, it is better to let users to draw chevron diagrams without arrows
>> whenever possible. However, if there is a scenario where only some chevrons
>> in a column succeeds a chevron in its previous column, we can let users to
>> indicate that using arrows. Therefore, we can support a combination of
>> column ordering and arrows to capture predecessor/successor relationships.
>> i.e. if arrows are not drawn, all chevrons in a column are in successor
>> relationship with all chevrons in its previous column.
>>
>> Regards,
>> Chathura
>>
>> On Thu, Dec 11, 2014 at 11:50 PM, Frank Leymann  wrote:
>>
>>> Hi Himasha,
>>>
>>> very good idea :-)Let me suggest a little variation:
>>>
>>> People modeling Chevron Diagrams are not really used to use arrows to
>>> connect the individual chevrons to indicate (control or data) flow. The
>>> flow is defined by the orientation of the diagram (i.e. horizontal or
>>> vertical). This would imply to avoid arrows as long as possible - but folks
>>> MAY use arrows if they want e.g. because of clarity and comprehensibility.
>>>
>>> Let's assume a horizontal orientation:  each chevron in a column of your
>>> grid will be a successor of all chevrons in the immediate preceding column.
>>> And all chevrons in the same column can be performed in parallel. And all
>>> chevrons of certain column must be "ready" before the chevrons of the
>>> succeeding column can be activated. And, yes, this is not really
>>> satisfactory because not all chevrons in a certain column have to be
>>> performed - but that's an inherent imprecision of Chevron Diagrams because
>>> they don't have an operational semantics (by will ;-)).
>>>
>>> Thus, the Chevron Diagram you draw would be equivalent to the following
>>> (ChevronRelations):
>>>
>>>
>>>
>>>
>>>
>>> Best regards,
>>> Frank
>>>
>>> 2014-12-11 7:45 GMT+01:00 Himasha Guruge :
>>>
 Hi All,

 The idea is to support multiple relations for the chevrons in initial
 chevron diagram editor. As the initial step, the editor canvas will include
 a virtual grid [1] where the chevron elements can be dropped into.

 When a chevron is dropped to the canvas most suitable cell location
 will be retrieved by checking the center position of the chevron.  In such
 a scenario where the most suitable cell is already occupied by another
 chevron element, it will be placed in the next most suitable location.
 Once a chevron element is added, it can be swapped between different
 cells as long as they are not already occupied.

 Any suggestion/feedback on building the virtual grid would be
 appreciated.

 [1] chevronEditor_virtualGrid_mockup
 

 Thanks & Regards,

 Himasha Guruge
 *Software Engineer*
 WS*O2* *Inc.*
 Mobile: +94 777459299
 himas...@wso2.com

>>>
>>>
>>
>
> --
> Himasha Guruge
> *Software Engineer*
> WS*O2* *Inc.*
> Mobile: +94 777459299
> himas...@wso2.com
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [POC] Performance evaluation of Hive vs Shark

[Niranda Perera]

Hi David,

I have been going through the Deep-Spark examples. It looks very promising.

On a follow up query, does Deep-spark/ deep-cassandra support SQL like
operations on RDDs (like SparkSQL)?

Example (from Datastax Cassandra connector demos):

object SQLDemo extends DemoApp {

  val cc = new CassandraSQLContext(sc)

  CassandraConnector(conf).withSessionDo { session =>
session.execute("CREATE KEYSPACE IF NOT EXISTS test WITH REPLICATION =
{'class': 'SimpleStrategy', 'replication_factor': 1 }")
session.execute("DROP TABLE IF EXISTS test.sql_demo")
session.execute("CREATE TABLE test.sql_demo (key INT PRIMARY KEY, grp
INT, value DOUBLE)")
session.execute("INSERT INTO test.sql_demo(key, grp, value) VALUES (1,
1, 1.0)")
session.execute("INSERT INTO test.sql_demo(key, grp, value) VALUES (2,
1, 2.5)")
session.execute("INSERT INTO test.sql_demo(key, grp, value) VALUES (3,
1, 10.0)")
session.execute("INSERT INTO test.sql_demo(key, grp, value) VALUES (4,
2, 4.0)")
session.execute("INSERT INTO test.sql_demo(key, grp, value) VALUES (5,
2, 2.2)")
session.execute("INSERT INTO test.sql_demo(key, grp, value) VALUES (6,
2, 2.8)")
  }

  val rdd = cc.cassandraSql("SELECT grp, max(value) AS mv FROM
test.sql_demo GROUP BY grp ORDER BY mv")
  rdd.collect().foreach(println)  // [2, 4.0] [1, 10.0]

  sc.stop()
}

I also read about Stratio Crossdata. Does Crossdata serve this purpose?

Rgds

On Tue, Dec 2, 2014 at 11:14 PM, David Morales  wrote:
>
> Hi¡
>
> Please, check the develop branch if you want to see a more realistic view
> of our development path. Last commit was about two hours ago :)
>
> Stratio Deep is one of our core modules so there is a core team in Stratio
> fully devoted to spark + noSQL integration. In these last months, for
> example, we have added mongoDB, ElasticSearch and Aerospike to Stratio
> Deep, so you can talk to these databases from Spark just like you do with
> HDFS.
>
> Furthermore, we are working on more backends, such as neo4j or couchBase,
> for example.
>
>
> About our benchmarks, you can check out some results in this link:
> http://www.stratio.com/deep-vs-datastax/
>
> Please, keep in mind that spark integration with a datastore could be done
> in two ways: HCI or native. We are now working on improving native
> integration because it's quite more performant. In this way, we are just
> working on some other tests with even more impressive results.
>
>
> Here you can find a technical overview of all our platform.
>
>
> http://www.slideshare.net/Stratio/stratio-platform-overview-v41
>
> Regards
>
> 2014-12-02 11:14 GMT+01:00 Niranda Perera :
>
>> Hi David,
>>
>> Sorry to re-initiate this thread. But may I know if you have done any
>> benchmarking on Datastax Spark cassandra connector and Stratio Deep-spark
>> cassandra integration? Would love to take a look at it.
>>
>> I recently checked deep-spark github repo and noticed that there is no
>> activity since Oct 29th. May I know what your future plans on this
>> particular project?
>>
>> Cheers
>>
>> On Tue, Aug 26, 2014 at 9:12 PM, David Morales 
>> wrote:
>>
>>> Yes, it is already included in our benchmarks.
>>>
>>> It could be a nice idea to share our findings, let me talk about it
>>> here. Meanwhile, you can ask us any question by using my mail or this
>>> thread, we are glad to help you.
>>>
>>>
>>> Best regards.
>>>
>>>
>>> 2014-08-24 15:49 GMT+02:00 Niranda Perera :
>>>
 Hi David,

 Thank you for your detailed reply.

 It was great to hear about Stratio-Deep and I must say, it looks very
 interesting. Storage handlers for databases such Cassandra, MongoDB etc
 would be very helpful. We will definitely look up on Stratio-Deep.

 I came across with the Datastax Spark-Cassandra connector (
 https://github.com/datastax/spark-cassandra-connector ). Have you done
 any comparison with your implementation and Datastax's connector?

 And, yes, please do share the performance results with us once it's
 ready.

 On a different note, is there any way for us to interact with Stratio
 dev community, in the form of dev mail lists etc, so that we could mutually
 share our findings?

 Best regards



 On Fri, Aug 22, 2014 at 2:07 PM, David Morales 
 wrote:

> Hi there,
>
> *1. About the size of deployments.*
>
> It depends on your use case... specially when you combine spark with a
> datastore. We use to deploy spark with cassandra or mongodb, instead of
> using HDFS for example.
>
> Spark will be faster if you put the data in memory, so if you need a
> lot of speed (interactive queries, for example), you should have enough
> memory.
>
>
> *2. About storage handlers.*
>
> We have developed the first tight integration between Cassandra and
> Spark, called Stratio Deep, announced in the first spark summit. You can
> check Stratio Deep out here: 

Re: [Architecture] Process center- Multiple predecessor/successor support for chevron diagram editor

[Himasha Guruge]

Hi Frank,

Sure, we can set up a brief demo of the initial version next week. :) Let
me know a free slot from your schedule.

Thanks & Regards,
Himasha

On Fri, Dec 12, 2014 at 11:28 PM, Frank Leymann  wrote:
>
> Hi Himasha,
>
> in case you have an initial version of your code running, I would be glad
> to get a brief demo :-)
>
>
> Best regards,
> Frank
>
> 2014-12-12 9:44 GMT+01:00 Himasha Guruge :
>>
>> Hi Frank,
>>
>> Thanks for the suggestion. As Chathura mentioned, will support both
>> approaches depending on the scenario.
>>
>> Thanks & Regards,
>> Himasha
>>
>> On Fri, Dec 12, 2014 at 1:57 PM, Chathura Ekanayake 
>> wrote:
>>>
>>> Hi Frank,
>>>
>>> Yes, it is better to let users to draw chevron diagrams without arrows
>>> whenever possible. However, if there is a scenario where only some chevrons
>>> in a column succeeds a chevron in its previous column, we can let users to
>>> indicate that using arrows. Therefore, we can support a combination of
>>> column ordering and arrows to capture predecessor/successor relationships.
>>> i.e. if arrows are not drawn, all chevrons in a column are in successor
>>> relationship with all chevrons in its previous column.
>>>
>>> Regards,
>>> Chathura
>>>
>>> On Thu, Dec 11, 2014 at 11:50 PM, Frank Leymann  wrote:
>>>
 Hi Himasha,

 very good idea :-)Let me suggest a little variation:

 People modeling Chevron Diagrams are not really used to use arrows to
 connect the individual chevrons to indicate (control or data) flow. The
 flow is defined by the orientation of the diagram (i.e. horizontal or
 vertical). This would imply to avoid arrows as long as possible - but folks
 MAY use arrows if they want e.g. because of clarity and comprehensibility.

 Let's assume a horizontal orientation:  each chevron in a column of
 your grid will be a successor of all chevrons in the immediate preceding
 column. And all chevrons in the same column can be performed in parallel.
 And all chevrons of certain column must be "ready" before the chevrons of
 the succeeding column can be activated. And, yes, this is not really
 satisfactory because not all chevrons in a certain column have to be
 performed - but that's an inherent imprecision of Chevron Diagrams because
 they don't have an operational semantics (by will ;-)).

 Thus, the Chevron Diagram you draw would be equivalent to the following
 (ChevronRelations):





 Best regards,
 Frank

 2014-12-11 7:45 GMT+01:00 Himasha Guruge :

> Hi All,
>
> The idea is to support multiple relations for the chevrons in initial
> chevron diagram editor. As the initial step, the editor canvas will 
> include
> a virtual grid [1] where the chevron elements can be dropped into.
>
> When a chevron is dropped to the canvas most suitable cell location
> will be retrieved by checking the center position of the chevron.  In such
> a scenario where the most suitable cell is already occupied by another
> chevron element, it will be placed in the next most suitable location.
> Once a chevron element is added, it can be swapped between different
> cells as long as they are not already occupied.
>
> Any suggestion/feedback on building the virtual grid would be
> appreciated.
>
> [1] chevronEditor_virtualGrid_mockup
> 
>
> Thanks & Regards,
>
> Himasha Guruge
> *Software Engineer*
> WS*O2* *Inc.*
> Mobile: +94 777459299
> himas...@wso2.com
>


>>>
>>
>> --
>> Himasha Guruge
>> *Software Engineer*
>> WS*O2* *Inc.*
>> Mobile: +94 777459299
>> himas...@wso2.com
>>
>

-- 
Himasha Guruge
*Software Engineer*
WS*O2* *Inc.*
Mobile: +94 777459299
himas...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture