Posts Tagged 'API'

July 11, 2012

Mandrill: Tech Partner Spotlight

This is a guest blog with Chad Morris from our partner Mandrill. Mandrill is an email delivery platform built on and managed by MailChimp. Created for developers to set up and manage with minimal coding effort, Mandrill offers advanced tracking, easy-to-understand reports and hundreds of template options. In this video interview, Chad goes into detail about the history of the company as well as the major differences between Mandrill and MailChimp. In the near future, you'll see a separate guest blog from the Mandrill team with best practices for managing your email systems.

This guest blog series highlights companies in SoftLayer's Technology Partners Marketplace.
These Partners have built their businesses on the SoftLayer Platform, and we're excited for them to tell their stories. New Partners will be added to the Marketplace each month, so stay tuned for many more come.
June 29, 2012

We're Shipping Up to Boston - HostingCon 2012

It's that time of year again ... HostingCon is upon us, and we're faced with an interesting challenge: Go even bigger and badder in Boston than we did at HostingCon 2011 in San Diego. And that's a tall order.

Given the fact that we've already sponsored and participated in dozens of conferences around the world this year, you might be surprised to learn that we've still got a surprises in our bag of tricks. Without giving too much away, I thought I'd share a few of the SoftLayer-specific highlights you make note of if you're planning your HostingCon itinerary.

Conference Sessions

Want some hosting insight from the executive management team of one of the largest privately held hosting providers in the world? You might want to add these sessions to your calendar:

Partnerships Done Right
Lance Crosby, CEO
9:00am – Monday, July 16
Management Track

As more "non-traditional" hosters (telcos, cable companies & VARs) enter the cloud services market finding the right partner is a must. The opportunity is huge but this isn’t a situation where a rising tide will float all boats. Lance Crosby, CEO of SoftLayer will explain how, in order to be successful, you’ll need to understand the following: 1) Building for Internet Scale, 2) Think platform first, and 3) How to automate. The session will include discussion of how SoftLayer leverages partners to drive business growth.

Build vs Buy: Operations & Billing Automation
Nathan Day, Chief Scientist (+ Panel)
9:00am – Tuesday, July 17
Technology Track

The finance, operations and administrative back office of a hosting company can be a complex animal. Some hosts have dedicated software development teams to build in-house solutions, others opt to buy as much as they can from 3rd party vendors. Hear three different approaches to tackling the problem, and learn how your product line can determine the optimal mix of open source, home grown and off-the-shelf solutions.

Finding Your Story: Branding and Positioning in the Hosting Industry
Simon West, CMO
2:00pm – Tuesday, July 17
Sales & Marketing Track

In a crowded marketplace it's critical to establish a clear position and identity in the minds of your customers and prospects. SoftLayer CMO Simon West will discuss best practices for defining and articulating your brand position, illustrating with specific examples drawn from his experience in building some of the industry's most notable brands.

Build, Launch, Sell: Strategies for Launching a Product in the Hosting Business
George Karidis, CSO (+ Panel)
3:00pm – Tuesday, July 17
Management Track

Introducing value-added services around basic hosting can be the strategy that turns a hosting business into a winning venture for the host, and a truly valuable service for the customer. In this interactive session, a panel of product management experts from the hosting business will cover best practices for building (or integrating), launching and selling a new product to your customers, helping you to develop processes, procedures and strategies for seeing a new product launch through from start to finish.

The SoftLayer Booth: #413

When you step into the expo hall at the John B. Hynes Convention Center, you're going to see SoftLayer. In our 20' x 30' space at booth 413, we'll have a few of your favorite SLayers available to answer any and all of your questions about what's new and what's next for SoftLayer ... And to pass out some always-popular SoftLayer swag.

SoftLayer Booth

By popular demand, the Server Challenge will be making its return to HostingCon, and if last year is any indication, the competition will be fierce. The pride of besting all HostingCon attendees in reassembling a server rack is arguably as valuable as the New iPad the winner receives. Though your pride doesn't have a Retina Display.

Host Me All Night Long

