<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>Hi All,<br>A number of interesting ideas appeared in recent dna-dev digest emails. While I'm not deleting my e-mails but I suppose I'm not the only one who found it difficult to manage our design minutes and proposals in e-mails.<br><br>May I suggest something (as it also has being pointed out by Randall in our discussions about JDBC graphs)?<br><br>It would be nice to see <span style="font-weight: bold;">summary of your design proposals/ideas as</span> <span style="font-weight: bold;">a JIRA tickets</span> for future releases OR as <span style="font-weight: bold;">comments to existing tickets </span>(where related/existed) <span style="font-weight: bold;">PLUS</span> <span style="font-weight: bold;">links to your WIKI with details</span> - so your ideas don't get lost in e-mail
threads. And we can vote on these tickets and understand more about priorities and future plans for components. Your <span style="font-weight: bold;">detailed proposals and SDD</span> can be managed by <a href="http://jboss.org/community/community/wiki"><span style="font-weight: bold;">JBoss Wiki</span></a>. JIRA is a good place to record/track progress of bugs and new feature requests, and Wiki is a good place for our collaboration and ideas. <br><br>What do you think?<br><br><br>Best regards, <br> Sergiy<br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> "dna-dev-request@lists.jboss.org" <dna-dev-request@lists.jboss.org><br><b><span style="font-weight: bold;">To:</span></b> dna-dev@lists.jboss.org<br><b><span
style="font-weight: bold;">Sent:</span></b> Friday, 21 November, 2008 4:00:06 AM<br><b><span style="font-weight: bold;">Subject:</span></b> dna-dev Digest, Vol 8, Issue 14<br></font><br>Send dna-dev mailing list submissions to<br> <a ymailto="mailto:dna-dev@lists.jboss.org" href="mailto:dna-dev@lists.jboss.org">dna-dev@lists.jboss.org</a><br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> <a href="https://lists.jboss.org/mailman/listinfo/dna-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/dna-dev</a><br>or, via email, send a message with subject or body 'help' to<br> <a ymailto="mailto:dna-dev-request@lists.jboss.org" href="mailto:dna-dev-request@lists.jboss.org">dna-dev-request@lists.jboss.org</a><br><br>You can reach the person managing the list at<br> <a ymailto="mailto:dna-dev-owner@lists.jboss.org"
href="mailto:dna-dev-owner@lists.jboss.org">dna-dev-owner@lists.jboss.org</a><br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of dna-dev digest..."<br><br><br>Today's Topics:<br><br> 1. Re: SOA/Enterprise project using DNA (Randall Hauch)<br> 2. Re: SOA/Enterprise project using DNA (Stefano Maestri)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Thu, 20 Nov 2008 01:10:28 -0600<br>From: Randall Hauch <<a ymailto="mailto:rhauch@redhat.com" href="mailto:rhauch@redhat.com">rhauch@redhat.com</a>><br>Subject: Re: [dna-dev] SOA/Enterprise project using DNA<br>To: Michael Neale <<a ymailto="mailto:michael.neale@gmail.com" href="mailto:michael.neale@gmail.com">michael.neale@gmail.com</a>>, JBoss DNA<br> <<a ymailto="mailto:dna-dev@lists.jboss.org"
href="mailto:dna-dev@lists.jboss.org">dna-dev@lists.jboss.org</a>><br>Message-ID: <<a ymailto="mailto:B8CF0E86-E60A-4A1B-BBC6-4EAB6BE9F09B@redhat.com" href="mailto:B8CF0E86-E60A-4A1B-BBC6-4EAB6BE9F09B@redhat.com">B8CF0E86-E60A-4A1B-BBC6-4EAB6BE9F09B@redhat.com</a>><br>Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes<br><br>I'm also working on a connector that stores the graph in a DB using <br>Hibernate. It's not complete, so I don't have any numbers yet. But <br>it's coming along nicely, and I did try to solve some of the problems <br>with how JR persistence works.<br><br>On Nov 19, 2008, at 11:50 PM, Michael Neale wrote:<br><br>> that sounds ideal. I know myself and others are not entirely<br>> comfortable with jackrabbit - particularly the way it stores thing in<br>> RDBMS (although if we are using jboss cache and its persistence - I am<br>> not sure if we will do much better then
blob storage??).<br>><br>> On Thu, Nov 20, 2008 at 3:05 PM, Randall Hauch <<a ymailto="mailto:rhauch@redhat.com" href="mailto:rhauch@redhat.com">rhauch@redhat.com</a>> <br>> wrote:<br>>> Actually, I'm hoping that we can support binary property values <br>>> (which is<br>>> actually where JCR stores file content, but you know that :-) in <br>>> memory<br>>> mapped (direct) buffers. That way, they don't take up any memory. <br>>> Plus, by<br>>> using federation and a file system connector, we could store these <br>>> large<br>>> files on the file system and just handle the "references" as property<br>>> values, opening a stream to the underlying only when required. Of <br>>> course,<br>>> you're app would have to pay the price for streaming gigabytes of<br>>> information. :-)<br>>><br>>> How does this
sound?<br>>><br>>> Best regards,<br>>><br>>> Randall<br>>><br>>> On Nov 19, 2008, at 9:09 PM, Michael Neale wrote:<br>>><br>>>> For our SOA repository, and rules - its possible we are looking at<br>>>> large single artifacts, as well as many small ones (which kind of<br>>>> stretch most JCR implementations). One idea floated is to (possibly)<br>>>> one day store entire machine images (OMG !!!) in the repository<br>>>> (obviously in memory will not work in that case !). But its hard to<br>>>> nail things down isn't it...<br>>>><br>>>> On Thu, Nov 20, 2008 at 7:21 AM, Randall Hauch <<a ymailto="mailto:rhauch@redhat.com" href="mailto:rhauch@redhat.com">rhauch@redhat.com</a>> <br>>>> wrote:<br>>>>><br>>>>> Stefano, this sounds great! Personally, I really like to hear <br>>>>>
these<br>>>>> kinds<br>>>>> of use cases and scenarios. It's always important to know <br>>>>> whether we're<br>>>>> working on the "right" set of features. So keep these use cases <br>>>>> coming!<br>>>>><br>>>>> And, please feel free to suggest or discuss features that might be<br>>>>> useful,<br>>>>> too. For example, do you think JCR versioning will be an <br>>>>> important part<br>>>>> of<br>>>>> your approach, or will you implement your own approach to managing<br>>>>> history<br>>>>> by designing the hierarchy to handle it? Also, do you have an <br>>>>> idea about<br>>>>> how much information the repository will store (perhaps broken <br>>>>> down by %<br>>>>>
in<br>>>>> uploaded files, and about how big those files will each be).<br>>>>><br>>>>> Best regards,<br>>>>><br>>>>> Randall<br>>>>><br>>>>> On Nov 18, 2008, at 3:34 PM, Stefano Maestri wrote:<br>>>>><br>>>>>> Hi all,<br>>>>>> as said in a previous post I'm going to start a SOA/Enterprise <br>>>>>> project<br>>>>>> using DNA for an important part of the project.<br>>>>>> I'm finishing the design of the whole application, but I can <br>>>>>> describe<br>>>>>> here the main idea and how DNA will be related.<br>>>>>><br>>>>>> In a nutshell we are SOAfing a complex system of a customer<br>>>>>> (J2EE+.NET+Oracle mainly, with external partner and provider <br>>>>>> with
SOAP<br>>>>>> service and/or custom legacy services).<br>>>>>> The system use a lot of data stored in various resources (mainly<br>>>>>> relationl DB, but also someone provided from partner services). <br>>>>>> Some<br>>>>>> code (in all languages) apply business rules to this data and <br>>>>>> transform<br>>>>>> it in a some enrich information (information=data+Business rules).<br>>>>>> Aggregating this data we build a final report to client that is <br>>>>>> the<br>>>>>> final product.<br>>>>>> As said we are moving to SOA and we are identifying services and<br>>>>>> aggregation of them. The area where DNA could be very useful is <br>>>>>> solving<br>>>>>> the problem of keeping track of information during
time.<br>>>>>> IOW we are asked to be able to provide not only current <br>>>>>> information, but<br>>>>>> also information related to a particular moment (remember <br>>>>>> information<br>>>>>> for us= data + business rules).<br>>>>>> The system (or better a lot of service provider we are <br>>>>>> considering part<br>>>>>> of the system) haven't ability to keep data or bsiness rules <br>>>>>> history, so<br>>>>>> we have to store in some other places answer to be able to <br>>>>>> retrive them<br>>>>>> in future.<br>>>>>> Here DNA could help us: the basic idea is to use JBossESB as <br>>>>>> integration<br>>>>>> layer where a MessageStore could store messages into DNA where
<br>>>>>> we can<br>>>>>> apply different sequencers to extract information and organize <br>>>>>> it for<br>>>>>> our different future purpose.<br>>>>>><br>>>>>> ok, a bit confused, but it's late night and I'm tired and <br>>>>>> moreover the<br>>>>>> project is on its start up.<br>>>>>><br>>>>>> I'll try to explain better details regarding DNA very soon, as <br>>>>>> soon as I<br>>>>>> finished my design.<br>>>>>><br>>>>>> bye<br>>>>>> S.<br>>>>>> _______________________________________________<br>>>>>> dna-dev mailing list<br>>>>>> <a ymailto="mailto:dna-dev@lists.jboss.org" href="mailto:dna-dev@lists.jboss.org">dna-dev@lists.jboss.org</a><br>>>>>> <a
href="https://lists.jboss.org/mailman/listinfo/dna-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/dna-dev</a><br>>>>><br>>>>> _______________________________________________<br>>>>> dna-dev mailing list<br>>>>> <a ymailto="mailto:dna-dev@lists.jboss.org" href="mailto:dna-dev@lists.jboss.org">dna-dev@lists.jboss.org</a><br>>>>> <a href="https://lists.jboss.org/mailman/listinfo/dna-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/dna-dev</a><br>>>>><br>>>><br>>>><br>>>><br>>>> --<br>>>> Michael D Neale<br>>>> home: www.michaelneale.net<br>>>> blog: michaelneale.blogspot.com<br>>><br>>><br>><br>><br>><br>> -- <br>> Michael D Neale<br>> home: www.michaelneale.net<br>> blog: michaelneale.blogspot.com<br><br><br><br>------------------------------<br><br>Message:
2<br>Date: Thu, 20 Nov 2008 15:58:03 +0100<br>From: Stefano Maestri <<a ymailto="mailto:stefano.maestri@javalinux.it" href="mailto:stefano.maestri@javalinux.it">stefano.maestri@javalinux.it</a>><br>Subject: Re: [dna-dev] SOA/Enterprise project using DNA<br>To: JBoss DNA <<a ymailto="mailto:dna-dev@lists.jboss.org" href="mailto:dna-dev@lists.jboss.org">dna-dev@lists.jboss.org</a>><br>Message-ID: <<a ymailto="mailto:49257AFB.7050207@javalinux.it" href="mailto:49257AFB.7050207@javalinux.it">49257AFB.7050207@javalinux.it</a>><br>Content-Type: text/plain; charset=ISO-8859-1<br><br><br>Randall Hauch wrote on 19/11/08 21:21:<br>><br>> And, please feel free to suggest or discuss features that might be<br>> useful, too. <br>The feature I'd like to see in a next future, not necessary for 0.4 of<br>course, is write connectors for graph api on DB and maybe on a<br>distributed storage (like hadoop). We will have a lot of data here,
see<br>below.<br>> For example, do you think JCR versioning will be an important part of<br>> your approach, or will you implement your own approach to managing<br>> history by designing the hierarchy to handle it?<br>No it isn't for our impl. What we are going to do is to keep a snapshot<br>of service responses linked to a particular user request. We keep of<br>course accounting of user requests and we will use the primary key of<br>accounting system to keep versioning. (I hope I've been sufficient clear<br>in my explanation, if not just shout :) )<br>What we could need, not in the fisrt step of the project anyway, is<br>analyzer to extract different views of data already saved in JCR with a<br>particular structure. JCR is good because infos are already organized in<br>the way we will read them, but I'm not sure we will get perfect fit of<br>our needs at fist shot. So I immagine analyzers a way to re-organize JCR<br>in different manner
(better).<br>> Also, do you have an idea about how much information the repository<br>> will store (perhaps broken down by % in uploaded files, and about how<br>> big those files will each be).<br>It is incremental increasing of course. Not a precise idea since we are<br>reviewing all the system to go to service. But we expect 1 terabyte in<br>18/24 months based on the experience of data we are storing on a DB. We<br>have a DB of pure data of 5 TB and we have an increasing of about 0.7<br>TB/year. We are not moving all data on JCR, but service data are more<br>expensive than pure datas....well it isn't a precise prevision...I'll be<br>more precise later in the project.<br><br>Bye<br>S.<br><br><br><br>------------------------------<br><br>_______________________________________________<br>dna-dev mailing list<br><a ymailto="mailto:dna-dev@lists.jboss.org" href="mailto:dna-dev@lists.jboss.org">dna-dev@lists.jboss.org</a><br><a
href="https://lists.jboss.org/mailman/listinfo/dna-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/dna-dev</a><br><br><br>End of dna-dev Digest, Vol 8, Issue 14<br>**************************************<br></div></div></div><br>
<hr size=1> Make the switch to the world's best email.
<a href="http://au.rd.yahoo.com/mail/taglines/au/mail/default/*http://au.yahoo.com/y7mail">Get Yahoo!7 Mail</a>.</body></html>