Fwd: escada and jgcs

[Nuno Carvalho-3]

(resent to be stored in the archives mailing list)

Begin forwarded message:

From: buzz lightyear <buzzheavyyear@...>

Date: September 21, 2007 1:25:47 PM GMT+02:00

To: Nuno Carvalho <nunomrc@...>

Subject: RE: escada and jgcs

Hi Nuno

Apologies - my misunderstanding - yes, jxta would simply be another protocol under jGCS.

My problem still exists with the gpl license, though. Unless someone is able to change this to lgpl then I'm stuck.

Incedently, did you have any thoughts re. hibernates second level cache and gorda/escada?

One last thing - I got a failure notice when I tried to email to community@...

Cheers
Nick

---

CC: community@...; jop@...
From: nunomrc@...
Subject: Re: escada and jgcs
Date: Fri, 21 Sep 2007 12:15:02 +0200
To: buzzheavyyear@...

Hi Nick,

On Sep 19, 2007, at 11:52 , buzz lightyear wrote:

I have just gone over what I was trying to do in July and realise that it will be much easier to implement any replication with jxta via tcp streams, and then stream over jxta ..... there are so many ways to configure jxta that coming up with an escada framework for jxta might just frustrate many users

I don't know JXTA very well, but I got the impression that it is a communication infrastructure. Escada is more than that, it uses a communication infrastructure (through jGCS) and does database replication using also the GAPI interface on the databases. It contains protocols such as primary-backup and DBSM, recovery, etc. 

I'm not sure what do you want to do, but JXTA and Escada are not comparable.

At the beginning of the week I tried to build derby-g-0.3 and was unable to do it. I followed the instructions and ran into problems via a unix shell - I have posted this issue to your forum and hope that someone might be able to respond.

I just answered that email. Sorry for the delay, we were all traveling for a demo of the GORDA project.

I also tried to build via netbeans which showed further problems of requiring xalan in the the gorda reflection api - xalan, I think, isn't mentioned in the build instructions.

I can build with eclipse... and I do not remember for the need for xalan on the derby implementation of GAPI. xalan is needed by Derby and not by the GORDA patch to implement GAPI (gorda reflection interface). The docs only refer to the things needed by this patch. 

One last thing - is there any possibility that the escada interface might be set as an apache license instead of gnu - I am unable to use gnu, and consequently escada. If just the interface was set as apache then I would be able to do my own implementation.

Are you talking about the jGCS interface or the GAPI interface? 

I do not manage this king of issues, I added José Pereira on Cc to clarify us about that.

Kind regards,

nuno

From: Nuno Carvalho <nunomrc@...>

To: buzz lightyear <buzzheavyyear@...>

CC: alfranio correia <alfranio@...>,José Orlando Pereira <jop@...>

Subject: Re: escada and jgcs

Date: Fri, 6 Jul 2007 13:27:54 +0100

Hi Nick,

On Jul 6, 2007, at 11:34 , buzz lightyear wrote:

I don't know if you/others have investigated Jxta as a possible  jgcs binding - the current code doesn't make it easy for Jxta to be  implemented.

No, not yet.

However, if SocketAddress is somehow embedded in a (for example)  'Member' interface then the Jxta IDs - there are two primary user  types for peer and peergroup - can also be embedded within a Member  interface, as jxta does reference sockets directly.

I'm not sure if you need this.

Since SocketAddress is an abstract class, you can do something like  this:

 public class JxtaPeer extends SocketAddress {

Member id;

 }

The addresses in Spread are Strings and it works perfectly. You can  take a look at the Spread binding (available for download in the SF) to see how we handle this. jGCS is supposed to be as generic as  possible, so we use Java standard interfaces and abstract where possible.

With jGCS you should also be able to reuse native classes of the  toolkit that you want to use for implementing jGCS. For example, the Appia binding does something like this:

public class AppiaMessage extends appia.Message implements  jgcs.Message {

(...)

}

The messages are created and sent directly to the toolkit without any  conversion overhead.

I suspect that I will press ahead soon and modify a local version  of escada/jgcs. Would you be interested in me sending you anything  I do? I would be unable to update and verify the jgroups and other  bindings as I don't know them. However, the abstraction of  SocketAddress into a Member class should make this relatively easy  for all bindings.

Great! You are welcome to send anything that you have. You can also  expect our help on problems and/or questions you may have.

Hope this helps,

--

Nuno Carvalho

