Archive for the ‘BPM / SOA’ Category

HP Software Universe 2012 Presentations #Cloud #Matrix

June 6, 2012 Comments off

Download the HP Software Universe 2012 Presentations:

Foggy Computing – SOA and the Cloud

October 12, 2010 Comments off

SOASaurus … an Extinct Species?

January 19, 2009 Comments off
Some blog posts on the demise of SOA…
SOA: Dead, or In a Coma?
"So, now that we have identified the leading causes of SOA’s demise, we need to ask the question, “Is SOA really dead or simply in a coma due to blunt force trauma to the head?”

Categories: BPM / SOA

Biztalk Server 2009

December 23, 2008 Comments off
Biztalk Roadmap:

Microsoft announced BizTalk Server 2009 today, and gave the green light to talking about the new version.    It’s due for release in the first half of next year, and is shaping up nicely. Microsoft is casting BizTalk Server 2009 as a major new version in its own right, rather than just an updated ‘release’ of BizTalk Server 2006. There is certainly enough in BizTalk Server 2009 to warrant thinking of it as a major revision of the product, although it retains the same familiar functionality and tooling in use since 2006 (or even 2004).

BizTalk Services is now also officially called ‘.NET Services’ and becomes part of the Azure Services Platform.


Categories: BPM / SOA

BizTalk Services aka .Net Services: An overview

November 26, 2008 Comments off
BizTalk Services is now Renamed .Net Services under the Azure Services Platform.
" … You may not, at this stage, have any idea about what BizTalk Services are, so let me explain.   First, you should understand that the technology is only loosely associated with BizTalk Server. Microsoft’s Connected Services Division is increasingly using the term ‘BizTalk’ as a brand name for anything to do with message routing, EAI, BPM, etc.   BizTalk Services are not tied in any way to the current version of BizTalk Server.   They are not a replacement for BizTalk Server or an attempt to replicate existing BizTalk Server functionality in the cloud, although they may offer services which have some similarity with those offered by BizTalk Server
BizTalk Services are a first step to implementing what Microsoft calls an Internet Service Bus (ISB) in order to support SaaS (Software as a Service) and S+S (Software and Services) models.   The fabric of the ISB is built on Windows Communication Foundation (WCF).   WCF, itself, is a platform-level messaging framework, and part of the .NET Framework.   It is not a product, and is not really a service bus, but it is a (very rich and flexible) foundation on which service buses can be built.   ISB is a service bus built on that foundation.   Interestingly, the main functionality for the ISB provided by the BizTalk Services SDK is packaged in an assembly called System.ServiceBus.dll, which makes it sound like a future extension to the.NET framework libraries.
You may wonder if there is a distinction between SaaS and S+S.   Having listened to Microsoft presentations on this subject, my understanding is that they use these terms broadly as follows.   SaaS, of course, refers to a software delivery model centred on hosted services and the management of multi-tenancy.   Users access services over the Internet and pay for use of those services, rather than licensing software for installation on-premise.   S+S is a broader term.   It refers to the use of SaaS within the context of broader composite applications and ‘mash-ups’.    S+S, therefore, is about the exploitation of SaaS in conjunction with on-premise software.
SaaS is a fascinating subject which raises a number of challenging architectural issues.   For example, what are the best design patterns for handling multi-tenancy issues?   Each client must be able to use the service as if they were the only user, and their data and state must be sufficiently isolated.   There are various approaches to handling this, each with its own strengths and weaknesses.   Things get more complex when a single service must support per-user contract customisation, and where different clients have widely different service-level and non-functional requirements.   SaaS is a rapidly emerging field, and we will doubtless see a great deal of evolution of platforms and tools in future years to meet the challenges of implementing this model.
For BizTalk Server developers, the concept of composite applications is familiar territory, especially in regard to the composition of services.   One of the chief reasons for selecting BizTalk Server into an enterprise platform is to exploit its rich support for orchestration of multiple services in conjunction with its EAI features.   BizTalk Server 2006 has a strong concept of ‘applications’ at the administrative level, and a typical BizTalk application may involve many different interactions with a wide range of external systems and services.   We use BizTalk Server today to build sophisticated applications built around service composition.   In a similar way, Windows SharePoint Services, built on ASP.NET 2.0, provides Microsoft’s platform for bringing together disparate data from many different sources within a single presentation tier.   The capabilities of this platform are further extended through Ajax to provide a rich environment for creating mashups and fronting composite applications.   S+S, then, is not exactly a new paradigm.   The term represents the natural evolution of today’s tools and platforms to embrace, more fully, the emerging world of SaaS and the emphasis on composite applications.
BizTalk Services is an enabling technology that broadens the reach and appeal of Microsoft’s platform.   It is not an on-line replacement for BizTalk Server, but a natural companion that makes it easier to build composite applications that exploit widely distributed services across the Internet.   Because it is built on WCF, it should be easy to exploit the ISB using the new WCF adapter library in BizTalk Server 2006 R2. I haven’t yet proved this, but it should be possible, for example, to use the WCF-Custom adapter to handle authentication against Identity Services via an endpoint behaviour and to pass messages securely via the Connectivity (Relay) Service. There is a lot of emphasis on the use of CardSpace for authentication within BizTalk Services.   However, CardSpace and information cards are not obligatory when using Identity Services, and the SDK supports alternative approaches.   CardSpace, which requires interaction with a user, is clearly not a viable option in the world of BizTalk Server."
%d bloggers like this: