Dotmad.net

I am working on a C4I application using GIS engine, and since the engine uses the CPU for it’s calculations (not many GIS systems use the capabilities of graphics cards so far) the effect of the processor is critical in terms of performance.
We recently ran a test of the same system and scenario, once with an old processor, and once with a new, faster (both in clock speed and FSB), HyperThreading capable processor.

According to some benchmarks, the new processor performed twice better than the old one, and so did the application in the tests I ran - the processor load with the new processor was 50% of the load with the old one, meaning 100% improvement, the same as the processor showed in the benchmarks.
So if your system’s configuration’s specification was set up long before the final release, consider upgrading it - replacing a CPU may save you month of development optimizing performance.

I went to a presentation organized by SRL and delivered by Mr. Brent Carlson, CTO and co-founder of LogicLibrary, on “New methodologies and governance in SOA implementation“.

The event was well-organized, and the Mr. Carlson focused on explaining how to avoid SOA becoming ABOS (A Bunch Of Services), by managing (governing) the process of creating those services and making sure the organization re-uses it’s pre-existing resources.
Of course the presentation led to the Logidex application, with which the governing mentioned above can be done. It seems this is relevant to very large organizations, not medium and small companies.

Although he gave me some ideas to consider, I was missing two things:

1. An actual demo of the Logidex product
2. How it fits with TFS (I got the impression it takes over “higher functions”, using TFS as a plain source control solution)

I looked around, and found a webcast from 2004 explaining the product itself, an article containing some of the material he presented, and what looks like a previous version of the presentation.

I took a couple of photos, but it seems my cell’s camera can’t handle semi-lit rooms very well.

Update: Arnon’s post regarding the event reminded me one of the key ideas from the presentation - you should think of each service as a complete product, which users/customers etc.

Worried about SQL injections, user spoofing and other hacking methods?
Worry no more - here you can find various security checklists from the P&P team.

The Composite UI Application Block, created by Microsoft’s patterns & practices team, is a reusable, source code–based component based on the Microsoft .NET Framework 2.0.
It provides proven practices to build complex smart client user interfaces based on well known design patterns such as the Composite pattern, in which simple user interface parts can be combined to create complex solutions, but at the same time allowing these parts to be independently developed, tested, and deployed.
In other words, it separates UI related logic and the business logic behind it to separate classes, making it easier to test and refactor you BL code without touching the UI and the other way around.
As it turns out, there is a WIKI resource on the subject, called CABpedia.

Something I heard in few SOA lectures I have been to was the question “how do I decide which services are in the system?”, to which there was never an easy answer.

Breaking the system into those services is not an exact science, so two architects may come up with a completely different set of services for the same system.

Udi Dahan talked about a simple method in an ARcast he did few months ago, mainly using transactions to define services - since distributed transactions are complex by nature, you should avoid them, so if you need a transaction for a set of actions, you should bundle that set into a service.

I think most developers in the .Net world have already heard about Service Oriented Architecture (SOA), which is the idea of breaking the system into individual autonomous components, each one in charge of handling specific tasks.

A SOA buzz phrase I recently heard a lot about is the Enterprise Service Bus (ESB).
Basically ESB is a middle ware which handles all message traffic to/from the services in the system, so each service only needs to be connected to the ESB and needn’t worry about communication stuff.

Microsoft is currently pushing the use of their Biztalk product the the ideal ESB technology, but there are many alternatives, including building your own custom ESB.

ESB is not a silver bullet, using it will not solve every possible problem in a system designed with SOA, but sometimes it may make your life easier.

Here is some reading material on the subject:

Understand Enterprise Service Bus scenarios and solutions in Service-Oriented Architecture (IBM article)

Microsoft on the Enterprise Service Bus (ESB) (MSDN article)

Microsoft’s Enterprise Service Bus (ESB) Strategy (Blog posts of a Microsoft architect)

ESB vs. Biztalk