Jul
28
2011

XPO ObjectLayer Tutorial BreakDown

User Rating: / 1
PoorBest 

Lets delve into the included example with DXperience 11.1, locate and open the XpoTutorials solution;

  • Windows Vista/7
    %Public%\Documents\DevExpress 2011.1 Demos\Components\XPO\VB\XpoTutorials\XpoTutorials.sln
  • Windows XP
    %ALLUSERSPROFILE%\Documents\DevExpress 2011.1 Demos\Components\XPO\VB\XpoTutorials\XpoTutorials.sln

Once VS is up, locate and view code ObjectLayerService\ObjectLayerService.vb/cs.

At first glance there is a fair bit happening here, but at the same time, nothing happening. Open-mouthed smile Let me explain.

 

WCF

WCF is a big beast of a communications library allowing for near unlimited configuration and extendibility. With this however comes a big learning curve one which is sometimes daunting and even when you do come to a conclusion you still have many questions.

Personally I went with “Learning WCF”and “Programming WCF Services”although there is a fair amount of double up the difference is one is explaining WCF whereas the other is how to more about how to implement it.

With this understanding that WCF is complex you may start to understand my statement that “nothing happening” in the code.

DevExpress supports WCF

DX have gone to some effort to try and help us deal with WCF and XPO, the first article reference would have to be “Transferring Data via WCF Services” write some base classes for us to use with WCF for communication. Straight away I fear using these, along with fellow XPO DX Squad Trevor Westerdahl we fear that using “prebuilt” classes/wrappers can lead to harder to find errors and lesser control.

Currently my application runs using the IDataStore as the WCF communications DataContract. For this I implemented the interface into my own class and built everything from the ground up. When doing this you realise how many things you have to handle in WCF, such as faulted channels due to transport failures, timeouts and general exceptions. Rolling a handler to take these into account and performing retries etc can be a large task.

DX provides base class for both DataStore and ObjectLayer serialization. DataStoreService / DataStoreClient and SerializableObjectLayerService / SerializableObjectLayerServiceClient

As I am moving away from DataStore I won’t be talking anymore about it, however this doesn’t mean that it is “Obsolete”, although I haven’t done and profiling I would imagine that serializing the IDataStore would result in less data transferred over the wire as it is a simpler interface. So if you don’t require full server side control of what is going in and out of your database then the IDataStore would be fine, the IObjectLayer purely provides a higher layer interface allowing further control.

IObjectLayer Serializationimage

This diagram is not a inheritance tree, but rather more of a dependency tree (you educated people out there that have certificates in diagramming can byte me, I am sure there is a better, more technical way to present this, but this is how I “view” it)

So this is telling us that the UnitOfWork will be communicating to the SerializableObjectLayerClient over the IObjectLayer interface. Then the SerializableObjectLayerClient will talk to the SerializableObjectLayerService over the ISerializableObjectLayerService interface, etc.

As I have highlighted, the ISerializableObjectLayerService is what is being used as our DataContract over WCF. This is apart of the DX implementation of WCF helpers. If you were to roll your own you only need to use the ISerializableObjectLayer as your contract.

So the question is, why would we use DX classes over our own?

This is up to you, if you feel comfortable with WCF and want to have complete control over your service then sure, roll your own, there is nothing stopping you. However after looking through the source of the DX classes, I am quite pleased with how they have implemented the class.

The SerializableObjectLayerServiceClient inherits from the WCF ClientBase class which is similar to what VS would do if you were to add a web reference. Overall their implementation seems to provide all the required functionality out of the box without hindering extendibility.

DX have included error handling and also a retry system on error. This explains why we DX are using the ISerializableObjectLayerService for their DataContract instead of ISerializableObjectLayer.

Lets look at the difference between them

imageimage

You will note that the ISerializableObjectLayerService returns OperationResult whereas the ISerializableObjectLayer just returns the Type.

