- occi-wg - lists.ogf.org

who is coming to the F2F
by Thijs Metsch 19 Nov '09

19 Nov '09

Hi, Just two short questions/polls: * If you're coming to the F2F on Friday meeting send a small +1 to the list, so we know and we can plan. * If you're unable to join us in person but would like to discuss something we can open the conference bridge :-) If you would like to discuss something send the topic and the best suitable time Thanks, -Thijs -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

14 19

Storage attributes
by Gary Mazz 18 Nov '09

18 Nov '09

1 0

Storage attributes
by Gary Mazz 18 Nov '09

18 Nov '09

1 0

concall in 20 minutes...
by Thijs Metsch 18 Nov '09

18 Nov '09

...sorry for the late announcement. We'll use the same conference bridge as always... -Thijs -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

1 0

Offtopic: Five competitive differentiators for cloud services
by Thijs Metsch 18 Nov '09

18 Nov '09

FYI (OCCI is in it *g*): http://news.cnet.com/8301-19413_3-10397874-240.html Cheers, -Thijs -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

2 1

Telecon Notes...
by Michael Behrens 12 Nov '09

12 Nov '09

Some draft notes from todays telecon attached. Let me know if content is inaccurate - thanks. - Michael Behrens R2AD

1 0

another OCCI RDF prototype
by Roger Menday 11 Nov '09

11 Nov '09

hi all, Seems a good time to publicise a very basic OCCI / RDF prototype put together a while back. http://fujocci.appspot.com/iamsecret/ As well as clicking through, you can also query your cloud from the SPARQL endpoint (click on 'search'). The following sample query should list all the compute resources. PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX occi: <http://www.ogf.org/occi#> SELECT ?c WHERE { ?c rdf:type occi:compute } it is possible to filter in the query, for example, to only return the live ones, etc. The following PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX occi: <http://www.ogf.org/occi#> SELECT ?s ?p ?o WHERE { ?s ?p ?o } should return *all* the triples. Quality pretty rough right now - for example, the states collection *should* change according to what it makes sense to offer - it doesn't. The other thing is that is it currently not possible to request the straight RDF representation. Both did work at some point ;( regards, Roger Roger Menday (PhD) <roger.menday(a)uk.fujitsu.com> Senior Researcher, Fujitsu Laboratories of Europe Limited Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE, U.K. Tel: +44 (0) 208 606 4534 ______________________________________________________________________ Fujitsu Laboratories of Europe Limited Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE Registered No. 4153469 This e-mail and any attachments are for the sole use of addressee(s) and may contain information which is privileged and confidential. Unauthorised use or copying for disclosure is strictly prohibited. The fact that this e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield does not guarantee that it has not been intercepted or amended nor that it is virus-free.

2 1

XHTML5 Rendering Proposal...
by Edmonds, AndrewX 11 Nov '09

11 Nov '09

Hi all, From the previous discussions had and agreeing in principle to OCCI providing a XHTML5 rendering, I'm submitting the following proposal [1] for the group's review. XHTML5 is used to make the representation machine readable and as it is well-formed any XML toolset can digest and manipulate it. Complimenting XHTML5 is the use of RDFa which is used to demarcate information that has semantic significance and in our particular case, used to expose attributes defined by the OCCI specification. The combination of XHTML5 and RDFa is a W3C recommendation [2]. Your thoughts are welcome as ever. Regards, Andy [1] Attached; source available here: http://code.google.com/p/occi/source/browse/docs/occi-xhtml5.xml [2] http://www.w3.org/TR/rdfa-syntax Andy Edmonds skype: andy.edmonds tweets: @dizz ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

7 9

Reminder: concall today
by Thijs Metsch 11 Nov '09

11 Nov '09

