Home > Blog > Tech

Hit Calculation Tutorial for Xignite Web Services

One of the huge benefits of cloud computing is low risk pay-as-you-go, usage-based pricing.  Unfortunately, if you are counting usage by anything other than users, then choosing the best subscription plan for your needs can get a little tricky.

At Xignite, we use a uniform usage metric known as “hits” across all of our Web services to simplify things.  Estimating the number of hits you need for your application is straightforward, once you get the basic idea.  However, for the first time customer it can be a little cryptic.  So, we’re providing this short tutorial and some handy tools to help you through the hit calculation process. The short story is that if you can convert inches to miles, ounces to liters, and Fahrenheit to Celsius, then you’ll have no trouble understanding how to estimate your hits, because the math required is essentially the same. Read more →

Thinking Out Cloud – The Market Data Sweet Spot

Market data providers and IT professionals have tough jobs. Every day financial markets spew out huge fountains of data that must be captured, routed, scrubbed, reconciled, stored and redistributed with dizzying speed and accuracy. The diversity of data is staggering, from low-latency pricing data for algorithmic trading to intermittent corporate actions such as stock splits, and from globally dispersed real-time currency exchange rates to aggregated end-of-day VWAP and NAV calculations. Optimizing and tuning the market data systems that keep this crucial information flowing smoothly and cost effectively is no easy task. What, if anything, can cloud computing offer to ease the challenge?

This is the second post in a series called “Thinking Out Cloud” with the aim of helping financial services and market data IT professionals charged with developing cloud computing strategies separate the cloud buzz from the cloud reality. This post explores the types of market data that naturally lend themselves to cloud computing (and those that do not) in order to identify the market data sweet spot for cloud computing.

Market Data Cloud Computing Sweet Spot

Read more →

Thinking Out Cloud – To Cloud or Not to Cloud in Financial Services?

Cloud computing has graduated from technical curiosity to technology trend. According to a recent Gartner survey, cloud computing and virtualization sit squarely at the top of the list of 2010 CIO priorities. However, most financial services IT professionals are still taking a cautious approach to cloud computing. This is quite understandable given the high performance, security and compliance requirements of financial applications. Unlike Twitter, you can’t just post the fail whale when a financial application has an issue, because real money is at stake not just tweets. So, what financial applications are good candidates for cloud computing and why? To cloud or not to cloud? That is the question.

This is the first post in an series entitled Thinking Out Cloud with the aim of helping financial services IT and market data professionals charged with developing cloud computing strategies separate the cloud buzz from the cloud reality. Read more →

Protected: 5 Minute Developer: How to Build a Currency Converter in 5 Minutes

This content is password protected. To view it please enter your password below:

Market Data Feeds vs. Web Services – Why buy the cow?

Many of the folks visiting our website looking for market data have previous experience with more traditional (or as we like to say legacy) data feed technology, but have not used Web services.   Or, they are new to market data in general and have difficulty cutting through all the technical detail and marketing-speak to make an honest appraisal of what is best for their application.  If this sounds like you, then take a look at this quick side-by-side comparison below.

To make a sound business decision, you need to ask yourself the practical question of “Why should I buy the cow, when I can get the milk through the fence?”  In truth, there can be very good reasons for buying the cow.  For example, you drink an awful lot of milk.  Or, maybe you are also a really big meat eater.  But, if your business isn’t dairy farming, then you are usually better off just buying the milk.

Following this analogy, let me state out front that Web services are NOT right for every application.  If you are developing an algorithmic trading program that requires very low latency custom pricing data, or you belong to a gigantic financial institution that has a massive, centrally provisioned data feed, a strategic SOA initiative, and an IT department chock full of C++ programmers just waiting around for their next integration project, then you probably don’t need web services.  However, if writing custom data parsers is not your forte and fooling around with market data is not the core competency of your business, but merely a means to a higher value end, then we may have just what you need.

One often confusing element that is worth clarifying is that on-demand Web services are not only Web services, they are also on-demand.  That is, many market data vendors bundle application programming interfaces (APIs) in wih their feed products (often as a free add-on).  And, some of these APIs may support Web service standards or at least provide XML formatted output.  However, this does not change the business economics of buying data in bulk and deploying and managing the infrastructure to host and distribute it yourself, versus accessing it one transaction at a time over the Internet.

The 10 Commandments of Web Service Change Management

Web service governance covers many topics one of which is change management. How do you change and enhance existing web services without breaking the code of your existing clients? After more than five years experience delivering web services to some pretty mission-critical applications, Xignite has learned a thing or two about what good business practices are in that domain. We use those rules internally when managing our services and we communicate those to our clients as well. These rules have worked well in helping prevent problems. We compiled those into the Ten Commandments below.

But let’s first remind what those Commandments seek to achieve:

  1. Never break existing code. It’s pretty clear that clients that have already integrated their apps with your web service don’t like it when things stop working. They will be quite upset when they find out it is because you made a change without telling them (this happened to us with code we wrote against the famed API of a just-as-famous Saas CRM vendor).
  2. Eliminate the need to update Existing code. Ideally, once clients have built something in, they should never have to change it. If that is impossible, the frequency and complexity of those changes should be kept to a minimum and clients should be given a time-frame to made those changes and multiple environments to test those changes against.

