Flexible Systems Integration Architecture

I may have a couple of large projects next year where I need to build up a great deal of functionality that easily needs to be integrated with existing systems.  What we want is some sort of clean very usable portal concept where a user can work with a predefined set of business objects.  The idea here is not to create some sort of "holy-grail" of a development environment where a business analyst can sit down and drag a few objects on to a page and wire them up.  So now that we took the whole "build a system without one line of code" marketing statement out of our vocabulary we can safely say we do need to write code and figure out the best way to do this to:

1. Get a high-level of reuse among different implementations
2. Do programming at the right level to minimize defects tedious coding
3. React to changes very quickly
4. Provide a clear upgrade path
   

First let's define the three aspect that are present in pretty much every system we are going to build, probably in the order of importance and from the most static to the most dynamic:

Data - In each problem domain there are a core set of data that describe the "world" of the domain.  For a sales system, this is going to be something like Customers, Products, Sales People, Sales Orders, Invoices etc...each of these has their unique set of attributes that describe them.  I would venture to say that in most sales system you are going to have at a minimum the above set of objects with probably 85% of the attributes on those objects remaining consistent.  For these type of objects the definition of these attributes probably remains fairly constant with respect to time.  That is to say the description of the objects is probably the most "static" part of your system.  I guess this is pretty much the premise of OO.

Business Rules - Objects by them selves might be interesting however to do anything with them you need to implement some sort of business logic, something like a sales person "CREATES" the order etc...these are really the functional requirements of your system.  In our sales system, although the objects and their attributes are probably about 85% the same across different systems, the actual functional requirements and business rules are probably much less consistent.

User Interface - Well now we have our data in our objects and we have methods so we can make them do something interesting, unless we are building a batch processing system, we need some sort of user interface.  If we look at this in terms of our sales system, there are really three components of our User Interface: 1) Simple CRUD stuff (Create Read Update Delete) 2) The buttons you press to make it do something like create a new order 3) Work flow.  The first two items are really pretty basic, get data from the business object display it on the screen, validate it and dump it back to the biz object as well as react to a button to launch a screen.  The third item is what really differentiates one system from the next, the work flow that's wires up the user interface to the business rules.

Let's talk a little bit about some concepts to solve these problems with a high-level of reuse and integration into back end systems.

Data - As we defined above, we will want to create some sort of rich object model based upon the domains we are building the system for, these should contain the attributes the core attributes that we defined above that are similar between different implementations.  These objects would then in turn be "bound" to the underlying data objects to provide the basic CRUD functionality.  This would either be through the use of implementing interface contracts in a high-level language or creating stored procedures in the underlying database that would bind our objects to the data.  We might implement our Customer object to execute a stored procedure on an Oracle database and return some sort of result set for one implementation and write code to execute a Web Service method call to retrieve the customers attributes in another, either way we let the specific implementation provide the data and bind it to the attributes on the business object.  Our objects would also need to provide some sort of mechanisms return lists and collections that are implemented based upon the data assets within the organization.  The idea here is the business object in our object model provides a well defined set of services to the work flow and user interface layers, but the actual persistence of the data will be implementation specific.

Business Rules - OK now we have a way to load and persists business objects as well as return collections and lists of these.  Now we need to make them do something.  The "do-something" part really comes in two flavors, simple methods we can invoke to set status and send out notifications to more complex work flow with respect to time.  They are tied together, but it may help to think of them separately.  As with our data implementation, our core implementation needs to provide a key set of methods that do certain things, like create a new order, send an email etc...these should be customizable by inheriting form base class and overriding methods.  The next flavor having to do with behavior of the object over time is really considered work flow and this probably the area where now two systems will be a like.  I think the right way to do this is through some sort of Work Flow engine and it just so happens with .NET 3.0 Microsoft released one.  The exciting part of this (at least as far as I understand it so far) we should be able to create our objects that have our properties and methods, but then "wire" them up using XAML to make them behave in a custom way.  This is not say we can build our systems without writing any code, but it does mean we may be able to "wire-up" our apps to get 80% of the way there, and then be very flexible with respect to change over time.