Following the phenomenal success of "Geeks Gone Wild" last year (headlined by The Dan Band), we knew we had our work cut out for us when it came to planning a party for HostingCon in Boston. We've teamed up with cPanel and comcure to put together "Host Me All Night Long" at Royale Boston on Monday, July 16.

Host Me All Night Long

One of my favorite comedians, Ralphie May, is going hit the stage at 8pm, and you won't want to miss a second of his set. Following Ralphie, Yellow Brick Road is bringing their award-winning Classic Rock tribute skills from Las Vegas to keep the night going. Given the name of the party, you shouldn't be surprised when a little AC/DC "You Shook Me All Night Long" is played.

Like last year, the attendance is strictly limited, and when the number of tickets available at reaches zero, you're out of luck. Even if you're our best customer ever, you need a ticket to get in the door, so register while you can! If you show a little extra SoftLayer love on Twitter or Facebook, send me a link to it (, and I might be able to hook you up with a VIP code to get you priority access and into the VIP section at the venue.

Like the Dropkick Murphys, we're "shipping up to Boston," and we hope to see you there!


June 21, 2012

New Swag, New Booth, New Product Announcement: SoftLayer at Cloud Expo East 2012

When a SLayers pack their bags and heads to the 'Big Apple,' we go BIG. Our most recent trip to NYC for Cloud Expo East proved that statement over and over again. When I heard I'd be one of the employees representing SoftLayer at the Javits Convention Center, I did a little dance ... Cloud Expo is one of my favorite conferences, and New York City is one of my favorite cities, so I had a lot to be excited about.

Cloud Expo East and Cloud Expo West are two of the biggest shows SoftLayer sponsors every year. Attendees come from various industries — from digital marketing agencies to software as a service providers to hosting resellers — with their own needs and questions about what's happening "in the cloud." Because our Cloud Expo presences usually get a ton of traffic, we decided to unveil our brand new 20' by 20' booth in New York:

SoftLayer at Cloud Expo East

For the last few months, we've been sketching, editing and tweaking our vision of the booth. Naturally, our new "Build the Future" branding was present, and you could see the simple "Our Platform. Your Vision." statement from wherever you were. By the time the design was finalized, we were on pins and needles in anticipation, waiting for the booth leap off the paper. We weren't disappointed, and conference attendees weren't either.

In addition to the hundreds of conversations we had with attendees about SoftLayer's cloud computing capabilities, it was pretty amazing to me that so many people commented on our booth design. Many attendees noticed that our booth gets bigger and bigger every year, and the fact that our booth towered over most of the other booths in the area made that a pretty easy observation. As attendees were moving down the escalators into the exhibition hall, they were greeted by the SoftLayer. Because the booth was designed with an open-concept in mind, we never felt too claustrophobic ... Even when a flood of people would come hunting for the new SoftLayer flexi-frisbees we were giving out after they heard Duke or Marc present.

SoftLayer at Cloud Expo East

Despite the "openness" of the booth design, many attendees were able to gather what SoftLayer is all about from the graphic side panels ... and the Server Challenge:

SoftLayer at Cloud Expo East

That's right. The infamous Server Challenge continued to draw crowds and spark conversations in the new booth. And it was the perfect "finishing touch" to put the new conference presence over the top. While some attendees were hesitant to step up to try their hands at the competition, others were eager to accept the challenge. And as usual, the leader board was impossibly close:

  1. Dejian Fang - 0:59.08
  2. Corjan Bast - 0:59.59
  3. Logan Best - 1:00.49
  4. Jeffrey Abatayo - 1:01.00
  5. Bryan Wong - 1:01.84

The top time of 59.08 seconds was a mere 2.76 seconds faster than the fifth place time!

When conference attendees weren't watching the Server Challenge craziness or ducking to avoid an errant SoftLayer frisbee, we had a few more "oohs" and "ahhs" to share. In the new booth design, we incorporated four iMacs, one in each corner. If an attendee had a question about our portal, our pricing or our API, we could fire up a browser and use the SoftLayer-sponsored conference wifi to take them where they needed to go. If no one was using the computers, the screens would show a flashy video that included some interesting SoftLayer facts and a look at a SoftLayer Truck Day.

SoftLayer at Cloud Expo East

Off the expo floor, SoftLayer CTO Duke Skarda and Vice President of Product Innovation Marc Jones announced our new product, Private Clouds. No big deal. If you didn't see that announcement or you want to learn more, Nathan Day (SoftLayer's Chief Scientist) posted a fantastic blog coinciding with SoftLayer's private clouds release, and Duke followed up with an in depth look at how and why we chose to build private clouds the way we did.

