You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> on 2013/06/28 14:51:56 UTC
Microsoft CRM as a reference architecture (part 2)
Some complementary links for avoiding to be classified as spam.
INFRASTRUCTURE LAYER
- Workflows: http://msdn.microsoft.com/en-us/library/cc151140.aspx
- Security Model: http://msdn.microsoft.com/en-us/library/bb955124.aspx
- Plugins and Internal Event Service: http://msdn.microsoft.com/en-us/library/cc151086.aspx
PRESENTATION - VIEWER LAYER
- User interface style guide (that could "inspire" Apache Isis user interface "sections"):
http://msdn.microsoft.com/en-us/library/cc150858.aspx
- Client extensions (Javascript events, etc.):
http://msdn.microsoft.com/en-us/library/cc150828.aspx
- Future user interface they will incorporate in next major version:
http://www.preact.co.uk/preact_blog/dynamics-crm-flow-interface
Main link to the MS CRM SDK:
http://msdn.microsoft.com/en-us/library/bb928212.aspx
Re: Microsoft CRM as a reference architecture (part 2)
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
OK, fair enough. I suspected I hadn't quite understood what you were
saying.
Thx
On 30 June 2013 22:42, David Tildesley <da...@yahoo.co.nz> wrote:
> Hi Dan,
>
> No, I wasn't saying that. The UI code is definitely using ISIS.
>
> At this stage we are only processing files (via Camel) and data in staging
> tables with this UI code.
>
> Regards,
> David.
>
>
> >If I understand you, are you saying that your UI code is not Isis; it's a
> >bespoke layer handling the JMS messages etc? If that's the case, then I'm
> >curious to know (I can't remember us discussing this) how you ensure that
> >all the declarative business rules are enforced in your non Isis UI code?
> >One approach is to use the WrapperFactory, but I imagine I'd've remember
> >you saying if you were using that approach.
>
> Dan
>
> [snip]
> > David.
> >
>
Re: Microsoft CRM as a reference architecture (part 2)
Posted by David Tildesley <da...@yahoo.co.nz>.
Hi Dan,
No, I wasn't saying that. The UI code is definitely using ISIS.
At this stage we are only processing files (via Camel) and data in staging tables with this UI code.
Regards,
David.
>If I understand you, are you saying that your UI code is not Isis; it's a
>bespoke layer handling the JMS messages etc? If that's the case, then I'm
>curious to know (I can't remember us discussing this) how you ensure that
>all the declarative business rules are enforced in your non Isis UI code?
>One approach is to use the WrapperFactory, but I imagine I'd've remember
>you saying if you were using that approach.
Dan
[snip]
> David.
>
Re: Microsoft CRM as a reference architecture (part 2)
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 29 June 2013 21:32, David Tildesley <da...@yahoo.co.nz> wrote:
> We separated out the "UI layer objects" from the domain layer objects via
> packaging.
> I would like to see a more enforced separation - I'm not sure how to go
> about it though.
>
Me neither. I'm not sure that Isis should have anything to enforce such
separation - I think you can achieve all that you want with Maven modules.
>
> With a system oriented UI (could be invoked in any number of ways: soap
> web service, JMS message, ...)
> as with a human UI, the trick is not to allow bleeding of domain business
> logic in to the UI
> and ensure that the domain never depends on the UI. This way, you can bolt
> on any number of UI's to the same domain layer.
>
>
If I understand you, are you saying that your UI code is not Isis; it's a
bespoke layer handling the JMS messages etc? If that's the case, then I'm
curious to know (I can't remember us discussing this) how you ensure that
all the declarative business rules are enforced in your non Isis UI code?
One approach is to use the WrapperFactory, but I imagine I'd've remember
you saying if you were using that approach.
Dan
[snip]
> David.
>
Re: Microsoft CRM as a reference architecture (part 2)
Posted by David Tildesley <da...@yahoo.co.nz>.
I should add to this because someone will point out the seemingly obvious:
Why not call the generated restful objects API?
The RO API that is generated reflects the domain behaviour.
Generally when providing a service to a service consumer(s)
you are doing a lot of aggregation of fine-grained domain behaviour to
coarse-grained service behaviour on a "large" non-OO information model.
And so you would naturally gravitate to the same method
as described in my post below and end up with "UI" "objects" that do
the coarse-grained aggregation of behaviour and data
but also implement ISIS services so that "their" (coarse-grained)
RO API get's presented for the service consumer(s).
btw, in our use cases, with processing the files and staging tables, using the RO API was pointless because
the service "consumers" are in the same application and java to java is far more
efficient and you get atomic transaction behaviour as part of the bargain.
David.
________________________________
From: David Tildesley <da...@yahoo.co.nz>
To: "users@isis.apache.org" <us...@isis.apache.org>
Sent: Sunday, 30 June 2013 8:32 AM
Subject: Re: Microsoft CRM as a reference architecture (part 2)
Hi Oscar, Dan,
We've successfully used Quartz and Apache Camel in an application using ISIS.
I had a conversation on this list with Dan a few months back about calling the ISIS domain
from what is effectively a "non-human oriented" UI layer.
We separated out the "UI layer objects" from the domain layer objects via packaging.
I would like to see a more enforced separation - I'm not sure how to go about it though.
The aim is to maintain separation of concerns and thereby protect the rich domain as per this app layer pattern:
UI --> Rich Domain <--SI
As Richard Pawson said in his replies to comments in that same blog:
"Use-case driven analysis leads to poor object modelling in my experience. My position on this is that use-cases should be used to validate the object model, not to identify it."
With a system oriented UI (could be invoked in any number of ways: soap web service, JMS message, ...)
as with a human UI, the trick is not to allow bleeding of domain business logic in to the UI
and ensure that the domain never depends on the UI. This way, you can bolt on any number of UI's to the same domain layer.
While what we have done (using packaging) works, maybe there could be a better (ISIS) way of enforcing separation of concerns?
Also it would be very nice to be able to independently package up the domain layer, SI in separate jar for reuse in different application contexts.
(by doing this you are removing all doubt about where the layer concerns are)
btw, in our UI we are processing files (using Camel) triggered by a schedule event (quartz) and also (another use case) processing staging tables,
calling domain business objects behaviour as required.
David.
________________________________
Oscar wrote:
>Really nice the wayback machine. I remember read about it quite time ago, but never used it... and works like a charm!
>I didn't pretended to open a debate about the role of Workflows on DDD or NakedObjects.
>It was just an example of an infrastructure service provided by MS CRM that could be also a higher-level "Infrastructure Service" available on Isis.
>My intention was to open a debate about the possibility that "higher-level" building blocks were also part of Isis,
>such as a collection of "infrastructure level services" (like Dan's Email Service, the Event Service recently
> commited by Dan, the publish-subscribe service, a Geographic Mapping Service - available on different ,
>the Workflow service, a generic interface to a SMS Service with implementations based on different providers -
>such as Twilio, or Apache Camel - useful in multiple uses cases -, etc.).
...
Re: Microsoft CRM as a reference architecture (part 2)
Posted by David Tildesley <da...@yahoo.co.nz>.
Hi Oscar, Dan,
We've successfully used Quartz and Apache Camel in an application using ISIS.
I had a conversation on this list with Dan a few months back about calling the ISIS domain
from what is effectively a "non-human oriented" UI layer.
We separated out the "UI layer objects" from the domain layer objects via packaging.
I would like to see a more enforced separation - I'm not sure how to go about it though.
The aim is to maintain separation of concerns and thereby protect the rich domain as per this app layer pattern:
UI --> Rich Domain <--SI
As Richard Pawson said in his replies to comments in that same blog:
"Use-case driven analysis leads to poor object modelling in my experience. My position on this is that use-cases should be used to validate the object model, not to identify it."
With a system oriented UI (could be invoked in any number of ways: soap web service, JMS message, ...)
as with a human UI, the trick is not to allow bleeding of domain business logic in to the UI
and ensure that the domain never depends on the UI. This way, you can bolt on any number of UI's to the same domain layer.
While what we have done (using packaging) works, maybe there could be a better (ISIS) way of enforcing separation of concerns?
Also it would be very nice to be able to independently package up the domain layer, SI in separate jar for reuse in different application contexts.
(by doing this you are removing all doubt about where the layer concerns are)
btw, in our UI we are processing files (using Camel) triggered by a schedule event (quartz) and also (another use case) processing staging tables,
calling domain business objects behaviour as required.
David.
________________________________
Oscar wrote:
>Really nice the wayback machine. I remember read about it quite time ago, but never used it... and works like a charm!
>I didn't pretended to open a debate about the role of Workflows on DDD or NakedObjects.
>It was just an example of an infrastructure service provided by MS CRM that could be also a higher-level "Infrastructure Service" available on Isis.
>My intention was to open a debate about the possibility that "higher-level" building blocks were also part of Isis,
>such as a collection of "infrastructure level services" (like Dan's Email Service, the Event Service recently
> commited by Dan, the publish-subscribe service, a Geographic Mapping Service - available on different ,
>the Workflow service, a generic interface to a SMS Service with implementations based on different providers -
>such as Twilio, or Apache Camel - useful in multiple uses cases -, etc.).
...
Re: Microsoft CRM as a reference architecture (part 2)
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Oscar,
This idea has come up several times before; my response has always been ...
go build it and then we can take it from there.
In terms of the recent services I've been adding into the Isis applib,
these are all "technical" / integration focused. They all also are
pluggable; there's a default implementation, but anyone can provide an
alternative implementation. I'm starting to think of these as part of
Isis' "SPI", rather than "API".
I see less value in the higher level domain-oriented concepts that you
describe; as David suggests, every domain is always slightly different to
the next. The Shiro/security one is perhaps a candidate, but even then
there are going to be multiple ways to skin that particular cat.
For now, I think that github is a good enough place for these potentially
reusable components to reside. As you know, the various extensions I've
written for Isis live here, ie the isis-wicket-* repos [1].
I've just learnt from Jeroen that we've got permission to formally open
source Estatio (the estate management app that we've been building), so
that will be appearing on github shortly too. Not sure what the license is
yet, but most recent indications were it would almost certainly be Apache.
There are definitely some modules in there that others might want to
borrow; with an Apache license they would be free to plunder and adapt as
they see fit.
If we start getting lots of good components, then it might make sense to
bring them together, a bit like Wicket [2] has done with its wicketstuff
companion project [3]. I don't have anything against that either. But I
don't, for myself, think that they should be part of Isis itself.
Cheers
Dan
[1] https://github.com/danhaywood?tab=repositories
[2] http://wicket.apache.org/
[3] https://github.com/wicketstuff
On 29 June 2013 15:24, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
>
> Really nice the wayback machine. I remember read about it quite time ago,
> but never used it... and works like a charm!
>
> I didn't pretended to open a debate about the role of Workflows on DDD or
> NakedObjects. It was just an example of an infrastructure service provided
> by MS CRM that could be also a higher-level "Infrastructure Service"
> available on Isis.
>
> My intention was to open a debate about the possibility that
> "higher-level" building blocks were also part of Isis, such as a collection
> of "infrastructure level services" (like Dan's Email Service, the Event
> Service recently commited by Dan, the publish-subscribe service, a
> Geographic Mapping Service - available on different , the Workflow service,
> a generic interface to a SMS Service with implementations based on
> different providers - such as Twilio, or Apache Camel - useful in multiple
> uses cases -, etc.).
>
> Also, some generic "infrastructure domain services" (such as the recently
> commented "Shiro's Security Domain Service", or a "Human Task Service" -
> more on this after).
>
> All them can be used as "infrastructure services" on a great variety of
> Bounded Contexts implementing Domains.
>
> If not possible to be part of Isis, at least been available on a
> "centralized" git repository that can be used and growth by the community.
> Same happens with different implementation examples that have been made by
> different community members that are hard to be found.
>
> We could contribute some of them (like Twilio's SMS Service or the Human
> Task Service) and I'm sure there are also other members with valuable
> services.
>
>
> Together with the "infrastructure services" I mentioned other parts of MS
> CRM architecture, a framework envisioned for building custom solutions over
> it. Specially relevant are those regarding the User Interface. What I read
> about the DHTMLX viewer, its DSL and the custom "scripting" capabilities is
> really close to the current MS CRM "viewer's" architecture. They have an
> editor to customize each entity view, but the technology is quite close to
> Maurizio's one.
>
> The fact is that they also have a user interface "metamodel" that allows
> the User Interface representation to be customized at real-time (also
> really close to what Maurizio showed on his demo):
>
> - MS CRM "Entity Forms" internals:
> http://msdn.microsoft.com/en-us/library/gg334527.aspx
>
> - MS CRM "Entity Forms" metamodel:
> http://msdn.microsoft.com/en-us/library/gg327975.aspx
>
> - MS CRM different "Entity Forms" presentations available:
> http://msdn.microsoft.com/en-us/library/hh913610.aspx
>
>
> And that DSL / FormXml can be associated through the "Metadata Service" /
> Isis ObjectRepresentation with the Entity, including the possibility to
> associate custom designs with different Security Roles:
>
> - MS CRM "Role Based Forms":
> http://msdn.microsoft.com/en-us/library/gg309517.aspx
>
> Here is a link to all customizations available on MS CRM 2011:
>
> http://msdn.microsoft.com/en-us/library/gg328235.aspx
>
>
>
>
> Regarding the "Human Tasks Service" I mentioned before and on the previous
> email, it was just an example. But I've found that it's really close to
> what Richard Pawnson's propose on his post as an example of what has worked
> for him. See the following documentation about the JBoss JBPM Human Task
> Service (the one we have been using, with Apache license). JBPM contains
> both an automated workflow implementation based on BPMN (what Richard
> thinks is not working :-), and also a Human Services implementation based
> on the WS-HumanTask (WS-HT) specification:
>
> http://docs.jboss.org/jbpm/v5.2/userguide/ch.Human_Tasks.html#d0e3725
>
> We are using it as the basis of a "small" Ticketing/ServiceDesk Bounded
> Context and works really well.
>
>
> The only intention with all this is just to show a proven architecture
> that has been commercially successful that contains building blocks quite
> close to those present or planned for Isis and that can serve as "an
> inspiration" for a future roadmap.
> Some things are made differently on Isis (are really simplified), but some
> others can show a higher-level path that can provide higher value (more
> closely aligned with business solutions needs) to Apache Isis users.
>
> Hope this helps,
>
> Oscar
>
>
> El 29/06/2013, a las 11:31, Dan Haywood <da...@haywood-associates.co.uk>
> escribió:
>
> > You can read it via way back machine if you really want... I re-read it
> > again myself this morning that way.
> >
> > Sorry to be brief, sent from my phone
> > On 29 Jun 2013 10:02, "GESCONSULTOR" <o....@gesconsultor.com> wrote:
> >
> >> Thanks for the link, david.
> >>
> >> The blog's database it's down and the post it's not showed.
> >>
> >> Enviado desde mi iPhone
> >>
> >> El 29/06/2013, a las 02:10, David Tildesley <da...@yahoo.co.nz>
> >> escribió:
> >>
> >>> Read Richard Pawson's
> >>
> http://blog.nakedobjects.org/2007/11/19/workflow-a-triumph-of-hope-over-experience/
> >>>
> >>> DDD is how you do this stuff and a problem domain is specific to your
> >> business and nobody elses. Which is why ISIS is so appealing in the
> first
> >> place.
> >>>
> >>> David.
> >>>
> >>>
> >>> ________________________________
> >>> From: GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>
> >>> To: "users@isis.apache.org" <us...@isis.apache.org>
> >>> Sent: Saturday, 29 June 2013 12:51 AM
> >>> Subject: Microsoft CRM as a reference architecture (part 2)
> >>>
> >>>
> >>>
> >>> Some complementary links for avoiding to be classified as spam.
> >>>
> >>>
> >>> INFRASTRUCTURE LAYER
> >>>
> >>> - Workflows: http://msdn.microsoft.com/en-us/library/cc151140.aspx
> >>>
> >>> - Security Model:
> http://msdn.microsoft.com/en-us/library/bb955124.aspx
> >>>
> >>> - Plugins and Internal Event Service:
> >> http://msdn.microsoft.com/en-us/library/cc151086.aspx
> >>>
> >>>
> >>> PRESENTATION - VIEWER LAYER
> >>>
> >>> - User interface style guide (that could "inspire" Apache Isis user
> >> interface "sections"):
> >>> http://msdn.microsoft.com/en-us/library/cc150858.aspx
> >>>
> >>> - Client extensions (Javascript events, etc.):
> >>> http://msdn.microsoft.com/en-us/library/cc150828.aspx
> >>>
> >>> - Future user interface they will incorporate in next major version:
> >>> http://www.preact.co.uk/preact_blog/dynamics-crm-flow-interface
> >>>
> >>>
> >>>
> >>>
> >>> Main link to the MS CRM SDK:
> >>>
> >>> http://msdn.microsoft.com/en-us/library/bb928212.aspx
> >>
>
>
Re: Microsoft CRM as a reference architecture (part 2)
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Really nice the wayback machine. I remember read about it quite time ago, but never used it... and works like a charm!
I didn't pretended to open a debate about the role of Workflows on DDD or NakedObjects. It was just an example of an infrastructure service provided by MS CRM that could be also a higher-level "Infrastructure Service" available on Isis.
My intention was to open a debate about the possibility that "higher-level" building blocks were also part of Isis, such as a collection of "infrastructure level services" (like Dan's Email Service, the Event Service recently commited by Dan, the publish-subscribe service, a Geographic Mapping Service - available on different , the Workflow service, a generic interface to a SMS Service with implementations based on different providers - such as Twilio, or Apache Camel - useful in multiple uses cases -, etc.).
Also, some generic "infrastructure domain services" (such as the recently commented "Shiro's Security Domain Service", or a "Human Task Service" - more on this after).
All them can be used as "infrastructure services" on a great variety of Bounded Contexts implementing Domains.
If not possible to be part of Isis, at least been available on a "centralized" git repository that can be used and growth by the community. Same happens with different implementation examples that have been made by different community members that are hard to be found.
We could contribute some of them (like Twilio's SMS Service or the Human Task Service) and I'm sure there are also other members with valuable services.
Together with the "infrastructure services" I mentioned other parts of MS CRM architecture, a framework envisioned for building custom solutions over it. Specially relevant are those regarding the User Interface. What I read about the DHTMLX viewer, its DSL and the custom "scripting" capabilities is really close to the current MS CRM "viewer's" architecture. They have an editor to customize each entity view, but the technology is quite close to Maurizio's one.
The fact is that they also have a user interface "metamodel" that allows the User Interface representation to be customized at real-time (also really close to what Maurizio showed on his demo):
- MS CRM "Entity Forms" internals: http://msdn.microsoft.com/en-us/library/gg334527.aspx
- MS CRM "Entity Forms" metamodel: http://msdn.microsoft.com/en-us/library/gg327975.aspx
- MS CRM different "Entity Forms" presentations available: http://msdn.microsoft.com/en-us/library/hh913610.aspx
And that DSL / FormXml can be associated through the "Metadata Service" / Isis ObjectRepresentation with the Entity, including the possibility to associate custom designs with different Security Roles:
- MS CRM "Role Based Forms": http://msdn.microsoft.com/en-us/library/gg309517.aspx
Here is a link to all customizations available on MS CRM 2011:
http://msdn.microsoft.com/en-us/library/gg328235.aspx
Regarding the "Human Tasks Service" I mentioned before and on the previous email, it was just an example. But I've found that it's really close to what Richard Pawnson's propose on his post as an example of what has worked for him. See the following documentation about the JBoss JBPM Human Task Service (the one we have been using, with Apache license). JBPM contains both an automated workflow implementation based on BPMN (what Richard thinks is not working :-), and also a Human Services implementation based on the WS-HumanTask (WS-HT) specification:
http://docs.jboss.org/jbpm/v5.2/userguide/ch.Human_Tasks.html#d0e3725
We are using it as the basis of a "small" Ticketing/ServiceDesk Bounded Context and works really well.
The only intention with all this is just to show a proven architecture that has been commercially successful that contains building blocks quite close to those present or planned for Isis and that can serve as "an inspiration" for a future roadmap.
Some things are made differently on Isis (are really simplified), but some others can show a higher-level path that can provide higher value (more closely aligned with business solutions needs) to Apache Isis users.
Hope this helps,
Oscar
El 29/06/2013, a las 11:31, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> You can read it via way back machine if you really want... I re-read it
> again myself this morning that way.
>
> Sorry to be brief, sent from my phone
> On 29 Jun 2013 10:02, "GESCONSULTOR" <o....@gesconsultor.com> wrote:
>
>> Thanks for the link, david.
>>
>> The blog's database it's down and the post it's not showed.
>>
>> Enviado desde mi iPhone
>>
>> El 29/06/2013, a las 02:10, David Tildesley <da...@yahoo.co.nz>
>> escribió:
>>
>>> Read Richard Pawson's
>> http://blog.nakedobjects.org/2007/11/19/workflow-a-triumph-of-hope-over-experience/
>>>
>>> DDD is how you do this stuff and a problem domain is specific to your
>> business and nobody elses. Which is why ISIS is so appealing in the first
>> place.
>>>
>>> David.
>>>
>>>
>>> ________________________________
>>> From: GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>
>>> To: "users@isis.apache.org" <us...@isis.apache.org>
>>> Sent: Saturday, 29 June 2013 12:51 AM
>>> Subject: Microsoft CRM as a reference architecture (part 2)
>>>
>>>
>>>
>>> Some complementary links for avoiding to be classified as spam.
>>>
>>>
>>> INFRASTRUCTURE LAYER
>>>
>>> - Workflows: http://msdn.microsoft.com/en-us/library/cc151140.aspx
>>>
>>> - Security Model: http://msdn.microsoft.com/en-us/library/bb955124.aspx
>>>
>>> - Plugins and Internal Event Service:
>> http://msdn.microsoft.com/en-us/library/cc151086.aspx
>>>
>>>
>>> PRESENTATION - VIEWER LAYER
>>>
>>> - User interface style guide (that could "inspire" Apache Isis user
>> interface "sections"):
>>> http://msdn.microsoft.com/en-us/library/cc150858.aspx
>>>
>>> - Client extensions (Javascript events, etc.):
>>> http://msdn.microsoft.com/en-us/library/cc150828.aspx
>>>
>>> - Future user interface they will incorporate in next major version:
>>> http://www.preact.co.uk/preact_blog/dynamics-crm-flow-interface
>>>
>>>
>>>
>>>
>>> Main link to the MS CRM SDK:
>>>
>>> http://msdn.microsoft.com/en-us/library/bb928212.aspx
>>
Re: Microsoft CRM as a reference architecture (part 2)
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
You can read it via way back machine if you really want... I re-read it
again myself this morning that way.
Sorry to be brief, sent from my phone
On 29 Jun 2013 10:02, "GESCONSULTOR" <o....@gesconsultor.com> wrote:
> Thanks for the link, david.
>
> The blog's database it's down and the post it's not showed.
>
> Enviado desde mi iPhone
>
> El 29/06/2013, a las 02:10, David Tildesley <da...@yahoo.co.nz>
> escribió:
>
> > Read Richard Pawson's
> http://blog.nakedobjects.org/2007/11/19/workflow-a-triumph-of-hope-over-experience/
> >
> > DDD is how you do this stuff and a problem domain is specific to your
> business and nobody elses. Which is why ISIS is so appealing in the first
> place.
> >
> > David.
> >
> >
> > ________________________________
> > From: GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>
> > To: "users@isis.apache.org" <us...@isis.apache.org>
> > Sent: Saturday, 29 June 2013 12:51 AM
> > Subject: Microsoft CRM as a reference architecture (part 2)
> >
> >
> >
> > Some complementary links for avoiding to be classified as spam.
> >
> >
> > INFRASTRUCTURE LAYER
> >
> > - Workflows: http://msdn.microsoft.com/en-us/library/cc151140.aspx
> >
> > - Security Model: http://msdn.microsoft.com/en-us/library/bb955124.aspx
> >
> > - Plugins and Internal Event Service:
> http://msdn.microsoft.com/en-us/library/cc151086.aspx
> >
> >
> > PRESENTATION - VIEWER LAYER
> >
> > - User interface style guide (that could "inspire" Apache Isis user
> interface "sections"):
> > http://msdn.microsoft.com/en-us/library/cc150858.aspx
> >
> > - Client extensions (Javascript events, etc.):
> > http://msdn.microsoft.com/en-us/library/cc150828.aspx
> >
> > - Future user interface they will incorporate in next major version:
> > http://www.preact.co.uk/preact_blog/dynamics-crm-flow-interface
> >
> >
> >
> >
> > Main link to the MS CRM SDK:
> >
> > http://msdn.microsoft.com/en-us/library/bb928212.aspx
>
Re: Microsoft CRM as a reference architecture (part 2)
Posted by GESCONSULTOR <o....@gesconsultor.com>.
Thanks for the link, david.
The blog's database it's down and the post it's not showed.
Enviado desde mi iPhone
El 29/06/2013, a las 02:10, David Tildesley <da...@yahoo.co.nz> escribió:
> Read Richard Pawson's http://blog.nakedobjects.org/2007/11/19/workflow-a-triumph-of-hope-over-experience/
>
> DDD is how you do this stuff and a problem domain is specific to your business and nobody elses. Which is why ISIS is so appealing in the first place.
>
> David.
>
>
> ________________________________
> From: GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>
> To: "users@isis.apache.org" <us...@isis.apache.org>
> Sent: Saturday, 29 June 2013 12:51 AM
> Subject: Microsoft CRM as a reference architecture (part 2)
>
>
>
> Some complementary links for avoiding to be classified as spam.
>
>
> INFRASTRUCTURE LAYER
>
> - Workflows: http://msdn.microsoft.com/en-us/library/cc151140.aspx
>
> - Security Model: http://msdn.microsoft.com/en-us/library/bb955124.aspx
>
> - Plugins and Internal Event Service: http://msdn.microsoft.com/en-us/library/cc151086.aspx
>
>
> PRESENTATION - VIEWER LAYER
>
> - User interface style guide (that could "inspire" Apache Isis user interface "sections"):
> http://msdn.microsoft.com/en-us/library/cc150858.aspx
>
> - Client extensions (Javascript events, etc.):
> http://msdn.microsoft.com/en-us/library/cc150828.aspx
>
> - Future user interface they will incorporate in next major version:
> http://www.preact.co.uk/preact_blog/dynamics-crm-flow-interface
>
>
>
>
> Main link to the MS CRM SDK:
>
> http://msdn.microsoft.com/en-us/library/bb928212.aspx
Re: Microsoft CRM as a reference architecture (part 2)
Posted by David Tildesley <da...@yahoo.co.nz>.
Read Richard Pawson's http://blog.nakedobjects.org/2007/11/19/workflow-a-triumph-of-hope-over-experience/
DDD is how you do this stuff and a problem domain is specific to your business and nobody elses. Which is why ISIS is so appealing in the first place.
David.
________________________________
From: GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>
To: "users@isis.apache.org" <us...@isis.apache.org>
Sent: Saturday, 29 June 2013 12:51 AM
Subject: Microsoft CRM as a reference architecture (part 2)
Some complementary links for avoiding to be classified as spam.
INFRASTRUCTURE LAYER
- Workflows: http://msdn.microsoft.com/en-us/library/cc151140.aspx
- Security Model: http://msdn.microsoft.com/en-us/library/bb955124.aspx
- Plugins and Internal Event Service: http://msdn.microsoft.com/en-us/library/cc151086.aspx
PRESENTATION - VIEWER LAYER
- User interface style guide (that could "inspire" Apache Isis user interface "sections"):
http://msdn.microsoft.com/en-us/library/cc150858.aspx
- Client extensions (Javascript events, etc.):
http://msdn.microsoft.com/en-us/library/cc150828.aspx
- Future user interface they will incorporate in next major version:
http://www.preact.co.uk/preact_blog/dynamics-crm-flow-interface
Main link to the MS CRM SDK:
http://msdn.microsoft.com/en-us/library/bb928212.aspx