Hi, Today's concall will be at 4pm CET (Berlin). For your timezone have a look here: http://www.timeanddate.com/worldclock/meetingtime.html?month=11&day=11&year… I would propose that we discuss the proposal Andy and Sam have recently announced on the mailinglist. Hope the hear from all of you soon, -Thijs Passcode: Participant: 9032568 Dial in numbers: Country Toll Numbers Freephone/Toll Free Number ARGENTINA 0800-777-0463 AUSTRALIA ADELAIDE: 61-8-8121-4868 1-800-249-288 AUSTRALIA BRISBANE: 61-7-3102-0970 1-800-249-288 AUSTRALIA CANBERRA: 61-2-6100-1970 1-800-249-288 AUSTRALIA MELBOURNE: 61-3-9010-7739 1-800-249-288 AUSTRALIA PERTH: 61-8-9467-5249 1-800-249-288 AUSTRALIA SYDNEY: 61-2-8205-8125 1-800-249-288 AUSTRIA 43-1-92-86-506 0800-005-029 BELGIUM 32-1-150-0314 0800-4-8680 BRAZIL 0800-7610674 CHILE 1230-020-2867 CHINA* 86-400-810-4766 10800-712-1433 10800-120-1433 COLOMBIA 01800-9-156430 CZECH REPUBLIC 420-2-25-98-56-54 800-700-173 DENMARK 45-7014-0280 8088-6132 ESTONIA 800-011-1089 FINLAND Land Line: 106-33-146 0-800-1-10100 FINLAND Mobile: 09-106-33-146 0-800-1-10100 FRANCE LYON: 33-4-26-69-12-81 080-563-9647 FRANCE MARSEILLE: 33-4-86-06-00-81 080-563-9647 FRANCE PARIS: 33-1-70-70-74-20 080-563-9647 GERMANY 49-69-2222-2566 0800-000-3441 GREECE 30-80-1-100-0683 00800-12-6973 HONG KONG 852-2286-5731 800-930-705 HUNGARY 06-800-18013 INDIA 000-800-852-1266 INDONESIA 001-803-011-3787 IRELAND 353-1-247-5253 1800-932-145 ISRAEL 1-80-9214916 ITALY 39-02-3600-3642 800-986-570 JAPAN OSAKA: 81-6-7739-4769 0034-800-400828 JAPAN TOKYO: 81-3-5539-5189 0034-800-400828 LATVIA 8000-3025 LUXEMBOURG 352-27-000-1360 MALAYSIA 1-800-80-2812 MEXICO 001-866-627-0574 NETHERLANDS 31-20-718-8533 0800-020-1392 NEW ZEALAND 64-9-970-4769 0800-449-823 NORWAY 47-21-59-00-59 800-15414 PANAMA 011-001-800-5072129 PERU 0800-53733 PHILIPPINES 63-2-858-3715 POLAND 00-800-1212021 PORTUGAL 8008-14061 RUSSIA 8-10-8002-9683011 SINGAPORE 65-6883-9228 800-120-4662 SLOVAK REPUBLIC 421-2-322-422-21 SOUTH AFRICA 080-09-80416 SOUTH KOREA 82-2-6744-1081 00798-14800-6860 SPAIN 34-91-414-62-98 800-099-810 SWEDEN 46-8-505-78-524 0200-890-106 SWITZERLAND 41-44-580-4389 0800-001-523 TAIWAN 886-2-2795-7377 00801-137-766 THAILAND 001-800-1206-65656 UNITED KINGDOM BIRMINGHAM: 44-121-210-9021 0808-238-6025 UNITED KINGDOM GLASGOW: 44-141-202-3221 0808-238-6025 UNITED KINGDOM LEEDS: 44-113-301-2121 0808-238-6025 UNITED KINGDOM LONDON: 44-20-7075-3246 0808-238-6025 UNITED KINGDOM MANCHESTER: 44-161-601-1421 0808-238-6025 URUGUAY 000-413-598-3415 USA 1-203-418-3122 866-692-3163 VENEZUELA 0800-1-00-3733 -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

1 0

The Top 10 Most Common API Pitfalls
by Sam Johnston 09 Nov '09

09 Nov '09