Sad that you missed your chance to see the new 20' x 20' booth in person? Don't cry... If you're in the Silicon Valley for Cloud Expo West (November 5-8), we won't be hard to spot.


May 30, 2012

What Does Automation Look Like?

Innovation. Automation. Innovation. Automation. Innovation. Automation. That's been our heartbeat since SoftLayer was born on May 5, 2005. The "Innovation" piece is usually the most visible component of that heartbeat while "Automation" usually hangs out behind the scenes (enabling the "Innovation"). When we launch a new product line like Object Storage, add new functionality to the SoftLayer API, announce a partnership with a service provider like RightScale, or simply receive and rack the latest and greatest server hardware from our vendors, our automated platform allows us to do it quickly and seamlessly. Because our platform is built to do exactly what it's supposed to without any manual intervention, it's easily overlooked.

But what if we wanted to show what automation actually looks like?

It seems like a silly question to ask. If our automated platform is powered by software built by the SoftLayer development team, there's no easy way to show what that automation looks like ... At least not directly. While the bits and bytes aren't easily visible, the operational results of automation are exceptionally photogenic. Let's take a look at a few examples of what automation enables to get an indirect view of what it actually looks like.

Example: A New Server Order

A customer orders a dedicated server. That customer wants a specific hardware configuration with a specific suite of software in a specific data center, and it needs to be delivered within four hours. What does that usually look like from an operations perspective?

SoftLayer Server Rack

If you want to watch those blinking lights for two or three hours, you'll have effectively watched a new server get provisioned at SoftLayer. When an order comes in, the automated provisioning system will find a server matching the order's hardware requirements in the requested data center facility, and the software will be installed before it is handed over to the the customer.

Example: Server Reboot or Operating System Reload

A customer needs to reboot a server or install a new operating system. Whether they want a soft reboot, a hard reboot with a full power cycle or a blank operating system install, the scene in the data center will look eerily familiar:

SoftLayer Server Rack

Gone are the days of server build technicians wheeling a terminal over to every server that needs work done. From thousands of miles away, a customer can remotely "unplug" his or her server via the rack's power strip, initiate a soft reboot or reinstall an operating system. But what if they want even more accessibility?

Example: What's on the Screen?

When remotely rebooting or power cycling a server isn't enough, a customer might want someone in the data center to wheel over to their server in the rack to look at any of the messages that can only be read with a monitor attached. This would generally happen behind the server, but for the sake of this example, we'll just watch the data center technician pass in front of the servers to get to the back:

SoftLayer Server Rack

Yeah, you probably could have seen that one coming.

Because KVM over IP is included on every server, physical carts carrying "keyboard, video and mouse" are few and far between. By automating customers' access to their server and providing as much virtual access as we possibly can, we're able to "get out of the way" of our technical users and only step in to help when that help is needed.

I could go on and on with examples of cloud computing upgrades and downgrades, provisioning a firewall or adding a load balancers, but I'll practice a little restraint. If you want the full effect, you can scroll up and watch the blinking lights a little while longer.

Automation looks like what you don't see. No humanoid robots or needlessly complex machines (that I know of) ... Just a data center humming along with some beautiful flashing server lights.


P.S. If you want to be able to remotely bask in the glow of some blinking server lights, bookmark the larger-sized SoftLayer Rack animated gif ... You could even title the bookmark, "Check on the Servers."

May 10, 2012

The SoftLayer API and its 'Star Wars' Sibling

When I present about the SoftLayer API at conferences and meetups, I often use an image that shows how many of the different services in the API are interrelated and connected. As I started building the visual piece of my presentation, I noticed a curious "coincidence" about the layout of the visualization:

