Message from discussion
Question about: Putting your events on a diet when using CQRS
Received: by 10.43.120.4 with SMTP id fw4mr2487830icc.28.1352292717561;
Wed, 07 Nov 2012 04:51:57 -0800 (PST)
X-BeenThere: nservicebus@googlegroups.com
Received: by 10.50.7.199 with SMTP id l7ls3568365iga.1.gmail; Wed, 07 Nov 2012
04:51:56 -0800 (PST)
Received: by 10.43.71.18 with SMTP id yi18mr2486226icb.21.1352292716817;
Wed, 07 Nov 2012 04:51:56 -0800 (PST)
Received: by 10.43.71.18 with SMTP id yi18mr2486224icb.21.1352292716769;
Wed, 07 Nov 2012 04:51:56 -0800 (PST)
Return-Path: <nservicebus.mirror+caf_=nservicebus=googlegroups....@gmail.com>
Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173])
by gmr-mx.google.com with ESMTPS id dx8si331051igc.1.2012.11.07.04.51.56
(version=TLSv1/SSLv3 cipher=OTHER);
Wed, 07 Nov 2012 04:51:56 -0800 (PST)
Received-SPF: pass (google.com: domain of nservicebus.mirror+caf_=nservicebus=googlegroups....@gmail.com designates 209.85.214.173 as permitted sender) client-ip=209.85.214.173;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of nservicebus.mirror+caf_=nservicebus=googlegroups....@gmail.com designates 209.85.214.173 as permitted sender) smtp.mail=nservicebus.mirror+caf_=nservicebus=googlegroups....@gmail.com
Received: by mail-ob0-f173.google.com with SMTP id wc18so1826437obb.32
for <nservicebus@googlegroups.com>; Wed, 07 Nov 2012 04:51:56 -0800 (PST)
Received: by 10.182.132.112 with SMTP id ot16mr2616540obb.69.1352292716511;
Wed, 07 Nov 2012 04:51:56 -0800 (PST)
X-Forwarded-To: nservicebus@googlegroups.com
X-Forwarded-For: nservicebus.mir...@gmail.com nservicebus@googlegroups.com
Delivered-To: nservicebus.mir...@gmail.com
Received: by 10.76.27.6 with SMTP id p6csp181442oag;
Wed, 7 Nov 2012 04:51:55 -0800 (PST)
Received: by 10.220.40.16 with SMTP id i16mr3967535vce.31.1352292715644;
Wed, 07 Nov 2012 04:51:55 -0800 (PST)
Return-Path: <sentto-21383118-16852-1352289794-nservicebus.mirror=gmail....@returns.groups.yahoo.com>
Received: from ng18-ip8.bullet.mail.ne1.yahoo.com (ng18-ip8.bullet.mail.ne1.yahoo.com. [98.138.215.109])
by mx.google.com with ESMTPS id n19si15508060vcw.76.2012.11.07.04.51.53
(version=TLSv1/SSLv3 cipher=OTHER);
Wed, 07 Nov 2012 04:51:55 -0800 (PST)
Received-SPF: pass (google.com: manual fallback record for domain of sentto-21383118-16852-1352289794-nservicebus.mirror=gmail....@returns.groups.yahoo.com designates 98.138.215.109 as permitted sender) client-ip=98.138.215.109;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoogroups.com; s=echo; t=1352292162; bh=3H2J0ydjtN57k8Tt6zLzhlgtlFZhQtLRuhcOGT5PhBs=; h=Received:Received:X-Yahoo-Newman-Id:X-Sender:X-Apparently-To:X-Received:X-Received:X-Received:X-Received:X-Received:To:Message-ID:In-Reply-To:User-Agent:X-Mailer:X-Originating-IP:X-eGroups-Msg-Info:X-Yahoo-Post-IP:From:X-Yahoo-Profile:Sender:MIME-Version:Mailing-List:Delivered-To:List-Id:Precedence:List-Unsubscribe:Date:Subject:Reply-To:X-Yahoo-Newman-Property:Content-Type; b=mA2X4AdvwckUTWeDW1SJ1saJrnufDeW5waiqxYLXu9IkqaB5ZUiRDcW/oju4YRXunlUBzORqeUvcTKNlVGwyFHDovHiJHDt0gnaD5YB97rQFMjjwclHBDE9Sx5N6j9gG7yMg3ZMxB9JVgFYvEAYf8qcHq4jtpGqb6N03ihHJNFc=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=echo; d=yahoogroups.com;
b=jQY/zvEfAmjb2/HyHZCajX+29oJlOjGV11+MO1XICkr6LjP9bXdT5z9YM0TIFmfIJLBz7Z5luXxmIX+EWmdKYhJwSxqclhwgDEBNGGFzJZh2cqjm+TCx9M/4UlMndu88A9uvIlN15E6G/p1sEovm2Fe2tDT4sijTg7RII+ABV7s=;
Received: from [98.138.217.179] by ng18.bullet.mail.ne1.yahoo.com with NNFMP; 07 Nov 2012 12:03:17 -0000
Received: from [98.137.34.41] by tg4.bullet.mail.ne1.yahoo.com with NNFMP; 07 Nov 2012 12:03:15 -0000
X-Yahoo-Newman-Id: 21383118-m16852
X-Sender: wernerclau...@yahoo.com
X-Apparently-To: nservice...@yahoogroups.com
X-Received: (qmail 3054 invoked from network); 7 Nov 2012 12:03:13 -0000
X-Received: from unknown (98.137.34.46)
by m5.grp.sp2.yahoo.com with QMQP; 7 Nov 2012 12:03:13 -0000
X-Received: from unknown (HELO ng5-vm5.bullet.mail.gq1.yahoo.com) (98.136.219.57)
by mta3.grp.sp2.yahoo.com with SMTP; 7 Nov 2012 12:03:13 -0000
X-Received: from [98.137.0.80] by ng5.bullet.mail.gq1.yahoo.com with NNFMP; 07 Nov 2012 12:03:13 -0000
X-Received: from [98.137.34.51] by tg1.bullet.mail.gq1.yahoo.com with NNFMP; 07 Nov 2012 12:03:12 -0000
To: nservice...@yahoogroups.com
Message-ID: <k7dilv+e...@eGroups.com>
In-Reply-To: <9A6E6E86-AEB4-4367-868C-27E8E385E...@gmail.com>
User-Agent: eGroups-EW/0.82
X-Mailer: Yahoo Groups Message Poster
X-Originating-IP: 93.167.197.82
X-eGroups-Msg-Info: 2:3:4:0:0
X-Yahoo-Post-IP: 93.167.197.82
From: "Werner" <wernerclau...@yahoo.com>
X-Yahoo-Profile: wernerclausen
Sender: nservice...@yahoogroups.com
MIME-Version: 1.0
Mailing-List: list nservice...@yahoogroups.com; contact nservicebus-ow...@yahoogroups.com
Delivered-To: mailing list nservice...@yahoogroups.com
List-Id: <nservicebus.yahoogroups.com>
Precedence: bulk
List-Unsubscribe: <mailto:nservicebus-unsubscr...@yahoogroups.com>
Date: Wed, 07 Nov 2012 12:03:11 -0000
Subject: [nservicebus] Re: Question about: Putting your events on a diet when using CQRS
Reply-To: nservice...@yahoogroups.com
X-Yahoo-Newman-Property: groups-email-ff-m
Content-Type: multipart/alternative;
boundary="D-vFzjt115SSunQJJwLrE6IE7IjMFMqKo5rHNAq"
--D-vFzjt115SSunQJJwLrE6IE7IjMFMqKo5rHNAq
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
A late response, but an upcomming vacation led to tons of work and then eve=
n more work after the vacation. Also, I wanted to reflect more than usual a=
bout all the answers.=20
Is IT Ops in your mind the same as an UI? Where different services deliver =
their UI widgets/components that, together, makes up the UI experience?=20
--=20
Werner
--- In nservice...@yahoogroups.com, Indu Alagarsamy <indu.alagarsamy@...> w=
rote:
>
> On the other hand, if you had a fat event.
> That say the notification subscribed to and another business capability a=
lso did. Now say some of the schema changes, then yikes!=20
>=20
> IT Ops is not a regular service in terms of a SOA context. I look at it a=
s a data enabler. The business services will be all autonomous and continue=
to be in the "lean" model.
>=20
> IT Ops doesn't typically subscribe to business events directly. Instead f=
acilitates getting data. Since this is a NSB endpoint, each service respons=
ible can deploy their integration interfaces to this endpoint. Again, it's =
each service that's doing it's work. The endpoint just orchestrates putting=
together data for the customer, sending a notification or an invoice.
>=20
> It was an aha moment after attending Udi's Advanced SOA training.
>=20
> Cheers,
> Indu
>=20
>=20
>=20
> Sent from my iPhone
>=20
> On Oct 12, 2012, at 5:27 AM, "Werner" <wernerclausen@...> wrote:
>=20
> >=20
> > In my view you just pushed the problem to another service. Let's define=
that the service "CRM" publishes the lean SOA event for those services out=
side it's boundary:
> >=20
> > interface ISoaCustomerCreated
> > {
> > Guid CustomerId { get; set; }
> > }
> >=20
> > Then "Communications" subscribes to this event. So, now it has the Cust=
omerId. It needs to know the customers age in order to set the Notification=
TypeId for OPS. How does "Communications" get the age of the customer? Quer=
y to another context (CRM) is the only way, since it doesn't receive the fa=
t event. Aren't you now querying between two ordinary (non-OPS) services th=
at were supposed to be autonomous?=20
> >=20
> > --=20
> > Werner
> >=20
> > --- In nservice...@yahoogroups.com, Andreas =C3=96hlund <andreasohlund2=
@> wrote:
> > >
> > > >Your OPS service receives an event with a CustomerId
> > > I usually do this with a command (OPS is the only service which is al=
lowed
> > > to accept commands from others) to the OPS component responsible for
> > > sending the notification. The service sending would be "Communication=
s".
> > >=20
> > > >You say that "IT/OPS" doesn't interpret the data, it only applies
> > > formatting. But what if it did (special emails based on age, order hi=
story
> > > for example). Would that change your design?
> > > Then "Communications" would include the "NotificationTypeId" in the c=
ommand
> > > since that decision doesn't belon in OPS. Ops would then map
> > > that NotificationTypeId to the relevant template.
> > >=20
> > > This way OPS doesn't need to interpret the data in anyway and only fo=
cus on
> > > the technical decisions.
> > >=20
> > > Does this make sense?
> > >=20
> > >=20
> > > On Fri, Oct 12, 2012 at 10:30 AM, Werner <wernerclausen@> wrote:
> > >=20
> > > > **
> > > >
> > > >
> > > >
> > > > > I would not say that it OPS is pulling data from others.
> > > >
> > > > Yet that _is_ what happens. Your OPS service receives an event with=
a
> > > > CustomerId. It will use that CustomerId to query some other context=
. Why
> > > > take that extra (blocking) step when you just could have received t=
he fat
> > > > event and discarded whatever information you didn't need?
> > > >
> > > > You say that "IT/OPS" doesn't interpret the data, it only applies
> > > > formatting. But what if it did (special emails based on age, order =
history
> > > > for example). Would that change your design?
> > > >
> > > > --
> > > > Werner
> > > >
> > > >
> > > > --- In nservice...@yahoogroups.com, Andreas =C3=96hlund <andreasohl=
und2@>
> > > > wrote:
> > > > >
> > > > > >just because IT/OPS is allowed to do anything - including pullin=
g data
> > > > > from several contexts
> > > > > I would not say that it OPS is pulling data from others. I like t=
o see it
> > > > > as "providing a way for all other contexts to contribute with dat=
a" to a
> > > > > composite.
> > > > >
> > > > > OPS doesn't interpret the data is just applies formatting (from t=
he
> > > > > "branding" service) and use the output to do whatever *technicall=
y
> > > > *needed
> > > >
> > > > > (that's why OPS is involved) to get the data to the end user.
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Andreas
> > > > >
> > > > >
> > > > > On Thu, Oct 11, 2012 at 2:21 PM, Werner <wernerclausen@> wrote:
> > > > >
> > > > > > **
> > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > I can relate to your thoughts here. Surely, the expense of subs=
cribing
> > > > to
> > > > > > fat events is better than a direct coupling where you pull data=
.
> > > > > >
> > > > > > Also I don't quite follow the paradigm of promoting
> > > > functionality/sevices
> > > > > > to "IT/OPS" just because IT/OPS is allowed to do anything - inc=
luding
> > > > > > pulling data from several contexts. It solves the problem in a =
very
> > > > > > pragmatic way though :)
> > > > > >
> > > > > > If we imagine for a moment that we DO have a fat event Handler =
that
> > > > picks
> > > > > > up "XyzService.ISomethingHappened", who owns that handler? The
> > > > XyzService
> > > > > > or the Notification service?
> > > > > >
> > > > > > --
> > > > > > Werner
> > > > > >
> > > > > >
> > > > > > --- In nservice...@yahoogroups.com, Mauro Servienti <mauro@> wr=
ote:
> > > > > > >
> > > > > > > I'll swear I'll watch it during lunch time today :-)
> > > > > > >
> > > > > > > I understood your approach, but to me it seems that it brings=
us
> > > > back to
> > > > > > availability problems.
> > > > > > >
> > > > > > >
> > > > > > > - The XyzService sends the event using the bus;
> > > > > > >
> > > > > > > - The notification system asynchronously receives it;
> > > > > > >
> > > > > > > - The notification system now depends on the availability of =
the
> > > > > > IProvideNotificationInfo implementers (that are services expose=
d by the
> > > > > > sender bounded context);
> > > > > > >
> > > > > > > Thus if one of the IProvideNotificationInfo is not available =
the
> > > > > > notification cannot be sent until the data is available.
> > > > > > >
> > > > > > > In this specific case having a fat event solves the dependenc=
y
> > > > problem.
> > > > > > >
> > > > > > > Be aware that this is not a critique, I'm simply trying to
> > > > understand :-)
> > > > > > > .m
> > > > > > >
> > > > > > >
> > > > > > > From: nservice...@yahoogroups.com [mailto:
> > > > nservice...@yahoogroups.com]
> > > > > > On Behalf Of Andreas =C3=96hlund
> > > > > > > Sent: marted=C3=AC 9 ottobre 2012 10.28
> > > > > > > To: nservice...@yahoogroups.com
> > > > > > > Subject: Re: [nservicebus] Question about: Putting your event=
s on a
> > > > diet
> > > > > > when using CQRS
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >If the service sending the event sends only the "identifier"=
of what
> > > > > > has happened the NotificationSystem depends on _all_ the possib=
le
> > > > senders
> > > > > > out there, and another problem is that the source data, identif=
ied by
> > > > the
> > > > > > id, >must be available to the notification system, in order to
> > > > generate the
> > > > > > notification.
> > > > > > > Watch the video:)
> > > > > > >
> > > > > > > In essense:
> > > > > > >
> > > > > > > * Notifications is a Composite owned by the "OPS service"
> > > > > > > * It can be triggered by a message containing relevant ID's,
> > > > customerId,
> > > > > > orderId, accountId
> > > > > > > * At that point the OPS code will invoke all code implementin=
g
> > > > > > IProvideNotificationInfo giving all your services a chance to g=
et data
> > > > onto
> > > > > > the notification based on that id
> > > > > > > * OPS then collects all this data, json, xml, etc and applies=
the
> > > > > > relevant template to produce the formatted output to deliver
> > > > > > > * Delivers the notification, push, email, sms , whatever
> > > > > > >
> > > > > > > Does this make any sense?
> > > > > > >
> > > > > > > Cheers,
> > > > > > >
> > > > > > > Andreas
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Oct 9, 2012 at 10:12 AM, Mauro Servienti <mauro@<mail=
to:
> > > > > > mauro@>> wrote:
> > > > > > >
> > > > > > > Context was misused with the meaning of bounded-context, my
> > > > italenglish
> > > > > > is quite poor :-)
> > > > > > >
> > > > > > > "Within a service boundary multiple services can share the sa=
me data.
> > > > > > Traditionally this is then stored in a database but this can so=
metimes
> > > > > > cause performance issues and to remove these you can choose to
> > > > implement
> > > > > > CQRS where each service has its own read-model that is updated =
by using
> > > > > > 'fat' events. These events are internal to the service boundary=
for
> > > > these
> > > > > > services."
> > > > > > >
> > > > > > > Internally I love the way we can use events to de-normalize r=
ead
> > > > models,
> > > > > > we use it intensively to survive, for example, to MongoDB javas=
cript
> > > > base
> > > > > > Map/Reduce.
> > > > > > >
> > > > > > > Now, the "XyzService" fires an event and the NotificationSyst=
em
> > > > (that is
> > > > > > a completely ignorant system whose role is to simply generate e=
mail
> > > > > > notifications, and a bunch of other notification types) is inte=
rested
> > > > in
> > > > > > handling that event so to create notifications for subscribed u=
sers.
> > > > > > >
> > > > > > > If the service sending the event sends only the "identifier" =
of what
> > > > has
> > > > > > happened the NotificationSystem depends on _all_ the possible s=
enders
> > > > out
> > > > > > there, and another problem is that the source data, identified =
by the
> > > > id,
> > > > > > must be available to the notification system, in order to gener=
ate the
> > > > > > notification.
> > > > > > >
> > > > > > > In this scenario, that is one of our real scenario, it seems =
to me
> > > > that
> > > > > > using "thick events" instead of "fat events" we have a coupling=
that
> > > > is a
> > > > > > pain to maintain in the long term.
> > > > > > >
> > > > > > > .m
> > > > > > >
> > > > > > > From: nservice...@yahoogroups.com<mailto:nservicebus@yahoogro=
ups.com
> > > > >
> > > > > > [mailto:nservice...@yahoogroups.com<mailto:nservicebus@yahoogro=
ups.com
> > > > >]
> > > > > > On Behalf Of Ramon Smits
> > > > > >
> > > > > > > Sent: marted=C3=AC 9 ottobre 2012 09.52
> > > > > > >
> > > > > > > To: nservice...@yahoogroups.com<mailto:nservicebus@yahoogroup=
s.com>
> > > > > >
> > > > > > > Subject: Re: [nservicebus] Question about: Putting your event=
s on a
> > > > diet
> > > > > > when using CQRS
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Really don't understand your Italian English there :-)
> > > > > > >
> > > > > > > I think we all agree that we:
> > > > > > > * only communicate domain events accross service boundaries
> > > > > > > * that events crossing service boundaries only contain identi=
fiers
> > > > (and
> > > > > > sometimes dates)
> > > > > > > * events are in the past
> > > > > > >
> > > > > > >
> > > > > > > I don't know what your definition is for the term 'context' i=
n your
> > > > > > response but maybe the following helps.
> > > > > > >
> > > > > > > Your question regarding the retrieval of data by key is not
> > > > performed by
> > > > > > a service. Services do not 'fetch/request/store' data from anot=
her
> > > > service
> > > > > > boundary. Only user interfaces do but these have controls that
> > > > logically
> > > > > > belong to the corresponding service boundaries.
> > > > > > >
> > > > > > > Within a service boundary multiple services can share the sam=
e data.
> > > > > > Traditionally this is then stored in a database but this can so=
metimes
> > > > > > cause performance issues and to remove these you can choose to
> > > > implement
> > > > > > CQRS where each service has its own read-model that is updated =
by using
> > > > > > 'fat' events. These events are internal to the service boundary=
for
> > > > these
> > > > > > services.
> > > > > > >
> > > > > > >
> > > > > > > -- Ramon
> > > > > > >
> > > > > > > On Tue, Oct 9, 2012 at 9:16 AM, Mauro Servienti <mauro@<mailt=
o:
> > > > mauro@>>
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > Guys,
> > > > > > >
> > > > > > > interesting, really interesting topic. While I strongly agree=
that
> > > > > > "inside" events are a different stuff of "outside" events (
> > > > > >
> > > > http://milestone.topics.it/2012/07/domain-events-and-domain-events.=
html)
> > > > > > I am interested in discuss this point:
> > > > > > >
> > > > > > > "Using events for communicating between business services/bou=
nded
> > > > > > contexts
> > > > > > > When communicating between well designed services the only da=
ta that
> > > > is
> > > > > > relevant on the is usually some kind of identifier. This is fur=
ther
> > > > > > enforced by the guideline that the only data that is duplicated=
between
> > > > > > services is ID's any other attributes on the event is only used=
to
> > > > update
> > > > > > data owned by the receiving service."
> > > > > > > I've not yet seen the Andreas video, but I am used to approac=
h
> > > > > > cross-context communication using the opposite approach.
> > > > > > >
> > > > > > > The problem is: if the two contexts are separated and I pass,=
with
> > > > the
> > > > > > events, only ids the receiving context needs to access the sour=
ce
> > > > context
> > > > > > data in order to retrieve information linked to the given id.
> > > > > > >
> > > > > > > In this case services are not autonomous any more, or am I mi=
ssing
> > > > > > something?
> > > > > > >
> > > > > > > .m
> > > > > > >
> > > > > > > From: nservice...@yahoogroups.com<mailto:nservicebus@yahoogro=
ups.com
> > > > >
> > > > > > [mailto:nservice...@yahoogroups.com<mailto:nservicebus@yahoogro=
ups.com
> > > > >]
> > > > > > On Behalf Of Andreas =C3=96hlund
> > > > > >
> > > > > > > Sent: marted=C3=AC 9 ottobre 2012 08.52
> > > > > > > To: nservice...@yahoogroups.com<mailto:nservicebus@yahoogroup=
s.com>
> > > > > >
> > > > > > > Subject: Re: [nservicebus] Question about: Putting your event=
s on a
> > > > diet
> > > > > > when using CQRS
> > > > > > >
> > > > > > >
> > > > > > > I have a post on this subject:
> > > > > > >
> > > > > > >
> > > > http://andreasohlund.net/2011/05/05/not-all-events-are-created-equa=
l/
> > > > > > >
> > > > > > > In short: (exactly like you mentions)
> > > > > > >
> > > > > > > interface ICqrsEventHappened : ISoaEventHappened {}
> > > > > > >
> > > > > > > Bus.Publish<ICqrsEventHappened >()
> > > > > > >
> > > > > > > Cheers,
> > > > > > >
> > > > > > > Andreas
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Oct 9, 2012 at 8:11 AM, Werner <wernerclausen@<mailto=
:
> > > > > > wernerclausen@>> wrote:
> > > > > > >
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > A question to this interesting video from Andreas:
> > > > > > > http://skillsmatter.com/podcast/open-source-dot-net/events-di=
et, and
> > > > > > interested in hearing about others and their usage of events wh=
en using
> > > > > > CQRS. I'm specifically talking about the difference/usage of SO=
A
> > > > events v/s
> > > > > > CQRS events. Andreas says, that subscribers outside the context=
should
> > > > only
> > > > > > receive an ID - not the fat event with the data.
> > > > > > >
> > > > > > > If using CQRS, is it recommended to contruct your events so t=
hat BOTH
> > > > > > the CQRS event and the SOA event is published? E.g.:
> > > > > > >
> > > > > > > interface ICqrsEventHappened : ISoaEventHappened {}
> > > > > > >
> > > > > > > Surely there are subscribers outside the context, and if they=
should
> > > > > > only receive the ISoaEventHappened with an ID, it looks as the =
easiest
> > > > > > solution is to make the above construct "default" or what?
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > --
> > > > > > > Werner
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > http://andreasohlund.net<http://andreasohlund.net/>
> > > > > > > http://twitter.com/andreasohlund
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > http://andreasohlund.net<http://andreasohlund.net/>
> > > > > > > http://twitter.com/andreasohlund
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > http://andreasohlund.net
> > > > > http://twitter.com/andreasohlund
> > > > >
> > > >
> > > >=20
> > > >
> > >=20
> > >=20
> > >=20
> > > --=20
> > > http://andreasohlund.net
> > > http://twitter.com/andreasohlund
> > >
> >=20
> >
>
--D-vFzjt115SSunQJJwLrE6IE7IjMFMqKo5rHNAq
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/htm=
l4/strict.dtd">
<html>
<head>
</head>
<body style=3D"background-color: #fff;">
<span style=3D"display:none"> </span>
<!--~-|**|PrettyHtmlStartT|**|-~-->
<div id=3D"ygrp-mlmsg" style=3D"position:relative;">
<div id=3D"ygrp-msg" style=3D"z-index: 1;">
<!--~-|**|PrettyHtmlEndT|**|-~-->
<div id=3D"ygrp-text" >
=20=20=20=20=20=20
=20=20=20=20=20=20
<p><br>
A late response, but an upcomming vacation led to tons of work and then eve=
n more work after the vacation. Also, I wanted to reflect more than usual a=
bout all the answers. <br>
<br>
Is IT Ops in your mind the same as an UI? Where different services deliver =
their UI widgets/components that, together, makes up the UI experience? <br=
>
<br>
-- <br>
Werner<br>
<br>
--- In <a href=3D"mailto:nservicebus%40yahoogroups.com">nservicebus@yahoogr=
oups.com</a>, Indu Alagarsamy <indu.alagarsamy@...> wrote:<br>
><br>
> On the other hand, if you had a fat event.<br>
> That say the notification subscribed to and another business capabilit=
y also did. Now say some of the schema changes, then yikes! <br>
> <br>
> IT Ops is not a regular service in terms of a SOA context. I look at i=
t as a data enabler. The business services will be all autonomous and conti=
nue to be in the "lean" model.<br>
> <br>
> IT Ops doesn't typically subscribe to business events directly. Instea=
d facilitates getting data. Since this is a NSB endpoint, each service resp=
onsible can deploy their integration interfaces to this endpoint. Again, it=
's each service that's doing it's work. The endpoint just orchestrates putt=
ing together data for the customer, sending a notification or an invoice.<b=
r>
> <br>
> It was an aha moment after attending Udi's Advanced SOA training.<br>
> <br>
> Cheers,<br>
> Indu<br>
> <br>
> <br>
> <br>
> Sent from my iPhone<br>
> <br>
> On Oct 12, 2012, at 5:27 AM, "Werner" <wernerclausen@...&=
gt; wrote:<br>
> <br>
> > <br>
> > In my view you just pushed the problem to another service. Let's =
define that the service "CRM" publishes the lean SOA event for th=
ose services outside it's boundary:<br>
> > <br>
> > interface ISoaCustomerCreated<br>
> > {<br>
> > Guid CustomerId { get; set; }<br>
> > }<br>
> > <br>
> > Then "Communications" subscribes to this event. So, now=
it has the CustomerId. It needs to know the customers age in order to set =
the NotificationTypeId for OPS. How does "Communications" get the=
age of the customer? Query to another context (CRM) is the only way, since=
it doesn't receive the fat event. Aren't you now querying between two ordi=
nary (non-OPS) services that were supposed to be autonomous? <br>
> > <br>
> > -- <br>
> > Werner<br>
> > <br>
> > --- In <a href=3D"mailto:nservicebus%40yahoogroups.com">nserviceb=
u...@yahoogroups.com</a>, Andreas =C3=96hlund <andreasohlund2@> wrote:<=
br>
> > ><br>
> > > >Your OPS service receives an event with a CustomerId<br>
> > > I usually do this with a command (OPS is the only service wh=
ich is allowed<br>
> > > to accept commands from others) to the OPS component respons=
ible for<br>
> > > sending the notification. The service sending would be "=
;Communications".<br>
> > > <br>
> > > >You say that "IT/OPS" doesn't interpret the da=
ta, it only applies<br>
> > > formatting. But what if it did (special emails based on age,=
order history<br>
> > > for example). Would that change your design?<br>
> > > Then "Communications" would include the "Noti=
ficationTypeId" in the command<br>
> > > since that decision doesn't belon in OPS. Ops would then map=
<br>
> > > that NotificationTypeId to the relevant template.<br>
> > > <br>
> > > This way OPS doesn't need to interpret the data in anyway an=
d only focus on<br>
> > > the technical decisions.<br>
> > > <br>
> > > Does this make sense?<br>
> > > <br>
> > > <br>
> > > On Fri, Oct 12, 2012 at 10:30 AM, Werner <wernerclausen@&=
gt; wrote:<br>
> > > <br>
> > > > **<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > > I would not say that it OPS is pulling data from o=
thers.<br>
> > > ><br>
> > > > Yet that _is_ what happens. Your OPS service receives a=
n event with a<br>
> > > > CustomerId. It will use that CustomerId to query some o=
ther context. Why<br>
> > > > take that extra (blocking) step when you just could hav=
e received the fat<br>
> > > > event and discarded whatever information you didn't nee=
d?<br>
> > > ><br>
> > > > You say that "IT/OPS" doesn't interpret the d=
ata, it only applies<br>
> > > > formatting. But what if it did (special emails based on=
age, order history<br>
> > > > for example). Would that change your design?<br>
> > > ><br>
> > > > --<br>
> > > > Werner<br>
> > > ><br>
> > > ><br>
> > > > --- In <a href=3D"mailto:nservicebus%40yahoogroups.com"=
>nservice...@yahoogroups.com</a>, Andreas =C3=96hlund <andreasohlund2@&g=
t;<br>
> > > > wrote:<br>
> > > > ><br>
> > > > > >just because IT/OPS is allowed to do anything =
- including pulling data<br>
> > > > > from several contexts<br>
> > > > > I would not say that it OPS is pulling data from o=
thers. I like to see it<br>
> > > > > as "providing a way for all other contexts to=
contribute with data" to a<br>
> > > > > composite.<br>
> > > > ><br>
> > > > > OPS doesn't interpret the data is just applies for=
matting (from the<br>
> > > > > "branding" service) and use the output t=
o do whatever *technically<br>
> > > > *needed<br>
> > > ><br>
> > > > > (that's why OPS is involved) to get the data to th=
e end user.<br>
> > > > ><br>
> > > > > Cheers,<br>
> > > > ><br>
> > > > > Andreas<br>
> > > > ><br>
> > > > ><br>
> > > > > On Thu, Oct 11, 2012 at 2:21 PM, Werner <werner=
clausen@> wrote:<br>
> > > > ><br>
> > > > > > **<br>
> > > ><br>
> > > > > ><br>
> > > > > ><br>
> > > > > ><br>
> > > > > > I can relate to your thoughts here. Surely, t=
he expense of subscribing<br>
> > > > to<br>
> > > > > > fat events is better than a direct coupling w=
here you pull data.<br>
> > > > > ><br>
> > > > > > Also I don't quite follow the paradigm of pro=
moting<br>
> > > > functionality/sevices<br>
> > > > > > to "IT/OPS" just because IT/OPS is =
allowed to do anything - including<br>
> > > > > > pulling data from several contexts. It solves=
the problem in a very<br>
> > > > > > pragmatic way though :)<br>
> > > > > ><br>
> > > > > > If we imagine for a moment that we DO have a =
fat event Handler that<br>
> > > > picks<br>
> > > > > > up "XyzService.ISomethingHappened",=
who owns that handler? The<br>
> > > > XyzService<br>
> > > > > > or the Notification service?<br>
> > > > > ><br>
> > > > > > --<br>
> > > > > > Werner<br>
> > > > > ><br>
> > > > > ><br>
> > > > > > --- In <a href=3D"mailto:nservicebus%40yahoog=
roups.com">nservice...@yahoogroups.com</a>, Mauro Servienti <mauro@> =
wrote:<br>
> > > > > > ><br>
> > > > > > > I'll swear I'll watch it during lunch ti=
me today :-)<br>
> > > > > > ><br>
> > > > > > > I understood your approach, but to me it=
seems that it brings us<br>
> > > > back to<br>
> > > > > > availability problems.<br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > > - The XyzService sends the event using t=
he bus;<br>
> > > > > > ><br>
> > > > > > > - The notification system asynchronously=
receives it;<br>
> > > > > > ><br>
> > > > > > > - The notification system now depends on=
the availability of the<br>
> > > > > > IProvideNotificationInfo implementers (that a=
re services exposed by the<br>
> > > > > > sender bounded context);<br>
> > > > > > ><br>
> > > > > > > Thus if one of the IProvideNotificationI=
nfo is not available the<br>
> > > > > > notification cannot be sent until the data is=
available.<br>
> > > > > > ><br>
> > > > > > > In this specific case having a fat event=
solves the dependency<br>
> > > > problem.<br>
> > > > > > ><br>
> > > > > > > Be aware that this is not a critique, I'=
m simply trying to<br>
> > > > understand :-)<br>
> > > > > > > .m<br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > > From: <a href=3D"mailto:nservicebus%40ya=
hoogroups.com">nservice...@yahoogroups.com</a> [mailto:<br>
> > > > <a href=3D"mailto:nservicebus%40yahoogroups.com">nservi=
ce...@yahoogroups.com</a>]<br>
> > > > > > On Behalf Of Andreas =C3=96hlund<br>
> > > > > > > Sent: marted=C3=AC 9 ottobre 2012 10.28<=
br>
> > > > > > > To: <a href=3D"mailto:nservicebus%40yaho=
ogroups.com">nservice...@yahoogroups.com</a><br>
> > > > > > > Subject: Re: [nservicebus] Question abou=
t: Putting your events on a<br>
> > > > diet<br>
> > > > > > when using CQRS<br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > > >If the service sending the event sen=
ds only the "identifier" of what<br>
> > > > > > has happened the NotificationSystem depends o=
n _all_ the possible<br>
> > > > senders<br>
> > > > > > out there, and another problem is that the so=
urce data, identified by<br>
> > > > the<br>
> > > > > > id, >must be available to the notification=
system, in order to<br>
> > > > generate the<br>
> > > > > > notification.<br>
> > > > > > > Watch the video:)<br>
> > > > > > ><br>
> > > > > > > In essense:<br>
> > > > > > ><br>
> > > > > > > * Notifications is a Composite owned by =
the "OPS service"<br>
> > > > > > > * It can be triggered by a message conta=
ining relevant ID's,<br>
> > > > customerId,<br>
> > > > > > orderId, accountId<br>
> > > > > > > * At that point the OPS code will invoke=
all code implementing<br>
> > > > > > IProvideNotificationInfo giving all your serv=
ices a chance to get data<br>
> > > > onto<br>
> > > > > > the notification based on that id<br>
> > > > > > > * OPS then collects all this data, json,=
xml, etc and applies the<br>
> > > > > > relevant template to produce the formatted ou=
tput to deliver<br>
> > > > > > > * Delivers the notification, push, email=
, sms , whatever<br>
> > > > > > ><br>
> > > > > > > Does this make any sense?<br>
> > > > > > ><br>
> > > > > > > Cheers,<br>
> > > > > > ><br>
> > > > > > > Andreas<br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > > On Tue, Oct 9, 2012 at 10:12 AM, Mauro S=
ervienti <mauro@<mailto:<br>
> > > > > > mauro@>> wrote:<br>
> > > > > > ><br>
> > > > > > > Context was misused with the meaning of =
bounded-context, my<br>
> > > > italenglish<br>
> > > > > > is quite poor :-)<br>
> > > > > > ><br>
> > > > > > > "Within a service boundary multiple=
services can share the same data.<br>
> > > > > > Traditionally this is then stored in a databa=
se but this can sometimes<br>
> > > > > > cause performance issues and to remove these =
you can choose to<br>
> > > > implement<br>
> > > > > > CQRS where each service has its own read-mode=
l that is updated by using<br>
> > > > > > 'fat' events. These events are internal to th=
e service boundary for<br>
> > > > these<br>
> > > > > > services."<br>
> > > > > > ><br>
> > > > > > > Internally I love the way we can use eve=
nts to de-normalize read<br>
> > > > models,<br>
> > > > > > we use it intensively to survive, for example=
, to MongoDB javascript<br>
> > > > base<br>
> > > > > > Map/Reduce.<br>
> > > > > > ><br>
> > > > > > > Now, the "XyzService" fires an=
event and the NotificationSystem<br>
> > > > (that is<br>
> > > > > > a completely ignorant system whose role is to=
simply generate email<br>
> > > > > > notifications, and a bunch of other notificat=
ion types) is interested<br>
> > > > in<br>
> > > > > > handling that event so to create notification=
s for subscribed users.<br>
> > > > > > ><br>
> > > > > > > If the service sending the event sends o=
nly the "identifier" of what<br>
> > > > has<br>
> > > > > > happened the NotificationSystem depends on _a=
ll_ the possible senders<br>
> > > > out<br>
> > > > > > there, and another problem is that the source=
data, identified by the<br>
> > > > id,<br>
> > > > > > must be available to the notification system,=
in order to generate the<br>
> > > > > > notification.<br>
> > > > > > ><br>
> > > > > > > In this scenario, that is one of our rea=
l scenario, it seems to me<br>
> > > > that<br>
> > > > > > using "thick events" instead of &qu=
ot;fat events" we have a coupling that<br>
> > > > is a<br>
> > > > > > pain to maintain in the long term.<br>
> > > > > > ><br>
> > > > > > > .m<br>
> > > > > > ><br>
> > > > > > > From: <a href=3D"mailto:nservicebus%40ya=
hoogroups.com">nservice...@yahoogroups.com</a><mailto:<a href=3D"mailto:=
nservicebus%40yahoogroups.com">nservice...@yahoogroups.com</a><br>
> > > > ><br>
> > > > > > [mailto:<a href=3D"mailto:nservicebus%40yahoo=
groups.com">nservice...@yahoogroups.com</a><mailto:<a href=3D"mailto:nse=
rvicebus%40yahoogroups.com">nservice...@yahoogroups.com</a><br>
> > > > >]<br>
> > > > > > On Behalf Of Ramon Smits<br>
> > > > > ><br>
> > > > > > > Sent: marted=C3=AC 9 ottobre 2012 09.52<=
br>
> > > > > > ><br>
> > > > > > > To: <a href=3D"mailto:nservicebus%40yaho=
ogroups.com">nservice...@yahoogroups.com</a><mailto:<a href=3D"mailto:ns=
ervicebus%40yahoogroups.com">nservice...@yahoogroups.com</a>><br>
> > > > > ><br>
> > > > > > > Subject: Re: [nservicebus] Question abou=
t: Putting your events on a<br>
> > > > diet<br>
> > > > > > when using CQRS<br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > > Really don't understand your Italian Eng=
lish there :-)<br>
> > > > > > ><br>
> > > > > > > I think we all agree that we:<br>
> > > > > > > * only communicate domain events accross=
service boundaries<br>
> > > > > > > * that events crossing service boundarie=
s only contain identifiers<br>
> > > > (and<br>
> > > > > > sometimes dates)<br>
> > > > > > > * events are in the past<br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > > I don't know what your definition is for=
the term 'context' in your<br>
> > > > > > response but maybe the following helps.<br>
> > > > > > ><br>
> > > > > > > Your question regarding the retrieval of=
data by key is not<br>
> > > > performed by<br>
> > > > > > a service. Services do not 'fetch/request/sto=
re' data from another<br>
> > > > service<br>
> > > > > > boundary. Only user interfaces do but these h=
ave controls that<br>
> > > > logically<br>
> > > > > > belong to the corresponding service boundarie=
s.<br>
> > > > > > ><br>
> > > > > > > Within a service boundary multiple servi=
ces can share the same data.<br>
> > > > > > Traditionally this is then stored in a databa=
se but this can sometimes<br>
> > > > > > cause performance issues and to remove these =
you can choose to<br>
> > > > implement<br>
> > > > > > CQRS where each service has its own read-mode=
l that is updated by using<br>
> > > > > > 'fat' events. These events are internal to th=
e service boundary for<br>
> > > > these<br>
> > > > > > services.<br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > > -- Ramon<br>
> > > > > > ><br>
> > > > > > > On Tue, Oct 9, 2012 at 9:16 AM, Mauro Se=
rvienti <mauro@<mailto:<br>
> > > > mauro@>><br>
> > > ><br>
> > > > > > wrote:<br>
> > > > > > ><br>
> > > > > > > Guys,<br>
> > > > > > ><br>
> > > > > > > interesting, really interesting topic. W=
hile I strongly agree that<br>
> > > > > > "inside" events are a different stu=
ff of "outside" events (<br>
> > > > > ><br>
> > > > <a href=3D"http://milestone.topics.it/2012/07/domain-ev=
ents-and-domain-events.html">http://milestone.topics.it/2012/07/domain-even=
ts-and-domain-events.html</a>)<br>
> > > > > > I am interested in discuss this point:<br>
> > > > > > ><br>
> > > > > > > "Using events for communicating bet=
ween business services/bounded<br>
> > > > > > contexts<br>
> > > > > > > When communicating between well designed=
services the only data that<br>
> > > > is<br>
> > > > > > relevant on the is usually some kind of ident=
ifier. This is further<br>
> > > > > > enforced by the guideline that the only data =
that is duplicated between<br>
> > > > > > services is ID's any other attributes on the =
event is only used to<br>
> > > > update<br>
> > > > > > data owned by the receiving service."<br=
>
> > > > > > > I've not yet seen the Andreas video, but=
I am used to approach<br>
> > > > > > cross-context communication using the opposit=
e approach.<br>
> > > > > > ><br>
> > > > > > > The problem is: if the two contexts are =
separated and I pass, with<br>
> > > > the<br>
> > > > > > events, only ids the receiving context needs =
to access the source<br>
> > > > context<br>
> > > > > > data in order to retrieve information linked =
to the given id.<br>
> > > > > > ><br>
> > > > > > > In this case services are not autonomous=
any more, or am I missing<br>
> > > > > > something?<br>
> > > > > > ><br>
> > > > > > > .m<br>
> > > > > > ><br>
> > > > > > > From: <a href=3D"mailto:nservicebus%40ya=
hoogroups.com">nservice...@yahoogroups.com</a><mailto:<a href=3D"mailto:=
nservicebus%40yahoogroups.com">nservice...@yahoogroups.com</a><br>
> > > > ><br>
> > > > > > [mailto:<a href=3D"mailto:nservicebus%40yahoo=
groups.com">nservice...@yahoogroups.com</a><mailto:<a href=3D"mailto:nse=
rvicebus%40yahoogroups.com">nservice...@yahoogroups.com</a><br>
> > > > >]<br>
> > > > > > On Behalf Of Andreas =C3=96hlund<br>
> > > > > ><br>
> > > > > > > Sent: marted=C3=AC 9 ottobre 2012 08.52<=
br>
> > > > > > > To: <a href=3D"mailto:nservicebus%40yaho=
ogroups.com">nservice...@yahoogroups.com</a><mailto:<a href=3D"mailto:ns=
ervicebus%40yahoogroups.com">nservice...@yahoogroups.com</a>><br>
> > > > > ><br>
> > > > > > > Subject: Re: [nservicebus] Question abou=
t: Putting your events on a<br>
> > > > diet<br>
> > > > > > when using CQRS<br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > > I have a post on this subject:<br>
> > > > > > ><br>
> > > > > > ><br>
> > > > <a href=3D"http://andreasohlund.net/2011/05/05/not-all-=
events-are-created-equal/">http://andreasohlund.net/2011/05/05/not-all-even=
ts-are-created-equal/</a><br>
> > > > > > ><br>
> > > > > > > In short: (exactly like you mentions)<br=
>
> > > > > > ><br>
> > > > > > > interface ICqrsEventHappened : ISoaEvent=
Happened {}<br>
> > > > > > ><br>
> > > > > > > Bus.Publish<ICqrsEventHappened >()=
<br>
> > > > > > ><br>
> > > > > > > Cheers,<br>
> > > > > > ><br>
> > > > > > > Andreas<br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > > On Tue, Oct 9, 2012 at 8:11 AM, Werner &=
lt;wernerclausen@<mailto:<br>
> > > > > > wernerclausen@>> wrote:<br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > > Hi,<br>
> > > > > > ><br>
> > > > > > > A question to this interesting video fro=
m Andreas:<br>
> > > > > > > <a href=3D"http://skillsmatter.com/podca=
st/open-source-dot-net/events-diet,">http://skillsmatter.com/podcast/open-s=
ource-dot-net/events-diet,</a> and<br>
> > > > > > interested in hearing about others and their =
usage of events when using<br>
> > > > > > CQRS. I'm specifically talking about the diff=
erence/usage of SOA<br>
> > > > events v/s<br>
> > > > > > CQRS events. Andreas says, that subscribers o=
utside the context should<br>
> > > > only<br>
> > > > > > receive an ID - not the fat event with the da=
ta.<br>
> > > > > > ><br>
> > > > > > > If using CQRS, is it recommended to cont=
ruct your events so that BOTH<br>
> > > > > > the CQRS event and the SOA event is published=
? E.g.:<br>
> > > > > > ><br>
> > > > > > > interface ICqrsEventHappened : ISoaEvent=
Happened {}<br>
> > > > > > ><br>
> > > > > > > Surely there are subscribers outside the=
context, and if they should<br>
> > > > > > only receive the ISoaEventHappened with an ID=
, it looks as the easiest<br>
> > > > > > solution is to make the above construct "=
;default" or what?<br>
> > > > > > ><br>
> > > > > > > Thanks,<br>
> > > > > > ><br>
> > > > > > > --<br>
> > > > > > > Werner<br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > > --<br>
> > > > > > > <a href=3D"http://andreasohlund.net">htt=
p://andreasohlund.net</a><<a href=3D"http://andreasohlund.net/">http://a=
ndreasohlund.net/</a>><br>
> > > > > > > <a href=3D"http://twitter.com/andreasohl=
und">http://twitter.com/andreasohlund</a><br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > ><br>
> > > > > > > --<br>
> > > > > > > <a href=3D"http://andreasohlund.net">htt=
p://andreasohlund.net</a><<a href=3D"http://andreasohlund.net/">http://a=
ndreasohlund.net/</a>><br>
> > > > > > > <a href=3D"http://twitter.com/andreasohl=
und">http://twitter.com/andreasohlund</a><br>
> > > > > > ><br>
> > > > > ><br>
> > > > > ><br>
> > > > > ><br>
> > > > ><br>
> > > > ><br>
> > > > ><br>
> > > > > --<br>
> > > > > <a href=3D"http://andreasohlund.net">http://andrea=
sohlund.net</a><br>
> > > > > <a href=3D"http://twitter.com/andreasohlund">http:=
//twitter.com/andreasohlund</a><br>
> > > > ><br>
> > > ><br>
> > > > <br>
> > > ><br>
> > > <br>
> > > <br>
> > > <br>
> > > -- <br>
> > > <a href=3D"http://andreasohlund.net">http://andreasohlund.ne=
t</a><br>
> > > <a href=3D"http://twitter.com/andreasohlund">http://twitter.=
com/andreasohlund</a><br>
> > ><br>
> > <br>
> ><br>
><br>
<br>
</p>
</div>
=20=20=20=20=20
<!--~-|**|PrettyHtmlStart|**|-~-->
<div style=3D"color: #fff; height: 0;">__._,_.___</div>
=20=20=20=20=20=20=20=20
=20=20
=20=20
<table cellspacing=3D4px style=3D"margin-top: 20px; margin-bottom: 10px=
;">
<tbody>
<tr>
<td style=3D"font-size: 12px; font-family: arial; font-weight: bo=
ld; padding: 7px 5px 5px; color: #FFF; background-color: #F2F2F2; border: 1=
px solid #EAEAEA " >
<a style=3D"text-decoration: none; color: #2D50FD=
" href=3D"http://groups.yahoo.com/group/nservicebus/post;_ylc=3DX3oDMTJyMDR=
rdW5qBF9TAzk3MzU5NzE0BGdycElkAzIxMzgzMTE4BGdycHNwSWQDMTcwNTAwNDc2MwRtc2dJZA=
MxNjg1MgRzZWMDZnRyBHNsawNycGx5BHN0aW1lAzEzNTIyODk3OTU-?act=3Dreply&messageN=
um=3D16852">Reply via web post</a>
</td>
<td style=3D"font-size: 12px; font-family: arial; padding: 7px 5p=
x 5px; color: #FFF; background-color: #F2F2F2; border: 1px solid #EAEAEA; "=
>
<a href=3D"mailto:wernerclau...@yahoo.com?subject=3DRe%3A%20Que=
stion%20about%3A%20Putting%20your%20events%20on%20a%20diet%20when%20using%2=
0CQRS" style=3D"text-decoration: none; color: #2D50FD;">
Reply to sender </a>=20
</td>
<td style=3D"font-size: 12px; font-family: arial; padding: 7px 5p=
x 5px; color: #FFF; background-color: #F2F2F2; border: 1px solid #EAEAEA; "=
>
<a href=3D"mailto:nservice...@yahoogroups.com?subject=3DRe%3A%2=
0Question%20about%3A%20Putting%20your%20events%20on%20a%20diet%20when%20usi=
ng%20CQRS" style=3D"text-decoration: none; color: #2D50FD">
Reply to group </a>=20
</td>
<td style=3D"font-size: 12px; font-family: arial; padding: 7px 5p=
x 5px; color: #FFF; background-color: #F2F2F2; border: 1px solid #EAEAEA; "=
>
<a href=3D"http://groups.yahoo.com/group/nservicebus/post;_ylc=
=3DX3oDMTJmMXI5cWNzBF9TAzk3MzU5NzE0BGdycElkAzIxMzgzMTE4BGdycHNwSWQDMTcwNTAw=
NDc2MwRzZWMDZnRyBHNsawNudHBjBHN0aW1lAzEzNTIyODk3OTU-" style=3D"text-decorat=
ion: none; color: #2D50FD">Start a New Topic</a>
</td>
<td style=3D"font-size: 12px; font-family: arial; padding: 7px 5p=
x 5px; color: #2D50FD; background-color: #F2F2F2; border: 1px solid #EAEAEA=
; " >
<a href=3D"http://groups.yahoo.com/group/nservi=
cebus/message/16224;_ylc=3DX3oDMTM3bnFpdWJyBF9TAzk3MzU5NzE0BGdycElkAzIxMzgz=
MTE4BGdycHNwSWQDMTcwNTAwNDc2MwRtc2dJZAMxNjg1MgRzZWMDZnRyBHNsawN2dHBjBHN0aW1=
lAzEzNTIyODk3OTUEdHBjSWQDMTYyMjQ-" style=3D"text-decoration: none; color: #=
2D50FD;">Messages in this topic</a>
(33)
</td>
</tr>
</tbody>
</table>
=20=20=20=20=20=20=20=20
<!------- Start Nav Bar ------>
<!-- |**|begin egp html banner|**| -->
<!-- |**|end egp html banner|**| -->
<!-- |**|begin egp html banner|**| -->
<div id=3D"ygrp-vital" style=3D"background-color: #f2f2f2; font-family: Ver=
dana; font-size: 10px; margin-bottom: 10px; padding: 10px;">
<span id=3D"vithd" style=3D"font-weight: bold; color: #333; text-tran=
sform: uppercase; ">Recent Activity:</span>
<ul style=3D"list-style-type: none; margin: 0; padding: 0; display: inl=
ine;">
<li style=3D"border-right: 1px solid #000; font-weight: 700; di=
splay: inline; padding: 0 5px; margin-left: 0;">
<span class=3D"cat"><a href=3D"http://groups.yahoo.com/group/nservice=
bus/members;_ylc=3DX3oDMTJnb3Z2dWVoBF9TAzk3MzU5NzE0BGdycElkAzIxMzgzMTE4BGdy=
cHNwSWQDMTcwNTAwNDc2MwRzZWMDdnRsBHNsawN2bWJycwRzdGltZQMxMzUyMjg5Nzk1?o=3D6"=
style=3D"text-decoration: none;">New Members</a></span>
<span class=3D"ct" style=3D"color: #ff7900;">6</span>
</li>
</ul>
=20=20=20=20
<div style=3D"clear: both; padding-top: 2px; color: #1e66ae;">
<a href=3D"http://groups.yahoo.com/group/nservicebus;_ylc=3DX3oDMTJmbm1=
mNWtpBF9TAzk3MzU5NzE0BGdycElkAzIxMzgzMTE4BGdycHNwSWQDMTcwNTAwNDc2MwRzZWMDdn=
RsBHNsawN2Z2hwBHN0aW1lAzEzNTIyODk3OTU-" style=3D"text-decoration: none;">Vi=
sit Your Group</a>
</div>
</div>
=20=20
<div id=3D"ft" style=3D"font-family: Arial; font-size: 11px; margin-top: 5p=
x; padding: 0 2px 0 0; clear: both;">
<a href=3D"http://groups.yahoo.com/;_ylc=3DX3oDMTJlOGF0aGQ1BF9TAzk3MzU5Nz=
E0BGdycElkAzIxMzgzMTE4BGdycHNwSWQDMTcwNTAwNDc2MwRzZWMDZnRyBHNsawNnZnAEc3Rpb=
WUDMTM1MjI4OTc5NQ--" style=3D"float: left;"><img src=3D"http://l.yimg.com/a=
/i/us/yg/logo/us.gif" height=3D"15" width=3D"137" alt=3D"Yahoo! Groups" sty=
le=3D"border: 0;"/></a>
<div style=3D"color: #747575; float: right;">Switch to: <a href=3D"mailto=
:nservicebus-traditio...@yahoogroups.com?subject=3DChange Delivery Format: =
Traditional" style=3D"text-decoration: none;">Text-Only</a>, <a href=3D"mai=
lto:nservicebus-dig...@yahoogroups.com?subject=3DEmail Delivery: Digest" cl=
ass=3D"margin-rt" style=3D"text-decoration: none;">Daily Digest</a> • =
<a href=3D"mailto:nservicebus-unsubscr...@yahoogroups.com?subject=3DUnsubsc=
ribe" style=3D"text-decoration: none;">Unsubscribe</a> • <a href=3D"ht=
tp://docs.yahoo.com/info/terms/" style=3D"text-decoration: none;">Terms of =
Use</a> • <a href=3D"mailto:ygroupsnotificati...@yahoogroups.com?subje=
ct=3DFeedback on the redesigned individual mail v1" style=3D"text-decoratio=
n: none;">Send us Feedback </a></div>
</div>
<!-- |**|end egp html banner|**| -->
</div> <!-- ygrp-msg -->
<!-- Sponsor -->
<!-- |**|begin egp html banner|**| -->
<div id=3D"ygrp-sponsor" style=3D"width:160px; float:right; clear:none; m=
argin:0 0 25px 0; background: #fff;">
<!-- Start Recommendations -->
<div id=3D"ygrp-reco">
</div>
<!-- End Recommendations -->
</div> <!-- |**|end egp html banner|**| -->
<div style=3D"clear:both; color: #FFF; font-size:1px;">.</div>
</div>
<img src=3D"http://geo.yahoo.com/serv?s=3D97359714/grpId=3D21383118/grpsp=
Id=3D1705004763/msgId=3D16852/stime=3D1352289795/nc1=3D3848640/nc2=3D450717=
9/nc3=3D5898816" width=3D"1" height=3D"1"> <br>
<div style=3D"color: #fff; height: 0;">__,_._,___</div>
<!--~-|**|PrettyHtmlEnd|**|-~-->
</body>
<!--~-|**|PrettyHtmlStart|**|-~-->
<head>
<style type=3D"text/css">
<!--
#ygrp-mkp {
border: 1px solid #d8d8d8;
font-family: Arial;
margin: 10px 0;
padding: 0 10px;
}
#ygrp-mkp hr {
border: 1px solid #d8d8d8;
}
#ygrp-mkp #hd {
color: #628c2a;
font-size: 85%;
font-weight: 700;
line-height: 122%;
margin: 10px 0;
}
#ygrp-mkp #ads {
margin-bottom: 10px;
}
#ygrp-mkp .ad {
padding: 0 0;
}
#ygrp-mkp .ad p {
margin: 0;
}
#ygrp-mkp .ad a {
color: #0000ff;
text-decoration: none;
}
#ygrp-sponsor #ygrp-lc {
font-family: Arial;
}
#ygrp-sponsor #ygrp-lc #hd {
margin: 10px 0px;
font-weight: 700;
font-size: 78%;
line-height: 122%;
}
#ygrp-sponsor #ygrp-lc .ad {
margin-bottom: 10px;
padding: 0 0;
}
#actions {
font-family: Verdana;
font-size: 11px;
padding: 10px 0;
}
#activity {
background-color: #e0ecee;
float: left;
font-family: Verdana;
font-size: 10px;
padding: 10px;
}
#activity span {
font-weight: 700;
}
#activity span:first-child {
text-transform: uppercase;
}
#activity span a {
color: #5085b6;
text-decoration: none;
}
#activity span span {
color: #ff7900;
}
#activity span .underline {
text-decoration: underline;
}
.attach {
clear: both;
display: table;
font-family: Arial;
font-size: 12px;
padding: 10px 0;
width: 400px;
}
.attach div a {
text-decoration: none;
}
.attach img {
border: none;
padding-right: 5px;
}
.attach label {
display: block;
margin-bottom: 5px;
}
.attach label a {
text-decoration: none;
}
=20=20
blockquote {
margin: 0 0 0 4px;
}
.bold {
font-family: Arial;
font-size: 13px;
font-weight: 700;
}
.bold a {
text-decoration: none;
}
dd.last p a {
font-family: Verdana;
font-weight: 700;
}
dd.last p span {
margin-right: 10px;
font-family: Verdana;
font-weight: 700;
}
dd.last p span.yshortcuts {
margin-right: 0;
}
div.attach-table div div a {
text-decoration: none;
}
div.attach-table {
width: 400px;
}
div.file-title a, div.file-title a:active, div.file-title a:hover, div.fi=
le-title a:visited {
text-decoration: none;
}
div.photo-title a, div.photo-title a:active, div.photo-title a:hover, div=
.photo-title a:visited {
text-decoration: none;
}
div#ygrp-mlmsg #ygrp-msg p a span.yshortcuts {
font-family: Verdana;
font-size: 10px;
font-weight: normal;
}
.green {
color: #628c2a;
}
.MsoNormal {
margin: 0 0 0 0;
}
o {
font-size: 0;
}
#photos div {
float: left;
width: 72px;
}
#photos div div {
border: 1px solid #666666;
height: 62px;
overflow: hidden;
width: 62px;
}
#photos div label {
color: #666666;
font-size: 10px;
overflow: hidden;
text-align: center;
white-space: nowrap;
width: 64px;
}
#reco-category {
font-size: 77%;
}
#reco-desc {
font-size: 77%;
}
.replbq {
margin: 4px;
}
#ygrp-actbar div a:first-child {
/* border-right: 0px solid #000;*/
margin-right: 2px;
padding-right: 5px;
}
#ygrp-mlmsg {
font-size: 13px;
font-family: Arial, helvetica,clean, sans-serif;
*font-size: small;
*font: x-small;
}
#ygrp-mlmsg table {
font-size: inherit;
font: 100%;
}
#ygrp-mlmsg select, input, textarea {
font: 99% Arial, Helvetica, clean, sans-serif;
}
#ygrp-mlmsg pre, code {
font:115% monospace;
*font-size:100%;
}
#ygrp-mlmsg * {
line-height: 1.22em;
}
#ygrp-mlmsg #logo {
padding-bottom: 10px;
}
#ygrp-msg p a {
font-family: Verdana;
}
#ygrp-msg p#attach-count span {
color: #1E66AE;
font-weight: 700;
}
#ygrp-reco #reco-head {
color: #ff7900;
font-weight: 700;
}
#ygrp-reco {
margin-bottom: 20px;
padding: 0px;
}
#ygrp-sponsor #ov li a {
font-size: 130%;
text-decoration: none;
}
#ygrp-sponsor #ov li {
font-size: 77%;
list-style-type: square;
padding: 6px 0;
}=20
#ygrp-sponsor #ov ul {
margin: 0;
padding: 0 0 0 8px;
}
#ygrp-text {
font-family: Georgia;
}
#ygrp-text p {
margin: 0 0 1em 0;
}
#ygrp-text tt {
font-size: 120%;
}
#ygrp-vital ul li:last-child {
border-right: none !important;=20
}=20
-->
</style>
</head>
<!--~-|**|PrettyHtmlEnd|**|-~-->
</html>
<!-- end group email -->
--D-vFzjt115SSunQJJwLrE6IE7IjMFMqKo5rHNAq--