I dived into the MEF session with Glenn Block, Sourabh Mathur, Brian Henderson, and others.  Glenn covered the basic architectural ideas of MEF and then dived into a few examples.

• Is a framework around decoupling components.
• Built around the idea of discoverable type systems.
• Traditional extensibility mechanisms have a host and the respective extensions, commonly linking these two aspects with a form of registration.
• MEF removes the need for the registration part of the architecture and uses a contract.
• At some point with MEF you get down to parts, which removes even the complexity of a host or extensions, but a truly evolvable architecture based on natural growth of parts.
• Also referred to as the framework that removes the “new” keyword.
• The idea is that parts pull together other parts that they need.  Between each part is a contract.
• Each part has imports or exports for the parts it needs or the things it offers.

If one checks out the MEF Codeplex Site you will find a host of additional information.  The framework download also has some decent examples that help one get kick started.

This is a topic I know nothing about, and thus, may be supremely disparate notes.  Have fun translating.  : )   . . .and coolness that the session is well past capacity.

• Separates things form the UI and everything that needs populated is done through commands.  The domain and reports have separate storage.
• Events populate these stores of data, such as “sold event”.
• What it looks like, is that the domain controls the requests by event, which would be a product order or something similar.
• Event sourcing is a key element of the logic.
• DDD (Domain Driven Design) is part of the core basis for this methodology/structure.
• The architecture/methodology/structure is perfect for blade style plugin hardware as needed.
• Good blog entry DDDD: Why I love CQRS and another Command and Query Responsibility Segregation (CQRS), more, CQRS ? la Greg Young, a bit by Udi Dahan and there are more.  Google, Bing, etc are there for a reason.

It appears the core underpinning architectural element of this is the break out of unique identifiable actions, or I suppose better described as events.  Those events then act upon specific pipelines such as read requests, write requests, etc.  I will be doing more research on this topic and will have something written up shortly.  At this time it seems like nothing new, just a large architectural break out of identifiable needs of the entire enterprise system.  The reporting is in one segment of the architecture, the domain is in another, hydration broken out to interfaces, and events are executed to incur events on the Reports, or what appears by the description to be events on the domain.

Anyway, more to come on this later.

Below are the notes I made in the REST Architecture Session I helped kick off with Andrew.

• RSS, ATOM, and such needed for better discovery.  i.e. there still is a need for some type of discovery.
• Difficult is modeling behaviors in a RESTful way.  ??  Invoking some type of state against an object.  For instance in the case of a POST vs. a GET.  The GET is easy, comes back as is, but what about a POST, which often changes some state or something.
• Challenge is doing multiple workflows with stateful workflows.  How does batch work.  Maybe model the batch as a resource.
• Frameworks aren?t particularly part of REST, REST is REST.  But point argued that REST is modeled, or part of modeling a state machine of some sort? ?
• Nothing is 100% reliable w/ REST ? comparisons drawn with TCP/IP.  Sufficient probability is made however for the communications, but the idea of a possible failure has to be built into the usage model of REST.
• Ruby on Rails / RESTfully, and others used.  What were their issues, what do they do.  ATOM feeds, object serialized, using LINQ to XML w/ this.  No state machine libraries.
• Idempotent areas around REST and single change POST changes are inherent in the architecture.
• REST ? one of the constrained languages is for the interaction w/ the system.  Limiting what can be done on the resources.  – disagreement, there is no agreed upon REST verbs.
• Sam Ruby ? RESTful services.  Expanded the verbs within REST/HTTP pushes you off the web.  Of the existing verbs POST leaves the most up for debate.
• Robert Reem used Factory to deal with the POST to handle the new state.  The POST identifying what it just did by the return.
• Different states are put into POST, so that new prospective verbs, without creating verbs for REST/HTTP can be used to advantage without breaking universal clients.
• Biggest issue with REST services is their lack of state, yet it is also one of their biggest strengths.  What happens is that the client takes up the often onerous task of handling all state, state machines, and other extraneous resource management.  All the GETs, POSTs, DELETEs, INSERTs get all pushed into abstraction.  My 2 cents is that this in a way ends up pushing a huge proprietary burden onto the REST services often removing the point of REST to be simple and to the point.
• WADL does provide discovery and some state control (sort of?)
• Statement made, “WADL” isn’t needed.  The JSON, XML, or other client side returned data handles this.

I then applied the law of 2 feet rule for myself and headed to finish up these notes, post to the Wiki, and figure out what I was going to do next.  For the original Wiki entry check it out here.

I will be adding more to this post with a subsequent post.  Please do feel free to post your thoughts and ideas about this, as I am sure everyone in the session will have more for elaboration.

I have been building software for over 10 years, and I just realized as time has flown while having fun, for almost 14 years.  It has been awesome, but jeez, what a way to remind myself that I am not the young blood of the development teams anymore.

With that in mind it made me think, that sometimes the truth is a rough thing that most people seem to suppress in work environments.  Strangely enough this tends to happen in software development a lot (I’m sure a lot of other occupations also).