SoftLayer API Visualization

What does that look like to you?

You might need to squint your eyes and tilt your head or "look beyond the image" like it's one of those "Magic Eye" pictures, but if you're a geek like me, you can't help but notice a striking resemblance to one of the most iconic images from Star Wars:

SoftLayer API == Death Star?

The SoftLayer API looks like the Death Star.

The similarity is undeniable ... The question is whether that resemblance is coincidental or whether it tells us we can extrapolate some kind of fuller meaning as in light of the visible similarities. I can hear KHazzy now ... "Phil, While that's worth a chuckle and all, there is no way you can actually draw a relevant parallel between the SoftLayer API and The Death Star." While Alderaan may be far too remote for an effective demonstration, this task is no match for the power of the Phil-side.

Challenge Accepted.

The Death Star: A large space station constructed by the Galactic Empire equipped with a super-laser capable of destroying an entire planet.

The SoftLayer API: A robust set of services and methods which provide programmatic access to all portions of the SoftLayer Platform capable of automating any task: administrative, configuration or otherwise.

Each is the incredible result of innovation and design. The construction of the Death Star and creation of the SoftLayer API took years of hard work and a significant investment. Both are massive in scale, and they're both effective and ruthless when completing their objectives.

The most important distinction: The Death Star was made to destroy while the SoftLayer API was made to create ... The Death Star was designed to subjugate a resistance force and destroy anything in the empire's way. The SoftLayer API was designed to help customers create a unified, automated way of managing infrastructure; though in the process, admittedly that "creation" often involves subjugating redundant, compulsory tasks.

The Death Star and the SoftLayer API can both seem pretty daunting. It can be hard to find exactly what you need to solve all of your problems ... Whether that be an exhaust port or your first API call. Fear not, for I will be with you during your journey, and unlike Obi-Wan Kenobi, I'm not your only hope. There is no need for rebel spies to acquire the schematics for the API ... We publish them openly at, and we encourage our customers to break the API down into the pieces of functionality they need.

-Phil (@SoftLayerDevs)

December 21, 2011

Spot Influence: Tech Partner Spotlight

This is a guest blog from Spot Influence. Spot Influence provides businesses with detailed information on who's influential in the world of social media and what those influencers actually care about. This data, accessed via an API, enables companies to react faster with more information and, more importantly, to be proactive and execute a strategic social media plan.

Discover the People Who Drive Your Business

If you're involved in marketing, you understand the importance of monitoring your business's community online. You also probably know that engaging with the "Influencers" who speak to your intended audience can be critical to understanding their needs and spreading your brand's message. But existing tools are limited in their ability to find these individuals. They don't allow you to sift through the noise and discover the people who are already impacting your business online.

Spot Influence is a data service that provides granular, actionable information to businesses about their online audience and the people who are influencing them. With this data, business can discover the key influencers they need to be paying attention to and gain valuable insight regarding their existing customers: their online profiles, where they publish and engage with content, and what they care about.

Solving this problem at scale is incredibly challenging. We deal with vast amounts of unstructured data, processing tens of millions of URLs and creating terabytes of data every day. That's why we're excited to be a SoftLayer customer and a part of the Technology Partners Marketplace. SoftLayer enables us to cost-effectively scale our machines to meet customer needs.

If you're interested in learning more about Spot Influence, please check out the following links and sign up for the Beta on our website!

Twitter: @spotinfluence

-Dave Angulo and Rich Grote, Co-Founders, Spot Influence

This guest blog series highlights companies in SoftLayer's Technology Partners Marketplace.
These Partners have built their businesses on the SoftLayer Platform, and we're excited for them to tell their stories. New Partners will be added to the Marketplace each month, so stay tuned for many more come.
September 13, 2011

SoftLayer Features and Benefits - Automation

Features and benefits ... They're like husband and wife, horse and carriage, hammer and nails! They are inseparable and will always complement each other. I wanted to jump right into a key "features and benefits" analysis of one of the value propositions of the SoftLayer platform, but before I did, I want to make sure we are all on the same page about the difference between the two.

