Martin,
I do not think that the granularity of IaaS contradicts our SOA RAF anywhere. Granularity of service interface is one thing (what is an interface of infrastructure service?) and the granularity of the contract and tuning rules or consumprion rules is different. SOA RAF never regulated granularity of deployment or provider's policies.
- Michael
Sent: Wednesday, April 22, 2015 at 10:28 PM
From: "Martin Smith" <>
To: "Ken Laskey" <>
Cc: "Mike Poulin" <>, "" <>
Subject: Re: [soa-rm] ESBs and cloud services
Ken--Good question. My impression, having only generally followed the evolution of how infrastructure services have been deployed by commercial Cloud providers, is that they have been quite a bit different the SOA standard components that OASIS and others imagined before commercial Cloud exploded. Lots more of them, more granular, with lots of extra features. Still I have always thought it would be possible to find all the orginal SOA functionality within today's collections of service components. But maybe my assumption that Cloud is mostly a fresh marketing buzzword for SOA (perhaps "with business characteristics."<g>) is not fundamentally valid.
Look forward to learning more . .
Martin
On Wed, Apr 22, 2015 at 4:41 PM, Ken Laskey <> wrote:
My question isn’t whether you should to do things in-house or out-source. There is (and I expect always will be) plenty to debate.
What I really had in mind is that cloud services seem a replacement for an ESB. Now I could have an ESB in-house for things I do not want (trust?) to put in a cloud, but that is just splitting the problem and adding the complication of making the ESB and cloud pieces work together (unless we can make the two pieces nearly independent of each other).
Is there any logical synergy in ESB and cloud use?
Ken
On Apr 22, 2015, at 4:29 PM, Martin Smith <> wrote:
I don't think that the ESB is mission-critical to a company any more than any other "commodity" IT service component that does not constitute the core and proprietary business knowledge, expertise and data of the company.
Sure, an external (or internal) ESB total failure can take down the business for a while. So can a wide electrical or Internet outage, flood, fire, etc. Companies cannot and do not totally insulate themselves from all external dependencies. Moreover, unless you are responsible for managing a disaster (FEMA) the losses the business faces from widespread outages are mitigated in part by the fact that partners and customers are also likely affected and therefore even if your company is up and running, there's not a lot of business to be done. (My big takeaway from Y2K.)
As for the fact that AWS and other Cloud providers have outages: sure, but the relevant standard is not perfection but performance relative to alternatives. My impression is that Cloud providers, at least the leading ones, measure up well by that standard.
Martin
On Wed, Apr 22, 2015 at 3:42 PM, Mike Poulin <> wrote:
I have had a few conversation on this topic. A potentially conceptual conflict might be in that ESB is used to be considered as an internal integration mechanism, i.e. all operations and usage was/is controlled by the corporate policies. When we talk about Cloud, we MUST understand that we plan to deal with another business, which is totaly out of our control and which would preserve its own interestest above ours in all situations ( which is normal for any independent business). This leads to a few questions:
1) do we want to take a risk of giving our integration "heart" into someone's hands?
2) what we would do if communication channel with the Cloud gets down (several cases of Amazone and others going down for a while are known already)?
3) what we want from the Cloud - to place our ESB over there or to utilise "Cloud Integrator/ESB"? Or we want to integrate several Cloud providers and think about hiring a Clouf Integrator provider? [Based on previous publications of Jason Bloomberg and my BLOG, I can say that if a company delegates integration between Cloud Providers to another Cloud provider, the company looks for troubles due to minimal visibility and control over sensitive to stability integration solution. INstead, a compny has to become a "Cloud Broker" and bridge between different Cloud providers. Remember Cloud providers are services - they have individual contracts with the client and do not care about each other.]
I can continue if needed.
- Michael
Sent: Wednesday, April 22, 2015 at 6:16 PM
From: "Ken Laskey" <>
To:
Subject: [soa-rm] ESBs and cloud services
Recently, I’ve done work where part of an organization was implementing an ESB and part was looking at the potential for cloud. Has anyone considered or seen other discussions of how ESBs and cloud are opposite paths or how they might work together?
Ken
------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S F510 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
Martin F Smith, Principal
BFC Consulting, LLC
McLean, Va 22102
703 506-0159
703 389-3224 mobile
--
Martin F Smith, Principal
BFC Consulting, LLC
McLean, Va 22102
703 506-0159
703 389-3224 mobile