This is DX’s own class to contain error information etc. Overall, I think the DX implementation is perfect, and in all cases better than what I had with my IDataStore implementation.

So I myself will be using the included Classes for my project rather than implementing my own

Code Walkthrough

Firstly, if you haven’t really looked at DX Tutorial sources before, please remember you can ignore the fact it inherits from TutorialControl and the SetNewWhatsThisPadding property, as these are just to support the “Demo Center” interface.

Private Const auxPath As String = "net.tcp://localhost:59723/XPOTutorialObjectLayerService"

So first line of interest is, a string auxPath set to “net.tcp://localhost:59723/XPOTutorialObjectLayerService”

This is an address that will work with a NetTcpBinding, when you look into WCF you will find that NetTcp uses a Binary serialization which provides a smaller data package, HOWEVER does not handle “poor” transports very well, including lack of support for Proxy Servers.

If you are looking at exposing your service across the internet I strongly suggest to use a HttpBinding instead, for simple services BasicHttpBinding is fine, however for complete control you should use WSHttpBinding. I won’t go into the configuration of these bindings here, if you have more questions about this I may look into a seperate blog on this subject.

		Private Sub PrepareDataLayer()
			Dim DBFileName As String = DevExpress.Utils.FilesHelper.FindingFileName(Application.StartupPath, "Data\nwind.xml")
			If (Not String.IsNullOrEmpty(DBFileName)) Then
				Dim inMemory As New InMemoryDataStore(AutoCreateOption.SchemaAlreadyExists)
				inMemory.ReadXml(DBFileName)
				mainDataStore = inMemory
			End If
		End Sub

The next point of interest is the constructor, containing the PrepareDataLayer call, if we look at this method we see that DX create a new InMemoryDataStore (which is a quick XML based datastore which is stored in memory and typically used for temporary databases such as testing), you’ll note they load data from an XML file. This datastore is then stored in the mainDataStore variable.