A feature is something prominent about a person, place or thing. It's usually something that stands out and makes whatever you're talking about stand out — for the purpose of this discussion it will be, at least. It could be something as simple as the new car you're buying having a front windshield or the house you're looking to buy having a garage. Maybe it's something a little more distinct like having your car's air conditioner stay cool and blow for 15 min after the ignition is switched to the ACC position when you turn your engine off while pumping gas. Maybe your house has a tank-less water heater. These examples are indeed real features, but the first two are more or less expected ... The last two make this particular car and this particular house stand out.

So where do the benefits come in? Benefits are features that are useful or profitable to you. With you being the operative word here. Think about it: If a feature does not provide any use to you, why would you care? Let's go back to the car with its unique A/C feature. What if you live in Greenland? Who cares that the A/C will stay on? You may not even care for the feature of having an air conditioner at all! Talk about that feature in Dallas, TX, where it has been over 100 degrees for the last 2 months and counting, and all of a sudden, this feature provides a real benefit!

It's now your cue to ask how all of this relates to hosting or, more specifically, SoftLayer.

{ ... Waiting for you to ask ... }

I am glad you asked! If you haven't noticed, SoftLayer boasts a wide array of features on our website, and I would like to point out some of the benefits that may not be apparent to everyone, starting with automation. You're probably aware that SoftLayer has one of the most robust and full featured automation platforms in the industry.


Think about the last time your IT director sent an email that went into your junk mail folder ... You happen to see it on Sunday night, and it reads, "Please stand up five test servers for a new project by the Monday morning meeting." You know that the vendors you typically use take anywhere from 3 days to 2 weeks to stand up new servers, so you wouldn't have had a problem if you saw the email a week ago when it was sent — but you didn't. So to avoid getting a smudge on your perfect employee record, you stumble across where automation enables us to deliver your five servers in 2 hours. Talk about a benefit: You still have time to watch a little TV before going to bed ... Five servers, to your exact specifications, all deployed before you could Google the orgin of "rubber baby buggy bumbers." (For those who care, it was a tag line said by Arnold Schwarzenegger in the movie Last Action Hero.)

At the heart of our automation platform lives the dedicated server, and the blood that courses though our network is the API. All that's left is the pretty face (which we call the Customer Portal). Our portal provides a graphical user interface to control every aspect of your account from ordering new servers, IP allocations and hardware reboots to port control, port speed selection and billing matters. If you're more into the behind-the-scenes stuff, then you can use all the same controls from the comfort of your own application via the API. Sounds like a lot of features to me, where are the benefits?

To start, you have options! Who doesn't like options? You get to choose how you want to manage your account and infrastructure. We don't force you into "our" way. Secondly, being able to do most functions yourself enables you to be more efficient. You know what you want, so you can log in and get it. No need to wait two hours for your firewall rule set to update; just log in and change it. You want to add load balancing to your account? Log in and order it! How about SAN replication? ... I think you see where I'm going with this. Our portal and automation bring this control to your computer anywhere in the world! Some of these features even extend to your iPhone and android platform. Now you can update your support tickets while at the park with the kids.

Look for a second installment of our study on SoftLayer Features and Benefits! There are many more features that I want to translate into benefits for you, so in the more familiar words of Arnold Schwarzenegger, "I'll be back"!


August 23, 2011

SOAP API Application Development 101

Simple Object Access Protocol (SOAP) is built on server-to-server remote procedure calls over HTTP. The data is formatted as XML; this means secure, well formatted data will be sent and received from SoftLayer's API. This may take a little more time to set up than the REST API but it can be more scalable as you programmatically interface with it. SOAP's ability to tunnel through existing protocols such as HTTP and innate ability to work in an object-oriented structure make it an excellent choice for interaction with the SoftLayer API.

This post gets pretty technical and detailed, so it might not appeal to our entire audience. If you've always wondered how to get started with SOAP API development, this post might be a good jumping-off point.

