Friday, September 21, 2007

CompSci != Software Engineering

Regarding Chris Chapman's article Reviewing Ontario CompSci Schools: Who's Teaching Best Practices? of September 17,2007

I was going to post this as a comment on his blog, but it turned into a posting of my own :)

I definitely appreciate the sentiments Chris has raised and respect the research he has done (even if he says it is a rough assessment). My biggest beef with this analysis, however, is that it completely ignores the fact that as many as half of the schools looked into also offer Computer Engineering with a Software specialization, if not true Software Engineering within the Engineering (not the Science) faculties.

I will insist that this is an important distinction. A Science faculty is going to emphasize research and development, as well as the more hard/pure/abstract aspects of Computer Science. Topics such as best practices in industry, ethics and professionalism are of course going to be elective, as they might be in mathematics or botany programs. I suppose the unfortunate reality is that most Comp Sci grads still go into industry as a developer (for instance) but the industry has made the assumption that such grads are software professionals truly grounded in best practices and methodology.

Software engineering is such an oft-abused word and by no means does a comp-sci grad necessarily have software engineering skills or even understand what software engineering really means. Especially in Ontario (to tow the line of the PEO) it is becoming clear why so many engineering faculties are trying to bring software engineering into their domain - industry is expecting a software developer to have engineering skills! And as you imply, it is to the detriment to us all in the software industry if these issues are not cleared up: people in the industry need to have a grounding in best practices and projects need to completed successfully within time/budget etc.

Having come through the Software Engineering program at UWO, I agree that there is still some bias towards requirements engineering (which for better or worse is still an approach used in the industry) but other methodologies including Agile are gaining more ground. The academic calendar for Western's SE program can be seen on this link:

http://www.westerncalendar.uwo.ca/western/web/2007(new)/Courses_UWO_SE.html

Universities by nature still tend to be slow moving of course and with such a rapidly evolving industry like software, there will likely always be a disparity between what is taught and what is done. That means industry may have to bear the burden of ramping up new grads. So be it - I'm sure this is nothing new to most employers. That said, I am all for academic programs (particularly ones with an industry focus, like engineering) teaching and making mandatory courses on best practices.

The reasons for software project failures are many, not the least of which is people understanding the difference between software and other "hard engineering" projects. I think much of the solution lies in educating industry on where best practices are truly taught (as Chris has helped show) but more importantly actually teaching them to all software graduates (especially those becoming software professionals) and this will likely include the continued migration of teaching software engineering into the engineering schools.
Posted by at 2 comments:
Labels:

Monday, September 17, 2007

Path to MCPD Certification Revised!

Whoa was I off... In one of my previous postings I outlined the steps to achieving an MCPD in Enterprise Applications. While legitimate, it is leveraging exams that focus on .NET 1.1 and are not part of the "new" stream of MCP exams. If you actually read the page for the MCPD requirements (as I apparently did not) it indicates that for individuals with no previous certifications, it really takes 5 exams (see plan below). This new path cannot, sadly, leverage my MCTS in BizTalk Server and does not have any intermediate certifications besides a .NET MCTS, but it only takes 5 exams rather than the 7 I had outlined before.


Exam

Certification Awarded

70-536


70-528

MCTS: .NET Framework 2.0 Web Applications

70-526

MCTS: .NET Framework 2.0 Windows Applications

70-553

MCTS: .NET Framework 2.0 Distributed Applications

70-549

MCPD: Enterprise Applications Developer

If you like, you can also get the specific MCPD after each of the MCTS if you don't intend on going as far as the MCPD Enterprise Applications.

Certification requirements:
Posted by at No comments:
Labels:

Thursday, September 13, 2007

Migrating BizTalk 2004 (VS 2003) Solution to BizTalk 2006 (VS 2005)

While the BizTalk Server product team has done a commendable job of being able to migrate an already deployed BizTalk 2004 solution to BizTalk 2006 in-situ, there is definitely some effort in upgrading the Visual Studio solution itself such that subsequent deploys actually work.

