Doorgaan naar hoofdcontent

Posts

Posts uit 2014 tonen

API Management

I currently work for a customer that wants to expose its "services" to partners and other external consumers. They do not want to build websites themselves anymore, but instead have the services published and used by partners. So how can this be done? Always curious and looking for good solutions i started to think about this. I saw one of the following options: Just expose the (web)services through a web gateway and use http basic authentication over SSL for security Make REST adapters and expose those  Requirements  However soon i also discovered: Consumers have to be managed. You have to manage the client credentials. For a few consumers this is doable, but for a couple of hundred or thousands this can be cumbersome Consumers have to find the services somewhere. What is the functionality of those services? Is it soap or REST based? Consumers want to test the services within a sandbox before actually using them As a service provider you have to manage the

OpenText Innovation Days 2014 in Eindhoven

Yesterday i visited the OpenText Innovation Days in Eindhoven. This event was held in the Evoluon, which in the early days was an exhibition hall for future products. This was the first place where i ever listened to a CD. Nowadays it is a nice conference place. The event was all about data / content / information in other words Enterprise Information Management ( EIM ). This is understandable because there is where OpenText is at its best, but due to some recent acquisitions they have a nice complete portfolio now to help customers innovate and be agile. Project RedOxygen OpenText has done a lot of acquisitions lately and the project RedOxygen is integrating all these produkts, so that consistent and integrated suites are developed. This leads to the fact that all suites will have the same look-and-feel eventually. The suites can integrate easier with each other. For example with the AppWorks  component suites are accessible through a RESTfull API.  Suites OpenText

Mobile is Hot ! But be aware ...

I see it in a lot of projects but also I see that it is handled just like testing in the beginning: "oh we estimate some extra days and we also go Mobile !" Of course this is not the case, it can be a project on its own. There are a lot of choices to be made, some of them are: Which mobile platforms do we have to support? What are the performance requirements? Do we want to develop once, run anywhere? Do we want to use native functions of the mobile OS? What I also see, is that more and more BPM/Integration platforms are going to support it. But then again the Mobile experience is somewhat different than the Browser (and Desktop) experience. So depending on the requirements of the Mobile App, the platform can suffice or not. I will shortly describe some platform examples. OpenText Assure This is a BPM platform that supports Mobile. However the UIs are running within the browser app of the mobile device. The advantage is that it is developed once, and

Book review: Continuous Delivery and DevOps: A Quickstart Guide

Introduction I wanted to know more about DevOps because I agree with the fact that we need to coorporate more and remove the barriers between departments. In the end I was a little disappointed by this book. It gives some high level tools and techniques but it could be much more ... In my opinion a change would be that someone from Operations will really participate within the project team and looks at it from an operation point of view. This way also these requirements will be taken into account and the system will be more easy to operate. However there were also some interesting chapters so lets review. Chapters The book contains 7 chapters: Evolution of a Software House No pain, No gain Plan of Attack Tools and Technical Approaches Culture and Behaviors Hurdles to Look Out For Measuring Success and Remaining Successful Chapter 1 - Evolution of a Software House As the name already suggests, this chapter is about the evolution of a software house. First it