Before you start playing with the SoftLayer SOAP API, you will need to find your API authentication token. Go into your portal account, and click the "Manage API Access" link from the API page under the Support tab. At the bottom of the page you'll see a drop down menu for you to "Generate a new API access key" for a user. After you select a user and click the "Generate API Key" button, you will see your username and your API key. Copy this API key, as you'll need it to send commands to SoftLayer's API.

In PHP 5.0+ there are built in classes to deal with SOAP calls. This allows us to quickly create an object oriented, server side application for handling SOAP requests to SoftLayer's API. This tutorial is going to focus on PHP 5.1+ as the server side language for making SOAP function calls. If you haven’t already, you will need to install the soap client for php, here is a link with directions.

Model View Controller

Model-View-Controller or MVC is a software architecture commonly used in web development. This architecture simply provides separation between a data abstraction layer (model), the business logic (controller), and the resulting output and user interface (view). Below, I will describe each part of our MVC "hello world" web application and dissect the code so that you can understand each line.

To keep this entry a little smaller, the code snippits I reference will be posted on their own page: SOAP API Code Examples. Protip: Open the code snippit page in another window so you can seamlessly jump between this page and the code it's referencing.

The first entry on the API Code Examples page is "The Call Class," a custom class for making basic SOAP calls to SoftLayer's API. This class represents our model: The SOAP API Call. When building a model, you need to think about what properties that model has, for instance, a model of a person might have the properties: first name, height, weight, etc. Once you have properties, you need to create methods that use those properties.

Methods are verbs; they describe what a model can do. Our "person" model might have the methods: run, walk, stand, etc. Models need to be self-sustaining, that means we need to be able to set and get a property from multiple places without them getting jumbled up, so each model will have a "set" and "get" method for each of its properties. A model is a template for an object, and when you store a model in a variable you are instantiating an instance of that model, and the variable is the instantiated object.

  • Properties and Permissions
    Our model has these properties: username, password (apiKey), service, method, initialization parameters, the service's WSDL, SoftLayer's type namespace, the SOAP API client object, options for instantiating that client, and a response value. The SOAP API client object is built into php 5.1+ (take a look at the “PHP” section above), as such, our model will instantiate a SOAP API object and use it to communicate to SoftLayer's SOAP API.

    Each of our methods and properties are declared with certain permissions (protected, private, or public), these set whether or not outside functions or extended classes can have access to these properties or methods. I "set" things using the "$this" variable, $this represents the immediate class that the method belongs to. I also use the arrow operator (->), which accesses a property or method (to the right of the arrow) that belongs to $this (or anything to the left of the arrow). I gave as many of the properties default values as I could, this way when we instantiate our model we have a fully fleshed out object without much work, this comes in handy if you are instantiating many different objects at once.

  • Methods
    I like to separate my methods into 4 different groups: Constructors, Actions, Sets, and Gets:
    • Sets and Gets
      Sets and Gets simply provide a place within the model to set and get properties of that model. This is a standard of object oriented programing and provides the model with a good bit of scalability. Rather than accessing the property itself, always refer to the function that gets or sets the property. This can prevent you from accidentally changing value of the property when you are trying to access it. Lines 99 to the end of our call are where the sets and gets are located.

    • Constructors
      Constructors are methods dedicated to setting options in the model, lines 23-62 of the call model are our constructors. The beauty of these three functions is that they can be copied into any model to perform the same function, just make sure you keep to the Zend coding standards.

      First, let’s take a look at the __construct method on line 24. This is a special magic php method that always runs immediately when the model is instantiated. We don’t want to actually process anything in this method because if we want to use the default object we will not be passing any options to it, and unnecessary processing will slow response times. We pass the options in an array called Setup, notice that I am using type hinting and default parameters when declaring the function, this way I don’t have to pass anything to model when instantiating. If values were passed in the $Setup variable (which must be an array), then we will run the “setOptions” method.

      Now take a look at the setOptions method on line 31. This method will search the model for a set method which matches the option passed in the $setup variable using the built in get_class_methods function. It then passes the value and name of that option to another magic method, the __set method.

      Finally, let’s take a look at the __set and __get methods on lines 45 and 54. These methods are used to create a kind of shorthand access to properties within the model, this is called overloading. Overloading allows the controller to access properties quicker and more efficiently.

    • Actions
      Actions are the traditional verbs that I mentioned earlier; they are the “run”, “walk”, “jump”, and “climb” of our person model. We have 2 actions in our model, the response action and the createHeaders action.

      The createHeaders action creates the SOAP headers that we will pass to the SoftLayer API; this is the most complicated method in the model. Understanding how SOAP is formed and how to get the correct output from php is the key to access SoftLayer’s API. On line 77, you will see an array called Headers, this will store the headers that we are about to make so that we can easily pass them along to the API Client.

      First we will need to create the initial headers to communicate with SoftLayer’s API. This is what they should look like:

      <authenticate xsi:type="slt:authenticate" xmlns:slt="">
          <username xsi:type="xsd:string">MY_USERNAME</username>
          <apiKey xsi:type="xsd:string">MY_API_ACCESS_KEY</apiKey>
      <SoftLayer_API_METHODInitParameters xsi:type="v3:SoftLayer_API_METHODInitParameters" >
          <id xsi:type="xsd:int">INIT_PERAMETER</id>

      In order to build this we will need a few saved properties from our instantiated object: our api username, api key, the service, initialization parameters, and the SoftLayer API type namespace. The api username and key will need to be set by the controller, or you can add in yours to the model to use as a default. I will store mine in a separate file and include it in the controller, but on a production server you might want to store this info in a database and create a "user" model.

      First, we instantiate SoapVar objects for each authentication node that we need. Then we store the SoapVar objects in an array and create a new SoapVar object for the "authenticate" node. The data for the "authenticate" node is the array, and the encoding is type SOAP_ENC_OBJECT. Understanding how to nest SoapVar objects is the key to creating well formed SOAP in PHP. Finally, we instantiate a new SoapHeader object and append that to the Headers array. The second header we create and add to the Headers array is for initialization parameters. These are needed to run certain methods within SoftLayer’s API; they essentially identify objects within your account. The final command in this method (__setSoapHeaders) is the magical PHP method that saves the headers into our SoapClient object. Now take a look at how I access the method; because I have stored the SoapClient object as a property of the current class I can use the arrow operator to access methods of that class through the $_client property of our class, or the getClient() method of our class which returns the client.

      The Response method is the action which actually contacts SoftLayer’s API and sends our SOAP request. Take a look at how I tell PHP that the string stored in our $_method property is actually a method of our $_client property by adding parenthesis to the end of the $Method variable on line 71.