Morning all, An interesting article by Boomi's CTO just popped up on TechCrunch that touches on many of the ways one can go wrong when creating an API. We're doing well with each of these points, except perhaps rate limiting which doesn't sound like a core concern anyway (rather an extension). Sam The Top 10 Most Common API Pitfalls<http://www.techcrunchit.com/2009/11/08/the-top-10-most-common-api-pitfalls/> *This is post was written by TecCrunchIT guest author Rick Nucci,<http://www.crunchbase.com/person/rick-nucci> the Co-founder and CTO of enterprise integration technology company Boomi.<http://www.crunchbase.com/company/boomi>Prior to forming Boomi Inc., Rick worked for EXE Technologies.* A robust application programming interface (API) has become essential for today’s successful SaaS independent software vendors (ISVs). As a SaaS vendor, you should expect that a majority of your customers are going to require interoperability with other SaaS applications, web services, and legacy systems. As demonstrated by internet pioneers Google, Amazon, and Facebook, an open application strategy facilitates deeper customer usage and enables new revenue streams. Integration is critical for SaaS vendors, and developing a reliable API strategy is the first step toward achieving that goal. Unfortunately, many ISVs still treat their API as an afterthought or merely a “checkbox” on their project list rather than a core feature of their solution. As a result, APIs are not well designed or properly built and wind up costing both the vendor and its customers tens of thousands of dollars in ongoing maintenance due to infrastructure costs and the drain on engineering resources. After reviewing hundreds of actual SaaS APIs, many up to par and others distinctly subpar, it is clear that there are a number of common mistakes made when developing an API. Fortunately, each of them can be easily remedied by following best practices. *1. Exposing operations instead of objects* *Impact:* Bloated call proliferation. By exposing operations, the number of calls your API has to support will balloon up to 4-5 x the number of objects in your application. What’s more, if more than one resource is building your API, there is a bad habit of inconsistent naming conventions, i.e. “addCustomer” and “insertItem” will exist in the same API. *Remedy:* Consider schemas for each object you support, and a common set of actions that can be performed against those objects, i.e. add(), update(), delete(), query(), and of course upsert(). Don’t forget about this often overlooked action, it will significantly reduce the IO against your API because they ‘check for this, then do this’ logic is inside your API tier vs. invoked by the client. This forces all of your developers to follow a consistent set of actions and think about the implications of those actions against a particular object versus designing arbitrary actions against their objects in a vacuum. Following this advice will also drastically improve the readability of your API. *2. Assuming a WSDL contains everything necessary to describe your API* *Impact:* To support the dynamic nature of your API, you either end up doing a blended WSDL/meta data API combination, or you contort and stretch the limits of your WSDL such that most web service toolkits cannot support it. *Remedy:* Keep in mind that WSDL was designed under the assumption that your API call was static, and not multi-tenant. The reality is the majority of your customers are probably customizing their tenant of your app, and those customizations need to appear in real time in your API. This is, from an integration perspective, one of the huge strengths SaaS apps have over their on-premise enterprise competitors. In the on-premise world, the APIs of those applications were either non-existent or at best completely disconnected from any customizations made to the application itself. Consider offering explicit metadata descriptor calls and in these calls return both your base schema for a given object along with any customizations made by the customer back to the user. Try denoting the custom fields with a consistent naming convention, or a dedicated section within each object. *3. Developing a single version of your API which changes with each release of your SaaS application* *Impact:* Your customers get on the “API treadmill” which requires that they repeatedly have to test their integrations with each release of your application. This will inevitably lead to push back from the customer base which may result in pressure to reduce the frequency of your product releases. *Remedy:* Think of your API as a contract between you and your customer. Once you release it, that specific version needs a SLA guaranteeing compatibility to it for some extensive period of time (years). As you release new versions of your application, version your API also. You can include the version number of the API as part of any URL request made against it. *4. Never batching or throttling the results of query calls against your API * *Impact:* Your application performance degrades, resulting in a substandard experience for your API users as well as your web users. You will also likely face unexpected increases in infrastructure costs to support unpredictable demands on your usage. *Remedy:* Put throttling in front of all of your API calls. There are specialists in this area, such as Mashery, that can proxy all of your API calls and enforce this behavior for you. Typically, experts recommend a time based throttle such as X-thousand calls per hour/day. You can also consider charging for additional throttling needs. However, this should not be viewed as a margin-based revenue source and instead should be viewed as a cost-protection revenue source. By charging a premium, you can offset the cost of the existing infrastructure needed to support their requirements. Fortunately, this is also becoming less of an issue due to the advent of elastic computing capabilities a number of cloud providers now offer because your API infrastructure can expand and contract inline with demands. Additionally, for any API call that can return an unpredictable number of results, consider returning those results in pages or groups of some reasonable number, along with a marker that your caller can use to iterate your pages as they see fit. *5. Maintaining separate schemas for adding, updating, or removing your Customer object* * Impact:* Creates the perception of inconsistency and complexity in your API. A Customer, Product, Employee, Invoice, etc. is what it is, regardless if you are adding it, changing it, or removing it. *Remedy:* Have a single schema for each object type. If you do not allow certain fields to be changed in your application once a record has been added, then either throw an error if the users pass in a value for this field (ideal) or ignore the contents of any field that cannot be modified. *6. Forcing the user to specify the data type of fields being passed into your API* *Impact:* You are creating an unnecessary dependency on documentation. And the problem carries forward not just to the initial user of the API, but in the ongoing changes to the underlying schemas that result from customization and product enhancements. * Remedy:* Provide the most relaxed data type restrictions possible and clearly type fields that restrict format patterns, such as a date/time field. An overarching goal when designing your API is to have to write the least amount of documentation possible and instead expose maximum metadata about your API through the use of explicit descriptor calls. *7. Using session-based security in your API* *Impact:* By forcing a session to be created and re-used, things like long running queries need to be contemplated and they are typically not, resulting in sessions being terminated mid-transaction. *Remedy: *Use a standardized sessionless security model like HTTP basic authentication or WS-Security with Username/Password token. Try to avoid implementing a proprietary authentication model like username/password in the SOAP headers or username/password in the body of the data being sent to the application, as this is not discoverable programmatically. Using sessionless security is a convenience for the user as well as provides easier scalability on the server side. This allows requests from the user to be routed to any server in the data center without needing to share sessions between them. Also, by avoiding any login orchestration it is easier to get other websites to access your API so they can do mashups. *8. Not providing a way for your user to know when a record was modified* *Impact:* Your users cannot capture “deltas” or changes to your data over time. This forces them to do bulk extracts out of your application, causing significant inefficiencies and detrimental performance impacts on your application. *Remedy: *Modification tracking is critical any time data in your application needs to be synchronized with another application. This is almost always a requirement with master data, i.e. Customer, Product, Employee, Vendor, etc., as this information is core to your customers’ business and will almost always be represented across all of the key applications they use. By exposing when a record was changed, and who changed it, external processes can capture this information and only extract the changes since the last sync vs. a full extract. *9. Charging extra for your API and not including it for free as part of your offering* *Impact:* An API is never viewed as an “add on” feature by your customer, it is viewed as a “get in the game” feature. In most cases it is needed for parity against your competition, not differentiation. As a result of this expectation, you may end up in an unnecessary and risky negotiation with your prospects. *Remedy:* Make your API free with every edition of your offering. Tout your commitment to openness and encourage your users to explore your API, even during their trial period. You will earn loyalty points with your customer and the message of confidence you exude with this positioning will make you friend vs. foe in the developer community. *10. Getting caught without an API strategy* *Impact:* You are likely losing deals to your competitors and worst case you are not even aware that the lack of API is the reason. You will be perceived as “legacy” and “closed” and “proprietary”. * Remedy:* Beyond the obvious suggestion which is to “build an API!” and from the outset, treat your API as a core part of your product and not an assignment you give the summer intern. Ensure that the API is represented by product management, and put strong resources on the engineering of that API. Consider this: salesforce.com reports that their API gets more traffic than their application! *Conclusion* Unlike the enterprise application era when applications were kept closed and proprietary, the success of today’s SaaS applications depend upon being open and interoperable. ISVs should view their APIs as not just a means of integration but in fact as a way to syndicate their capabilities to a much broader audience – a channel to market as it were. As such, implementing a well conceived and well designed API is arguably as paramount to the success of your business as developing the base application itself. Following the guidelines above should help in maximizing your success as you design, build and implement your API.

1 0