Pavel, good ideas. We have so far only tried to provide the basic building blocks for EDA without much constraints on how to use them and how to design interaction between business components. I don't mind defining higher level abstractions or constraints based on best practices. That is much what we have done with the domain model (DDD). The difficulty is that events can be used in so many different ways, from local to enterprise. We should define a few concrete scenarios that we would like to support better and then see if that should be solved within Sculptor or within integration product.
/Patrik PaloT wrote: > > On Wed, Jul 21, 2010 at 9:53 PM, Patrik Nordwall > <patrik.nordw...@gmail.com> wrote: >> PaloT wrote: >>> >>> Than after event reply aren't some events duplicated (one from replay >>> and one from service)? >>> >> I'm not sure that I understand the question. >> If you are using EventSourcing and the replay mechanism it is always the >> CommandEvents that are replayed and if they result in additional >> DomainEvents to be published they will be published again during replay. >> This can definitely be unwanted and must be handled by the application. >> Fowler describes this issue and talkes about gateways that must be aware >> of >> replay mode and avoid interaction with external parties. Currently we >> have >> not done anything about this. > Can't we "tag" event that it's reaction event and than we don't have > to store/reply it? This mean, framework will handle it without > necessity to write specific code in application. We can also store for > example module name which created event and events coming from system > which is replaying event will be not replayed. I guess we can make > something what will result in higher quality of EDA and mechanisms > which will work better in "default" mode. > >> PaloT wrote: >>> >>> If we can't fire CommandEvent from service do we have some well know >>> patter which will bridge two services - for example service will fire >>> DomainEvent and some integration code will generate CommandEvent as >>> reaction to DomainEvent? >>> >> That is possible to do. We will write more examples in the blog. > I can imagine with existing infrastructure but I guess this is higher > level logic than Service. It's integration or orchestration code. I > guess we have to split somehow this code from standard services and > apply some constraint about this code. Something like - not possible > to inject such kind of "service" to standard service (you can't call > it from standard service), or maybe more strict and disallow injection > of services to integration layer and allow invoking services from > integration layer only with Events. It will also mean that such events > and integration code will be invoked in another technical transaction, > ... > Many things appear in my hand which could be useful and necessary if > we want use it in enterprise environment. > >>> Don't we have to store some information about event like >>> module/application where it was created, ... for replay? >>> >> The EventSourcing mechanism operate on CommandEvents, which are >> persistent >> and stored with the ordinary persistence mechanism in Sculptor, i.e. in >> the >> same db as the business component where the specific CommandEvent is >> defined. > This was meant for better reply mechanism which can use this > information and work better out of box. > >>From my experience, we have to find way how to layer services and way > how to constraint communication between this layers. I mean something > like this: http://en.wikipedia.org/wiki/File:SOA_Metamodel.svg > In our system we have everything as Service. It's not bad, it's more > flexible but in enterprise environment we have to layer and constrain > service invocations. I would like to see it explicit in our DSL. > > Regards > > Pavel > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Fornax-developer mailing list > Fornax-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fornax-developer > > -- View this message in context: http://old.nabble.com/BLOG%3A-EDA-sculptor-support-tp29208795s17564p29329083.html Sent from the Fornax-Platform mailing list archive at Nabble.com. ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ Fornax-developer mailing list Fornax-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fornax-developer