The view is what the user interprets, this is where we present our information and create a basic layout for the web page. Take a look at "The View" section on SOAP API Code Examples. Here I create a basic webpage layout, display output information from the controller, and create a form for sending requests to the controller. Notice that the View is a mixture of HTML and PHP, so make sure to name it view.php that way the server knows to process the php before sending it to the client.

The controller separates user interaction from business logic. It accepts information from the user and formats it for the model. It also receives information from the model and sends it to the view. Take a look at "The Controller" section on SOAP API Code Examples. I accept variables posted from the view and store them in an array to send to the model on lines 6-11. I then instantiate the $Call object with the parameters specified in the $Setup array, and store the response from the Response method as $Result in line 17 for use by the view.

Have Fun!
Although this tutorial seems to cover many different things, this just opens up the basic utilities of SoftLayer's API. You should now have a working View to enter information and see what kind of data you will receive. The first service and method you should try is the SoftLayer_Account service and the getObject method. This will return your account information. Then try the SoftLayer_Account service and the getHardware method; it will return all of the information for all of your servers. Take the IDs from those servers and try out the SoftLayer_Hardware_Server service and the getObject method with that id as the Init property.

More examples to try: SoftLayer Account, SoftLayer DNS Domain, SoftLayer Hardware Server. Once you get the hang of it, try adding Object Masks and Result Limits to your model.

Have Fun!


August 16, 2011

SLDN 2.0 - The Development Network Evolved

