nPlus1.org

Design Review Checklist for SOA Service Capabilities

Michael Levy — Tue, 10 Nov 2009 14:03:10 GMT

http://artofsoftwarereuse.com/2009/11/09/design-review-checklist-for-service-capabilities/

Vijay Narayanan has created a checklist for reviewing service capabilities of SOA solutions. According to the post:

"This checklist contains close to 50 questions and covers the following areas:

Functionality
Design decomposition
Documentation
Coupling
Reuse
Consistency
Integration
Performance
Reliability
Deployment"

Busting the Mythical Man Month

Mike Wood — Sun, 08 Nov 2009 13:24:04 GMT

A group at Microsoft Research decided to investigate several of the ideas set forth in the Mythical Man Month as well as a few other software development trends, such as Test Driven Development. The results are pretty interesting.

http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx

“To some degree, The Mythical Man Month formed the foundation of a lot of the work we did,” [Nachi] Nagappan says. “But we also studied other existing assumptions in software engineering. They can be good or bad, because people make decisions based on these assumptions. Our primary goal was to substantiate some of these beliefs in a Microsoft context, so managers can make decisions based on data rather than gut feel or subjective experience.”

Some of the items covered were TDD and the use of assertions in code.

If you have experience with these practices, do you agree or disagree with their findings?

Object Oriented Programming, Part 2: Understanding Objects

James Bender — Fri, 06 Nov 2009 01:51:23 GMT

Before we can do that, it’s important to understand the basics of objects before you can grasp Object Oriented Programming.

Key Object Concepts

Objects are essentially a collection of structured data stored in memory. An object is based on a class that defines how to create an object.

In this article, I will describe the following concepts.

· Classes

· Class members

o Properties and Fields

o Methods

o Events

· Instances

· Static Types

· Interfaces

· Message Passing

Because all these terms are interrelated, it is difficult to discuss one without mentioning the others. So be patient if I mention a term before I define it – I will get to the definition shortly.

Classes

A class is a definition for an object. It describes the attributes such as properties, fields and methods (more on this later) of an object. It may also set default values and implementations for these attributes. Think of a class as a blueprint we can use to help us build an object. Generally, we work with classes only at design-time, defining the attributes appropriate for that class. In most cases, we do not work directly with classes while a program is running.

A class is often represented by a UML class diagram, such as the one below.

Public Members

A class (and an object) exposes a finite set of publicly-exposed members. Members are methods, properties and fields (defined below). This public interface is how you interact with an object. An object may be capable of far more than what it exposes by its public interface, but these other capabilities are not seen directly by the outside world. Keeping object interfaces simple is one way that an object can help simplify a complex system.

Properties and Fields

Properties and fields describe static data associated with a class.

A property is similar to a field, but a property provides a “Getter” and “Setter” – methods that run when you attempt to read or write the value of a property. This allows a developer to add code that will automatically run whenever a field’s value is retrieved or assigned. This code might perform validation or calculate a value on the fly.

Methods

A method is a discrete section of code that is associated with a class and therefore with an object. Some methods return a value; others just run code and return nothing.

Instances

So far, we’ve been talking about objects without defining what an object is. An object is an instance of a class – it represents a specific set of data.

We said before that a class is like a blueprint. Think of an object as the house, machine or other device built from that blueprint. Methods, properties and fields defined in a class become methods, properties and fields in any object based on that class.

It is possible to produce more than one house from the same blueprint. Similarly, it is possible to create multiple objects from the same class.

Static Types

It is possible to instantiate a class without explicitly creating an instance of that class. You can do this if the class is defined as “static”.

For static classes, the .Net framework takes care of instantiating an object for us. Static types require and use only one instance of a class.

Constructors

A constructor is a special type of method that runs when an object is first created. This is a good place to put initialization code for your object.

You may create constructors that accept parameters. This is useful if you want to set the values of an object’s properties at the time you instantiate that object.

Events

An event is a notification by an object that something has happened. This something might be user input, such as a mouse-click on a form; or it can be something less tangible, such as a customer exceeding his credit limit. Other objects may or may not respond to these events. It is up to these other objects to subscribe to an event if they wish to respond to that event. Generally the object and raising event do not know how the event will be consumed.

Interfaces

An interface looks like a class in that it can have properties, fields and methods. The difference is that the properties and methods contain no implementation code. Interfaces are used only to define the public members of a class. A class implementing an interface inherits all the public members of that interface and it is up to the class to provide implementation.

Message Passing

Objects communicate by passing messages. These messages can be primitive data types, such as strings and integers; they can be XML; they can be binary data; or they can be other objects. Generally speaking objects expose public members to accept these messages. This helps to simplify the communication between objects.

In this article, we learned the basics of objects, their definitions, their members and how to work with them. In the next article, we’ll introduce Object Oriented Programming constructs and how these concepts are implemented using objects.

David Giard has been developing solutions using Microsoft technologies since 1993. In the past, he has spoken at Day of .Net, CodeStock, Microsoft DevCares, Microsoft ArcReady, Dot Net University, X Conference and numerous user groups around the Midwest. He is a recovering certification addict and holds an MCTS, MCSD, MCSE, and MCDBA, as well as a BS and an MBA. He is the host and producer of the popular online TV show Technology and Friends. He is an officer of the Great Lakes Area .Net User Group. He is an avid photographer and has visually documented many of the Heartland community events. You can read his latest thoughts at www.DavidGiard.com.

David lives in Michigan with his two teenage sons.

Turtles and Architecture

