All of these courses will be taught by Jason Bloomberg President of ZapThink. Bloomberg will be conducting these courses in the UK, Singapore, Australia and India. The company also has plans to introduce these courses to the Middle East, South Africa and other regions.

The course will cover topics such as: Type 1 and Type 2 virtualization; cloud service and deployment models; enterprise architecture and the cloud; cutting through vendor hype; relationship between cloud and SOA; traditional, para, full, OS, and hosted virtualization; virtualization and cloud computing; workloads, pods and cloud control systems.

In a release, Bloomberg said, “Cloud Computing is far more than simply outsourcing your data center. Fully leveraging the Cloud requires an architecture-focused, enterprise-centric approach that places Cloud resources into the context of enterprise IT.”

Read the entire article at http://www.mspnews.com/channels/cloud/articles/259677-zapthink-offer-enterprise-cloud-computing-training.htm.

Your data center, sometime in the mid 1990’s: the server you ordered finally arrives. Could be Windows, Linux, some flavor of Unix, doesn’t matter. You unpack it. Boot it up. Patch the OS. Configure the OS. Install software off of CDs. Patch the software. Configure the software. Move data to the box. Test. Tweak. Test again. Finally, the box goes live.

Cut to 2012. You’re working in the Cloud now. You provision a virtual machine (VM) instance in the Cloud. Or three. Or maybe a few dozen. Only you’re not just provisioning VMs. You also provision some dynamic storage. Maybe some Cloud-based queues. You also want some SaaS-based services.

And your software release cycles? Weekly. No, daily. How about hourly?

Now what?

Clearly, it’s impractical to set up your Cloud instances manually, the way we used to set up servers in the good old days. So you go through the process once and create an image file that represents your Platonic ideal of what a fully configured VM instance should look like. Now, every time you need to provision a new VM instance, simply reconstitute the image. Right?

Not so fast! There are numerous gotchas to this scenario. Every time you need to patch anything, you would need to create a new image. If different VM instances are meant to differ in any way – say, contain different application data – you would need to configure those differences manually. But most significantly, there is far more to your Cloud environment than single VM instances. What about the storage? Databases? Network configuration? What about the architecture?

The Basics of Automated Provisioning

Remember, “automated” means “not manual,” in the sense that hands are not allowed. You want the ability to deploy, update, and repair your entire application infrastructure using nothing but pre-defined, automated procedures. Ideally, you want to automatically provision your entire environment from bare-metal (hardware with no operating systems – or anything else – installed on them) all the way up to running business services completely from a pre-defined specification, including the network configuration. Furthermore, there should be no direct management of individual boxes. You want to manage the entire Cloud deployment as a single unit.

Deploying sophisticated provisioning tools, of course, is a large part of the secret. And the more sophisticated the tools, the less skilled your staff has to be. Ideally, any people familiar with a few basic commands and appropriate permissions should be able to deploy any release to any integrated development, test, or production environment. They only require minimal domain specific knowledge. You don’t need a senior sysadmin. You don’t even need a systems developer. Any junior techie should be able to handle the task.

If something goes wrong, you should be able to revert to a “previously known good” state at any time. In a mature Cloud environment, it’s always easier to reprovision than it is to repair. Reprovisioning could mean an automated cycle of validating and regenerating application and system configurations, or even rerunning the full provisioning cycle from the base OS up to running business applications.

In many cases, of course, the previously known good state isn’t good enough, typically because there are live data in the real time state that would be lost with this kind of rollback. As a result, such rollbacks must be handled carefully, as they really aren’t rollbacks in the sense of a two-phase commit. Instead, with fully automated provisioning, the provisioning system should be able to “roll forward to a previous version,” where the provisioning tools will automatically return your applications to a functionally acceptable state, with all your data intact.

Automated provisioning depends upon the environment specification. This spec is essentially a declarative representation of how you want your entire deployment. Your provisioning tools will then essentially execute the spec, starting with bare metal and possibly stock virtual machine images, and then they will automatically deploy, configure, and start up the entire system or the application stack (or both), with no runtime decisions or tweaking by an operator. The spec should also contain sufficient detail to direct the appropriate tools to test whether the automation is implemented correctly, and if it isn’t, to take the appropriate action.

This specification can be as sophisticated as your tools and your architecture allow it to be. It may vary from release to release, and you should be able to break it down for specific tools that handle different parts of the configuration. The spec may also have conditional logic, and can also specify deployment or configuration changes over time, for example, the instruction to provision additional instances when traffic numbers cross a threshold.