University of Lisbon, Portugal

http://lasige.di.fc.ul.pt/~ncarvalho

_________________________________________________________________

The next generation of Hotmail is here!  http://www.newhotmail.co.uk

--

Nuno Carvalho

University of Lisbon, Portugal

http://lasige.di.fc.ul.pt/~ncarvalho

---

Do you know a place like the back of your hand? Share local knowledge with BackOfMyHand.com

--

Nuno Carvalho

University of Lisbon, Portugal

http://lasige.di.fc.ul.pt/~ncarvalho

[Jose Orlando Pereira]

On Friday 21 September 2007, Nuno Carvalho wrote:
> From: buzz lightyear <buzzheavyyear@...>
> Date: September 21, 2007 1:25:47 PM GMT+02:00
> To: Nuno Carvalho <nunomrc@...>
> Subject: RE: escada and jgcs
>
> My problem still exists with the gpl license, though. Unless someone is
> able to change this to lgpl then I'm stuck.

Can you elaborate on this? Do you a specific license compatibility problem?

> Incedently, did you have any thoughts re. hibernates second level cache and
> gorda/escada?

Using a DBMS replicated with ESCADA should not cause any trouble for an
application level cache that wouldn't exist with a single non-replicated DBMS
backend. The only requirement is that you enforce client affinity: the same
client should not use more than one replica unless a server fails. This
shouldn't be an issue unless you use some sort of load balancer in between.
For more details check this paper:

http://portal.acm.org/citation.cfm?id=1141277.1141442

Regards,

--
Jose Orlando Pereira

[buzzc4nfw]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi Jose

Thanks for the reference to the paper - when using jxta I'm having to take into account node failure and clients are generally aware of which nodes have the database - jxta is pretty good at discovery. This idea is to ensure that clients connect to the 'best' connection at the time an operation is invoked. The 'load balancing' is effectively taking place on the client side.

The license is an issue do to the fact that customers may construct standalone applications using my libraries, your libraries and all the other libraries which they might pass onto their clients. Some customers may not not want to make public the source of their application. Other customers may be overlook the gpl issue, distribute an application without source and be unaware that they are contravening escadas license terms, and as a consequence be liable. All of the libraries I'm using, including my own (once they are ready), hibernate, jboss, jxta, derby etc have at worst the lgpl license, and at best the apache license.

I dearly hope we can resolve this licensing issue.

As for the client node and load balancing, I think that this is going to need some more thought.

Cheers
Nick

> From: jop@...
> To: community@...
> Subject: Re: Fwd: escada and jgcs
> Date: Fri, 21 Sep 2007 13:54:08 +0100
> CC: nunomrc@...; buzzheavyyear@...
>
> On Friday 21 September 2007, Nuno Carvalho wrote:
> > From: buzz lightyear <buzzheavyyear@...>
> > Date: September 21, 2007 1:25:47 PM GMT+02:00
> > To: Nuno Carvalho <nunomrc@...>
> > Subject: RE: escada and jgcs
> >
> > My problem still exists with the gpl license, though. Unless someone is
> > able to change this to lgpl then I'm stuck.
>
> Can you elaborate on this? Do you a specific license compatibility problem?
>
> > Incedently, did you have any thoughts re. hibernates second level cache and
> > gorda/escada?
>
> Using a DBMS replicated with ESCADA should not cause any trouble for an
> application level cache that wouldn't exist with a single non-replicated DBMS
> backend. The only requirement is that you enforce client affinity: the same
> client should not use more than one replica unless a server fails. This
> shouldn't be an issue unless you use some sort of load balancer in between.
> For more details check this paper:
>
> http://portal.acm.org/citation.cfm?id=1141277.1141442
>
> Regards,
>
> --
> Jose Orlando Pereira

---

Are you the Quizmaster? Play BrainBattle with a friend now!

[Jose Orlando Pereira]

On Friday 21 September 2007, buzz lightyear wrote:
> Thanks for the reference to the paper - when using jxta I'm having to take
> into account node failure and clients are generally aware of which nodes
> have the database - jxta is pretty good at discovery. This idea is to
> ensure that clients connect to the 'best' connection at the time an
> operation is invoked. The 'load balancing' is effectively taking place on
> the client side.

I understand. You should definitely take a look at the paper and think about
the best solution for you: Enforcing some client affinity or using ESCADA in
the proposed safe mode, which does however have an impact in read only
transactions.