Michael Levy — Wed, 04 Nov 2009 15:14:16 GMT

http://techdistrict.kirkk.com/2009/11/03/turtles-and-architecture/

"Software architecture is 'turtles all the way down.'Many of us can relate. In dysfunctional organizations, architects and developers fail to communicate effectively. The result is a lack of transparency and a lack of understanding by both sides, ... The failure often occurs (though I recognize there are other causes) because architecture is about breadth and development is about depth. Each group has disparate views of software architecture, and while both are warranted, a gap between these views exists. The architect might focus on applications and services while the developer focuses on the code. Sadly, there is a lot in between that nobody is focused on. It is this gap between breadth and depth that contributes to ivory tower architecture."

nPlus1 Winter 2009 ArcSummit (Chicago)

Mike Wood — Fri, 30 Oct 2009 00:31:31 GMT

nPlus1.org is hosting its fifth Architecture Summit on December 7th in Chicago, IL. The topic of this summit will be Patterns and Principles.

Session One: Software Patterns
Patterns are an important tool to use as architects and developers. They provide a common vocabulary for us to design with, as well as a common approach to a common problem. Come learn about useful patterns, and how to use them in your everyday code.

Session Two: How I Learned To Love Dependency Injection
Dependency Injection is one of those scary topics that most developers avoid. It sounds all ‘high-falootin’ and complex. It’s not. Really. We wouldn’t lie. It’s a great way to manage complexity in your system, and a great way to make your system so much more testable. And isn’t that what we all want?

Each session will be followed by open discussions periods.

A catered lunch will be provided starting at noon when the welcome time begins.

There will be an optional Introduction to Object Oriented Programming prior to lunch from 10:00 AM to Noon. If you're looking to get up to speed quickly prior to the patterns and DI talk, or if you just want a refresher, please come to the morning session.

Cloud Computing Use Cases White Paper

Michael Levy — Thu, 29 Oct 2009 12:38:58 GMT

http://www.stumbleupon.com/s/#2jJDaf/cloud-computing-use-cases.googlegroups.com/web/Whitepaper_V2_Draft_3.pdf?gda=V5VvH0wAAAAPGXgkJ5fi30lYg4awQpoEt_zsDgQGqOYzy1aGmKyJO7dMQXP4LWLs8nZKm8G1Sg4qmt-Oc-AoYVao2e3x_UDw_Vpvmo5s1aABVJRO3P3wLQ&gsc=QZjXAgsAAABQG7y5erK9QmR0z42f1NGR/

"The Cloud Computing Use Case group brought together cloud consumers and cloud vendors to define common use case scenarios for cloud computing. The use case scenarios demonstrate the performance and economic benefits of cloud computing and are based on the needs of the widest possible range of consumers.

The goal of this white paper is to highlight the capabilities and requirements that need to be standardized in a cloud environment to ensure interoperability, ease of integration and portability. It must be possible to implement all of the use cases described in this paper without using closed, proprietary technologies. Cloud computing must evolve as an open environment, minimizing vendor lock-in and increasing customer choice."

Enterprise Service Pollution

Michael Levy — Tue, 27 Oct 2009 16:25:06 GMT

http://service-architecture.blogspot.com/2009/10/requirements-landfill-challenge-of.html

Enterprise Services of any type from Business Services like procurement through to technical infrastructure services such as Identity management are all at risk from a threat of pollution. I call this threat the requirements landfill.

One of the key principles of SOA in operation has been the ability to have services which are used across the enterprise. These single services represent a single point of truth and a single functional boundary that ensures enterprise consistency, it is their goal to shift away from fragmented sytems towards Services which represent the single way of accomplishing a technical or business objective

This is great and good but I've been seeing something more and more over the past few years. Its that these enterprise class services, particuarly when successful, suffer from being the easy place to add new requirements rather than always being the right place to add those requirements.

Microsoft releases The Infrastructure Planning and Design Guide Series

Michael Levy — Mon, 26 Oct 2009 12:20:02 GMT

http://technet.microsoft.com/en-us/solutionaccelerators/ee382254.aspx

The Infrastructure Planning and Design guide series gives you architectural guidance for Microsoft infrastructure products. The IPD guides help clarify and streamline design processes for Microsoft infrastructure technologies, with each guide addressing a unique infrastructure technology or scenario.
Learn more.

IPD guides provide:

Concise planning guidance to design an infrastructure for Microsoft technologies
The critical decisions to be addressed and the available options
A means to validate design decisions with the business to ensure that the solution meets the requirements of both business and infrastructure stakeholders

SOA Manifesto

Michael Levy — Mon, 26 Oct 2009 12:04:31 GMT

http://www.soa-manifesto.org/

So it seems that some SOA folks got together and created a manifesto for SOA in a manner similar to the Agile Manifesto. What do you think?

To gain collaboration, lean on the common values

Michael Levy — Tue, 20 Oct 2009 17:06:57 GMT

"It is not enough for an EA to “want” to collaborate, or even to be “open” to collaboration. Other roles can make that claim. The EA has no choice but to “drive” collaboration: to make collaboration happen in situations where your stakeholders may actually be incented to ignore you, disregard you, or outright oppose your very existence.

And there’s the rub. How does an EA create an environment of collaboration, and mutual interdependency, without wielding a large club? There are many answers to this question, but the one I want to touch on, right now, is 'the appeal to common values.' "

http://blogs.msdn.com/nickmalik/archive/2009/10/19/collaboration-without-common-values-is-fruitless.aspx