From einstein at mangala-server.com Tue Jun 3 02:56:48 2008 From: einstein at mangala-server.com (einstein at mangala-server.com) Date: 3 Jun 2008 02:56:48 +0100 Subject: [einstein-dev] Einstein Update: 3rd June 2008 Message-ID: !Welcome to this week's Einstein newsletter {maketoc} !!Quote of the Week "Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer." __- Fred Brooks__ !!A break from tradition No interesting articles this week just a link to the [http://einstein.codecauldron.org/tw/releases/einstein-0.1-bin.zip|0.1 (Uber-Experimental)] release. This is highly experimental code so don't expect miracles. It is really for those of you who are curious to take a look at some examples compile and run them. Beyond that just let me know what goes wrong and that will be your first contribution to the community. :: {img src=/tw/e_images/download-200x149.jpg link=http://einstein.codecauldron.org/tw/releases/einstein-0.1-bin.zip} :: Next week I'll return to form with more information on existing and planned features. !!Get involved. Plenty of Einstein has already been sketched out but it's still very early days on the project, so if you are interested in Einstein and the way it works and would like to help turn it into the definitive means for building distributed systems ... then come and join us; join the list dev-subscribe at einstein.codecauldron.org and say hello. __Right now I'm looking for some partners in crime, if you're interested in programming languages, distributed systems or enterprise architecture feel free to drop me a line directly : neil.ellis at mangala.co.uk __. I regularly add new articles on the website, also check out the downloads page for the latest downloadable PDFs and presentations. !!A word from our sponsors ... Paremus have produced a fantastic distributed, SCA configured, OSGi based distributed application platform which supports some great features such as autonomic self-healing, self-scaling, distributed registry and distributed messaging. The full product is commercial and is known as Infiniflow, please feel free to drop them a line at info at paremus.com. If you are more interested in the technical side of the product or just want to take a look at how it works then drop by http://newton.codecauldron.org . All the best until next time. Neil Ellis project:Einstein -- You can unsubscribe from this newsletter following this link: http://einstein.mangala-server.com/tw/tiki-newsletters.php?unsubscribe=087db851b4bc17d69e7a204f7129c225 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://einstein.codecauldron.org/pipermail/dev/attachments/20080603/5c105bd6/attachment.html From einstein at mangala-server.com Tue Jun 3 02:58:31 2008 From: einstein at mangala-server.com (einstein at mangala-server.com) Date: 3 Jun 2008 02:58:31 +0100 Subject: [einstein-dev] (FIXED) Einstein Update: 3rd June 2008 Message-ID: !Welcome to this week's Einstein newsletter {maketoc} !!Quote of the Week "Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer." __- Fred Brooks__ !!A break from tradition No interesting articles this week just a link to the [http://einstein.codecauldron.org/tw/releases/einstein-0.1-bin.zip|0.1 (Uber-Experimental)] release. This is highly experimental code so don't expect miracles. It is really for those of you who are curious to take a look at some examples compile and run them. Beyond that just let me know what goes wrong and that will be your first contribution to the community. :: {img src=http://einstein.codecauldron.org/tw/e_images/download-200x149.jpg link=http://einstein.codecauldron.org/tw/releases/einstein-0.1-bin.zip} :: Next week I'll return to form with more information on existing and planned features. !!Get involved. Plenty of Einstein has already been sketched out but it's still very early days on the project, so if you are interested in Einstein and the way it works and would like to help turn it into the definitive means for building distributed systems ... then come and join us; join the list dev-subscribe at einstein.codecauldron.org and say hello. __Right now I'm looking for some partners in crime, if you're interested in programming languages, distributed systems or enterprise architecture feel free to drop me a line directly : neil.ellis at mangala.co.uk __. I regularly add new articles on the website, also check out the downloads page for the latest downloadable PDFs and presentations. !!A word from our sponsors ... Paremus have produced a fantastic distributed, SCA configured, OSGi based distributed application platform which supports some great features such as autonomic self-healing, self-scaling, distributed registry and distributed messaging. The full product is commercial and is known as Infiniflow, please feel free to drop them a line at info at paremus.com. If you are more interested in the technical side of the product or just want to take a look at how it works then drop by http://newton.codecauldron.org . All the best until next time. Neil Ellis project:Einstein -- You can unsubscribe from this newsletter following this link: http://einstein.mangala-server.com/tw/tiki-newsletters.php?unsubscribe=087db851b4bc17d69e7a204f7129c225 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://einstein.codecauldron.org/pipermail/dev/attachments/20080603/7332921c/attachment.html From neil.ellis at mangala.co.uk Wed Jun 4 01:12:29 2008 From: neil.ellis at mangala.co.uk (Neil Ellis) Date: Wed, 4 Jun 2008 01:12:29 +0100 Subject: [einstein-dev] OSGi integration Message-ID: One of my key tasks for release 0.2 is going to be OSGi integration so here are some of my thoughts in no particular order: What license model should a language actually be, the compiler definitely AGPL, the runtimes maybe? If I have to integrate with an OSGi container for the compiler and runtime why shouldn't I just integrate with Newton? Dave, specifically you've been working on making Newton lightweight and embedded I believe, is it lightweight enough to act as an almost vanilla OSGi container. This way the actual compiler can use it to load up the plugins, the compiler needs to have access to the same bundles and registry as the runtime because of the amount of compile time checks done on code. So ideally I'd like to keep the code the same or very similar for the compiler and runtime access to 3rd party plugins. I will need to invert the control with an Einstein script starting up the Newton instance (not the other way round) for a local runtime, is this realistic at the mo, Dave? What is the current release timetable on Newton, obviously I won't work against HEAD/trunk that would be crazy, which release would you recommend I aim for if I go this route? How volatile are the runtime APIs; I currently have no spare bandwidth on Einstein so I really need to get a feel whether I would lose a lot of time integrating now or whether I should stick to vanilla OSGi for now. Is Newton maven-ized , if not what timetable are you working to for this. Sorry the barrage of questions :-) and thanks guys. All the best Neil The Language of the Enterprise? This exciting new Open Source project aims to provide a high level coarse grained programming language for distributed computing. We're looking for talented individuals to join in while we're still at the early stages of development; if you fit the bill then email dev-subscribe at einstein.codecauldron.org now! Tel/Fax: +44 (0) 207 000 1918 | Skype: neilellis | AIM: neilellis at mac.com | Blog: http://web.mac.com/neilellis/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://einstein.codecauldron.org/pipermail/dev/attachments/20080604/e09c1570/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: pastedGraphic.tiff Type: image/tiff Size: 43559 bytes Desc: not available Url : http://einstein.codecauldron.org/pipermail/dev/attachments/20080604/e09c1570/attachment-0001.tiff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2431 bytes Desc: not available Url : http://einstein.codecauldron.org/pipermail/dev/attachments/20080604/e09c1570/attachment-0001.bin From richard.nicholson at paremus.com Wed Jun 4 20:36:43 2008 From: richard.nicholson at paremus.com (Richard Nicholson) Date: Wed, 4 Jun 2008 20:36:43 +0100 Subject: [einstein-dev] OSGi integration In-Reply-To: References: Message-ID: <3DC88C1C-214E-4D30-9294-E705AAA10540@paremus.com> On 4 Jun 2008, at 01:12, Neil Ellis wrote: > One of my key tasks for release 0.2 is going to be OSGi integration > so here are some of my thoughts in no particular order: > > What license model should a language actually be, the compiler > definitely AGPL, the runtimes maybe? Neil - lets chat about the runtime license when I'm back and we sync up next? BTW - when would you like to do that? > > If I have to integrate with an OSGi container for the compiler and > runtime why shouldn't I just integrate with Newton? I'd say so. Newton / Infiniflow are likely to be the first developer exposure and commercial opportunity? > > Dave, specifically you've been working on making Newton lightweight > and embedded I believe, is it lightweight enough to act as an almost > vanilla OSGi container. This way the actual compiler can use it to > load up the plugins, the compiler needs to have access to the same > bundles and registry as the runtime because of the amount of compile > time checks done on code. So ideally I'd like to keep the code the > same or very similar for the compiler and runtime access to 3rd > party plugins. Not sure I understand the first piece of that. Newton is pretty lightweight already. David is currently working on Provisioner upgrades, Rob on the next generation of dependency graphic and internal model. Cannot comment on the second part. Anyone? > > I will need to invert the control with an Einstein script starting > up the Newton instance (not the other way round) for a local > runtime, is this realistic at the mo, Dave? > > What is the current release timetable on Newton, obviously I won't > work against HEAD/trunk that would be crazy, which release would you > recommend I aim for if I go this route? So next major Product release is September - this will include a lot of core newton re-work. Not sure to what degree this will affect you though - again Rob/David - comments? > > How volatile are the runtime APIs; I currently have no spare > bandwidth on Einstein so I really need to get a feel whether I would > lose a lot of time integrating now or whether I should stick to > vanilla OSGi for now. > > Is Newton maven-ized , if not what timetable are you working to for > this. Derek should be close to completing this; i.e. done by the end of this week. > > Sorry the barrage of questions :-) and thanks guys. > > All the best Neil > > > > > > > > The Language of the Enterprise? > > This exciting new Open Source project aims to provide a high level > coarse grained programming language for distributed computing. We're > looking for talented individuals to join in while we're still at the > early stages of development; if you fit the bill then email dev-subscribe at einstein.codecauldron.org > now! > > Tel/Fax: +44 (0) 207 000 1918 | Skype: neilellis | AIM: neilellis at mac.com > | Blog: http://web.mac.com/neilellis/ > > > > Richard Nicholson Chief Executive Officer url: http://www.paremus.com blog: http://adaptevolve.blogspot.com/ Direct: +44 (0) 207 993 4486 Mobile: +44 (0) 797 105 1645 Indirect: +44 (0) 207 936 9098 Fax: +44 (0) 845 127 5999 _______________________________________________________________________ Paremus Limited. Registered in England No. 4181472 Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA Postal Address: 107-111 Fleet Street, London, EC4A 2AB The information transmitted is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. _______________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://einstein.codecauldron.org/pipermail/dev/attachments/20080604/cf44c852/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: home_logo_paremus.gif Type: image/gif Size: 1951 bytes Desc: not available Url : http://einstein.codecauldron.org/pipermail/dev/attachments/20080604/cf44c852/attachment-0001.gif From neil.ellis at mangala.co.uk Thu Jun 5 11:27:52 2008 From: neil.ellis at mangala.co.uk (Neil Ellis) Date: Thu, 5 Jun 2008 11:27:52 +0100 Subject: [einstein-dev] OSGi integration In-Reply-To: <3DC88C1C-214E-4D30-9294-E705AAA10540@paremus.com> References: <3DC88C1C-214E-4D30-9294-E705AAA10540@paremus.com> Message-ID: On 4 Jun 2008, at 20:36, Richard Nicholson wrote: > > On 4 Jun 2008, at 01:12, Neil Ellis wrote: > >> One of my key tasks for release 0.2 is going to be OSGi integration >> so here are some of my thoughts in no particular order: >> >> What license model should a language actually be, the compiler >> definitely AGPL, the runtimes maybe? > > Neil - lets chat about the runtime license when I'm back and we sync > up next? BTW - when would you like to do that? Suggest any day from 12th to 20th, since I'll probably round trip on the day would ideally prefer 1pm start. Let me know if there's a day when that works. > >> >> If I have to integrate with an OSGi container for the compiler and >> runtime why shouldn't I just integrate with Newton? > > I'd say so. Newton / Infiniflow are likely to be the first developer > exposure and commercial opportunity? Indeed, I'm just trying to figure out if coupling the whole of Einstein to Newton immediately is the way forward or should I just couple to OSGi. Obviously when it comes to a distributed runtime Newton is without question the first choice .. I'm just trying to figure out when that coupling begins (compiler, core runtime, distributed runtime etc). >> >> Dave, specifically you've been working on making Newton lightweight >> and embedded I believe, is it lightweight enough to act as an >> almost vanilla OSGi container. This way the actual compiler can use >> it to load up the plugins, the compiler needs to have access to the >> same bundles and registry as the runtime because of the amount of >> compile time checks done on code. So ideally I'd like to keep the >> code the same or very similar for the compiler and runtime access >> to 3rd party plugins. > > Not sure I understand the first piece of that. Newton is pretty > lightweight already. David is currently working on Provisioner > upgrades, Rob on the next generation of dependency graphic and > internal model. > I mean lightweight in terms of not starting any distributed parts up, being embedded etc, lightweight enough to be part of the actual compiler (which means very lightweight); not just a runtime. > Cannot comment on the second part. Anyone? > If someone could that would be great >> >> I will need to invert the control with an Einstein script starting >> up the Newton instance (not the other way round) for a local >> runtime, is this realistic at the mo, Dave? >> >> What is the current release timetable on Newton, obviously I won't >> work against HEAD/trunk that would be crazy, which release would >> you recommend I aim for if I go this route? > > So next major Product release is September - this will include a lot > of core newton re-work. Not sure to what degree this will affect you > though - again Rob/David - comments? If I integrate Newton in the core-runtime (i.e. not just distributed) this would mean tight coupling and would I'm sure mean changes would affect Einstein. It still seems a toss-up for me whether to stick to using vanilla OSGi like Felix for the compiler and core runtime or to use Newton for all parts. I'm thinking that I don't want to bloat the compiler runtime but having CDS (for example) for all runtimes for example would seem to be useful. However would that mean that potential uses of Einstein would be restricted by that tight coupling ? > >> >> How volatile are the runtime APIs; I currently have no spare >> bandwidth on Einstein so I really need to get a feel whether I >> would lose a lot of time integrating now or whether I should stick >> to vanilla OSGi for now. >> >> Is Newton maven-ized , if not what timetable are you working to for >> this. > > Derek should be close to completing this; i.e. done by the end of > this week. Great stuff. > >> >> Sorry the barrage of questions :-) and thanks guys. > > > > >> >> All the best Neil >> >> >> >> >> >> >> >> The Language of the Enterprise? >> >> This exciting new Open Source project aims to provide a high level >> coarse grained programming language for distributed computing. >> We're looking for talented individuals to join in while we're still >> at the early stages of development; if you fit the bill then email dev-subscribe at einstein.codecauldron.org >> now! >> >> Tel/Fax: +44 (0) 207 000 1918 | Skype: neilellis | AIM: neilellis at mac.com >> | Blog: http://web.mac.com/neilellis/ >> >> >> >> > > Richard Nicholson > Chief Executive Officer > > > > > url: http://www.paremus.com > blog: http://adaptevolve.blogspot.com/ > > Direct: +44 (0) 207 993 4486 > Mobile: +44 (0) 797 105 1645 > Indirect: +44 (0) 207 936 9098 > Fax: +44 (0) 845 127 5999 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://einstein.codecauldron.org/pipermail/dev/attachments/20080605/fd36d101/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2431 bytes Desc: not available Url : http://einstein.codecauldron.org/pipermail/dev/attachments/20080605/fd36d101/attachment-0001.bin From neil.ellis at mangala.co.uk Thu Jun 5 16:09:37 2008 From: neil.ellis at mangala.co.uk (Neil Ellis) Date: Thu, 5 Jun 2008 16:09:37 +0100 Subject: [einstein-dev] TESTING Message-ID: test -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2431 bytes Desc: not available Url : http://einstein.codecauldron.org/pipermail/dev/attachments/20080605/2dda16b1/attachment.bin From susan.forshaw at ricston.com Thu Jun 5 16:11:25 2008 From: susan.forshaw at ricston.com (Susan Forshaw) Date: Thu, 5 Jun 2008 17:11:25 +0200 Subject: [einstein-dev] TESTING In-Reply-To: References: Message-ID: <003401c8c71e$7280f760$6802a8c0@SusanNB> works Thanks Susan Susan Forshaw, Operations Manager | Tel: +356 21334457 | Fax: +356 21 334156 ricston Ltd., Lincoln, 7 Ferdinand Grech Street, Lija LJA1142, MALTA email: susan.forshaw at ricston.com | web:ricston.com -----Original Message----- From: dev-bounces at einstein.codecauldron.org [mailto:dev-bounces at einstein.codecauldron.org] On Behalf Of Neil Ellis Sent: 05 June 2008 17:10 To: dev at einstein.codecauldron.org Subject: [einstein-dev] TESTING test From neil.ellis at mangala.co.uk Thu Jun 5 16:18:18 2008 From: neil.ellis at mangala.co.uk (Neil Ellis) Date: Thu, 5 Jun 2008 16:18:18 +0100 Subject: [einstein-dev] TESTING In-Reply-To: <003401c8c71e$7280f760$6802a8c0@SusanNB> References: <003401c8c71e$7280f760$6802a8c0@SusanNB> Message-ID: Thanks Susan I've been having problems receiving emails on some of the codecauldron dev lists so I was double checking I could receive email on all the lists. Ta Neil On 5 Jun 2008, at 16:11, Susan Forshaw wrote: > works > > > > Thanks > Susan > > Susan Forshaw, Operations Manager | Tel: +356 21334457 | Fax: +356 > 21 334156 > ricston Ltd., Lincoln, 7 Ferdinand Grech Street, Lija LJA1142, MALTA > email: susan.forshaw at ricston.com | web:ricston.com > > -----Original Message----- > From: dev-bounces at einstein.codecauldron.org > [mailto:dev-bounces at einstein.codecauldron.org] On Behalf Of Neil Ellis > Sent: 05 June 2008 17:10 > To: dev at einstein.codecauldron.org > Subject: [einstein-dev] TESTING > > test > > _______________________________________________ > Dev mailing list > Dev at einstein.codecauldron.org > http://einstein.codecauldron.org/mailman/listinfo/dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2431 bytes Desc: not available Url : http://einstein.codecauldron.org/pipermail/dev/attachments/20080605/e2b2a75c/attachment.bin From susan.forshaw at ricston.com Thu Jun 5 17:59:57 2008 From: susan.forshaw at ricston.com (Susan Forshaw) Date: Thu, 5 Jun 2008 18:59:57 +0200 Subject: [einstein-dev] TESTING In-Reply-To: References: <003401c8c71e$7280f760$6802a8c0@SusanNB> Message-ID: <001101c8c72d$976c1dc0$2463cb58@SusanNB> Hi Neil, Good to see its working ok for you! Thanks Susan Susan Forshaw, Operations Manager | Tel: +356 21334457 | Fax: +356 21 334156 ricston Ltd., Lincoln, 7 Ferdinand Grech Street, Lija LJA1142, MALTA email: susan.forshaw at ricston.com | web:ricston.com -----Original Message----- From: dev-bounces at einstein.codecauldron.org [mailto:dev-bounces at einstein.codecauldron.org] On Behalf Of Neil Ellis Sent: 05 June 2008 17:18 To: EinsteinDev Subject: Re: [einstein-dev] TESTING Thanks Susan I've been having problems receiving emails on some of the codecauldron dev lists so I was double checking I could receive email on all the lists. Ta Neil On 5 Jun 2008, at 16:11, Susan Forshaw wrote: > works > > > > Thanks > Susan > > Susan Forshaw, Operations Manager | Tel: +356 21334457 | Fax: +356 > 21 334156 > ricston Ltd., Lincoln, 7 Ferdinand Grech Street, Lija LJA1142, MALTA > email: susan.forshaw at ricston.com | web:ricston.com > > -----Original Message----- > From: dev-bounces at einstein.codecauldron.org > [mailto:dev-bounces at einstein.codecauldron.org] On Behalf Of Neil Ellis > Sent: 05 June 2008 17:10 > To: dev at einstein.codecauldron.org > Subject: [einstein-dev] TESTING > > test > > _______________________________________________ > Dev mailing list > Dev at einstein.codecauldron.org > http://einstein.codecauldron.org/mailman/listinfo/dev From einstein at mangala-server.com Sat Jun 14 20:45:55 2008 From: einstein at mangala-server.com (einstein at mangala-server.com) Date: 14 Jun 2008 20:45:55 +0100 Subject: [einstein-dev] Einstein Update: 14th June 2008 Message-ID: !Welcome to this week's Einstein newsletter {maketoc} !!Quote of the Week ~pp~ A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: "How long will it take to design this system if I assign five programmers to it?'' "It will take one year,'' said the master promptly. "But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?'' The master programmer frowned. "In that case, it will take two years.'' "And what if I assign a hundred programmers to it?'' The master programmer shrugged. "Then the design will never be completed,'' he said. ~/pp~ __ The Tao of Programming __ !!This Week Well I have been busy OSGi-ing up Einstein these last few days, which has also involved some general refactoring. OSGi will be the base mechanism for the support of plugins in Einstein, I'll be adding certification, isolation and risk management on top later on. Amongst OSGi's many useful features is the support for Dynamic Services in Release 4, this is the basis for dynamic plugins. Later on we'll be building onto the OSGi support to provide distributed OSGi style functionality using Newton. The initial work on the type system will happen over the next month with another experimental release due in mid July. This newsletter is dedicated to the features currently under design and may hopefully also get your gray matter going and stimulate a few ideas of your own. !!Event Physics - Balls don't know how to bounce. Event Physics is a replacement for the OO-centric view of systems. In Object-Orientation we ascribe all knowledge of behavior to objects, yet balls do not know how to bounce. Bouncing is in fact described by a set of physical laws. So how does event physics work, it works by describing the laws of a universe, a universe is where a set of laws apply. So we describe each law at a time and combine them to form a universe. Of course each law has exceptions! It may look just like a rules engine, but beware, the goals are a little different. A rules engine aims to be declerative, whereas we are mearly describing cause and effect literally. Laws are more a combination of aspects and rules, they are rules that could be applied at any point in processing, for example on a transition of an invoice from Unpaid to Paid occuring. Event physics does __not__ preclude objects having behavior, because there is knowledge that will always be local to the object, this is the mechanics of the object and we'll discuss mechanics in a bit. ~pp~ law PaymentInteraction { //You'd never do this in reality! apply to Anything; intersection of Payable and Payment causes { .... }; intersection of Payment and Cancellation causes { ... }; transition from Unpaid to Paid causes { .... }; //Laws allow us to say that some conditions may not be allowed //even if they are described on the relevant type, in this case //even if Paid to Unpaid is a valid transition for a type, this //law forbids it. disallow transition from Paid to Unpaid; disallow intersection of Payment and Payment; } law InvoiceTransition { //'only' signifies not to apply to 'subclasses' of Invoice. apply to Invoice only; transition from Unpaid to Paid causes { }; } universe PaymentProcessingRealm { apply law PaymentInteraction except when ...; apply law InverseTransition except when ...; } ~/pp~ !!Types, Mechanics, Structure and Classification !!!Theory A type in Einstein is a description of the type of something, for example this object is a bottle. Bottles are made of glass and can be broken. It's mechanics describes how the message can pass through state changes. If we have a law that describes that a hammer hitting a bottle causes it to break, the mechanics describe __how__ it breaks. The structure of the bottle is that it is made of glass and has a bottle top and contains a liquid of some sort. A classification is a mixture of mechanics, structure and type, so we can say this is a coke bottle and this is how it breaks. Classifications support multiple types, structures and mechanics however no overlaps are allowed i.e. a bottle can only break one way. Resources are specified with classifications, not types, mechanics or structures otherwise types are used for all relationships. Mechanics and structures specify the 'HOW' of a message the type describes the 'WHAT'. Types, behaviors, structures and classifications are all overlays in Einstein, that is they are overlayed onto an already created message; the compiler can then follow the usage of types through Einstein's code to determine whether any rules have been violated. As you will see, they can be darn stringent rules too! The structure and mechanics will then be used (in conjunction with prevailing laws) to decide how interactions and transitions occur. The equivalent to Java's __Object__ is Einstein's __Anything__ type, if no type is given for a resource it is assumed to be __Anything__ (this may be changed before release 1.0). __Anything__ has as it's antonym __Nothing__ which means that no message can have this type. Types restrict messages, they are a set of assertions. Structures provide additional structural information about a message they turn a black box into an opaque one. Mechanics describe how messages change state. Classifications attempt to categorize a message by combining type, structure and behavior information and are used when describing the input and output of resources. !!Links !!!Theory Links provide association between events/messages; a link states what part of a message contains the information to correlate with another message and where in the other message the correlation information lies. Links are in fact tuple relationships, meaning that they are always one to many, they are not bi-directional. Links are then used in correlations !!!Code ~pp~ type InvoiceType { link Payment invoiceId; } structure InvoiceStructure { link Payment from "xpath://id" to "xpath://invoiceId" as invoiceId; } class Invoice has structure InvoiceStructure has type InvoiceType; structure PaymentStructure { link Invoice from "xpath://invoiceId to "xpath://id as invoiceId"; } class Payment has structure PaymentStructure; resource (in:Nothing, out:Invoice) "jms://receive.invoices" invoices; resource (in:Payment, out:Payment) Payment "jms://payments" payments; listen invoices { //this searches for a matching payment (invoiceId is a link defined on the Payment structure) //correlation is a resource specific operation. correlate with payments using invoiceId; }; ~/pp~ !!Intersections !!!Theory Intersections occur when two or more events collide, they can result in transitions, splits, combination, creation or destruction. An intersection when defined applies to all instances of the types it describes __within__ the scope it exists in (including Systems and Applications when they are added). !!!Code ~pp~ law PaymentInteraction { //You'd never do this in reality! apply to Anything; intersection of Payable and Payment causes { execute "java:org.me.MyPaymentService"; . }; transition from Unpaid to Paid causes { .... }; } resource (in:Nothing, out:Invoice) "jms://receive.invoices" invoices; resource (in:Payment, out:Payment) Payment "jms://payments" payments; listen invoices { //this searches for a matching payment (invoiceId is a link defined on the Payment type) //correlation is a resource specific operation. correlate with payments using invoiceId; //now we have a tuple with two values so all we need to say is: intersect; }; ~/pp~ Now the the invoice and it's correlated payment intersect each other via the MyInvoicePaymentService !!States !!!Theory States need to be explained so that we can cover transitions. States are a form of dynamic invariant (okay so that's a contradiction in terms) placed on a message, they say what states can be valid and what the pre-conditions are for the states. They overlay a Finite State Machine onto a message. !!!!Code ~pp~ structure MyInvoiceStructure { //Now we list invariants with their exceptions valid "groovy:lastChangedBy != null" unless "groovy:state == null"; //We can specify one or more different query URIs and this can be used for general Design By Contract checking. //NB: Initial is a special state that is looked for when messages are created and are not part of a transition. state Initial ("groovy:state == null", "groovy:owner != null"); state Stored "groovy:state == 'STORED'"; state Sent "groovy:state == 'SENT'"; state Paid "groovy:state == 'PAID'"; link Payment from "xpath://id" to "xpath://invoiceId" as invoiceId; } type InvoiceType { //These are not structural validations, they decide whether this is an InvoiceType //or not, be careful not to place structural information here. valid "instanceof:org.me.MyInvoiceInterface"; //NB: Initial is a special state that is looked for when messages are created and are not part of a transition. //It never needs to be specified in a type; states Stored, Sent, Paid; //And that link from earlier link Payment invoiceId; } ~/pp~ !!!Transitions !!!!Theory Every operation in Einstein that passes the payload to a resource that is all read, write and execute operations assume that they are getting a new message in return. If however what is actually happening is that the message is being moved from one state to another then we need to specify that it is a transition. Remember no mutations occur in Einstein, so we're actually saying that we're creating a new message which is __logically__ the same as the old message but with a new state. A transition will take any message as input but the type of the message that exits the block must be the same as the one which entered. Note that this means it makes no sense to have a tuple block as it's argument. The message at the end will be examined to make sure the transition that occurred is valid for that type. If a transition block is not explicitly placed in code an error will occur if a message is returned which is not in a valid __initial__ state for it's type. Transitions defined in a mechanics of a classification can be explicitly invoked. !!!!Code ~pp~ type InvoiceType { //These are not structural validations, they decide whether this is an InvoiceType //or not, be careful not to place structural information here. valid "instanceof:org.me.MyInvoiceInterface"; //NB: Initial is a special state that is looked for when messages are created and are not part of a transition. //It never needs to be specified in a type; states Stored, Sent, Paid; //Now we list transitions transition Initial => Stored; transition Stored => Sent; transition Stored => Paid; transition Sent => Paid; //And that link from earlier link Payment invoiceId; } transition { execute "java:org.me.MyInvoicePaymentService"; } ~/pp~ We can be a little more explicit with our transition and supply the initial and final states to check for: ~pp~ transition Sent to Paid { execute "java:org.me.MyInvoicePaymentService"; } ~/pp~ Now if we define the mechanics, a type and a class we can use the transitions explicitly: ~pp~ mechanics InvoiceMechanics { //This describes HOW to transition if we are requesting the transition. //What happens when the transition occurs is determined by laws. transition from Stored to Paid using { .... }; } type InvoiceType { states Stored, Sent, Paid; ... transition Stored => Paid; .... } class Invoice has mechanics InvoiceMechanics has type InvoiceType{ .... } //Now we can explicitly cause a transition: resource Invoice "jms://receive.invoices" invoices; resource Payment "jms://payments" payments; listen invoices { //this searches for a matching payment (invoiceId is a link defined on the Payment type) //correlation is a resource specific operation. correlate with payments using invoiceId; //The behavior will now be invoked to make the transition happen //and then perform the associated action. transition Stored to Paid; }; ~/pp~ !!Don't forget You can download the [http://einstein.codecauldron.org/tw/releases/einstein-0.1-bin.zip|0.1 (Uber-Experimental)] release. This is highly experimental code so don't expect miracles. It is really for those of you who are curious to take a look at some examples compile and run them. Beyond that just let me know what goes wrong and that will be your first contribution to the community. :: {img src=http://einstein.codecauldron.org/tw/e_images/download-200x149.jpg link=http://einstein.codecauldron.org/tw/releases/einstein-0.1-bin.zip} :: !!Get involved. Plenty of Einstein has already been sketched out but it's still very early days on the project, so if you are interested in Einstein and the way it works and would like to help turn it into the definitive means for building distributed systems ... then come and join us; join the list dev-subscribe at einstein.codecauldron.org and say hello. __Right now I'm looking for some partners in crime, if you're interested in programming languages, distributed systems or enterprise architecture feel free to drop me a line directly : neil.ellis at mangala.co.uk __. I regularly add new articles on the website, also check out the downloads page for the latest downloadable PDFs and presentations. !!A word from our sponsors ... Paremus have produced a fantastic distributed, SCA configured, OSGi based distributed application platform which supports some great features such as autonomic self-healing, self-scaling, distributed registry and distributed messaging. The full product is commercial and is known as Infiniflow, please feel free to drop them a line at info at paremus.com. If you are more interested in the technical side of the product or just want to take a look at how it works then drop by http://newton.codecauldron.org . All the best until next time. Neil Ellis project:Einstein -- You can unsubscribe from this newsletter following this link: http://einstein.mangala-server.com/tw/tiki-newsletters.php?unsubscribe=087db851b4bc17d69e7a204f7129c225 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://einstein.codecauldron.org/pipermail/dev/attachments/20080614/869dd39e/attachment-0001.html From einstein at mangala-server.com Fri Jun 27 17:51:11 2008 From: einstein at mangala-server.com (einstein at mangala-server.com) Date: 27 Jun 2008 17:51:11 +0100 Subject: [einstein-dev] Einstein Update: 27th June 2008 Message-ID: !Welcome to this week's Einstein newsletter {maketoc} !!Quote of the Week ~pp~ Beware of bugs in the above code; I have only proved it correct, not tried it. - Donald Knuth ~/pp~ !!This Week Well Einstein has taken a back seat over the last week as we have been updating Mule4Newton, however the planning and design of Einstein never stops! So this week I have a short explanation of how Einstein will tackle the problem of inadvertent shared memory access by ensuring immutability. Oh and a quick apology if you try to build the code direct from the Subversion repository, the trunk is curently broken and with a huge refactoring checked out that's not going to change soon. Please checkout the 0.1 release tagged code instead. !!Solving immutability in Einstein !!!The Problem One of the problems I faced very early in Einstein's development was that of guaranteeing thread safe access to messages. The problem is that Java does not provide any mechanism for providing immutable objects or for avoiding aliasing of objects (that is allowing references to inner objects leaking into other messages). Various frameworks and languages have their own approaches; the best approach for Einstein would of course be to modify the JVM but really that's not an option! So what to do? Well with the help of Holger Hoffstatte I was able to step back and look at the bigger picture of Einstein. Information in a distributed system data will usually oscillate between two forms: it's serialized form and it's de-serialized form. If you wish to process sub sets of the data or to easily navigate it you will usually de-serialize from say a byte array to an object graph, later the object graph will be re-serialized to it's byte array form. The serialization and de-serialization will of course vary with the type of application, but it does in fact offer us an opportunity to guarantee immutability. When we de-serialize an object graph we will (unless we have a very dubious serialization mechanism) produce a clean un-aliased graph of objects. Those objects can be mutated or passed around without affecting the serialized form. And that was the clue to solving our problem. So a new concept will be introduced in Einstein, the canonical format of the data will not be the de-serialized form but the serialized form. This will be applied to object graphs, XML, CSVs any data format. While the data is in it's serialized form we will still potentially be able to query/extract if the __Data Model__ supports the query in the serialized form. So even when we've serialized our data we can still do content based routing etc. When we wish to pass the data to a resource the resource is given the serialized data object (not the serialized data mind) and then the resource can decide if it wants to act on the de-serialized form with it's associated penalty. So if the resource is the filesystem or a blob record in a database it will choose not to de-serialized and will persist the serialized form. using the __write(OutputStream)__ method on the serialized object. If the resource acts upon the de-serialized format, say executing a Java class, then it will be passed a virgin copy of the data, the result of any manipulation will then again be serialized. This guarantees that neither aliasing or mutation is an issue. Let me clarify that again as this is the most important point. A clean unaliased graph is passed to a resource (which could be a 'Service') if the resource chooses to return the same graph back after mutating it __it will be treated as a new graph__ thus ensuring the incoming data is immutable. So in other words we are doing __pass by value__ not __pass by reference__. A serialized __DataObject__ can be converted to it's deserialized form with the __deserialize()__ method which is guaranteed to produce an un-aliased object model (i.e. there are no external references to any mutable objects in the graph). Data Models will no longer produce __DataObject__ in their factory model, rather they will return __SerializedDataObject__ instead. __SerializedDataObject__ will have a reduced interface only supporting queries, deserialization and the __write(OutputStream )__ method. It is down to the data models to decide the internal representation of serialized objects, if the underlying model (e.g. Strings) are immutable then they can use the same representation for both, whereas a general object model will store a full serialized object graph. These optimizations made by the __Data Model__ will be key to ensuring we do not sacrifice performance to get what is an essential form of safety. !!!The Cost Well inevitably there is a cost, but we have a balance of costs to look at. While we now certainly incur an overhead every time we wish to work with the full graph we no-longer have any cost involved in going from serialized->de-serialized->serialized as is often the case in distributed software. We can now pass data from node to node without worrying about additional serialization costs since the canonical format is now the serialized form. Also routing and data extraction can be very low cost if the Data Model supports such actions against the serialized form. We no longer have the potential penalties of locking objects instead we use the guaranteed safety of unaliased disposable objects. Since Einstein is primarily coarse grained in nature it's likely that most accesses to the payloads could be performed without full de-serialization. Furthermore the data models themselves can choose to get smart about caching the de-serialized form, especially if it can guarantee the immutability of __every__ object in the graph. If you wish to produce a high performance system using Einstein and have your own mechanisms for optimizing the process of (de)serialization you can write your own Data Model to implement your own conversion from serialized to de-serialized optimized for your needs as long as you guarantee that the de-serialized objects __getValue()__ method returns an unaliased object graph. !!!References Object Aliasing: http://gee.cs.oswego.edu/dl/aliasing/aliasing.html Kilim: http://www.malhar.net/sriram/kilim/ !!Don't forget You can download the [http://einstein.codecauldron.org/tw/releases/einstein-0.1-bin.zip|0.1 (Uber-Experimental)] release. This is highly experimental code so don't expect miracles. It is really for those of you who are curious to take a look at some examples compile and run them. Beyond that just let me know what goes wrong and that will be your first contribution to the community. :: {img src=http://einstein.codecauldron.org/tw/e_images/download-200x149.jpg link=http://einstein.codecauldron.org/tw/releases/einstein-0.1-bin.zip} :: !!Get involved. Plenty of Einstein has already been sketched out but it's still very early days on the project, so if you are interested in Einstein and the way it works and would like to help turn it into the definitive means for building distributed systems ... then come and join us; join the list dev-subscribe at einstein.codecauldron.org and say hello. __Right now I'm looking for some partners in crime, if you're interested in programming languages, distributed systems or enterprise architecture feel free to drop me a line directly : neil.ellis at mangala.co.uk __. I regularly add new articles on the website, also check out the downloads page for the latest downloadable PDFs and presentations. !!A word from our sponsors ... Paremus have produced a fantastic distributed, SCA configured, OSGi based distributed application platform which supports some great features such as autonomic self-healing, self-scaling, distributed registry and distributed messaging. The full product is commercial and is known as Infiniflow, please feel free to drop them a line at info at paremus.com. If you are more interested in the technical side of the product or just want to take a look at how it works then drop by http://newton.codecauldron.org . All the best until next time. Neil Ellis project:Einstein -- You can unsubscribe from this newsletter following this link: http://einstein.mangala-server.com/tw/tiki-newsletters.php?unsubscribe=087db851b4bc17d69e7a204f7129c225 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://einstein.codecauldron.org/pipermail/dev/attachments/20080627/60d9569d/attachment.html From ashish.x.kumar.singh at accenture.com Sun Jun 8 12:49:54 2008 From: ashish.x.kumar.singh at accenture.com (ashish.x.kumar.singh at accenture.com) Date: Sun, 08 Jun 2008 11:49:54 -0000 Subject: [einstein-dev] (no subject) Message-ID: 2day only I came to know about this Thanks & Regards, Ashish Kumar Singh Accenture, India. AIM: ashish3757 * ashish.x.kumar.singh at accenture.com This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://einstein.codecauldron.org/pipermail/dev/attachments/20080608/2da2e909/attachment.html