> The license is an issue do to the fact that customers may construct
> standalone applications using my libraries, your libraries and all the
> other libraries which they might pass onto their clients. Some customers
> may not not want to make public the source of their application. Other
> customers may be overlook the gpl issue, distribute an application without
> source and be unaware that they are contravening escadas license terms, and
> as a consequence be liable. All of the libraries I'm using, including my
> own (once they are ready), hibernate, jboss, jxta, derby etc have at worst
> the lgpl license, and at best the apache license.
>
> I dearly hope we can resolve this licensing issue.

IANAL, but the client application cannot be considered a derived work from
ESCADA and thus is exempt from any licensing restrictions imposed by ESCADA.
Let me try to explain this.

Actually, this is a _major_advantage_ of the GORDA approach: replication is
implemented by intercepting requests within the DBMS and not within the
client application. This allows the client application (ditto JBoss,
hibernate) to link to the original unmodified JDBC driver. No linking to
ESCADA code is done. Besides technically interesting this should also solve
any licensing issues.

Licensing issues might arise only when linking ESCADA to the DBMS, since the
resulting replicated DBMS is a derived work from both ESCADA and the DBMS.
This is why we chose GPLv3, which unlike GPLv2 is compatible with Apache 2.0
license, hence with Derby or Sequoia. There are also no problems when linking
GPLv3 with modified-BSD licenses, hence with PostgreSQL.

Moreover, like Apache License 2.0, GPLv3 should also be safer when
redistributing code for money regarding possible patent claims.

I hope this clears the licensing issue,

--
Jose Orlando Pereira

[buzzc4nfw]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi Jose

If you are saying what I think you are saying then it's certainly fine by me. All that needs to be known is that works running on top of escada won't be subject to patent or copyright issues.

Thanks

Cheers
Nick

.. and thanks for mentioning the safe mode.

> From: jop@...
> To: buzzheavyyear@...
> Subject: Re: escada and jgcs
> Date: Fri, 21 Sep 2007 16:11:05 +0100
> CC: community@...; nunomrc@...
>
> On Friday 21 September 2007, buzz lightyear wrote:
> > Thanks for the reference to the paper - when using jxta I'm having to take
> > into account node failure and clients are generally aware of which nodes
> > have the database - jxta is pretty good at discovery. This idea is to
> > ensure that clients connect to the 'best' connection at the time an
> > operation is invoked. The 'load balancing' is effectively taking place on
> > the client side.
>
> I understand. You should definitely take a look at the paper and think about
> the best solution for you: Enforcing some client affinity or using ESCADA in
> the proposed safe mode, which does however have an impact in read only
> transactions.
>
> > The license is an issue do to the fact that customers may construct
> > standalone applications using my libraries, your libraries and all the
> > other libraries which they might pass onto their clients. Some customers
> > may not not want to make public the source of their application. Other
> > customers may be overlook the gpl issue, distribute an application without
> > source and be unaware that they are contravening escadas license terms, and
> > as a consequence be liable. All of the libraries I'm using, including my
> > own (once they are ready), hibernate, jboss, jxta, derby etc have at worst
> > the lgpl license, and at best the apache license.
> >
> > I dearly hope we can resolve this licensing issue.
>
> IANAL, but the client application cannot be considered a derived work from
> ESCADA and thus is exempt from any licensing restrictions imposed by ESCADA.
> Let me try to explain this.
>
> Actually, this is a _major_advantage_ of the GORDA approach: replication is
> implemented by intercepting requests within the DBMS and not within the
> client application. This allows the client application (ditto JBoss,
> hibernate) to link to the original unmodified JDBC driver. No linking to
> ESCADA code is done. Besides technically interesting this should also solve
> any licensing issues.
>
> Licensing issues might arise only when linking ESCADA to the DBMS, since the
> resulting replicated DBMS is a derived work from both ESCADA and the DBMS.
> This is why we chose GPLv3, which unlike GPLv2 is compatible with Apache 2.0
> license, hence with Derby or Sequoia. There are also no problems when linking
> GPLv3 with modified-BSD licenses, hence with PostgreSQL.
>
> Moreover, like Apache License 2.0, GPLv3 should also be safer when
> redistributing code for money regarding possible patent claims.
>
> I hope this clears the licensing issue,
>
> --
> Jose Orlando Pereira

---

The next generation of MSN Hotmail has arrived - Windows Live Hotmail