none
Loosely coupled code, a myth?

    Question

  •  

    Tightly Coupled – depends heavily on external components. In practice what does this mean. In the process of creating a solution you end up with a number of services that service a common interest. For example, logging, authentication\verification, exception handling, utilities (e.g. Xml, file handling, etc), etc. This immediately creates a number of dependencies. Conveniently ignoring those “common” dependencies you then start to model the domain problem. So you may have a Car that contains an Engine, wheels, seats, etc, etc. So in order to create a car you need to have these other entities available to you. Now some wise designer may model this by arguing for re-use and saying I’m going to create an engine service, a seat service, etc, etc because hey I’m serving up for the big cloud now not just this tiny solution. Admirable but probably impractical, but why is it impractical, what is wrong with this approach? This is where some arguments start to talk about dependencies in a very specific fashion, such as - I’ve derived from engine to create a V8 engine and a Vtec engine. I’ve put these in different assemblies and I want to choose/configure which one I want to go into which car. So how do I reduce the dependency on which assembly to load? Hmm, I think this is tightly coupling with a little ‘c’. Ok sure with dependency injection or factory or broker or etc the decision about which specific assembly to load is JIT but the fact remains that I still need to reference some interfaces/base class or drop down the lowest denominator of loosely typed. Even if I do use interfaces then it gets into the nasty world of versioning and the headaches that brings to the table.

    So my question is, is there really a good mechanism for creating truly loosely coupled components or is a case of getting to the interface level and then giving up? Lights touch paper and backs off Wink

    Tuesday, April 08, 2008 9:29 PM

Answers

  • You at it again mate, getting into these philosophical threads! Big Smile

     

    First of all, my view on coupling is largely based around concrete implementation.  Clearly, as you point out objects have dependencies, and somewhere those dependencies would have to come together.  What we're looking for with loosely coupled code, is just that something that depends as loosely as possible on some other artifact, otherwise we'd call it completely decoupled Smile

     

    Loose coupling is being able to change the implementation in a certain subsystem, or service or whatever without affecting another subsystem or service or whatever.  If the definition of that contract of service changes, then we can't really expect our implementations then to stay unchanged, or not without some really unmanageable late bound configuration defined nightwares at least (let's leave that idea there!)

     

    As you point out, there's a need in the engine example for a factory, which should be served up through an interface.  The coupling to that 'subsystem' for example is through the services it provides.  There is nothing stopping you swapping out one implementation for another.  For this loose coupling to work as intended no subsystem should be dependent upon implementation detail, only on the services they provide or the contract that interface fulfills.

     

    An approach that I've used successfully in the past is a strategy pattern with a factory pattern, commonly known as a provider.  That allows implementations to be served up via and implemented interface, and each system has no knowledge of the implementation details, only the services that it provides.

     

    Interfaces and problems with them changing has always been a challenge, but shouldn't make us back away from using them, or striving for as loosely coupled a system as possible, I wouldn't say? 

     

    Designs of systems evolve, I don't believe I've ever been involved with a project that hasn't changed, or doesn't immediately go into a second revision once the first is delivered.  We should expect the changes, welcome them even, which is what loose coupling is about.  However, if the original definition of modelling cars also has to take into account aeroplanes, we're likely to expect that the service contract will have to change, as the purpose of the software has also now shifted.  I would imagine that that would be the case as least, since only on a James Bond film have I seen a car with wings!  It's similar but different enough to turn our system from a car classification system, to a vehcile classification system. 

     

    I hear what you're saying, but I think you're confusing loose coupling with a software utopia of being able to define services, and they can somehow automatically communicate with each other without knowing anything about each other.  If I use the analogy of cars and planes again (re-use is good!) It's a bit like a user of a car that it used to the car interface contract being able to pilot a plane to the same standard and they drive the car.  I'm just hoping that you don't fly like that at any rate!

     

    Keep 'em coming mate!

     

    Martin Platt.

     

     

     

    Tuesday, April 08, 2008 10:08 PM
  • Some on the good articles on Why do we require High Cohesion and Loose Coupling in our design architecture:

    http://en.wikipedia.org/wiki/Coupling_(computer_science)

    http://c2.com/cgi/wiki?CouplingAndCohesion

    http://www.cs.kent.ac.uk/teaching/this_year/modules/CO/3/20/slides/lecture15.pdf

     

    Wednesday, April 09, 2008 6:23 AM
  • I must agree with the base class /interface..

    you must define the methods to call and the parameters needed for these methods, and that's not so easily changeable.

    a common understanding of a number of interactions is necessary for any interaction to succeed.

    think about it as going to the store for a bread. 

     

    Normally the contract is :

    IStore{

    public Bread Buy(Money m);

    }

     

    if you want to change the arguments (say not sending any money Wink) - the store keeper will not be so happy ..

     

    For myself, any (exposed) contracts are bound to use the simplest of POCO object possible, this to eleminate as many possibilities as possible.


    Also, once a contrac has been published, it should remain there for all eternity.. (unless it really poses a breaking change). sadly, that means that you have (a asmx example):

     

    OrderService\20070801\default.asmx

    OrderService\20080101\default.asmx

     

    after the web service layer comes an interpreter layer which maps it to true domain objects, but the "old" interface is at least still out there.

     

    imho, wcf provides some nice capabilities there with IExtensibleDataObject...

     

     

    my 0.02$
    Monday, April 14, 2008 12:38 PM
  • I guess Karl Weick would have loved to ease (if not solve) the gnarls here.

    I think his theories that were organizational and individual based can be applied to software as well.

    Martin is right in the sense that loose coupling has been misconstrued for effective change management. Though it's a banality please excuse when I say "Changes and uncertainty are certain" in this nascent software industry (at least relative to other industries).

    What is lacking in existing systems is the concept of Sensemaking. This is something which I think complements loose coupling and that can make both the requestor and the provider more intelligent and sensible. Even if either of them implements sensemaking, interfaces could look much better both technically and pragmatically. One could call this as "AI" but I would just term it as "I".

    It's high time for companies like Microsoft to start thinking on these lines and as usual abstract this intelligence from service developers (I say this because it is more appropriate to services than internal modules).

     

    Shyam

    Tuesday, April 15, 2008 12:50 PM