User Interface - I believe that some sort of portal concept is the right way to go here, I'm very intrigued by Share Point Portal Services 7.0 as providing the plumbing to hold everything.  This area probably will require the most customization however this will probably just be starting out with some control templates, dragging a few additional controls on to the template then wiring those controls up to the business objects.  The portal "needs" to be built as a set of building blocks that can be assembled and "connected" at run time.  I think the right way to do this is through the use of Web Parts in ASP.NET 2.0.  In addition, it will be important to create some sort of role based security that controls access to the UI components/data not only to show/hide features and UI components, but also something to secure access to either groups of records or specific records.  It's also important to build and integration story that will leverage any existing credentials that the company may already have.  I would love to see the use of "Card Spaces" for this, but I'm not sure that's all that good of an idea.  This may however be on implementation of our security model.

More to come on this topic...I'm just starting to get my head into these efforts....

- ec

Microsoft Robotics Studio - Very KEWL!

This weekend I'm working at the "beach-house" (well our 28ft travel trailer parked at a campground right one the Gulf at Fort Myers Beach).  Since I've got most of my work deliverables caught up (I hate saying that since I know I'll jinx myself), this weekend I wanted to play a little.  From about 1991 to 1995 my job was to design hardware then write the software that ran on it to make the lights come up in the right order (well maybe make it do a little more than that).  I really loved this but since about 1995, I've been focused mainly on business applications...really a different world.  About once a year I try to spend a few days doing something hardware related so those brain cells don't totally die off.  A few years ago it was hacking an X-Box, then the last couple years it was working on W3, my home-brew robot based upon the BasicStamp chip that contained Sonar, Compass, X-10 Camera and an interface via WiFi on an old iPaq, this was a lot of fun but most of the effort here was actually constructing the hardware and writing the device interfaces.

That brings me to this years effort and MDEC (incredibly good conference) earlier this year I was introduced to the MS Microframework, they had a "Sumobot" competition, unfortunately at the time I was doing the conference in the day and "work-stuff" at night so I didn't get involved.  After browsing the MSDN site last week, I came across the Microsoft Robotics Studio, then saw that it supported the new Lego NXT robotics system...I had to have one of these.  It arrived on my doorstep Thursday and I was set for my weekend in Fort Myers Beach.  I spent Saturday "playing" with lego's and built up the robot you can see between my two monitors.

Next was to get it talking to the computer, this was actually pretty easy since the NXT has built in Bluetooth and the communications "stuff" happened in the plumbing of the MS Robotics Studio.  My prior solution was to hookup an RS232 serial port between my BasicStamp chip to the inputs on an iPAQ, then I used the WiFi card in the sleeve to do some lo-level socket stuff to talk to the desktop app.  This is much cleaner!

So now all the pieces are in place, I've got the robot setup, I've got communications up and running, now it's time to make it do something!  We have three little terriers in our trailer that don't like being left alone.  My goal is to hookup the sound detector on the robot to fire off an SMS message to my cell phone when the dogs start barking (so we don't get kicked out of anymore RV parks).  Then I want to allow some sort of PocketIE interface to manipulate the robot to take "correct actions", I think I should be able to hookup my software to my MCE that is in the trailer, then with some Text-to-Speech stuff, issue the "No-Bark" command to the pups and see how that works.  There is also a small wireless web cam I plan to get for this...I think that would be extremely interesting

-ec

Morse Code Reader

I was really brought back in time after reading the following post.  When I was a in junior high, I was I guess what you call a "early adopter" to being geek.  I got my HAM radio license and purchased a Heath Kit SB100 radio (Vacuum tubes and all).  I learned Morse code to get my license but was happy when I could interpret Morse Code at 13 words per minute and got my general class license and could actually use a microphone to talk to other folks.  In the mean time, I read an article in a Popular Electronics magazine that talked about how to build a circuit to digitize the tones from the speaker "playing" the code (using a Schmidt trigger if I remember right).  I was on my second computer after saving up enough to get a VIC-20 (after my Timex Sinclair) so I built a little chunk of code to convert the tones to actual characters on the display, this worked well!  The other chunk of functionality I needed was the ability to key the transmitter to send out code, I think I used a bit on the joystick port to drive a relay and I was set.  This brings me back to the original post from Ashish Derhgawen, he wrote an output from a parallel port on his PC to drive an LED (I didn't see the current limiting resister in his screen shot, but maybe this is one of those new fangled LEDS with it built in).  He had a challenge on the bottom of hist post to identify what the message he was sending, I had a difficult time reading the Morse code from the LED, so I had to write a little program to read the LED and turn it into dots and dashes I could easily read...I'm not going to give away the answer to his challenge, but if you know Morse code it should be obvious.  I wouldn't call this a very robust solution, but sometimes coding is just fun.

Anyway here is a screen capture of the simple program...

The SWF file just gets loaded up into an IE component on the form, then here's the snippet that reads the LED, the rest is a simple state machine...

-ec

Compact Framework Development Environment

Over the past year or so, I've been working on a large compact frameworks application.  Working on a device application presents a different set of challenges from doing web or desktop application.  Along the way I've found a number of tools/processes that really help me work as efficient as possible doing this type of development, here are some of those ideas:

1. Work on an actual device, it's much faster and gives you a better feel for the application you are developing than working on an emulator.
2. When developing your application it may make sense to put all your business logic AND the actual screens of your application into a different assembly than the main application.  What I did that worked out really well was to create a shell or host application that acts as a switch board that launches the individual screens that contains the functionality.  Then I created an additional version of this switch board that ran as a Windows Desktop application, what this allowed me to do was to do most of my development in a desktop app which is much more efficient, then once I got the functionality working, I wired that into the device host/switchboard application and tested it there.
3. There is an awesome tool from Laurent Docquir that allows capturing debug messages from your device on your development PC, this is similar what you could do if you attached the VS.NET debugger although it is much faster.  In addition this program allows you to launch the process you want to test as well as kill that process on the device.  Another nice feature is the display of the timing in the left hand column, this works awesome for doing performance tuning of your application.
   
   
4. Since it isn't much fun pulling out the stylus and entering text, clicking on the actual device, you should try to find some sort of program that will display the contents of the device on your screen that will allow you to manipulate the device, the best one I found to date is Soti's Pocket Controller Pro.  This also allows you to download skins from the different devices to get realistic screen shots of your application.
   

- ec

ASP.NET Under Vista

Vista is deployed with IIS 7.0 a cool feature that wasn't available on XP is the ability to create multiple web sites.  This means you can can configure IIS to look at the host name and map that to a particular web site...I explain...

First find and open your hosts file, this is in in \Windows\System32\Drivers\Etc add a couple of entries that point back at your local machine (127.0.0.1)

Next open up IIS and create a new web site, in the Host header section enter the name of "virtual host" you entered in your hosts file (also don't forget to set your app pool up to use the "Classic ASP.NET" pipe line mode)

Now you can browse to the site you are developing with just http://plinks instead of http://localhost/plinks

Although this seems like a fairly small deal, if you are working on multiple projects it's nice to keep things organized a little better not to mention a few less key strokes bringing up the page.

-ec

DataBinding in WPF - 101

Once you understand the core concepts, databinding within WPF is a piece of cake!

Here's what you need to do (this example assumes that are getting your data from a business object through some code behind the scenes).

For this example we have a grid (not a data grid, but it's more analogous to an HTML <table> structure. that is our container:
1) Define the template of how the items should be displayed.
<Grid x:Name="grdMyData">
   <Grid.Resources>
      <DataTemplate x:Key="tblTableTemplate">
         <StackPanel x:Name="lstTables" Orientation="Horizontal">
            <TextBlock x:Name="colTableName" Text="{Binding Path=TABLE_NAME}" Width="100"/>
            <TextBlock x:Name="colTableSize" Text="{Binding Path=TABLE_COLUMN_COUNT}"  Width="100"/>
         </StackPanel>
      </DataTemplate>
   </Grid.Resources>
.....

 2) Next within the grid container, we place the control that will contain the bound items.
<ListBox x:Name="lstColumns" ItemTemplate="{StaticResource tblTableTemplate}" ItemsSource="{Binding Mode=OneWay}" /

3) Also within the grid we can include a simple text box
<TextBox x:Name="txtTableName" Text="{Binding TABLE_NAME, Mode=Default}" />

4) Finally within our code behind, we can bind our data source (in this case a middle tier object that returns a System.Data.DataTable) to the grdMyData object.
   grdMyData.DataContext = ChaosFilter.DataLibrary.Database.DbEnvironment.ReadTable();

5) Here are some interesting observations of how this works

