For those of you who are following my writing on SAF (or the Milestone 1 post for more details) - here is an introductory presentation to SAF (1.2 Mb). I delivered a slightly modified version of this 2 days ago and someone commented he would like to see more information on strategies to deal with quality attributes. I'd be happy to hear any other comments you may have

 

Last week Beat Schwegler and Ingo Rammer visited Israel with the Software Factories Seminar  (The link is to the same seminar presented in  Finland -  videos are in English)

 

Software Factories is not a new idea  - see for example "Software reuse: From Library to Factory" by M. L. Griss  (published in 1993(!)) which talks about "Software Factories" and "Domain Specific kits": components, frameworks, glue languages etc.  The current Microsoft  incarnation of Software Factories takes a similar approach focusing on Domain Specific Languages, Frameworks but also adding important aspects like multiple viewpoints, patterns and designers. The idea is that  building on modern technologies, as well as learning from the mistakes from sister approaches to code generation (OMG's MDA, in case you are wondering) will enable us to build something that is useable.

 

Microsoft seems to be taking some steps in the right direction (GAT is probably the best example). Nevertheless there is still a long way to go before we can realize the dream of "factories" for vertical applications

 

This is evident if you take a look at the  current crop of DSL examples. These are either some Horizontal languages and tools  (i.e. not aimed at a specific business domain) like UIP designer or the GAT4WS beat talked about @ the event or even worse UML designers... ('nuff said).

 

The other thing is, that developing real factories, and getting them right is a really complicated  task, which requires a lot of domain knowledge and effort. In the recent Microsoft Architect's Journal  there's an article by Jack Greenfield and Mauro Regio regarding a software factory for the Health Level 7 ( a standard for Health organization collaboration) - As far as I know this project has been under way for more than a year now (first time I heard about it was Feb. 2005) and yet the article ends with :

 

"Our experience in developing a factory for HL7 collaboration ports

has shown that we need to define better frameworks, tools, and processes

to specify the factory schema, to manage factory configuration

in a flexible and extensible way, and to better understand how

and when domain-specific languages should be used."

My expericen with MDA shows similar results. Nevertheless, they continue to say that:

 

"At the same time, initial implementations of extension mechanisms like GAT and

DSL have proven their value, filling significant gaps in software factory

infrastructure, and pointing to future innovation in that area.

 

So, maybe there's hope after all :)

 

I recently found MSF 4.0 is out  - yep, it is still in two flavors…

 

MSF Agile (or officially "MSF for Agile Software Development Process Guidance") and MSF 4 CMMI (MSF for CMMI Process Improvement Process Guidance)

I consider MSF Agile as a lightweight process, however I prefer SCRUM as an Agile project management  process.

 

I find the CMMI version more interesting - Both for  cases where Agile is not a good fit (also see  Agile vs. Plan driven development  )

and/or for organizations that need to have CMMI certifications (such as the one I currently work for). MSF 4 CMMI covers level 3 pretty well and also has some guidance moving on to the next levels.

 

Definitely worth a look :)

 

I just read an excellent post by Gregor Hohpe talking about the motivation for Event Driven semantics for service communication.

Gregor gives an example of a shipping service listening on order events and address change events to produce shipments.

It is nice to see how architectural approaches transcends business domains so well -  The Naval C4I project Udi Dahan  and myself are working on, we basically try to take the same approach. For example: A Sensors service publishes its status every predefined time - The sensor knows if something is wrong with its state. A sensor, however, doesn't know if the problem is important or  not. We designed an Alerts service that listens in on status messages, based on (changing) business rules a certain status may trigger an alert event (which a UI can then choose to display); a severe alert may result in an SMS alerting a technician to come and have a look.

 

However, while this approach is very good for inter-service communication -things aren't as rosy when it  comes to interacting with UIs. The point is UIs  are based on interaction so the request-reply idiom (should actually be implemented as request-reaction) is much more prevalent. Users really want to know their request is being taken care of

 

Another lesson we learnt is that since services make go on-line and off-line independently of each other, it is not enough just to support event listening for event aggregators to be up-to-date. One option is to relay on reliable messaging to any event posted will eventually get to the listener - there are several problems with this approach for example:

•  For one, you need a reliable message transport which might be a problem e.g. you may not be able to use JMS/MSMQ between enterprises and/or the protocols you use don't support it (e.g. WS-RM is not durable see here  and here )
• Even if you have reliable communication,  if one service has been offline for a long period of time (where long is defined by the communication load) - it may be a waste of time (or plainly wrong)  to process old events that are no longer valid

 Another option to handle this situation is to supply in the contract request for current state (the current state can be published using the same message structure used by the matching event). The advantage here is that a server coming on-line can quickly and efficiently get up-to-speed on the current situation.

 

The event thinking is relatively on par with Take-it-or-leave-it approach for contracts construction, but as I said in the previous post on contracts, I think it is more beneficial to know about your consumer and take their input into account

 

Apropos EDA,  I also learnt today that the Micro-Services  strategy Udi and me came up with had already been "invented" several years ago. It is called SEDA (Staged Event Driven Architecture) there's a nice presentation explaining it here 

 

When I first learnt about WPF (it was still called Avalon back then) I thought it was strange that Microsoft is touting Smart Client development using WinForms when the WPF/XAML development model is much more closer to the code behind concept of ASP.NET.

 

Developers with ASP.NET experience will have life much  easier in the WPF era - They'll be able to utilize the same skill-set and thinking to build:

•  Regular, run of the mill, ASP.NET application
• AJAX application (utilizing Atlas)
• XBAP (XAML Browser Applications) - Smart clients running in the browser
• XAML stand-alone applications

While  the WinForm guys (and gals) will be left behind to try and learn the new  programming model.
Looking at the different CTPs of WPF it seemed all of us have a lot to learn in order put it to full use - so I guess no one will have it realy easy :).

 

