[dna-dev] SOA/Enterprise project using DNA

[Randall Hauch]

I'm also working on a connector that stores the graph in a DB using  
Hibernate.  It's not complete, so I don't have any numbers yet.  But  
it's coming along nicely, and I did try to solve some of the problems  
with how JR persistence works.

On Nov 19, 2008, at 11:50 PM, Michael Neale wrote:

> that sounds ideal. I know myself and others are not entirely
> comfortable with jackrabbit - particularly the way it stores thing in
> RDBMS (although if we are using jboss cache and its persistence - I am
> not sure if we will do much better then blob storage??).
>
> On Thu, Nov 20, 2008 at 3:05 PM, Randall Hauch <rhauch at redhat.com>  
> wrote:
>> Actually, I'm hoping that we can support binary property values  
>> (which is
>> actually where JCR stores file content, but you know that :-) in  
>> memory
>> mapped (direct) buffers.  That way, they don't take up any memory.   
>> Plus, by
>> using federation and a file system connector, we could store these  
>> large
>> files on the file system and just handle the "references" as property
>> values, opening a stream to the underlying only when required.  Of  
>> course,
>> you're app would have to pay the price for streaming gigabytes of
>> information. :-)
>>
>> How does this sound?
>>
>> Best regards,
>>
>> Randall
>>
>> On Nov 19, 2008, at 9:09 PM, Michael Neale wrote:
>>
>>> For our SOA repository, and rules - its possible we are looking at
>>> large single artifacts, as well as many small ones (which kind of
>>> stretch most JCR implementations). One idea floated is to (possibly)
>>> one day store entire machine images (OMG !!!) in the repository
>>> (obviously in memory will not work in that case !). But its hard to
>>> nail things down isn't it...
>>>
>>> On Thu, Nov 20, 2008 at 7:21 AM, Randall Hauch <rhauch at redhat.com>  
>>> wrote:
>>>>
>>>> Stefano, this sounds great!  Personally, I really like to hear  
>>>> these
>>>> kinds
>>>> of use cases and scenarios.  It's always important to know  
>>>> whether we're
>>>> working on the "right" set of features.  So keep these use cases  
>>>> coming!
>>>>
>>>> And, please feel free to suggest or discuss features that might be
>>>> useful,
>>>> too.  For example, do you think JCR versioning will be an  
>>>> important part
>>>> of
>>>> your approach, or will you implement your own approach to managing
>>>> history
>>>> by designing the hierarchy to handle it?  Also, do you have an  
>>>> idea about
>>>> how much information the repository will store (perhaps broken  
>>>> down by %
>>>> in
>>>> uploaded files, and about how big those files will each be).
>>>>
>>>> Best regards,
>>>>
>>>> Randall
>>>>
>>>> On Nov 18, 2008, at 3:34 PM, Stefano Maestri wrote:
>>>>
>>>>> Hi all,
>>>>> as said in a previous post I'm going to start a SOA/Enterprise  
>>>>> project
>>>>> using DNA for an important part of the project.
>>>>> I'm finishing the design of the whole application, but I can  
>>>>> describe
>>>>> here the main idea and how DNA will be related.
>>>>>
>>>>> In a nutshell we are SOAfing a complex system of a customer
>>>>> (J2EE+.NET+Oracle mainly, with external partner and provider  
>>>>> with SOAP
>>>>> service and/or custom legacy services).
>>>>> The system use a lot of data stored in various resources (mainly
>>>>> relationl DB, but also someone provided from partner services).  
>>>>> Some
>>>>> code (in all languages) apply business rules to this data and  
>>>>> transform
>>>>> it in a some enrich information (information=data+Business rules).
>>>>> Aggregating this data we build a final report to client that is  
>>>>> the
>>>>> final product.
>>>>> As said we are moving to SOA and we are identifying services and
>>>>> aggregation of them. The area where DNA could be very useful is  
>>>>> solving
>>>>> the problem of keeping track of information during time.
>>>>> IOW we are asked to be able to provide not only current  
>>>>> information, but
>>>>> also information related to a particular moment (remember  
>>>>> information
>>>>> for us= data + business rules).
>>>>> The system (or better a lot of service provider we are  
>>>>> considering part
>>>>> of the system) haven't ability to keep data or bsiness rules  
>>>>> history, so
>>>>> we have to store in some other places answer to be able to  
>>>>> retrive them
>>>>> in future.
>>>>> Here DNA could help us: the basic idea is to use JBossESB as  
>>>>> integration
>>>>> layer where a MessageStore could store messages into DNA where  
>>>>> we can
>>>>> apply different sequencers to extract information and organize  
>>>>> it for
>>>>> our different future purpose.
>>>>>
>>>>> ok, a bit confused, but it's late night and I'm tired and  
>>>>> moreover the
>>>>> project is on its start up.
>>>>>
>>>>> I'll try to explain better details regarding DNA very soon, as  
>>>>> soon as I
>>>>> finished my design.
>>>>>
>>>>> bye
>>>>> S.
>>>>> _______________________________________________
>>>>> dna-dev mailing list
>>>>> dna-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/dna-dev
>>>>
>>>> _______________________________________________
>>>> dna-dev mailing list
>>>> dna-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/dna-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Michael D Neale
>>> home: www.michaelneale.net
>>> blog: michaelneale.blogspot.com
>>
>>
>
>
>
> -- 
> Michael D Neale
> home: www.michaelneale.net
> blog: michaelneale.blogspot.com