Integrating in the Cloud - part 1
11/13/2008 08:28 PM
Microsoft - as well as everyone else today - is really investing to "the cloud". Whereas many are talking about Software as a Service (SaaS), Microsoft's idea is to provide a platform for Software + Services (S+S) -- indicating that running applications on-site and using hosted services are complementary, not contradictory technologies. Personally, I think this is a good approach -- even though network technologies have matured, there will be still requirement to run applications off-line (e.g. on a laptop with no network connection available) or provide computing services as "near" as possible for low-latency reasons.
Integration does not live in isolation -- it is in many ways similar to any other enterprise application development. With integration solution possibly passing information between systems in several organizations, there is always some kind of "cloud" involved. When talking about message passing, we may be talking simply about TCP/IP cloud, or there may be something more elaborate involved. Such as .NET Services.
"Cloud" communication between organizations is nothing new. For quite some time, there have been value-added networks (VANs) that provide guaranteed message passing functionalities and possibly message mapping between different formats (in-house files, XML, EDI,...). Organizations are usually paying a monthly or transaction-based fees from these services. The need for guaranteed message passing has diminished over the time with Internet and XML-based message formats and protocols maturing, but they still may provide added value especially in trading networks.
Now with .NET Services (a part of Azure Services Platform and earlier known as BizTalk Services), Microsoft is trying to develop an "Internet Service Bus" that could extend Internet's messaging functionalities with publish-subscribed model, guaranteed messaging as well as authentication/authorization with easy interfacing into .NET Framework. Thus, distributed applications (such as system-to-system communication in B2B integration scenarios) could utilize this service for passing messages reliably and securily between organizations. .NET Services basically provides another value-added network that could be utilized instead of your traditional EDI operator.
If we are thinking about clouds in the context of message passing between organizations, I don't really see too much added value in additional messaging functionalities -- if you have already integrated your organization's systems (a must if you want to do successful B2B integration) you already know how to pass and transform messages between different systems. So, why don't you simply use your existing integration solution and "free" Internet for B2B communications, possibly augmenting messaging with appropriate WS-* protocols?
But cloud computing is not just about message passing -- by definition, it should involve some computing as well. With .NET Services now providing hosted workflow functionalities, there may be a catch. Process interoperability, B2B protocols, even hosting traditional EAI processes...
But that's a topic for another post.
Response to “Integrating in the Cloud - part 1”
What do you think about EDA (event driven architecture) - is SOA about passing away?
Response to “Integrating in the Cloud - part 1”
Both architectural models require some kind of process layer on top of them as I think that by narrow definition both SOA and EDA can be understood as messaging models. Without a process layer there is just an uncontrollable mesh of communications. What I hope is that there will be some day a uniform process layer with SOA and EDA being the underlying connectivity infrastructure where both service-orientation and event-orientation can be used where most applicable.
Which one is better in integration scenarios? No idea. I haven't seen one good example of either SOA or EDA that could deliver everything that they promise. Web Services interfaces do not make a SOA solution and pub-sub messaging does not make an EDA solution. At least the largest hype around SOA seems to be over -- see e.g. this Tietoviikko article (in Finnish). I don't know if SOA is dead -- or has it ever really been alive?
Response to “Integrating in the Cloud - part 1”
Thanks gor your response.
Is Frends already experienced in integrating these two architectures in real world - and how have you done it? Lession learned?
Response to “Integrating in the Cloud - part 1”
The overall integration architecture of a customer solution may be designed on SOA principles, but we can e.g. utilize BizTalk's pub-sub engine to deliver event-driven functionalities in scenarios such as error management, alerting, or such. On the other hand, in the same SOA-based solution it may be necessary to forget all good practices of service-orientation if the only way to integrate to some application is e.g. through some legacy file transfer interface or a database connection.
In the world where there is no single truth or a single best practice, those who are able to combine different patterns will live long and prosper.
Response to “Integrating in the Cloud - part 1”
i think your last sentance sums it up excellently, in my experience you hear people and organisations talk about patterns such as SOA and EDA in the same way as people used to talk about some products as being a silver bullet where you do almost no work and it magically makes your organisation work.
In my opinion the its all about return on investment. A company should use people who understand the principals and patterns that work well and look to use the right thing in the right place for the interests of the business.
Ive seen occasions where a very simplistic point to point integration was used and implemented with little cost but made a significant difference to the business and at the other end of the scale a full SOA plan was put in place to implement a vastly over engineered component with all of the modern "best practices" but in the end it took ages to implement and was a maintenence nightmare and really made no significant difference to the company.
I think the best thing from an organisations perspective with integration problems is to take a pragmatic view of things. Use the appropriate principles of SOA or other patterns when you know they will be of benefit and not just because someone wants to put it on their CV.
Also treat the project budget as if it was your own money is a good mentality to have in these situations.