The situation is complicated by two things: the change in project definitions between VS 2003 and VS 2005, and of course the migration from .NET 1.1 to .NET 2.0 (there should be no complication by .NET 3.0 with BizTalk 2006 R2 as .NET 2.0 exists as-is in 3.0).

Depending on the solution, some of the following items may not apply, and there may be other items not mentioned you will need to take care of (ie referencing deprecated classes, method overloads etc).


  1. Migrate the solution to VS 2005 by simply opening the VS 2003 .sln file.  Complete the steps of the solution migration wizard.  This will generate a report of the items you may need to fix (esp deprecated classes)
  2. Once in the solution, at the BizTalk Project level you will need to do the following:
    1. If you have web references in your project, you will need to rebuild them.
      1. Delete each web reference and re-add them with the same name
      2. If you use Dynamic web references, ensure that property is selected
      3. Add a reference to System.Configuration if it is not there already (the compiler will fail otherwise)
    2. Open the project's properties
      1. Assign a default BizTalk Configuration Database
      2. Assign an Application Name
  3. For each schema in your solution that uses promoted properties
    1. Open the 'Show Promotions' dialog.  This will rebuild the xsd's code-behind (.cs)
  4. For each orchestration with a web-port
    1. Delete the configured web port (since you regenerated the web reference)
    2. Re-add the web port with the same name, ensuring it is a Dynamic web port if necessary
    3. Re-assign message types for messages defined in Orchestration Explorer
    4. Re-connect send/receive shapes if necessary
You may find after your first build there are new warnings.  Some warnings have been added to assist in improving the performance/stability of your BizTalk solution.  The one most notable to my solution was the following:

Performance Warning: marking service 'OrchestrationName' as a longrunning transaction is not necessary and incurs the performance penalty of an extra commit

For orchestrations where long-running was not necessary (ie do not contain send/receive pattern or other long-running transactions), I have since changed them to use Transaction Type of None.  Hopefully we will see a reduction of database chatter for these orchestrations when we benchmark the changes.

Clearly the migration is not trivial, though hopefully yours is smooth and relatively quick.
Posted by at 1 comment:
Labels:

Thursday, September 06, 2007

XLANG/s error 10034 FileLoadException at _GetTypeByName, Issue and Resolution

(For those who want the abstract, see `The Solution` below.)

After performing a migration of a BizTalk 2004 project to BizTalk 2006 and running some unit tests, I ran into a very frustrating and at first misleading error in the application event log.

Source: XLANG/s
Event ID: 10034
Type: Error
Category: None

Uncaught exception (see the 'inner exception' below) has suspended an instance of service ' Bulloch.ProcessTrs(5146e3cd-3d88-4845-0795-4ccd1196bbe3)'.
The service instance will remain suspended until administratively resumed or terminated.
If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception.
InstanceId: 29059449-1b02-4e27-9b09-520ec69520a7
Shape name: Receive Trs File
ShapeId: f8763ddd-f0a3-41a9-9aee-4d13bc541cfa
Exception thrown from: segment 1, progress 3
Inner exception: The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047)
       
Exception type: FileLoadException
Source: mscorlib
Target Site: Void* _GetTypeByName(System.String, Boolean, Boolean, Boolean, System.Threading.StackCrawlMark ByRef, Boolean)
The following is a stack trace that identifies the location where the exception occured

   at System.RuntimeTypeHandle._GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark, Boolean loadTypeFromPartialName)
   at System.RuntimeTypeHandle.GetTypeByName (String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark)
   at System.RuntimeType.PrivateGetType(String typeName, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark)
   at System.Type.GetType(String typeName)
   at Microsoft.XLANGs.Core.XMessage._verifyPublisherSchema()
   at Microsoft.XLANGs.Core.XMessage.FetchProperties()
   at Microsoft.BizTalk.XLANGs.BTXEngine.BTXPortBase.ReceiveMessage (Int32 iOperation, Envelope env, XLANGMessage msg, Correlation[] initCorrelations, Context cxt, Segment s)
   at Bulloch.ProcessTrx.segment1(StopConditions stopOn)
   at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment (Segment s, StopConditions stopCond, Exception& exp)

My first thought was (due to the FileLoadException) was that an assembly couldn't be found and gave myself a crash course in debugging .NET assembly loading (the Fusion Log viewer is very useful. See a good explanation here).  Sadly, this did not help. 

After fearing a breaking change in the BizTalk engine (I was using the R2 Beta), I started again from first principles, first trying to trace the exception stack using Lutz Roeder's .NET Reflector.  This triggered the first critical link: the orchestration is failing on the Receive shape, confirmed by the stack trace referring to the method ReceiveMessage() in the XLANG/s engine.  I knew the subscription was fine, as it triggered the orchestration, but it seemed to have difficulty loading the message instance itself.  The message body looked fine and so I started to look at the message context.  Looking at the property SchemaStrongName, I looked at the description:

"SchemaStrongName" is not a promoted property.  Such Properties can be used for message tracking and can be referenced by components (e.g. from Orchestration), but they are not used for routing.

Working on this lead, I looked at the strong name of the schema that was deployed in the Schema node of the BizTalk application.  Sure enough, it didn't match.  Consequently, the orchestration subscription kicked off a new orchestration instance, but when the engine tried to load the message instance by type name (ie its strong name) it failed.

First of all, I had been using a custom file disassembler to build the original message and in hindsight, this should have been one of the first places I looked.  In the custom pipeline component, I was manually setting the value of SchemaStrongName.  The assembly's strong name changed when I built the new project because I started to use a new strong name key, thus changing the PublicKeyToken part of the strong name.

Second of all, and perhaps rather mysterious, is that the original code (which had been functioning in BizTalk 2004) used a different format for the SchemaStrongName string.  Strong names for schemas should be in this format:
Fully.Qualified.SchemaName, Fully.Qualified.AssemblyName, Version=x.x.x.x, Culture=neutral, PublicKeyToken=XXXXXXXXXXXXXXXXXX
whereas the original code simply used the format
Fully.Qualified.AssemblyName, Version= x.x.x.x, Culture=neutral, PublicKeyToken=XXXXXXXXXXXXXXXXXX

Beats me as to why it worked in BTS 2004, but the good news is I found the solution.

The Solution

If using custom file disassemblers where you manually assign the SchemaStrongName property, ensure it always matches the complete schema strong name of the deployed schema as shown in the BizTalk Administration Console, otherwise you will get an XLANGs error indicating a FileLoadException.
Posted by at No comments:
Labels:

Wednesday, September 05, 2007

Path to MCPD Certification Demystified

Update Sept 17, 2007: [See updated Path to MCPD post here]

I don't know about you, but I found it a bit unclear at first glance of what the best route to each MCP certification and what the 'hierarchy' is. I have had to infer as much by the number of exams and which certs were esssentially pre-reqs for others.

Here is the plan I have developed that (AFAIK) is the shortest path to MCPD (measured by number of exams written) while maximizing the number of intermediate certifications. Exams to be written in order:

Exam

Certification Awarded

70-235

MCTS (BizTalk)

70-320


70-315

MCAD

70-316


70-300

MCSD for Microsoft .NET

70-553


70-554

MCPD: Enterprise Applications Developer

I already have the MCTS (BizTalk). As of now I am setting a goal of writing an exam every two months, which if I follow will make me MCPD in one year's time. Wish me luck!

Certification requirements:
Exams:
Of course, feel free to substitute any other MCTS to begin with (most of which require two exams) and the Visual Basic .NET variants if necessary for your own needs :)
Posted by at No comments:
Labels: , ,
Subscribe to: Posts (Atom)