You may also want to handle the automatic configuration of the application stack separately from the configuration of the system stack, as your applications may change more frequently than the systems. The goal is to make the spec sufficiently sophisticated so that the automation itself doesn’t vary from release to release. It will only require updates when your requirements call for a significant architectural change.

The View from Above and Below the Clouds

There are fundamentally two sides to this story: the view from the perspective of the Cloud service provider (including the internal providers of private Clouds), vs. the view from the consumer of Cloud-based resources. Clearly, Amazon, Microsoft, and the other public Cloud providers have figured out how to automate the configuration of their public Cloud environments. For organizations building their own private Clouds, the challenge is to take a page out of the public service providers’ playbooks on how to run a Cloud environment. Bottom line: if you don’t get automated configuration management down pat, you’re not running a private Cloud at all. You simply have a traditional data center with some Cloud-like features – and furthermore, you have a data center that is more expensive to run than necessary.

If you’re in a position to consume Cloud resources, regardless of the Cloud deployment model, then automated provisioning is every bit as important as it is for Cloud service providers, only now it impacts your existing IT processes and policies. As organizations adopt the Cloud, they increasingly transform the role of operations. No longer does your ops team actually take care of servers, networks, and applications. Instead, you’re automating that work, shifting the expertise required to the development team who must now create and manage the automation scripts that form the specification. Or perhaps the ops team moves their cubicles to the dev area, working hand-in-hand with developers to handle those scripts. Either way, Cloud changes everything in the IT department.

The Realization of the DevOps Vision

Reworking the relationship between dev and ops, or DevOps, is nothing new, of course. According to Wikipedia, “DevOps is an emerging set of principles, methods and practices for communication, collaboration and integration between software development (application/software engineering) and IT operations (systems administration/infrastructure) professionals. It has developed in response to the emerging understanding of the interdependence and importance of both the development and operations disciplines in meeting an organization’s goal of rapidly producing software products and services.” While ZapThink hasn’t discussed DevOps by name up to this point, we have been calling for iterative, full-lifecycle governance for several years now – an essential enabler of success with SOA in particular and agile architectures in general.

With the rise of Cloud Computing, DevOps is entering what might be its “golden age.” As Cloud provisioning specifications become more sophisticated, creating them becomes more of a development task than an operational one. Ops doesn’t go away, of course, but it moves to the other side of the Cloud: supporting Cloud data centers. In other words, if you have a private Cloud, your ops team is responsible for managing the private Cloud infrastructure. And yes, if you use a public Cloud, well, you have the luxury of outsourcing operations to your Cloud provider. Good sysadmins need not worry, of course. If anything, demand for your skills is only increasing with the move to the Cloud.

The ZapThink Take

First there was software development. Write a bunch of code and run it on a computer – “the computer is the computer.”

Then there was systems development. Write a bunch of code and put it on a bunch of computers, and have them serve up bits of it to many more computers – “the network is the computer.”

Now we’re at the dawn of Cloud development: create sophisticated Cloud provisioning/deployment/management specifications, and run those in the Cloud. Yes, the Cloud itself becomes the computer. We’re not talking IaaS, PaaS, or SaaS here. Even those oh-so-2011 Cloud service models are only elements of the spec, for automated provisioning tools to provision and configure dynamically.

We’re not there yet, of course – but there are a number of increasingly sophisticated automated provisioning tools on the market today, and an increasing number of organizations are leveraging them to take full advantage of the Cloud. Want to learn more? ZapThink covers automated provisioning, including a broad discussion of available tools, in our Enterprise Cloud Computing and Architecting for the Cloud courses. We’re running them in Singapore February 23-24, Sydney February 27-28, Melbourne Australia February 29-March 1, Delhi March 5, Mumbai March 6, Hyderabad March 7, Bengaluru March 8, and London March 15-16. Be prepared for a comprehensive, vendor-independent, architecture-focused fire hose of everything Cloud. There is no way to get this material from anyone but ZapThink. Classes are filling up so register now. We hope to see you at one of the courses soon!

Image source: Horia Varlan

One and Two Day Courses in London, Singapore, Australia, and India

 MCLEAN, VA January 24, 2012 – Today, ZapThink, a Dovèl Technologies Company, a global Enterprise Architecture, Service-Oriented Architecture, and Cloud Computing advisory, training, and thought leadership firm, announced that it will be running a series of one and two-day training courses on Enterprise Cloud Computing.

