Message for you, sir! - All Comments

Can your name be a trademark? : South Florida Artist Entrepreneurs

Can your name be a trademark? : South Florida Artist Entrepreneurs — Mon, 18 Aug 2008 13:44:25 GMT

Pingback from Can your name be a trademark? : South Florida Artist Entrepreneurs

re: 10 Things I Hate About Indigo

Alex G — Wed, 21 Nov 2007 14:30:00 GMT

WCF rules my world.

I understand your statement about the domain model infection. Still, ask yourself if your domain entities should really double as datacontracts.

Certainly not for a rich domain model, because entities would need to fulfill both the data and operations contracts. As for an anemic domain model, what do you make of aggregates and lazy loading - those are operations hidden behind properties. And certainly you aren't planning on exposing repositories as operation contracts, that would be extremely silly.

So my answer to you is, leave your domain model intact, keep it in its own assembly. Your data and operations contracts should reside within the Application layer, not the domain layer, the same way your UI should not be directly coupled with your domain layer.

You may also prefer to step-up the architecture to 5 layers and have a service layer between your domain and application layers. In this case the client side has Interface and Application layers, then a big bold separation (in reality, the network sits here), then the server side has Service and Domain layers. Both client and server also have an Infrastructure layer - the infamous boilerplate.

What Eric Evans and Martin Fowler write are not meant as gospel, just inspiration. Adapt so you can leverage technology.

:)

Prince Mathew — Wed, 07 Nov 2007 06:27:00 GMT

Very nice one....thank you..

re: Majoring on the Minors

ros — Mon, 17 Jul 2006 06:39:00 GMT

how to obtain a singleton architecture, without using .NET Remoting

re: [DataContract], the Holy Roman Empire of Distributed Computing

Cordell Lawrence — Wed, 21 Jun 2006 11:07:00 GMT

Just a few thoughts

<quote>
A contract is "an agreement between two or more parties." In most discussions of services, the term contract is used in an entirely inappropriate fashion. Because the consuming side of the "contract" is unknown at the time the "contract" is published, we should hardly be calling this thing a contract.
</quote>

I agree that the word ‘contract’ can lead to some semantic conflict there, ‘Terms of Use’ seem to be a better suited phrase i.e. The service publicly states, “I’m am a service, these are my operations, this is the data and the format that I will accept. I can only understand your intent if you send me a message with the following operation with the respective data in the format described …” etc. However disagree that it is entirely inappropriate. Not all contracts are drafted with explicit knowledge of universe of entities/persons that will agree to/sign said contract. Some “None Disclosure Agreement” contracts leave no room for discussion, either you accept the terms of us working together specified by the contract or you don’t, while others can be negotiated/customized. I think the use of the word contract here is describes these ‘generic’ contracts type, those that employees sign when joining an organization that aren’t re-written for every individual joining the company.

<quote>
Rather than a system that, like both Indigo and ASMX, completely hides the transformation between the messages and our internal processing model, we need a system that surfaces that transformation to the developer. The transformation between the external messages and internal processing is a key part of the business logic of any service. Having to control that transformation indirectly through attributes is slow, frustrating, and error-prone.
</quote>

Interesting, I would like to find out more about why you think this. I rather like the whole ‘Services are atomic’ notion and don’t really care about the other guys internal representation of the message.

For the most part I agree with the rest of the post :) In systems oriented around message exchange developers should have access to the message as a first class citizens and not some entity of another type system that I hope gets rendered as my message after some processing. That said though, I think they've done a pretty good job which covers most of the simpler service contract requirements. I hope better tools are coming soon though and smarter code generators so that I can design and view my messages as XML (if this continues to be the service lingua franca) and be confident when manipulating my internal object representation that it will be rendered to my message correctlyon the wire.

Consideration after building a distributed application

Document Security — Sat, 27 May 2006 05:46:00 GMT

Distributed application is great when you are creating software for more than one user and they will use it at different location. OODA is nice flowcharting showing the flow of data. Security is major concern in distributed application.

re: How to build a distributed application: Why Practice Matters

jPrasaad — Thu, 18 May 2006 10:31:00 GMT

Interesting article. Awaiting for your article on Communications API.

re: How to build a distributed application: Preface

steve — Sun, 14 May 2006 22:40:00 GMT

Sounds interesting...will be following

re: How to build a distributed application: Preface

somayeh — Wed, 19 Apr 2006 19:46:00 GMT

hello pleaze tell me what is distirbuted application and how can i build distributed application
thanks

re: Helping Don spend $100

John Williams — Tue, 21 Mar 2006 02:08:00 GMT

Thought you were using C#? You're back to VB are you? I wonder how many others who went to C# switch back?

4. $129 for Visual Assist X; to make typing C# as easy, if not easier, than VB. ;-)

Interesting Finds

Jason Haley — Sun, 19 Mar 2006 11:01:00 GMT

re: How to build a distributed application: Introduction

Ali Pasha — Sat, 28 Jan 2006 22:19:00 GMT

I agree with Rob. Before you go into the OODA description, can you please describe what other frameworks you considered and why you found them lacking?

re: How to build a distributed application: Introduction

Rob — Thu, 19 Jan 2006 21:54:00 GMT

John

My 2c.
I'm pretty happy with the OODA description and don't feel that more examples will add much.
As far as frameworks go, I think that they are a bit like opinions - everybody has one.

re: How to build a distributed application: Introduction

John CJ — Thu, 19 Jan 2006 21:49:00 GMT

I've fixed it now. Let me know if it still doesn't work.

re: How to build a distributed application: Introduction

Rob — Thu, 19 Jan 2006 21:46:00 GMT

Can't see the image John.