Ten Commandments of Web Service Change Management

  1. Thou shalt never remove or rename a web service. This is pretty basic. If you change the location of the web service, all hell breaks loose. If you are going to rename a service, make sure you leave a proxy of the new one where the old one was.
  2. Thou shalt never remove or rename a web service operation. With SOAP, the operation defines the SOAP action. With REST, the operation is part of the resource url. In either case, if your remove or rename the operation, the code will break. Because of the nature of web services, keeping “old” operations around for compatibility purpose is typically not a huge issue since only those clients using those operations are affected. We found it is a good practice to do so.
  3. Thou shalt never rename a web service operation parameter. With SOAP, the operation parameters are part of the SOAP message. With
    REST, the operation parameters make up the resource url. In either
    case, the client code will break.
  4. Thou shalt never add a web service operation parameter. Adding a new parameter to an operation will break your client’s code since that code does not currently pass that parameter. If the client uses REST, you may be able to add logic inside your web service to provide a default value for that new parameter, if the client uses the tighter-controlled SOAP, the code will break right away since it will never get passed the server and not even enter your code.
  5. Thou shalt never remove a web service operation parameter. Removing an operation parameter is one of the lesser sins on this list. If the client uses REST, their code will most likely continue to work since the extra parameter will be ignored by your new service. If the client uses SOAP, the result will depend on the behavior of the client’s SOAP toolkit. Some may fail, some may ignore the additional parameters (For instance, client code written over .Net would continue working).
  6. Thou shalt never remove an enumeration value on an operation parameter. Some
    values used as operation parameters are enumerations (i.e. a list of valid
    string values like ‘Daily’, ‘Monthly’, and ‘Annually’ could be the
    enumeration values of a member called PeriodType). Whether the client uses SOAP or REST, if the client code passes one of those values after you removed them from the valid list, their code will break.
  7. Thou shalt never remove or rename a returned object member. Just like for #2 and #5, this is a very evil sin. If the client uses SOAP, their parser will break when not finding the member it is looking for. If the client uses REST, their code will only break if they use that parameter in their code. Either way, this one sends you straight to customer service hell.
  8. Thou shalt never change the type of a returned object member. Although all data is exchanged over the wire as strings, changing the type of an object could have bad consequences based on the logic the client built on its side. For example, if you change type type of a field from Integer to Double, the code on the client side will probably choke on those decimals.
  9. When adding new enumeration values on a web service member, make sure they are not returned by old operations. This is one of the trickiest rules on the list (and we found it the hard way). Note that adding new enumeration values is not a Commandment on the list. The reason is that new enumeration values are typically not returned by old operations.  For example if an operation value helps you identify a given type of interest rate or currency, if your client’s “old code” does not know about this value, it will never request it and never expose the problem. But if an “old operation” can return “new enumeration values”, the client’s SOAP parser will fail on trying to interpret those new unknown values. If this is functionality you need to have, you’d better turn those enumerations into strings.
  10. Thou shall pray a lot before adding a new web service member. This is the only Commandment I wish did not make the list. The other ones make sense in a technical kind of way. This one really should not be. You should be able to add new web service members to your heart delight without anguishing over the consequences. After all, if a web service returns a new data element, the code on the other side does not know about it and should be able to simply ignore it. But the cold hard truth is that some parsers (Axis to be specific) will throw an exception when parsing new values returned by a service. The good news is that Axis plans to address this problem. The bad news is until then you will have to pray and notify your Axis users.

Making Composite Apps Work

I recently had the opportunity to meet with the senior IT management team of one of one of the countries’ largest commercial banks. This was an open, round table discussion involving multiple Silicon Valley startup companies who—like us—try to woo similar-sized enterprises into using their latest and coolest wares. The CTO started saying that in the old days, standard software was supposed to meet 80% of a firm’s need, with the remaining 20% requiring customizations to fit the firm’s process. “With packaged software these days”, he said “it is more like 50%/50%. This forces us to spend a lot of time customizing things, while we are actually trying to be more agile and more responsive to changing market conditions.”

This comment struck a chord with me. Many IT executives now understand that re-usable web services finally offer the promise to address those changing needs. Instead of buying a standard app that only does 50% of the job, the firm can build a custom application from re-usable web services. If you can buy most of the services you need, you get the best of both worlds: the fit of a custom app for less than the price of a standard app.

That’s all nice and good, but there is a big assumption built in: you must be able to purchase most of the services you need without having to customize them much. Otherwise you are back to where you started. And there lies the problem with the state of the web service industry today. Dana Gardner made it clear on his ZDNet blog last month: “There are either not many services available or the services are too general and not specific to a specialized vertical industry or a niche function.” Dana further states that 80% of those services need to be customized. This type of problem could seriously hamper the success of composite applications in IT America.

Since we have been delivering web services for a while, we saw that problem coming a while back. This is why we not only offer a broad and deep set of integrated web services sharply focused on a specialized industry and function (financial market and industry data–in case you did not notice), but we also engineer those services with the needs of the composite application designer and developer in mind. Our goal is to make those re-usable components so integration-ready that you just have to drop them “as-is” in your composite applications. We still have ways to go, but we will get

And what’s the payoff you say? Gardner again puts it best: “The higher [developers] can drive the percentage of reuse, the more scale and productivity they gain. They become the go-to organization for cost-efficient applications in a specific industry, or for specialized business processes.”