Jason Bloomberg, President of ZapThink, will be delivering each course personally. His itinerary currently includes the UK, Singapore, Australia, and India, and will also include South Africa, the Middle East, and other regions.

“Cloud Computing is far more than simply outsourcing your data center,” said Jason Bloomberg, President of ZapThink. “Fully leveraging the Cloud requires an architecture-focused, enterprise-centric approach that places Cloud resources into the context of enterprise IT.”

The Enterprise Cloud Computing course covers the following material:

Cloud service and deployment models

• Enterprise Architecture & The Cloud
• Cutting through vendor hype
• Relationship between Cloud & SOA
• Type 1 and Type 2 virtualization
• Traditional, para, full, OS, and hosted virtualization
• Virtualization and Cloud Computing
• Workloads, Pods and Cloud Control Systems
• IaaS, PaaS, and SaaS: Strategies & Caveats. Options. Strategies, and Key Players
• Cloud Configuration
• The role of DevOps
• Cloud Security
• Cloud Governance
• Big Data & The Cloud
• MapReduce & Hadoop
• BASE and data consistency
• Building a RESTful Cloud
• High performance computing in the Cloud
• Architecting for Failure
• Availability Zones and disaster recovery
• The future of the Cloud

The course also includes several case studies and exercises.

All attendees will receive the following benefits:

•  A clear, vendor-independent understanding of Cloud Computing
• The tools and expertise necessary to put together a Cloud roadmap and migration plan for their organizations
• Multi-tenancy, including real-life case studies
• An understanding of how to place the Cloud into the context of their current Enterprise Architecture

The current international training schedule is as follows:

Enterprise Cloud Computing (Two day), Singapore, February 23 – 24.

To register: http://www.icmgworld.com/corp/events/apac/singapore/Cloud/JasonBloomberg/workshop_2012/home.asp

 Enterprise Cloud Computing (Two day), Australia: Sydney February 27 – 28 & Melbourne February 29 – March 1.

To register: http://www.icmgworld.com/corp/events/australia/Cloud/JasonBloomberg/workshop_2012/home.asp

 Enterprise Cloud Computing (One day), India: Delhi March 5, Mumbai March 6, Hyderabad March 7 & Bangalore March 8.

To register: http://www.icmgworld.com/corp/events/india/Cloud/JasonBloomberg/workshop_2012/home.asp

 Cloud Computing for Architects (Two day), London, UK, March 15 – 16.

To register: http://www.irmuk.co.uk/events/103.cfm