• At this point as soon as the DataContext of the grdMyData grid is bound, the list box will be populated with two columns.
• Since we bound this to the grid object not just the list box, as we move through the items in the list box, the text box you've added to your grid will follow the value selected in the list box. 
• If you make a change to the value in the text box, the data change is reflected back to the underlying DataTable object.
• Since the changes are reflected in the underlying DataTable object, you can easily invoke the .GetChanges() method on that data table and write those back to the database (this obviously is fairly naive in that somewhere along the line you need to do validation and any auditing).

-ec 

WPF (Windows Presentation Foundation) Key Points - 101

Just getting back from DevConnections, I'm even more pumped on the .NET 3.0 stuff than I was before the conference.  I've played enough with Microsoft Expression Interactive Designer (which by the way doesn't work with the .NET 3.0 RTM) Sept 2006 CTP to get a feel for the cool UI stuff you could do.

First a note, the main intent for gathering this information is learning the new technology.  There is no guarantee what so-ever that this informations is complete or correct if errors are found every effort will be made to update the content but in no circumstance what-so-ever will Software Logistics, LCC or Kevin Wolf be held responsible for errors or omissions.  So on with the good stuff!

First some basic concepts/definitions at 10000 feet...this isn't intended to go into detail on any of the topic with should provide enough background as to the terms and landscape of WPF.

• XAML (Extensible Application Markup Language) - The language of WPF, used to declaratively define our user interfaces and how are applications are "glued" together.
  

  <Application
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  x:Class="UntitledProject1.MainApplication"
  StartupUri="Scene1.xaml"/>

• Controls - CLR .NET 3.0 components that are used within XAML as elements to represent the user interfaces

  • <TextBox HorizontalAlignment="Stretch" VerticalAlignment="Top" Margin="31,62,140,0" Width="Auto" x:Name="txtColumnName" Text="{Binding Mode=Default, XPath=@columnName}" TextWrapping="Wrap"/>

• Resources - In the cases of XAML, these are really different than the "Assembly Resources" which exist and are compiled into your application, resources are used to provide data to properties or content of other controls within your WPF object, there are different types of resources:

• StaticResource - Data to be extracted from somewhere within the XAML document, or common application XAML resources
  • <Application.Resources><LinearGradientBrush x:Key="brshHorizontalGradient" .... </LinearGradientBrush></Application.Resource>
  • <TextBlock ForeGround="{StaticResource brshHorizontalGradient}" />
• x:Static - Allows for access to static properties or fields (can invoke Non-WPF class by using a name space on the binding resource key)
  • xmlns:src="clr-namespace:SoftwareLogistics.DataLibrary"
  • <Window.Resources><src:Customer x:key="MyCustomer" /> </Window.Resources>
  • <Binding Source="{StaticResource MyCustomer}" />
• DynamicResource - With a dynamic resource, this is similar to doing a property lookup each time the resource is access, with a static, it is just loaded the initial time and used throughout the lifetime of the object.
• <TextBlock ForeGround="{DynamicResource {x:Static SystemColors.ActiveCaptionBrushKey}" />
  
• Templates can be created and assigned to WPF components to provide a customized rendering for the object.
  
• Content - On certain WPF controls there is a property called "Content" content is a place holder where really any type of object (usually another WPF object or a .NET Primiative can be placed) Content can also hold WPF Container type of objects
  
• DataBinding - This is a pretty area that will be the topic of my next post.

This is by no means a complete list of the concepts in WPF, however it may be helpful to think of these as the different areas surrounding WPF

 - ec

Key components to look for in a Web Application Frameworks

When building a non-trivial web site, they can really come in two flavors: a simple read-only advertising site that lets your clients know about your product or business or a more dynamic web site that allows your clients (users in this case) to interact with your companies services online.  This post will discuss some requirements for a good solution for the second option.

As I always say, the thing that all successful software projects share is that they change/grow and get better with age, with this fact in mind any web application framework should efficiently support this goal.  This is to say that the right level of plumbing or support components should be in place to allow the developers to focus on providing and updating content that supports quickly and effectively automating business processes.  This post will outline a set of key features that exist in every non-trivial frameworks:

·         “Glued” together at run time (not one big monolithic project)

·         Organized into well partitioned Functional Areas that can be deployed independently

·         Security should be dynamic

·         Content/resources should be customized by Subject Matter Experts

·         Provide a simple way to create a consistent, fresh and engaging user interface style

·         Small Learning Curve allow new developers to quickly add bite-size nuggets of functionality

A couple I'm interested in checking out would be Share Point 2007 Services and Community Server.

stay tuned 

-ec