Anyway, today I read Charles Petzold's "WinForms: More Vital Than Ever" blog post  - it seems that WinForms will stay with us for a while after all (ok, ok, so no real surprise there - I just wanted to make a point). By the way, it is especially interesting seeing this  coming from  Charles considering he is one of the authors currently working on WPF books 

 

ANother interesting point is that Microsoft is going into a lot of trouble unifying all the remoting and  distribution technologies into WCF on the one hand - but will leave us with 5 different technologies for UI development (ASP.NET, WinForms, DirectX, Atlas and WPF) on the other.

 

Yoni Commented  on my SAF - Deployment post :

 

"Somewhere in your blog you've mentioned Martin Fowler's "Who needs an Architect" article in a positive way. However, it seems that in contrast to Fowler's notions of an architect who's job is to "remove architecture by finding ways to eliminate irreversibility in software designs" - you are advocating making long-term binding decisions in the initial stages of the development cycle"

 

It is very hard to argue with Martin Fowler (as Gregor Hohpe put it in a recent post "Now who would want to argue with Martin Fowler? His opinions are facts " ) However, I think that devising solutions for flexibility (such as the database schema example in the article) are also architectural decisions. What makes things even "worse" is that these decisions are usually made at the expense of other quality attributes (e.g. performace) or other project constrains (e.g. time to market) - meaning that a decision on flexibility is a making  tradeoff  or in other words an architectural decision "par excelance".

 

Thus - architectural decisions, by definition,  are early  - whether we like that or not. Furthermore, Flexibility is an important quality attribute, one the architect brings into the table (in the same way that other stakeholders bring their concerns - e.g. the Project manager who want the project to end on time and on budget). It is the architect's role to balance quality attributes, understand the tradeoffs and make the decisions that will enable the project to achieve its goals. Many of these decisions have to be made early so that the project can move on, some of these decisions have to be made early to prevent ad-hoc architecture (un-balanced, spur of the moment decisions that will be hard to change). I believe very few decisions can be postponed without doing anything (i.e. without making some active decision to introduce flexibility).

 

 

Udi Dahan writes about "Contract First, Discussion Second?" saying that "a service's contract is a more "take-it, or leave-it" kind of deal." 

There are situations when this is true - for example when Amazon decided to expose some of its functionality as Services they probably didn't negotiate it with most (if not all) of us. Similarly, whenever you want to consume a deployed version of a service you can either use it as is or move on.

However, services are rarely developed in a void. This means that when you set up to design the next iteration of a service (first or otherwise) there are usually several potential consumers out there (other internal systems, partners etc.) - and like it or no, you will be negotiating the service contract with them, after all, the  whole idea of the service is to add some business value. If you disregard your consumers, it will make it harder on them to actually make use of the (hopefully) wonderful functionality you will be providing.

 

This, Also means that it is better to negotiate the contract first (i.e. as one of the first steps of  developing the next service version). Again, deciding on the contract upfront, allows the other parties to get organize to better take use of the functionality that will be exposed through the service once it is deployed.

 

I suggest you be pragmatic when you set up to develop a service, meet with the potential consumers and try to agree on something that will be useful for them - or as the Beatles once said "let it be, let it be, speaking words of WSDL, let it be"…

 

I've just found out (via  Gianpaolo's blog) that Roger Wolter (former PM of Service Broker) started blogging . He is going to focus on  Data in a Service Oriented world. I had a chance to work with Roger for a short time, which was enough to notice that if anyone knows about data, it is him.  I guess there is no surprise there, considering his past at Microsoft working on :SQL Server Service Broker, SQL Express, SQL XML Datatype, SOAP Toolkit, SQLXML and COM Plus.

His first post (after the obligatory "hello world" post) is about Service Broker positioning (vs. MSMQ, Biztalk and WCF) - Subscribed