All replies

  • You at it again mate, getting into these philosophical threads! Big Smile

     

    First of all, my view on coupling is largely based around concrete implementation.  Clearly, as you point out objects have dependencies, and somewhere those dependencies would have to come together.  What we're looking for with loosely coupled code, is just that something that depends as loosely as possible on some other artifact, otherwise we'd call it completely decoupled Smile

     

    Loose coupling is being able to change the implementation in a certain subsystem, or service or whatever without affecting another subsystem or service or whatever.  If the definition of that contract of service changes, then we can't really expect our implementations then to stay unchanged, or not without some really unmanageable late bound configuration defined nightwares at least (let's leave that idea there!)

     

    As you point out, there's a need in the engine example for a factory, which should be served up through an interface.  The coupling to that 'subsystem' for example is through the services it provides.  There is nothing stopping you swapping out one implementation for another.  For this loose coupling to work as intended no subsystem should be dependent upon implementation detail, only on the services they provide or the contract that interface fulfills.

     

    An approach that I've used successfully in the past is a strategy pattern with a factory pattern, commonly known as a provider.  That allows implementations to be served up via and implemented interface, and each system has no knowledge of the implementation details, only the services that it provides.

     

    Interfaces and problems with them changing has always been a challenge, but shouldn't make us back away from using them, or striving for as loosely coupled a system as possible, I wouldn't say? 

     

    Designs of systems evolve, I don't believe I've ever been involved with a project that hasn't changed, or doesn't immediately go into a second revision once the first is delivered.  We should expect the changes, welcome them even, which is what loose coupling is about.  However, if the original definition of modelling cars also has to take into account aeroplanes, we're likely to expect that the service contract will have to change, as the purpose of the software has also now shifted.  I would imagine that that would be the case as least, since only on a James Bond film have I seen a car with wings!  It's similar but different enough to turn our system from a car classification system, to a vehcile classification system. 

     

    I hear what you're saying, but I think you're confusing loose coupling with a software utopia of being able to define services, and they can somehow automatically communicate with each other without knowing anything about each other.  If I use the analogy of cars and planes again (re-use is good!) It's a bit like a user of a car that it used to the car interface contract being able to pilot a plane to the same standard and they drive the car.  I'm just hoping that you don't fly like that at any rate!

     

    Keep 'em coming mate!

     

    Martin Platt.

     

     

     

    Tuesday, April 08, 2008 10:08 PM
  • Sorry I think the arch' forum should be less code driven, and I like the sound of my own...keyboard Wink

    Yes I'm not under any illusion that there is some magic solution (although please prove me wrong) and that some form of contract be it interface or base class will be the likely outcome. I think the salient point you made (sorry that sounds like you only made one) is to be as loosely coupled as possible in terms of the impact of change. However, practically, I'm beginning to think that we've not really solved a great deal. Interfaces change which means changing the clients. "No you create a new interface", I hear you cry. But practically do you? Do you want to support a number of versions, of course not. You strive to refactor, if you're in house then you just bin the old interface. If you're public facing you mark the old one as obsolete which, again, practically means you're "forcing" the clients to change to the new one. So we've not really isolated our clients from change. Yes technically we have, but no practically we haven't. It just seems like one of those areas where we're kidding ourselves when we sit back and look at all our lovely contracts and believe we've done our best to isolate change.

    Wednesday, April 09, 2008 5:55 AM
  • Some on the good articles on Why do we require High Cohesion and Loose Coupling in our design architecture:

    http://en.wikipedia.org/wiki/Coupling_(computer_science)

    http://c2.com/cgi/wiki?CouplingAndCohesion

    http://www.cs.kent.ac.uk/teaching/this_year/modules/CO/3/20/slides/lecture15.pdf

     

    Wednesday, April 09, 2008 6:23 AM
  • The first two links are nice intro's to the subject but I did enjoy the conversation from the kent thread. I also linked the link in it to Fowlers where the last paragraph indicates how vauge any advice about reducing coupling is. The other point I get from the link is again no-one really offers a good solution. I just think it remains one of those things to strive for but you'll never obtain

    Monday, April 14, 2008 10:45 AM
  • I must agree with the base class /interface..

    you must define the methods to call and the parameters needed for these methods, and that's not so easily changeable.

    a common understanding of a number of interactions is necessary for any interaction to succeed.

    think about it as going to the store for a bread. 

     

    Normally the contract is :

    IStore{

    public Bread Buy(Money m);

    }

     

    if you want to change the arguments (say not sending any money Wink) - the store keeper will not be so happy ..

     

    For myself, any (exposed) contracts are bound to use the simplest of POCO object possible, this to eleminate as many possibilities as possible.


    Also, once a contrac has been published, it should remain there for all eternity.. (unless it really poses a breaking change). sadly, that means that you have (a asmx example):

     

    OrderService\20070801\default.asmx

    OrderService\20080101\default.asmx

     

    after the web service layer comes an interpreter layer which maps it to true domain objects, but the "old" interface is at least still out there.

     

    imho, wcf provides some nice capabilities there with IExtensibleDataObject...

     

     

    my 0.02$
    Monday, April 14, 2008 12:38 PM
  • This is what loosely coupled code means to me...

     

    When I design an application called car, that has components like Engine, Chasis, Wheel, exhaust, etc.,

     

    The following would be my design goals

     

    1. No change if, -- Engine is upgraded from V6 to V8.

     

    2. Refractoring required to support engines that run on,  -- Kerosene, Ethanol, Diesel, Hybrid without making lot of changes to my car. 

     

    3. Major change to drive-terrain, -- if a new type of engine something that runs on Magneticforce, cold-fusion, etc..  Yes, I did mention Drive-Terrain, because my other components of car like wheels, steering may not change significantly.

     

    4. But my design may not support --  if my application morphs from Car to Plane, Rockets or Submarine.  True all those have engine, exhaust, wheels, etc., but the environmental medium is totally different, that I have to build a whole new system.  Some components may be borrowed [yes borrowed], but not coupled.

     

    Monday, April 14, 2008 3:19 PM
  • re: contracts for ever

    With my puriest hat on I'd agree, with my pragmatic-I've-got-to-support-it hat on I'd disagree. The people with the money that make the decisions will quickly go with the latter and I don't blame them.

     

     

     

    Monday, April 14, 2008 3:26 PM
  • ah,

    pragmatism, my old nemesis Stick out tongue..

     

    in theory contracts should remain, in practice they often disappear with the first hint of change..

    which is quite normal, when you're dealing with a limited number of consumers

    but if Microsoft decides to change it's public API for cloud services (the live map thingie and so on) then I guess having old interfaces linger makes some more sense...

     

    Cheers

     

    Monday, April 14, 2008 3:40 PM
  • It is interesting to see how big companies deal with this. Microsoft have felt the pain with backwards compat' when it comes to the desktop and IE so it will be interesting to see which way they go with their public APIs. Companies such as Apple tend to give you one version (if that) to change and then pull the plug, ask anyone with a slightly old Mac how easy it is to run a new Ipod on them. So the versioning argument comes down to cost vs forcing clients to changes. But again, there is that phrase again, forcing clients to change. Of course the term "cost" needs to be quantified. I'd naively think that it would cost a company its customers if they just force them to change, but then Apple aren't doing too badly are they?

     

    I still remain convinced that loosely coupled code will only ever be a theory and not a law.

     

     

    Monday, April 14, 2008 3:51 PM
  • there's some interesting articles out on IE 8, which has/had strict html interpretation on by default. which means that about 30% of the internet still works... question is what they will do with it before they release..

    also, MS now seems to be more at ease with breaking api changes (half of the pre vista stuff is broken) than they were before.. (raymond chen had a few posts on this if i'm not mistaken).

     

    Apple gets away with a million things MS would never get away with.. but then again, they have a certain image Stick out tongue

    if you can't afford the latest and greatest, you shouldn't use a mac. Only cool, successful and rich people use macs.

     

    i wholeheartedly agree on the theory vs law, but as a "design goal" loosly coupled code has it's merits..

    Monday, April 14, 2008 3:58 PM
  • I think that we need a clear distinction between loosely coupling our intended implementations, instead of designing a code where nothing depends upon anything else, and is completely unaffected by said changes.

     

    We also need to descriminate between good and bad practices.  An interface or contract is by definition something that should not be changed, unless all stakeholders for that contract agree to it.  The reason that I say that is if a new interface makes breaking changes and replaces an older interface, and all users of that contract are in agreement to using the new interface, the old one is no longer needed.  That said, it may not be possible to contact all stakeholders, and it must be absolutely necessary to consider the situation, and reach the agreement, in the same way as might happen with a legal contract, a new contract superceding the older one.

     

    So, that said, with any sort of reasonable sized system, we can safely say that we need to maintain interface compatibility to maintain the contract for users of it.  Now, assuming that we create a new contract that includes some new interface to a new domain object for example, that can still be loosely coupled, and can still accept many implementations of the interface different engine types, and so on, that system is still loosely coupled.

     

    Personally, whilst I agree that the customer is always right, obviously apart from when they are not, I don't see the correlation between people with the money, and loosely coupled architectures?  The obvious thing that comes to mind is the argument that a loosely coupled architecture might take longer to produce than a closely coupled architecture.  I think I'd agree that that is the case, but over the lifetime of the project that certainly would not be the case, and factoring in mocked up unit tests and the like, I don't see any other viable alternative that serves the needs of the customer fully.  I know that I have digressed here, but I'm confused how one has anything to do with the other?

     

    I certainly think that loosely coupled architectures are achievable, and I also would say, having worked with my fair share of closely coupled solutions, that whilst it's easier to get those solutions out to the client, the compromise inherent in software architecture comes to the fore - we got the software out quickly, but dug ourselves a hole in the process.

     

    I personally find it difficult to justify doing it any other way, but to make that statement I must understand fully what I'm implementing, and have a plan in place for how to manage change, control features and so on.

     

    I'm not interested - how else would you approach a situation?  Not loosely couple, have bad seperation of concerns and so on, and still serve your customers needs?

     

    This is getting interesting now!

     

    Martin Platt.

    Tuesday, April 15, 2008 2:46 AM
  • For me it's like a journey from A to Z, from tightly to loosely coupled. I absolutely agree that we should strive to to get to Z but for me we're somewhere near R (!?). This post is about reassuring me that this is true and I've not missed some obvious fact that gets us to X.

    re: People with money.
    The point of that thread (or is that a strand/fibre in a thread?) was to say that a large number of versions of interfaces cost more to maintain so from that point of view it's in a company's interest to get rid of old interfaces as quickly as possible.

    re: Customer side of the contract
    In theory we all use code analysis and the like (even Java developers!) so any interface we use that is marked as obsolete would be flagged and we're make it a priority to refactor our code ASAP...hmm. I do like the use of obsolete but it does require too many assumptions to be true for it to be a fool proof answer to versioning.

    I think it will take a significant change in technology to get us out of this situation, as we've already mentioned some form of  dynamic language might be the right direction. If we look at chemistry/biology we see mutations of viruses that allow them to bind to new "chemical interfaces" without any intervention (look out this could get theological if I'm not careful) so could our programs "simply" examine the available interfaces and alter themselves? Of course they could...although I've not got the time to code that Wink

    Tuesday, April 15, 2008 6:13 AM
  •  

    >> although I've not got the time to code that

    yeah, i'll whip you up a little AI in five minutes Wink

     

     

     

    Tuesday, April 15, 2008 6:27 AM


  • Now I'm worried!

    If the chemical interface can be found, what is stopping it evolving into a computer program, replacing us, and taking over the world?!

    I see what you're saying now, with regard to interfaces.  Absolutely the same situation with implementations too, and is probably another case of not managing change properly (do we really know who uses that method / class, etc?)  If we knew if the interface was about to be retired, that would be a good thing, since the situation of ever changing interfaces would be of a lesser impact.  And there's another problem, the ever changing interface, is that really a problem with coupling, or a problem with understanding requirements and managing change?

    Personally, I think that with legacy systems you're always going to have some aspect in the way of maintenance to deal with.  On the other hand, so long as the interface are abstracted, we should still be able to plug new functionality, as well as create new interfaces and retire old ones.  I think you get around about Z, but it's a sliding scale, as the project ages, goes up around R, then back to V and so on...  I think that's a case of revisiting and refactoring, and managing things as we go, which may not happen all that often.

    Martin.
    Tuesday, April 15, 2008 6:32 AM
  •  frederikm wrote:

     

    >> although I've not got the time to code that

    yeah, i'll whip you up a little AI in five minutes

     

    I look forward to seeing that then. At the risk of hijacking my own thread, it does seem odd that the world of AI is so fixated on learning about how human systems work when more time could be spent getting it solve problems in its own domain. But hey that would slow them bring out the cute teddy in film AI so I'm not going to deflect their work to putting Martin out of a job Wink

     

    Tuesday, April 15, 2008 9:11 AM
  • I guess Karl Weick would have loved to ease (if not solve) the gnarls here.

    I think his theories that were organizational and individual based can be applied to software as well.

    Martin is right in the sense that loose coupling has been misconstrued for effective change management. Though it's a banality please excuse when I say "Changes and uncertainty are certain" in this nascent software industry (at least relative to other industries).

    What is lacking in existing systems is the concept of Sensemaking. This is something which I think complements loose coupling and that can make both the requestor and the provider more intelligent and sensible. Even if either of them implements sensemaking, interfaces could look much better both technically and pragmatically. One could call this as "AI" but I would just term it as "I".

    It's high time for companies like Microsoft to start thinking on these lines and as usual abstract this intelligence from service developers (I say this because it is more appropriate to services than internal modules).

     

    Shyam

    Tuesday, April 15, 2008 12:50 PM
  • I've not heard of the term sensemaking before, I've learnt something today, well at least I know of the word! It is interesting that some parts of "our" technology strives to become more self-aware, attributes and microformats are certainly examples. So can we turn to more symantic structures to help systems discover and mutate themselves. All sounds very interesting, again, probably take me 20 mins if I had the time <yeah right>.

    re: effective change managment
    I'm not sure I agree here, IMO the main goal of loosely coupled components is to help with change management, otherwise if I could guarantee I could write exactly what was needed once and it would never change then I'd make it tight.




    Tuesday, April 15, 2008 8:27 PM


  • Never heard of sensemaking either.  What is that then?  Common sense?  Or some new technology preview that we're the first to see? 

    I like the idea of code that can mutate to figure out new interfaces, in concept.  My thought is that although that would be cool  to be able to make, it would be counter-intuitive.  The interface is not supposed to be change, so having a system that morphs and mutates to fit an ever changing interface could be seen to be something similar to a cancer, which is actually just evolution taking a wrong turn.

    Loose coupling is used so that the implementation details can change whilst the interface remains the same, and one subsystem is not coupled to another through it's implementation, only through an unchanging interface.

    Agile software, iterative development, and welcoming change is closely related, but only really in the sense that the implementation of an interface or contract can change without affecting other subsystems.

    Change mangement and architecture artifacts such as loose coupling have very little to do with one another.  Change management is concerned with managing the changes to, and impacts of altering existing code.
    Loose coupling does allow different implementations, but loose coupling has no consideration for the impact, or risks involved in making such a change.  I do agree that loose coupling can help change to take place, and in a lot of way mitigate a lot of risk, but it can only do that within the confines of the contract, or interface definition.

    Loose coupling can also be be considered as being able to aid maintenance too, since there's a lesser impact on making a change, or more succinctly, the change has a lesser effect on the rest of the systems that use it.  That doesn't mean that loose coupling is synonymous with support, though.

    Loose coupling also helps with code re-use, since de-coupled code can have different implementations or flavours of the interface contract used by the same code (assuming that it is designed properly! - yet another assumption)

    Loosely coupled code also allows proper unit testing and mocking to take place. 

    In my opinion, loosely coupled code is the manifestation of a well considered, analysed and designed system, that just happens to have a lot of benefits.

    Definitely not a myth! 

    And I'm really looking forward to seeing the AI / genetic interface discovery system.  Could loosely coupled systems really be the reason for, and start of the end of the world?!  I mean, what's preventing the system from morphing and evolving to interface with the computer itself, then the room, then the country, then the world.... Big Smile  That actually happened with Arnie, you know?!

    Cheers,

    Martin Platt.
    Tuesday, April 15, 2008 11:00 PM
  • It's not surprising for me to see a few "Oh! what's this?" kind of reactions because sensemaking is more of an organizational theory.

    But I see its value in software as I coif it in loosely coupled architecture. Let me reiterate that sensemaking complements loose coupling and not replace, in making a software more intelligent and driving SOA (I'm sorry I have to stick to it) to another level.

    I see sensemaking somwehere in between mutation and blunt interfaces and services (likely to be more towards mutation).

    As Martin pointed out mutation is definitely anti-intuitive and pro-unemployment

    One means of achieving sensemaking is to have an intelligent manager (sounds like a wrong adjective) sit in between the provider and requestor and make sense of the intention of the communication and establish the best link.

    How does google give us the most appropriate search results inspite of our dumb search text?

    It's time to think

     

    Shyam

    Wednesday, April 16, 2008 6:22 AM
  • I'm not changing my name to The Pedantic one but...

     

    Although I essentially agree with everything Martin says..."Loose coupling is used so that the implementation details can change whilst the interface remains the same, and one subsystem is not coupled to another through it's implementation, only through an unchanging interface."

    No, loose coupling has nothing to do with interfaces per se, interfaces are one mechanism used to help get somewhere near loosely coupled. I know what what you saying is "true" but since I'm not convinced that interfaces get us to our goal I'm trying to re-enforce the difference in the hope that someone can provide me with a better alternative.

     

    "Loosely coupled code also allows proper unit testing and mocking to take place."

    I think that although it helps it certainly isn't a pre-req'.

     

    "Definitely not a myth!"

    Of coure we all love the ideal of loosely coupled components (and I'll fight anyone that says otherwise Wink ) I still believe that in it's true form (point Z) it doesn't exist, the myth is that it is currently achievable.

     

    re: end of the world

    I can see the remake now, 5 (well at least 1 anyway) geeks on an MSDN forum unwittingly spawning the MS2000 from a simple MVC Linq sample...ah the terror of extension methods!

     

     

     

     

     

     

     

     

    Wednesday, April 16, 2008 8:18 AM
  •  

    re: end of the world

    I have this new open source project called SkyLab.. Stick out tongue

     

    Wednesday, April 16, 2008 9:54 AM
  • patent pending on anything with a capital letter (just kidding)

     

    i agree is that the trick to self adapting (within reasonable measures) interfaces would be that model the [Intent] of services.

    thus going beyond the pure technical speficiations of parameter a of type int, paremeter b of type string...

     

    However, what i fail to grasp is how you would express that Intent..

     

    say, you have a Collaboration (2 or more parties talk to each other) comprised of multiple Services (both client and provider can be seen as services).

    Each service has an Intent, expressed in a Manifest.

    The Collaboration manager interprets these manifests and puts them together via some kind of transformation..

    (basically you're recreating an ESB)

     

    The loose coupling desired would come from the way the intent can be expressed i guess..
    but in the end even that imposes a number of dependencies..

     

     

    Wednesday, April 16, 2008 10:02 AM
  • I think it would be silly of me to try and dream up the solution but it would seem that there a number of technological parts that could be brought into it. E.g. microformats, reflection, dynamic languages, rule engines, AI learning, ODBC (in terms of dynamically altering your offering), policy, etc. So in your example the controller would need to understand what existing parts it could use to satisfy the choice of discovered services but also craft new parts to bridge the gaps. Oddly it doesn't seem that difficult a problem to solve, obviously our experience would say otherwise but somehow I get the feeling it is within mankinds limits to build something like this. And yes it probably would result in self-generating programs, again something that seems to have disapeared into SciFi...although some of those create a site/app from the database tools aren't a million miles away. Anyway I think I'm drifting into a dream world, but if anyone want to sponsor us to do some research please post the budget...

     

     

     

     

    Wednesday, April 16, 2008 1:00 PM
  • hmz, any mvp wanna chime in on OSLO?

    <shameless plug of newly started blog>

    go here for a link i could have pasted directly Wink

    http://frederikm.blogspot.com/2008/04/things-to-look-at-on-16042008.html

    </shameless plug of newly started blog>

     

     

     

    Wednesday, April 16, 2008 2:08 PM
  • I'm not sure where you're going with the OSLO link? Distilling OSLO down, to a grossly simplified description, is moving some well known services from LAN to the WAN (or cloud for you dudes out there). Sure it will involve the contract debate but is there some gem in it that I've missed?

     

    PS. I can't wait to see the licensing structure, it will probably take an army of sales people to get that sorted!

     

     

    Wednesday, April 16, 2008 2:18 PM
  • hmz, the impression i got from OSLO is that it will, among  other things, be an implementation of an ESB using bizztalk + some form of hosted workflow for cross company workflows + some wf & wcf enhancements.

     

    It's a long way off from the magical Controller or manager or whatever that performs re-mapping as the messages change, but it's something i want to know more about Smile

    As i've heard it describe: it is the Next generation of SOA tools (a silver bullet if you will )

     

    Licensing will probably be a nightmare...
     

    Wednesday, April 16, 2008 2:31 PM
  • <whisper>smells like stuff that's already available but Microsoft want to get into the SaaS money so are marketing as something clever...not that I've ever thought that about the whole Biztalk product...ever</whisper>. I've not had chance to try out the Biztalk ESB but I'm must confess I doubt I will. I did have a chat with one of the bods at Microsoft and they assured me that Biztalk was now great and no longer sucked equine handbrake but I'm affraid I remain sceptical, once bitten and all that.

     

     

     

     

    Wednesday, April 16, 2008 2:50 PM
  •  

    >> and no longer sucked equine handbrake

    :grin:

     

    hey, i'm not saying that bizztalk is the best thing since bottled beer, far from it..

    honestly, my experience with bizztalk is on the conceptual level..

    I'm just expecting something grand.. for once I'm enthused.. I feel dirty now Tongue Tied

     

     

    Wednesday, April 16, 2008 3:48 PM
  • i read the initial posts with interest and then skimmed the rest.  there was something about making software molecules and sensemaking, which is a word with infinite possibilities till I look up the real meaning.

     

    any how, like we learn early on when coding, "increasing complexity of data structures reduces complexity/verbosity of algorithms", here, to bring down the coupling,  ramp up the indirection.  As also moving from constants to variables.

     

    if you think about it, we loosen coupling by adding indirection.  This way, an interface can be seen to be an indirection.

     

    There was this post earlier in this thread that talked about going to a store and buying bread for money:

     

    IStore{

    public Bread Buy(Money m);

    }

     

    If you look at this contract, there are three 'constants' here.  1) the name of the interface, 2) the data types and 3) the method name.

     

    So if we make all three of these constants into variables, we have this ultimate interface:

     

    I

    {

    public IntPtr F(IntPtr m[]);

    }

     

    where IntPtr is newspeak for void *.

     

    There are two sides to this interface, namely this side and the other side.

     

    On this side of the interface, close to us is the code we are writing to solve the business problem on hand.  Between this code and the ultimate interface is the consumer side interfaces.  This contract is business specific, and it changes when our code changes. 

     

    On the other side of ultimate interface will be the provider interface.  The ultimate interface is able to look at how it has been called and decide which provider side interface to call (sum of float, sum of double and so on.).  Beyond the provider side interface is the providers implementation.

     

    This Ultimate Interface shields the providers from the consumers.  That is the point at which coupling is most tiresome to deal with.

     

    Wednesday, April 16, 2008 8:22 PM
  • kdixit, I see interfaces (coupled with delgates) as a kind of OO alternative to function pointers, but yes I take your point. So where on the A..Z measure do you believe is achievable today?

    Thursday, April 24, 2008 6:18 AM