If you take a quick look at the Designer (you will have to Build your project to view the Designer) you will see there are 2 buttons, “Start Service and Create Client” and “Load Employees via WCF Service”. The click handler is set to the sbStartService_Click method. In here DX have used some multithreading code to create the service on a separate thread (ThreadPool.QueueUserWorkItem), in simple terms it calls CreateService with the argument of mainDataStore.

		Private Sub CreateService(ByVal dataStore As IDataStore)
			Dim xpDictionary As XPDictionary = New ReflectionDictionary()
			xpDictionary.CollectClassInfos(GetType(Employees))
			Dim dataLayer As IDataLayer = New ThreadSafeDataLayer(xpDictionary, dataStore)
			Dim service As New SerializableObjectLayerServiceTutorial(dataLayer)
            serviceHost = New ServiceHost(service)
			Dim binding As New NetTcpBinding()
			binding.MaxReceivedMessageSize = Int32.MaxValue
			serviceHost.AddServiceEndpoint(GetType(ISerializableObjectLayerService), binding, auxPath)
			serviceHost.Open()
		End Sub
  1. A new ReflectionDictionary is created and Persistent Objects are loaded from the Assembly of the Type that is passed through (this is needed for ThreadSafeDataLayer as this DataLayer requires to know what Persistent Classes are included in this database, whereas the SimpleDataLayer handles this more like Late Binding).
  2. A new instance of SerializableObjectLayerServiceTutorial is created, this is local class which inherit the SerializableObjectLayerService (SOLS) and creates a new SerializableObjectLayerProxyBase descendant to handle the communication to the DataLayer.
  3. A new ServiceHost is created passing in our newly created SOLS, this class is the core “WCF Server” and handles all incoming requests.
  4. We have a server however we haven’t specified how to communicate with it. So now we create a new Binding, in this example DX are using NetTcpBinding. from there they increase the default (read very small) MaxReceivedMessageSize.
  5. Now they add this Binding as a ServiceEndpoint (think of it as a “road” for communication to travel on, a server can have more than one road (ie. different configurations such as encryption, authentication etc) and can even have different types of transport, (ie. you could also add a LocalPipe transport and Http transport) and they can all communicate to the same instance of the server over these different types of transport, (obviously there are caveats such as you can’t use the same address for different transports etc).
  6. From here the ServiceHost is Opened which basically tells WCF to start listening for connections.

Now back to our sbStartService_Click method, we have created a Service and now we run the CreateClient method

		Private Sub CreateClient()
			Dim binding As New NetTcpBinding()
			binding.MaxReceivedMessageSize = Int32.MaxValue
			Dim endPoint As New EndpointAddress(auxPath)
            Dim serializableObjectLayer As ISerializableObjectLayer = New SerializableObjectLayerServiceClient(binding, endPoint)
			serializableObjectLayer.CanLoadCollectionObjects.ToString() 'Check connection
			Dim objectLayer As IObjectLayer = New SerializableObjectLayerClient(serializableObjectLayer)
			session = New UnitOfWork(objectLayer)
		End Sub
  1. Again we create a new Binding to tell WCF how to communicate to our Server, obviously this needs to match the binding you setup on the Server.
  2. We create a new EndpointAddress, this is telling the client where to find our server and what it should look like (ie. lots of options here, we could also specify a DnsEndpoint so we can match the Dns name to the provided server SSL certificate etc)
  3. We now create a new SerializableObjectLayerServiceClient (SOLSC) passing through through our binding and endpoint address.
  4. DX then perform a simple method call to ensure the connection has been made, (if you were to step through the SOLSC you will see the WCF ClientBase would create a new ChannelFactory and then the DX class will create a new Channel to start communication with)
  5. Now we have a connection to the server we need a IObjectLayer to use with our app this is where the SerializableObjectLayerClient (SOLC) (Note the difference between SerializableObjectLayerClient and SerializableObjectLayerServiceClient)
  6. Create a UnitOfWork using the new SOLC which is using the SOLSC to communicate to the SOLS to communicate to the SOLPB to communicate with the TSDL which communicates to the DS Open-mouthed smile (easy) Confused smile

From here you use the UnitOfWork just like normal and all the WCF communications happen seemlessly inbetween.

OK whats the catch?

Well there are a few that come to mind…

  1. Gracefully handling errors within the UI
  2. Monitoring the connection
  3. Advanced endpoints such as www.noemax.com which I use for great compression/encoding capabilities.

Conclusion

I hope this walkthrough helps layout what you are dealing with when looking at implementing serialization of the ObjectLayer.

On the surface the classes provided by DX seem to be quite well thought out and provide the functionality we are all after.

The next part is delving into the SOLS more by overriding methods to provide functionality such as auditing and security. I am still a little aways from getting to this part but will be blogging as I go along. So please keep in mind this blog is based on my initial play with ObjectLayer and I am sure I will come across little gotchas or misunderstandings and will keep blogging updates as I go.

Happy Coding, also if anyone is on EVE, hit up “Aussie ALF” Smile with tongue out

Comments  

 
0 # 2011-10-17 14:39
Please keep up this good work. I's blogs like these that help cement what 'I think' is what the documentation is saying
Reply | Reply with quote | Quote
 
 
0 # Michael Proctor [Dx-Squad] 2011-10-17 14:52
Cheers Glen, I have held off continuing the series until 11.2 (which is just around the corner).

DX are still busily fleshing the ObjectLayer out based on it's own use cases and the scenarios that customers have provided. So heres hoping in 11.2 we have some more extensibility to allow us to perform server based auditing and less chatty interface for more efficient comms.

Again thanks for the comment it really does help with the motivation to keep doing em
Reply | Reply with quote | Quote
 

Add comment

Although I believe your free to say what you want, please don't abuse either myself or other peoples, be constructive.


Security code
Refresh

Latest Comments

My Twitter

Follow me on twitter