SoftLayer is in a constant state of change ... It's not that bad change we all fear; it's the type of change that allows you to stretch the boundaries of your normal experience and run like a penguin ... Because I got some strange looks when coworkers read "run like a penguin," I should explain that I recently visited Moody Gardens in Galveston and saw penguins get crazy excited when they were about to get fed, so that's the best visual I could come up with. Since I enjoy a challenge (and enjoy running around like a penguin), when I was asked to design the new version of SLDN, I was excited.

The goal was simple: Take our already amazing documentation software infrastructure and make it better. A large part of this was to collapse our multi-site approach down into a single unified user experience. Somewhere along the way, "When is the proposal going to be ready?" became "When is the site going to be ready?", at this point I realized that all of the hurdles I had been trampling over in my cerebral site building were now still there, standing, waiting for me on my second lap.

I recently had the honor to present our ideas, philosophy and share some insight into the technical details of the site at OSCON 2011, and KHazzy had the forethought to record it for all of you!

It's a difficult balance to provide details and not bore the audience with tech specs, so I tried to keep the presentation relatively light to encourage attendees (and now viewers) to ask questions about areas they want a little more information about. If you're looking at a similar project in the future, feel free to bounce ideas off me, and I'll steer you clear of a few land mines I happened upon.


June 28, 2011

Modern Website Design: Layout

There have been many books written about website design, and I am not about to take on the challenge of disputing any of them or trying to explain every facet of design. In this short blog, I want to explain what I have come to understand as the modern layout of websites. The term "layout" may have many different definitions, but for this article I am talking about the basic structure of your website, meaning separation of concerns, data transfer from host to client, how to handle changes in data, and when to change your page structure.

Separation of Concerns

It is important when sitting down for the first time to build a website to come up with an outline. Start by making a list of the parts of your website and the functions of those parts. I always start at the base of my web structure and work from there. HTML is always the foundation of a website; it defines the structure and outlines how you will display your data – plain and simple. It doesn't have to include data or styles, nor does it need to be dynamic ... At its essence, it's a static file that browsers can cache.

Client-side scripting languages like JavaScript will take care of client-side animations and data dispersal, while cascading style sheets (CSS) take care of style and presentation, and server-side scripting languages like PHP or Perl can take care of data retrieval and formatting.

Data Transfer

Where is your data going to come from, and what format it will be in when the client receives it? Try to use a data format that is the most compatible with your scripting languages. I use JavaScript as my primary client side scripting program, so I try to use JSON as my data format, but that's not always possible when dealing with APIs and transferring data from remote computers. JSON is quickly becoming a standard data format, but XML* is the most widely accepted format.

I prefer to use REST APIs as much as possible, because they sends the information directly on the client, rather than using the server as a proxy. However, if a REST API is not available or if there is a security risk involved, you get the advantage of being able to format the data on the server before pushing it to the client. Try to parse and format data as little as possible on the client side of things, the client should be concerned with placing data.

Changes in Data

In the past, websites were made from multiple HTML documents, each one containing different data. The structure of the pages were the same though, so the data changed, but the code was nearly identical. Later, using server side scripting programs, websites became more dynamic, displaying different data based on variables passed in the URL. Now, using AJAX or script injection, we can load new data into a static webpage without reloading. This means less redundant code, less load on the client, and better overall performance.

Page Structure

It is important when displaying data to understand when to change the structure of the page. I start by creating a structure for my home page - it needs to be very open and unrestricting so I can add pictures and text to build the site. Once the overall loose structure is established, I create a structure for displaying products (this will be more restrictive, containing tables and ordering tools). The idea is to have as few HTML structures as possible, but if you find that your data doesn't fit or if you spend a lot of time positioning your data, then it might be time to create a new structure.

The Impact of a Modern Layout

Following these steps will lead to quicker, more efficient websites. This is (of course) not a new subject, and further understanding of web layout can be found in Model-View-Controller frameworks. If you find that you spend too much time writing code to interface with databases or place data, then frameworks are for you.


*If you have to deal with XML, make sure to include JavaScript libraries that make it easier to parse, like JQuery.

Subscribe to api