It took me a good 15 minutes to figure out how to get a list of table names with schema’s from sql 2005..jeez. not good.
I would not be surprised if its actually wrong. Anyway, whats with hiding the sys tables? Weird.
select ss.name ‘schema’, so.name ‘table’
from sysobjects so
inner join sys.schemas ss
on so.uid = ss.schema_id
where so.xtype = ‘U’
order by ss.name, so.name
We are at a cross roads on our current project where:
• We are hitting limitation of our current architecture and framework
• We need to be able to facilitate service orientation and be come part of an SOA environment
• We are not completely swamped with work
• Bugs are lingering in a hard to understand convoluted stack
We have an NHibernate /Oracle based distributed (client – server) application.
Current concrete problems:
• We pass entities around across service boundaries. These entities can be huge and are therefore very slow to pass around and we hit upper limits on WCF message size (semi)regularly. The screens we are displaying show a lot of related data and the load time for some pages is insanely slow.
• Our application has some smarts in it that can be argued are actually domain logic, not application logic.
• We have a lot of code repetition “copy and paste mania” through out the stack
• We have a tightly coupled stack; using doubles/mocks/fakes at times is near on impossible meaning test are integrated, brittle and slow
• Services expose too many finely grained functions, many of which are not appropriate as public calls.
• We have one domain which needs to be spilt to shared kernels
• We have a very anaemic domain. Our domain objects are treated a bit like strongly types datasets with the service controlling business logic and flow.
• Poor separation of concerns both vertically and horizontally (i.e. mega classes)
• subtle and painful circular references
• Logic in views
DDD
• Clearly define boundaries. Implicit knowledge should not be required. Code should be fluent and readable. Refactoring is therefore a necessary component of building a fluent domain
• Flesh out the actual business problem and map it completely and deeply into the domain code. Reading a domain entity class it should obvious what it can do and what is cant.
• Assert your assumptions, use DBC, predicates, valuators and factories, especially with complex entity construction
• Domain entities are smart. Do not let the smarts of these domain object leak into the repositories or services (ie an anaemic domain)
• Repositories are just that, effectively a bucket holding domain objects. If you want to do complex DB logic use a report data access call, don’t muddy the repositories with reporting.
• Services are aggregators of domain functionality. They control flow and coordination between Repositories, Factories and Domain objects. They do not hold leaked domain logic.
• Reports are anything that is not domain object based: Actual reports, Scheduling, Complex db searching etc. These may return objects but they are not smart domain entities, nor are they are domain value types and so should not pollute the repositories.
• Value types are immutable and so consider whether they are suitable to be structs (e.g. time code)
• Reference Value types are read-only (i.e. only selectable form the database, never CUD) and so do not need mapped “created/last modified“ properties. These may be necessary in the DB (for standardisation) but this does not mean they need to be leaked into the domain
Distribution
• The message and service should be verbose enough to describe the functionality.
• Use messages. Don’t pass entities around across boundaries.
• Messages are immutable, don’t attempt to modify request messages on the recipient, nor should you modify response on the caller
• Feel free to reuse structures ie DTO but don’t reuse messages at all. A message is bound to a service and a function
• A message is the object passed across the wire which holds a DTO, which may be in turn made up of more DTOs. A message implements either IRequestMessage or IResponseMessage
• On entry to the server side any instrumentation/auditing/logging/security checks etc should be handling in a standardised reusable manner, consider AOP or delegate passing.
• On entry to the server side transactions/sessions should be handled as this is the entry point to the domain and a service call should be considered atomic.
• Faults, not exceptions, should be passed back to the caller.
• Consider whether the use of an ESB could improve the use of your domain. Message based communication is necessary if this is to be implemented.
Application
Logic in an application is bound to application specific flow. The exception here is validators. [I am yet to figure out how best to organise validation across boundaries. Currently my thinking is keep it very separate with well constructed messages helping]
General
Do not pollute any part of the stack with cross cutting concerns. Use AOP. The entry and exit of a method is usually more than enough context for things like security and logging. If it is not then rethink the size of your methods!
Loosely couple yours stack. Use IoC. A standard IoC container can ease testing and un-clutter the complexity of object creation.
Concerns I need to keep at the back of my mind if we switch to something like the guidelines above:
• Client and Server side Authentication and authorisation. How will we pass security tokens around?
• Concurrency, how will I address 2 user working on the same asset at the same and race conditions?
Bring on the refactoring, I just wish we did it as we went! Please learn from our lessons.
The Web sample in the MassTransit download that i talked about in the last post used MonoRail. As i am working on a project not using monorail (and there may be a couple of others doing the same) i thought i would make demo project using asp.net, oldskool.
The project contains 6 files (well 9 really)
AsynchWebForm.aspx (marked as Async=”true”)
Global.asax
Web.config
WebAppContainer.cs
RequestMessage.cs
ResponseMessage.cs
Thats it. It references the mass transit dlls (mt.sb., mt.sb.msmq, mt.WindsorInt) and the appropriate castle dlls.
the global.asax is just like the DashboardApplication in the morails sample and the WebAppContainer.cs again is similar to the monorail sample without any references to monorail! The message are exactly the same and the web config has the castle section definition and castle section inserted into a default web.config file.
I was lazy with my resolving of the IServiceBus, see below.
—–WebApContainer——–
using System;
using Castle.Core.Resource;
using Castle.Facilities.Startable;
using Castle.MicroKernel.Registration;
using Castle.Windsor.Configuration.Interpreters;
using MassTransit.WindsorIntegration;
using MassTransit.ServiceBus;
namespace MassTransitWebTest
{
public class WebAppContainer :
DefaultMassTransitContainer
{
private static IServiceBus bus;
public WebAppContainer()
: base(new XmlInterpreter(new ConfigResource()))
{
RegisterFacilities();
bus = Resolve();
}
protected void RegisterFacilities()
{
AddFacility("startable", new StartableFacility());
}
internal static IServiceBus getBus()//yes im that lazy
{
return bus;
}
}
}
—–AsynchWebForm.aspx.cs——–
using System;
using System.Collections.Generic;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using MassTransitWebTest.Server;
using MassTransit.ServiceBus;
namespace MassTransitWebTest
{
public partial class AsynchWebForm : Page, Consumes.For
{
private IServiceBus _bus;
private Guid _correlationId;
private ServiceBusRequest _request;
private ResponseMessage msg;
private RequestMessage pendingMessage;
protected void Page_Load(object sender, EventArgs e)
{
//not much to do here
}
IAsyncResult PageBeginEventHandler(object sender, EventArgs e, AsyncCallback cb, object state)
{
_request = _bus.Request()
.From(this)
.WithCallback(cb, state);
_request.Send(pendingMessage);
pendingMessage = null;
return _request;
}
void PageEndEventHandler(IAsyncResult ar)
{
IAsyncResult r = ar;
this.txtResponse.Text = msg.Text + " (and my response)";
}
#region All Members
public void Consume(ResponseMessage message)
{
msg = message;
_request.Complete();
}
#endregion
#region CorrelatedBy Members
public Guid CorrelationId
{
get { return _correlationId; }
}
#endregion
protected void Button1_Click(object sender, EventArgs e)
{
AddOnPreRenderCompleteAsync(
new BeginEventHandler(PageBeginEventHandler),
new EndEventHandler(PageEndEventHandler));
_bus = WebAppContainer.getBus();
pendingMessage = new RequestMessage(CorrelationId, this.txtRequest.Text);
}
}
}
Happy days! I am sure you can work out the rest, if any one cares the complete solution can be downloaded from :
http://www.fullstack.co.uk/downloads/MassTransitWebTest.zip
NB:See previous post for setting up queues
A demo project i am frantically working on has a requirement for some sort of ESB like message control. My first instinct was to go with NServiceBus but something, for some reason drew me to MassTransit.
MassTransit is an Open source .Net project run by Chris Patterson and Dru Sellars which aims to be a “lean service bus implementation for building loosely coupled applications using the .NET framework.”. Cool cause that’s what I need.
It sit on top of MSMQ and has some heavy hooks into the castle project for DI etc.
I am writing this while i wait for my VS2008 SP1 install to finish… what the hell is it that thing?? oh the entity framework! well at least its worth the wait ;P
Anyway the documentation is a bit slight and i am a documentation nerd. I like to get a synopsis of what we are trying to achieve and some sample project, also documented, to help me get up to speed, so here is my very basic version of just getting started.
You can just download the binaries if you are feeling very confident or alternatively you can get the source which includes some sample projects.
Running the MassTransit samples:
NB: you will need to install/set up MSMQ (or whatever queue they support in the future), for details on how to do this, see below.
1) Download the source code to an appropriate folder using the following svn command (this is read only)
svn checkout http://masstransit.googlecode.com/svn/trunk/ masstransit-read-only
2) For Mass Transit you will need to create a private MSMQ queue of the name “test_servicebus” and leave the default setting of NOT transactional.
3) Open up the WebRequestReply.sln found in :
..\masstransit-read-only\Samples\WebRequestReply\WebRequestReply.sln (or 2008 if you have it)
4) Build the solution, ensuring it builds (I had to delete a couple of version files for both 2005 and 2008)
5) Set the monorail project to the start up project.
6) F5 that mutha.
This will show a splash screen that links to the asynch screen. Type in some stuff in the request textbox and hit the button and the response will come up.
Things to look for in the code:
The monorail project is the initiating code here and basically is the stuff you will be looking at for how to use this framework. If you are not familiar with castle, monorail and asynch calls then your head may pop.
Firstly look at the DashboardApplication.cs file. This is the gloabal.asax code behind file that is called on app start up. This file starts up the Container which loads the facilities/components using windsor IoC. The container inherits from the defaultMasstransitContainer which has Windsor Castle hooks. Check out the config to see the injection of the Uri and queue type for the bus.
In the DashboardApplication you should also see the line
and its related delegate
container.Resolve().Publish(response);
}
this is saying that this delegate wants to handle the receipt of the RequestMessage, “when the RequestMessage is published i want to process it with this command”.
alrighty… next is the DemoController.
This is the controller for the asych page that does the work. If you are not familiar with monorail or the ASP.net MVC project this may be a bit confusing, but this is like the code behind page for a dynamic web page. Some of the important things to note are:
This says that this class is interested in (consumes or subscribes to) ResponseMessages. Now i need to look more into the .For aspect so i wont comment much yet ( i assume it related to the request message id?)
The Synch method is empty but you will notice there is a BeginAsynch method with the same signature and an EndSynch method with no signatures. These methods and there contents are the asynch approach used by Monorail. Don’t be too concerned, classic Asp.Net has had this little known feature for years albeit a slightly different syntax and wrapped around the pre-render aspect of the page life cycle (i may cover this in another post).
The asynch method is called from the the view on clicking the submit button (read up on MVC if this appears odd) where the bus is called and a Requestmessage sent to the bus. Some of the semantics here are very much monorail so the main point is:
a Request Message was sent to the Bus to be processed in an asynch fashion.
If you have debugging on with a break point in the DashboardApplication.HandleRequestMessage method you will see the bus has routed the request here. The method simply creates a basic response and publishes that response. Because the the DemoController is a subscriber to the ResponseMessage type it receives that message via its consume method, assigns it to a local variable and calls the request to be completed, which inturn calls the EndAsynch method.
the key points are the
on the controller with its consume methods and the asynch calls to the bus. each framework will do this slightly differently
the subscribing to the request message
the publishing of the response message
If you want to see the inner working then the 3 projects under the mass transit folder contain all the juicy stuff. typically these would just be refence dll’s but the whole idea of sample is to see how the code works 🙂
Hopefully next up I may do a classic Asp.Net example to see if i actually get the concepts correctly (reading and writing are not the same things!) and can use the asynch methods from there.
————————————–
Setting up MSMQ
NB On XP You must have an edition that supports MSMQ (ie not home)
Go in to Control panel > add or remove programmes
Select the add/remove windows components
Select Message Queuing if it is not already selected and add it.
Now if you go to “Control Panel” > “Administrative Tools” > “Computer Management” under the “Services and Applications” branch, when expanded, you should see a “Message Queuing” branch.
If so you have MSMQ set up.
You now need to set up queues for an application to uses
From : http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.ebd.eai.help.src/setting_up_msmq.htm
Setting Up Microsoft Message Queuing (MSMQ)
To Set up MSMQ on your Server:
1. Go to Control Panel -> Add/Remove Programs -> Add/Remove Windows Components.
2. Select Message Queuing Services Component from the Windows Component Wizard.
3. Follow the directions provided by the Queuing Services Wizard.
4. After completing the Queuing Services Wizard, go to Control Panel -> Administrative Tools -> Computer Management -> Services and Applications -> Message Queuing.
To Create a Public Queue:
1. Right click the Public Queues Directory.
2. Select New.
3. Select Public Queue.
4. In the Queue Name Dialogue Box, enter the Queue Name, where the format is [machine_name]\[queue_name].
To Create a Private Queue:
1. Right click the Private Queues Directory.
2. Select New.
3. Select Private Queue.
4. In the Queue Name Dialogue Box, enter the Queue Name, where the format is [machine_name]\private$\[queue_name].
For Mass Transit you will need to create a private queue of the name “test_servicebus” and leave the default setting of NOT transactional.
Rhys Campbell 