Welcome to EMC Consulting Blogs Sign in | Join | Help

Jack Hanison's Blog

in·te·gra·tion (ĭn'tĭ-grā'shən)
n.
"the combining and coordinating of separate parts or elements into a unified whole"

  • The relationship between Service Autonomy and Loose Coupling in SOA

    I was recently asked by a client if the SOA design principles of Service Autonomy and Loose Coupling amounted to the same thing. I thought it was an interesting question, so after some thought, I replied with the following, which I repeat here to help others that may be intrigued by the distinction:

    The principle of Service Autonomy says that a service should be independent of external dependencies so that it is predictable in it's run-time behaviour, able to be maintained without disrupting other aspects of an organisation's systems landscape, and implementation decisions such as technology choice can be made in the best interests of delivering the service without affecting the usability of the service.

    On the surface of it, Service Autonomy would seem to imply that there should be no coupling at all. That is to say, that coupling of any kind implies the introduction of a dependency. And this is where the distinction exists. Coupling and Autonomy are not the same thing, but they are very closely related. Coupling is about the way in which dependencies are introduced, and by doing so perfect autonomy is compromised. They feel like the same thing, because a balance must be reached between them and they go hand-in-hand.

    Within a service boundary, there will naturally exist some tight couplings, and this is not always anathema to Service Orientation. Service Logic will be tightly bound to the service contract in order to implement the appropriate service behaviour, for example. However, it is when we introduce dependencies outside of the service boundary where we should pay careful attention to the manner of coupling.

    In this context, loose coupling means that the services that are being coupled maintain as much autonomy as possible. This can be achieved by careful service contract design, and through the use of standards for contract implementation, including standardised schemas.

    So, there is a strong relationship between Service Autonomy and Loose Coupling, they can be thought of as two sides of the same coin, but they are not the same thing.

  • SOA and Master Data Management

    I just read a really interesting post that sparked me off on a train of thought that I just had to share.

    Joe McKendrick writes an SOA blog for ZDNet (amongst other things) and often poses some interesting questions or disseminates some key nuggets of thought from the SOA blogosphere. One of his recent posts talks about how Pfizer have bridged between Service Oriented Architecture (SOA) and Master Data Management (MDM). I found this particularly interesting for two reasons.

    1. The Microsoft ESB Guidance Toolkit has just gone RTM and been published to MSDN. Marty Wasznicky (who led the team that built this) acknowledged at the Microsoft SOA and BP Conference that this Patterns and Practices guidance toolkit was put together following a successful ESB implementation that Microsoft produced using BizTalk Server at Pfizer. Clearly this is a key plank to the SOA that Pfizer is operating.
    2. Conchango led the way on MDM and it's usage in SOA a couple of years ago. My colleagues Mick Horne, Rob Grigg and Jamie Thompson were working on a large scale integration project in the Oil & Gas Industry. They faced three key problems. They needed to commodify what they were building so that this could be rolled out to other markets, plus they needed to standardise the process of getting data from multiple disparate data sources, and each of these data sources had their own data dictionaries and domain specific languages. Clearly a Service Oriented approach was going to tick the first two boxes, and MDM rode to the rescue for the third problem. They called it Service Oriented Business Intelligence, and coined yet another TLA - SOBI. Their work was published in the January 2006 issue of the Microsoft Architecture Journal and presented to the Microsoft Architects Insight Conference. Jamie published a series of posts giving loads of details into how they solved the problem. You can find a summary post here.

    So what does this series of links tell us? That a good idea can be a long time coming?

    Perhaps. The argument goes that IT, for all it's promise of "agility" "scalability" and every other -ility at the forefront of a CIO's agenda, is still just an industry like any other. So whilst Silverlight can be the darling of rotating text boxes in no time at all, no C level decision maker is going to stake the future of business application construction and data rationalisation for their organisation on SOA and MDM if it might just be the latest great idea that doesn't quite make it into the air.

    Perhaps this news from Pfizer shows us that it's not only our Oil & Gas client (who were in a unique position of having no other choice but to adopt a SOA + MDM route) who think that SOBI (or SOA + MDM, or one version of the truth plus a single enterprise data dictionary plus composite applications built upon services, or whatever else you want to call it) is an idea that has delivered the -ilities that it promised, and has not only taken off, but delivered down to earth benefits.

  • Will Unified Modelling change the way we build SOA? - Microsoft announces "Oslo"

    I'm currently attending the Microsoft SOA & BP Conference in Redmond. It's been a fantastic conference so far, with loads of great sessions by industry luminaries.

    The key news of the conference is the announcement of Microsoft's new wave of products for building Service Oriented Architecture.

    Will this change the way we build SOA?

    SOA is not a product. It is a way of building IT systems. That’s the facts of the matter. Consultancy organisations like ours have known this for a long time. We have been building Service Oriented Architectures for our clients in Retail, Media & Entertainment, Financial Services, Consumer Packaged Goods, and Energy for many years. Vendors will often try and sell a product for SOA, maybe it’s an ESB product or an Web Services product, or even claims to be an SOA product. This is not a reality. SOA is not a product. The announcement of Oslo made by Microsoft this week marks the fact that Microsoft have long realised that the tools needed to build SOA must be delivered as part of co-ordinated strategy across their application platform products.

    The SOA approach is different from n-tier development. The SOA approach says model your individual business process steps as granular reusable services, and expose them using open standards such as Web Services. Then provide business value through the automation and managed execution of business processes that are created through a composition of the services using a Business Process Management (BPM) tool, to be surfaced to end users through the web and on the desktop.

    An example might be the business process of booking a flight on an airline. The airline provide you, the consumer, access to this business process on their website. The airline implements their business process in their BPM tool as a number of steps. The Web site integrates with the BPM implementation, which executes the process step by step. Each step is provided by a service, such as a service to look up the number of available seats on the flight that you have selected, the service to take payment from your credit card, or the service to actually book your reservation.

    To date, Microsoft have released 5 versions of Microsoft BizTalk Server, with BizTalk Server 2006 R2 being the latest and greatest version. This has enabled thousands of companies big and small across the world to build SOA solutions. This is accomplished through deep integration with Visual Studio, SQL Server, System Center and the .NET Framework. Many of our customers have received business agility, productivity improvements and real world SOA solutions through the use of this application stack.

    Oslo marks a real shift in Microsoft’s approach. Currently implementing an SOA requires a lot of heavy lifting and a lot of highly skilled manpower. A lot of this work is related to the separate silos that people have to work in when building SOA. Business analysts using one set of tools, Architects using another, Developers use a third tool set and Operational people use yet another set of tools. Communication between all of these teams tends to rely on paper documentation. What Microsoft have announced is that they will unify the key products that are used to build SOA today by all of these different roles in the IT organisation, so that the tools all communicate with a common set of models. This will deliver productivity and agility improvements to both the business and IT. And, of course, cost savings to boot.

    Unified modelling is the new aspect promised by Oslo. Models are used to describe the Service Oriented Architecture from multiple points of view. Different views being accessed and created by different people with different tools, but importantly all of these tools and all of these people will be working on the same part of the business solution. So a business process is expressed in business terms by the business analyst, how that process will be implemented in Software will be designed by the Architect, the developer will provide the code, operations can implement the instrumentation and monitoring, and all of this is being done in the tools that these people prefer, and the tools are all communicating with each other through a common model repository. And this all works at run time as well as design time.

    So, when the operations guy sees that a service is underperforming, the business analyst will also be able to see this in his view, in terms that are important to him, for example that fulfilment of a particular customer’s order will not meet the agreed Service Level. And when a new requirement is expressed by the business analyst, the developer will immediately see that he needs to implement some new features. This is a revolutionary approach to building SOA. The products that will enable this will be the next wave of application platform products coming from Microsoft over the next couple of years. This new wave of products is called Oslo, and will be made up of:

    • BizTalk Server “6” – Process Server, the hosting infrastructure for not just WF and WCF, but any .net code
    • BizTalk Services “1” – Internet Service Bus – publish/subscribe communications beyond the firewall.
    • Visual Studio “10” – Development platform
    • System Center “5” – Operations – infrastructure support
    • .NET Framework “4” – Application building framework that will deliver the guts of these products and the SOA implementations that run on them

    These are not necessarily the version numbers of the products that will deliver Oslo, but indicates the next version of the Microsoft application platform.

    So that's Oslo. I believe it will change not just the way we build SOA, but the way that all business sytems are built in the future.

    Modelling + Services. It's the future of Information Technology.

  • Handy utility for managing Data stored in SSO

    Well it's been quite a while since I last blogged about anything of note, but reading through my RSS subscriptions this morning I noticed that Richard Seroter has written a very handy utility for managing configuration data stored in the SSO database.

    I tend to use a combination of the BizTalk rules engine and the SSO database to store configuration information for the projects that I work on. I tend to use the rules engine where I wish to have several items returned in one operation rather than a simple name-value pair. I also tend to use the rules engine where it is beneficial to have the data returned as xml. Plus there are performance considerations and versioning implications to consider. The SSO database I find very useful especially for configuration parameters that are environment specific, and I will tend to use this database as the configuration store of first choice.

    On my current project we are using the Scott Colestock BizTalk Deployment Framework, and we use this for deploying the SSO data. In the past I have built specific utilities for support teams to use to alter configuration data stored in SSO, but this new tool that Richard Seroter has built is a fully comprehensive application for this purpose. I think I'll be making a lot of use of this on my projects in the future.

    Thanks Richard!

  • QuickSet can change your life too!

    World rejoice! - Rich Wadsworth has just started blogging.

    Whilst this experienced .net architect is sure to have loads of interesting stuff to say to the world, he's kicked things off with a post extolling the virtues of Dell's QuickSet utility.

    And what an excellent subject to start with. As a consultant, I'm often working in different locations at different times and switching proxy servers and default printers can be a time consuming pain. QuickSet does it all automatically for you.

    So, I recommend you read Rich's post and make your life easier

  • Dependency not found issue when building BizTalk Server 2006 project

    When you build a BizTalk 2006 project, you might get build output containing warnings such as:

     

    Updating references...

    The dependency 'Microsoft.BizTalk.CachingService' could not be found.

    The dependency 'Microsoft.BizTalk.DBAccessor' could not be found.

    The dependency 'Microsoft.BizTalk.Bam.EventObservation' could not be found.

    The dependency 'Microsoft.BizTalk.Streaming' could not be found.

    The dependency 'Microsoft.BizTalk.XPathReader' could not be found.

    Performing main compilation...

     

    This is because one of the BizTalk assemblies has been added to your project with Copy Local set to true. Most likely this is because you've added Microsoft.XLANGs.Pipelines to your project in order to execute a pipeline from within your orchestration. Go through your project references and ensure that any external assembly references that are in the GAC have Copy Local set to false.

     

  • Technorati Profile

    I've claimed this blog on Technoratio. Visit my profile.

  • How to set registry ACL Permissions with VBScript

    As a quick update to my post on how to clone a BizTalk server, I've recently found this article

    http://support.microsoft.com/?kbid=269159

    Which explains how to set registry ACL permissions in script - nice!

  • Installing BizTalk Server 2004 Service Pack 1 before running the Config Framework

    Another one for the online memory...

    Although the readme for BizTalk Server 2004 states "Only install Service Pack 1 (SP 1) on computers already running BizTalk Server 2004", you can in fact install BizTalk Server 2004 Service Pack 1 before you run configframework.exe

    So that should say "Only install Service Pack 1 (SP 1) on computers that have BizTalk Server 2004 already installed"

    Hmm... why are my blog posts always on installation issues? Oh yeah, maybe it's coz installation is a pain and there's too many fiddly bits to remember!

    I'll blog some BizTalk 2006 dev stuff soon!

  • View Solution Node in Solution Explorer in Visual Studio 2005

    Blogging this one as a reminder to myself, and in the hope that it might help someone out.

    Visual Studio 2005, by default doesn't show the solution node in solution explorer if the solution only has one project.

    To display the solution node bring up options Tools->Options, under the Projects and Solutions node, on the General page, check the 'Always show solution' box.

Powered by Community Server (Personal Edition), by Telligent Systems