[dna-dev] SOA/Enterprise project using DNA
Michael Neale
michael.neale at gmail.com
Thu Nov 20 00:50:51 EST 2008
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
More information about the dna-dev
mailing list