You are viewing a plain text version of this content. The canonical link for it is here.
Posted to photark-dev@incubator.apache.org by Avdhesh Yadav <av...@avdheshyadav.com> on 2010/06/06 15:22:41 UTC
Re: Running the filesystem instead of jcr
Yes I think Facade layer is good idea and i am planning to work on this.We
can not simply flip to other implementation from the web.composite.Facade
layer helps in switching between different providers.
Right now we have two different types of dataproviders .. JCR based and
DataStore(for google apps Engine JPA/JDO..Not Implemented Yet).
Here is code snippet.
-----------------------------------------
// This class go in Photark Module
interface DataProvider
{
public AlbumRepository getAlbumRepository();
public UserRepository getUserRepository();
}
//JCR Based Implementation
// Photark JCR module
public class JCRDataProvider implements DataProvider
{
private JCRRepositoryManager repositoryManager;
public JCRDataProvider(JCRRepositoryManager repositoryManager)
{
this.repositoryManager = repositorymanger
}
public AlbumRepository getAlbumRepository()
{
AlbumRepository albumRepositry = new
JCRALbumReposiroty(repositoryManager);
return albumRepositry;
}
}
//DataStore Based Implementation
// PhotaArk FileSystem module.
public class DataStoreProvider implements DataProvider
{
private JDOPersistence jdoPersistenceManager;
public JCRDataProvider(JCRRepositoryManager jdoPersistenceManager)
{
this.repositoryManager = repositorymanger
}
public AlbumRepository getAlbumRepository()
{
AlbumRepository albumRepositry = new
JDOALbumReposiroty(jdoPersistenceManager);
return albumRepositry;
}
}
//Photark Module
public interface AlbumRepository
{
public String findCoverImage(String albumName) ;
public String addAlbum(String album);
...................
}
// Photark JCR Module
public class JCRAlbumRepository implements AlbumRepository
{
private JCRRepositoryManager repositoryManager;
public String findCoverImage(String albumName)
{
// use the repository manager and fetch the data from the
repository
}
}
similary we have seprate implementation from DataStore Based
// Photark FileSystem Module
public class DataStoreAlbumRepository implements AlbumRepository
{
private JDORepositoryManager repositoryManager;
public String findCoverImage(String albumName)
{
// use the repository manager and fetch the data from the
repository
}
}
This way we separate the Data Access from the Model objects and Services.
This API also helpful in developing the Security Module.In security module
we need to fetch the data for users and also save the permissions,
etc.Security module should not be dependent on the Implementation other we
can not deploy it on the google apps engine.The propose facade layer help in
achieving this by injecting the the interface DataProvider instead of
concreate implementation and i would work with both Google apps engine and
Tomcat.
If all are agree on this I would like to work on this
Thought/Suggestions welcome
--
Avdhesh Yadav
http://www.avdheshyadav.com
http://twitter.com/yadavavdhesh
On Thu, May 13, 2010 at 4:30 AM, Luciano Resende <lu...@gmail.com>wrote:
> On Wed, May 12, 2010 at 3:46 PM, Henry Saputra <he...@gmail.com>
> wrote:
> > Actually there are some missing implementation for the SCA components in
> the
> > filesystem which supported in JCR:
> >
> > ImageServiceComponent
> > ImageUploadServiceComponent
> > RepositoryManager
> >
> > so I cant simply change the composite file to flip the component
> > implementation.
> >
> > - Henry
>
> RepositoryManager was created more like for JCR, and the other two
> should be somewhat independent of the store... let me take a look at
> this tonight to check the current status, but feel free to send
> patches if you make any progress.
>
> --
> Luciano Resende
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
Re: Running the filesystem instead of jcr
Posted by Henry Saputra <he...@gmail.com>.
And the injection for the repository happen in the composite properties
file?
- Henry
On Sun, Jun 6, 2010 at 8:22 AM, Avdhesh Yadav <av...@avdheshyadav.com> wrote:
> Yes I think Facade layer is good idea and i am planning to work on this.We
> can not simply flip to other implementation from the web.composite.Facade
> layer helps in switching between different providers.
>
> Right now we have two different types of dataproviders .. JCR based and
> DataStore(for google apps Engine JPA/JDO..Not Implemented Yet).
>
> Here is code snippet.
> -----------------------------------------
>
> // This class go in Photark Module
> interface DataProvider
> {
> public AlbumRepository getAlbumRepository();
>
> public UserRepository getUserRepository();
> }
>
>
> //JCR Based Implementation
> // Photark JCR module
> public class JCRDataProvider implements DataProvider
> {
> private JCRRepositoryManager repositoryManager;
>
> public JCRDataProvider(JCRRepositoryManager repositoryManager)
> {
> this.repositoryManager = repositorymanger
> }
>
> public AlbumRepository getAlbumRepository()
> {
> AlbumRepository albumRepositry = new
> JCRALbumReposiroty(repositoryManager);
> return albumRepositry;
> }
> }
>
> //DataStore Based Implementation
> // PhotaArk FileSystem module.
> public class DataStoreProvider implements DataProvider
> {
> private JDOPersistence jdoPersistenceManager;
>
> public JCRDataProvider(JCRRepositoryManager jdoPersistenceManager)
> {
> this.repositoryManager = repositorymanger
> }
>
> public AlbumRepository getAlbumRepository()
> {
> AlbumRepository albumRepositry = new
> JDOALbumReposiroty(jdoPersistenceManager);
> return albumRepositry;
> }
> }
>
> //Photark Module
> public interface AlbumRepository
> {
>
> public String findCoverImage(String albumName) ;
>
> public String addAlbum(String album);
>
> ...................
>
> }
>
>
> // Photark JCR Module
> public class JCRAlbumRepository implements AlbumRepository
> {
> private JCRRepositoryManager repositoryManager;
>
> public String findCoverImage(String albumName)
> {
> // use the repository manager and fetch the data from the
> repository
>
> }
> }
>
>
>
> similary we have seprate implementation from DataStore Based
> // Photark FileSystem Module
> public class DataStoreAlbumRepository implements AlbumRepository
> {
> private JDORepositoryManager repositoryManager;
>
> public String findCoverImage(String albumName)
> {
> // use the repository manager and fetch the data from the
> repository
>
> }
> }
>
> This way we separate the Data Access from the Model objects and Services.
>
> This API also helpful in developing the Security Module.In security module
> we need to fetch the data for users and also save the permissions,
> etc.Security module should not be dependent on the Implementation other we
> can not deploy it on the google apps engine.The propose facade layer help
> in
> achieving this by injecting the the interface DataProvider instead of
> concreate implementation and i would work with both Google apps engine and
> Tomcat.
>
> If all are agree on this I would like to work on this
>
> Thought/Suggestions welcome
>
> --
> Avdhesh Yadav
> http://www.avdheshyadav.com
> http://twitter.com/yadavavdhesh
>
> On Thu, May 13, 2010 at 4:30 AM, Luciano Resende <luckbr1975@gmail.com
> >wrote:
>
> > On Wed, May 12, 2010 at 3:46 PM, Henry Saputra <he...@gmail.com>
> > wrote:
> > > Actually there are some missing implementation for the SCA components
> in
> > the
> > > filesystem which supported in JCR:
> > >
> > > ImageServiceComponent
> > > ImageUploadServiceComponent
> > > RepositoryManager
> > >
> > > so I cant simply change the composite file to flip the component
> > > implementation.
> > >
> > > - Henry
> >
> > RepositoryManager was created more like for JCR, and the other two
> > should be somewhat independent of the store... let me take a look at
> > this tonight to check the current status, but feel free to send
> > patches if you make any progress.
> >
> > --
> > Luciano Resende
> > http://people.apache.org/~lresende <http://people.apache.org/%7Elresende
> >
> > http://twitter.com/lresende1975
> > http://lresende.blogspot.com/
> >
>
Re: Running the filesystem instead of jcr
Posted by Suhothayan Sriskandarajah <su...@gmail.com>.
On 6 June 2010 20:52, Avdhesh Yadav <av...@avdheshyadav.com> wrote:
> Yes I think Facade layer is good idea and i am planning to work on this.We
> can not simply flip to other implementation from the web.composite.Facade
> layer helps in switching between different providers.
>
> Right now we have two different types of dataproviders .. JCR based and
> DataStore(for google apps Engine JPA/JDO..Not Implemented Yet).
>
> Here is code snippet.
> -----------------------------------------
>
> // This class go in Photark Module
> interface DataProvider
> {
> public AlbumRepository getAlbumRepository();
>
> public UserRepository getUserRepository();
> }
>
>
> //JCR Based Implementation
> // Photark JCR module
> public class JCRDataProvider implements DataProvider
> {
> private JCRRepositoryManager repositoryManager;
>
> public JCRDataProvider(JCRRepositoryManager repositoryManager)
> {
> this.repositoryManager = repositorymanger
> }
>
> public AlbumRepository getAlbumRepository()
> {
> AlbumRepository albumRepositry = new
> JCRALbumReposiroty(repositoryManager);
> return albumRepositry;
> }
> }
>
> //DataStore Based Implementation
> // PhotaArk FileSystem module.
> public class DataStoreProvider implements DataProvider
> {
> private JDOPersistence jdoPersistenceManager;
>
> public JCRDataProvider(JCRRepositoryManager jdoPersistenceManager)
> {
> this.repositoryManager = repositorymanger
> }
>
> public AlbumRepository getAlbumRepository()
> {
> AlbumRepository albumRepositry = new
> JDOALbumReposiroty(jdoPersistenceManager);
> return albumRepositry;
> }
> }
>
> //Photark Module
> public interface AlbumRepository
> {
>
> public String findCoverImage(String albumName) ;
>
> public String addAlbum(String album);
>
> ...................
>
> }
>
>
> // Photark JCR Module
> public class JCRAlbumRepository implements AlbumRepository
> {
> private JCRRepositoryManager repositoryManager;
>
> public String findCoverImage(String albumName)
> {
> // use the repository manager and fetch the data from the
> repository
>
> }
> }
>
>
>
> similary we have seprate implementation from DataStore Based
> // Photark FileSystem Module
> public class DataStoreAlbumRepository implements AlbumRepository
> {
> private JDORepositoryManager repositoryManager;
>
> public String findCoverImage(String albumName)
> {
> // use the repository manager and fetch the data from the
> repository
>
> }
> }
>
> This way we separate the Data Access from the Model objects and Services.
>
> This API also helpful in developing the Security Module.In security module
> we need to fetch the data for users and also save the permissions,
> etc.Security module should not be dependent on the Implementation other we
> can not deploy it on the google apps engine.The propose facade layer help
> in
> achieving this by injecting the the interface DataProvider instead of
> concreate implementation and i would work with both Google apps engine and
> Tomcat.
>
> If all are agree on this I would like to work on this
>
> Thought/Suggestions welcome
>
> +1
> --
> Avdhesh Yadav
> http://www.avdheshyadav.com
> http://twitter.com/yadavavdhesh
>
> On Thu, May 13, 2010 at 4:30 AM, Luciano Resende <luckbr1975@gmail.com
> >wrote:
>
> > On Wed, May 12, 2010 at 3:46 PM, Henry Saputra <he...@gmail.com>
> > wrote:
> > > Actually there are some missing implementation for the SCA components
> in
> > the
> > > filesystem which supported in JCR:
> > >
> > > ImageServiceComponent
> > > ImageUploadServiceComponent
> > > RepositoryManager
> > >
> > > so I cant simply change the composite file to flip the component
> > > implementation.
> > >
> > > - Henry
> >
> > RepositoryManager was created more like for JCR, and the other two
> > should be somewhat independent of the store... let me take a look at
> > this tonight to check the current status, but feel free to send
> > patches if you make any progress.
> >
> > --
> > Luciano Resende
> > http://people.apache.org/~lresende<http://people.apache.org/%7Elresende><
> http://people.apache.org/%7Elresende>
> > http://twitter.com/lresende1975
> > http://lresende.blogspot.com/
> >
>
Re: Running the filesystem instead of jcr
Posted by Luciano Resende <lu...@gmail.com>.
On Sun, Jun 6, 2010 at 8:22 AM, Avdhesh Yadav <av...@avdheshyadav.com> wrote:
> Yes I think Facade layer is good idea and i am planning to work on this.We
> can not simply flip to other implementation from the web.composite.Facade
> layer helps in switching between different providers.
>
> Right now we have two different types of dataproviders .. JCR based and
> DataStore(for google apps Engine JPA/JDO..Not Implemented Yet).
>
> Here is code snippet.
> -----------------------------------------
>
> // This class go in Photark Module
> interface DataProvider
> {
> public AlbumRepository getAlbumRepository();
>
> public UserRepository getUserRepository();
> }
>
>
> //JCR Based Implementation
> // Photark JCR module
> public class JCRDataProvider implements DataProvider
> {
> private JCRRepositoryManager repositoryManager;
>
> public JCRDataProvider(JCRRepositoryManager repositoryManager)
> {
> this.repositoryManager = repositorymanger
> }
>
> public AlbumRepository getAlbumRepository()
> {
> AlbumRepository albumRepositry = new
> JCRALbumReposiroty(repositoryManager);
> return albumRepositry;
> }
> }
>
> //DataStore Based Implementation
> // PhotaArk FileSystem module.
> public class DataStoreProvider implements DataProvider
> {
> private JDOPersistence jdoPersistenceManager;
>
> public JCRDataProvider(JCRRepositoryManager jdoPersistenceManager)
> {
> this.repositoryManager = repositorymanger
> }
>
> public AlbumRepository getAlbumRepository()
> {
> AlbumRepository albumRepositry = new
> JDOALbumReposiroty(jdoPersistenceManager);
> return albumRepositry;
> }
> }
>
> //Photark Module
> public interface AlbumRepository
> {
>
> public String findCoverImage(String albumName) ;
>
> public String addAlbum(String album);
>
> ...................
>
> }
>
>
> // Photark JCR Module
> public class JCRAlbumRepository implements AlbumRepository
> {
> private JCRRepositoryManager repositoryManager;
>
> public String findCoverImage(String albumName)
> {
> // use the repository manager and fetch the data from the
> repository
>
> }
> }
>
>
>
> similary we have seprate implementation from DataStore Based
> // Photark FileSystem Module
> public class DataStoreAlbumRepository implements AlbumRepository
> {
> private JDORepositoryManager repositoryManager;
>
> public String findCoverImage(String albumName)
> {
> // use the repository manager and fetch the data from the
> repository
>
> }
> }
>
> This way we separate the Data Access from the Model objects and Services.
>
> This API also helpful in developing the Security Module.In security module
> we need to fetch the data for users and also save the permissions,
> etc.Security module should not be dependent on the Implementation other we
> can not deploy it on the google apps engine.The propose facade layer help in
> achieving this by injecting the the interface DataProvider instead of
> concreate implementation and i would work with both Google apps engine and
> Tomcat.
>
> If all are agree on this I would like to work on this
>
> Thought/Suggestions welcome
>
Are you trying to follow the DAO pattern within our API ? If so, I
think this was the original intent when we defined the Gallery facade.
In this approach, what is going to be the responsibility of
Gallery/Album or other services, other then simple delegation to the
proper dataStoreProvider ?
Also, I have a feeling you are proposing this because of the comment I
added to the OpenID JIRA mentioning that the security module should
not have dependency on JCR module.
So here is the general Design Principles I usually have in mind :
Define business objects/domain models (e.g album, image, user, etc)
Define service interfaces/facades that act on these business objects
(e.g UserAuthentication, Gallery, etc)
These two types of artifacts should be defined in a module that is
free of implementation specific 3rd party dependencies (e.g our
photark module or security module)
In this approach, at least to our current extent, the Service Facades
becomes the actual DAO, which then have different implementations such
as JCR based Gallery versus FileSystem based gallery. The application
then uses SCA assembly (composite file) to wire the specific
implementation of these services.
The current issue is that we sometimes cross the boundaries of the
service interfaces, accessing the repository directly, making things
more complex and sometimes less prone to reuse, and then comes the
necessity of a new layer of abstraction... which is why I'm trying to
promote a clean layer with specific contracts and dependencies on
other services in the rest branch.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/