About ZapThink
As a recognized authority and master of Service-Oriented Architecture (SOA), Enterprise Architecture, and architectural approaches to Cloud Computing, ZapThink (http://www.zapthink.com) provides its global audience of public and private sector enterprises with practical advice, guidance, and education, to assist in creating an architecture that meets business needs. ZapThink offers a clear roadmap for standards-based, loosely coupled distributed computing – a vision of IT meeting the needs of the agile business.

ZapThink’s flagship offering is the Licensed ZapThink Architect (LZA) course, which provides training and certification on SOA & Cloud Computing around the world. ZapThink has certified over 1,500 individuals to date, and continues to offer an expanded LZA curriculum. Outside of the classroom, ZapThink publishes the ZapFlash Newsletter. Distributed to over 20,000 subscribers, this newsletter provides perspective on technology trends and implementations of cutting edge IT solutions.

In August 2011, Dovèl Technologies acquired ZapThink LLC as part of its continuing strategy to expand its scope, capabilities, and thought leadership in SOA, Cloud Computing and related technologies. ZapThink is now a wholly owned subsidiary of Dovèl Technologies. By joining with Dovèl, ZapThink is able to draw on the expert resources within the company and their real-world experience in implementing Cloud and SOA in federal systems. This expanded pool of talent and experience enriches the training experience and allows ZapThink to create more customized courses to further educate the market on the realities of SOA and Cloud.

About Dovèl Technologies

Dovèl Technologies provides high-end software and application development to government clients. Dovèl is recognized as an industry leader in Service Oriented Architecture (SOA), using the approach to create low-impact approaches to process, communicate, and store mission critical information. Clients include Food and Drug Administration, Department of Defense, U.S Census Bureau, Department of Education, and the Federal Aviation Administration. Dovèl has been appraised at CMMI level 3 and its annual quality report receives accolades from industry leaders such as Capers Jones, who has listed Dovèl in the category of “Companies That Utilize Best Practices” along with IBM, Amazon, Google, and Apple. To learn more visit http://www.doveltech.com.

Press Contact:

Piper Conrad

piper.conrad@doveltech.com

+1-571-499-3718

Read the entire release at http://news.yahoo.com/zapthink-offer-enterprise-cloud-computing-training-worldwide-132823699.html

If you don’t realize by now that Cloud Computing has its risks, then, well, you must have your head in the clouds. But then again, without risk there is no reward. When you place a bet on the Cloud, you know you’re betting on an emerging set of capabilities. And in any case, there are risks everywhere in business. Why should the Cloud be any different?

Download the full article here.

Jason will be delivering the seminar Cloud Computing for Architects in London, 15 – 16 March.

Read the entire newsletter at http://www.irmuk.co.uk/newsletters/january2012.htm

Jason Bloomberg, President of ZapThink, a Dovèl Technologies Company, will be presenting at the Open Group Conference on February 1, 2012. The topic of his presentation is “Architecting a RESTful Cloud: The key to Elasticity.”

The conference is being held at the Intercontinental Mark Hopkins San Francisco on Nob Hill. Jason’s talk will be at 9:00 AM on Wednesday, February 1.

The abstract for his talk is as follows:

Architecting a RESTful Cloud: The key to Elasticity

It’s a common misconception that the Cloud is nothing more than a virtual server in the sky, where you can take any on-premise, legacy app, drop it into the Cloud, and expect it to both work properly and leverage the Cloud’s advantages. In reality, it’s essential to architect applications properly, both to mitigate the Cloud’s shortcomings as well as leverage the most important Cloud benefit: elasticity.

The problem? Cloud environments are inherently partition tolerant, which impacts both data consistency and application state. As a result, architects must utilize different approaches from traditional application environments, instead leveraging best practices for creating hypermedia applications. In particular, they must move application state off the server to the client, following an architectural style known as Representational State Transfer, or REST.

Attendees of this session will:

• Obtain an understanding of the unique architectural requirements for Cloud-based applications
• Gain a new perspective on how the Cloud can support and complement existing applications
• Learn how REST is essential for achieving elasticity in Cloud-based applications.

Read the entire article at http://www.cfoworld.de/finance_und_it/it-prognosen-2011-und-2012-cloud-ausfall-vorhergesehen.

A funny thing happened as I was noodling on this ZapFlash. I was all set to put the nail in the Application Programming Interface (API) coffin, continuing the discussion of just how awful Remote Procedure Call (RPC) interfaces are, and how we should avoid them at all costs. But then I ran across the “explosion of APIs” meme at ProgrammableWeb and elsewhere. After all, your head must be planted deeply in the sand not to notice the plethora of APIs at all our favorite Social Web sites like Twitter, Facebook, and hundreds of others. How can the API be dead when APIs are more important and plentiful than ever?

Maybe I’m just nitpicking. As APIs become less RPC-centric and more RESTful, the inflexible tight coupling of the past is giving way to a new golden age of API-ness, where anybody can connect any piece of software seamlessly and automatically to any Web site or app we might care to use. But upon closer reflection, my concern is not all nitpickiness. There are API best practices and API worst practices, just as there are good APIs and bad ones. Perhaps more to the point, most of the APIs out there, well, are among the bad ones. So, what makes for a good API today, with all the power and capabilities that modern technology approaches afford us? Why are so many people getting them wrong? And what can we do to steer everyone in the right direction?

Programmable Interfaces: The Never-ending Story

The real reason that APIs get under my skin is the “P” – “programmable,” as in programmatic. The core notion of an API, after all, is that you want one application to be programmable by something external to it, in the sense that you have an imperative control flow that goes from here to there and back to here.

The problem with such imperative programming in any distributed environment, of course, is that there is no end of problems that can arise between here and there. Network issues, incompatibilities, timing and sequence issues, the list goes on and on, leading computer scientists to the notion of functional programming. In the functional world, functions (which also go by the names procedures or methods) encapsulate the software at the remote location, forming black boxes with fixed inputs and outputs. Any local piece of software, therefore, can call a remote procedure and get the desired response, without having to worry about whether multiple calls to that procedure might interfere with each other or lead to other nasty surprises that a purely imperative approach might exhibit.

Here’s the rub: functional programming is nothing more than RPC, with all the tight coupling issues that come along for the ride. However, functional programming is also considered to be a type of declarative programming. Declarative programming has always been the ugly duckling of the programming language world, because with a declarative approach, you don’t specify the control flow. Instead, you describe the desired behavior you want the software to exhibit. And somehow, via some kind of behind-the-scenes hand waving, the software miraculously does what you want it to.

Functional programming is declarative in the sense that a remote procedure acts as a black box. Specify the operations, inputs, and outputs (its signature, in API-speak), and the inner workings of the procedure aren’t your problem. That is, unless you don’t understand what it’s supposed to do for you, or heaven forbid, its behavior changes.

REST to the Rescue?

Building abstracted interfaces that enable organizations to deal better with change is what SOA is all about, of course. Unfortunately, the tools we had at our disposal – namely, Web Services – didn’t go far enough. Yes, we moved from RPC-style Web Services to document-style, and that improved our loose coupling substantially. But even document-style Web Services still have operations, a holdout from the bad old functional programming days.

Enter REST. ZapThink has discussed the move away from RPC to RESTful interfaces before: in REST-Based SOA: an Iconoclastic Approach, but of course, we’ve been discussing the advantages of document style interfaces over RPC for several years now. But people still aren’t getting it. Not only are techies missing the point of REST, even when they build supposedly RESTful APIs, they’re failing to follow the REST constraints.

For example, many of these ostensible RESTful APIs don’t provide self-descriptive messages. With REST, every message from a resource should contain all the metadata necessary for any client to understand what it can do with representations of that resource. In the RPC days, procedural responses may have contained only data with no metadata. With Web Service interactions, Service responses contained some metadata in the form of the SOAP envelope, header, and the tagging structure in the body. But even with Web Services, the WSDL contract and policy metadata are external to the Service. You don’t expect to get the contract when you query a Service.

With a RESTful interaction, on the other hand, contract metadata may be returned in particular representations, whether it be media type metadata, schemas, or even less structured metadata. And of course, representations also include hyperlinks, which also provide contract metadata to the client.

Separation of resources from representations is another essential REST constraint – one that developers also frequently violate. If there are any instructions to the resource in a request other than one of the four operations of the uniform interface (GET, POST, PUT, and DELETE), then you are violating this constraint. For example, if your request is instructing a resource to update a record, you’re not being RESTful. It’s up to the resource to determine whether a POST or PUT should update a record, not the representation.

Finally, hypermedia as the engine of application state – the dreaded HATEOAS – is perhaps the most overlooked of the REST constraints, even though it’s the most important. The big picture of HATEOAS are the hypermedia applications that we’re trying to build, but even at the API level, HATEOAS is critical, in conjunction with the self-descriptive message constraint. In any truly RESTful interaction, the resource returns a representation that contains all necessary metadata, including hyperlinks that instruct the client what it can do next. Likewise, a RESTful client has no idea what a resource can do for it unless it follows such links.

“RESTful” Equals “Web-friendly”

What so many techies lose sight of is the fact that REST isn’t supposed to make the Web more like system integration; it’s meant to make system integration more like the Web. When you click a link in a Web page, you expect to go to another Web page, or perhaps a video or sound file or some other media representation. REST takes that simple interaction and abstracts it. Now you have an abstracted client (instead of a browser) supporting a request of a resource (the Web server capability, for example, the php script that generated the response) on an abstracted server (the Web server) that returns a representation (the resulting media file or Web page) as per the uniform interface (what the link you clicked was supposed to do). These abstractions let us apply simple Web behavior to all manner of system-to-system interactions. But never, ever lose sight of the fact that you want simple Web behavior from your application.

I’m sure many readers who made it this far are muttering to themselves that their RESTful APIs are truly RESTful. Well, maybe, but probably not, and here’s proof. Let’s take a popular, supposedly RESTful API as an example: the Yahoo! Maps PlaceFinder Geocoding API. You’ll notice on the documentation page a “BASE URI,” which it expresses as http://where.yahooapis.com/geocode?[parameters]. There are two problems with this expression. First, it’s not a hyperlink (it just looks like one). Second, the URL has the question mark in it, requiring the user to know what parameters might be valid.

Let’s say instead we turn this expression into a true hyperlink, leaving off the parameters since we don’t know what they are: http://where.yahooapis.com/geocode. Go ahead,  click on that link, I dare ya. Sure enough, you get an error message. True, it’s XML formatted, but it’s missing something absolutely essential: a hyperlink.

In fact, Yahoo! made several serious mistakes: first, the base URI isn’t a hyperlink, violating HATEOAS. Second, the metadata that tell you how to use the interface are separate from the interface, rather than  returned in the response from hyperlinking to the base URI, violating the self-descriptive messages constraint. Third, the URI requires parameters as part of the search query (the characters after the question mark), violating the separation of resource and representation. And finally, the error response it did return didn’t include a hyperlink, once again violating HATEOAS. Bottom line: there’s really very little that’s RESTful about this API.

While it may be amusing to pick on Yahoo!, it’s important to point out that they aren’t alone. In fact, they’re typical. It’s quite rare, in fact, for a supposed RESTful interface to be truly Web-friendly. After all, most techies don’t expect Web friendliness from APIs. APIs are, well, programming interfaces, while the Web consists of user interfaces. But in the REST world, programming interfaces are simply abstracted user interfaces. In other words, truly RESTful APIs aren’t really like the APIs we know and love, and have been working with for years. They’re fundamentally different.

The ZapThink Take

I know this ZapFlash is deeply iconoclastic, but that’s what you’ve come to expect from ZapThink, after all. However, the point of this article isn’t to scold everybody for doing REST wrong. The point is to help you think differently about what it means to program in a distributed environment. The point to the “programmable Web” isn’t to make the Web more programmable, it’s to make software more Web-like. If we can finally free ourselves from the last vestiges of imperative, RPC-style programming, even going so far as to steer clear of functional programming, and move to a fully declarative, document-centric paradigm, only then will we be able to achieve the resilience and power of the Web when we tackle system integration challenges.

This mind shift is at the core of REST. When Roy Fielding wrote his dissertation, he didn’t come up with REST and then build the Web following its constraints. On the contrary: he deeply understood what made the Web itself so special, and he sought to express that specialness as an architectural style. True, tackling system integration following true RESTful principles is difficult. But remember, building the Web was easy. Take TCP/IP, add a few simple standard protocols, code an HTML rendering app we called a browser, and the Web more or less took it from there. Almost twenty years later, the Web is unimaginably immense, and yet it still works just fine, thank you very much. Is it too much to ask for all of our IT systems to behave the same way?

Image source: cloudzilla

Read the entire article at http://www.bpm-spain.com/articulo/70404/bpm-general/todos/analistas-predicen-el-incremento-del-uso-de-rest-para-vincular-procesos-de-negocio.

“HTML 5 is maturing as the next generation of Web markup to the point where we see it as a replacement for Adobe Flash,” Bloomberg said. “But also as a common mobile development platform. If you’re building an app for an iPhone, you use Objective C; if you’re building one for Android, you use Java. But with HTML 5, you can do almost everything you can do with the native application environment, but in a cross-platform way. It gives you much more flexibility and opens up a whole new realm of possibility for mobile and enterprise development.”

Read the entire article at http://adtmag.com/blogs/watersworks/2012/01/2012-agile-predictions-from-an-enterprise-architecture-insider.aspx.

Architected properly, REST-based SOA is more lightweight, flexible, and user-centric than “traditional” Web Services-based SOA. Learn more about this easy to implement, innovative approach to SOA and make your enterprise agile and real-time today.

Listen to distinguished analyst, Jason Bloomberg, President of leading US Analyst firm, ZapThink and an SOA practitioner with over 15 years of experience in real-live implementations and Atul Saini, CEO and CTO of Fiorano Software, a leading enterprise integration middleware Singapore company headquartered in Silicon Valley, USA, as they pull all three threads together-SOA, REST, and Cloud Computing-into a set of practical approaches that provide greater agility at a lower cost.

Event Topics

REST-Based SOA

Representational State Transfer, or REST, is an HTTP-centric approach to addressing resources on a network. Heralded as simpler and less verbose than Web Services, REST has engendered a near-religious fervor among architects and integration engineers in enterprises around the globe. Read More »

RESTful Cloud Computing

Enterprises typically begin their move to the Cloud with “toe in the water” initiatives: email in the Cloud, or perhaps leveraging a SaaS provider’s offering. Before long, the focus shifts to the on-premise legacy environment: how can we move our old apps and systems to the Cloud, Read More »

Click here for more information and to register.