What is REST?

REST (Representational State Transfer) is a term often used in software engineering when talking about services or other API's. A lot of these so-called RESTful services or interfaces are not RESTful at all. Even the author of REST gets frustrated by the common misuse; http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven: "I am getting frustrated by the number of people calling any HTTP-based interface a REST API.". REST is often confused with an application of REST to HTTP and URI (uniform resource identifier). An URI is a unique identifier to identify a web resource. HTTP is a transport protocol used to interact with the web resource. REST however is a bit more then just that. The division between resource identification and resource interaction is important. The application of REST uses the URI to identify a concept. In this blog post I will elaborate a bit more on REST while trying to avoid literally repeating other sources like Wikipedia. I will also provide some background and examples I found during my short study of the concept. In addition, this post will be introductory to other more (Oracle) implementation focused articles.

MockServer: Easy mocking of HTTP(S) services (e.g. SOAP or JSON)

Testing services as an atomic entity can be difficult. Especially if these services are part of a call chain or call other services. Often in such cases mock services are developed to reduce test dependencies and exclude services which are not interesting to the specific test case. For example, I'm testing service A. Service A calls service B. I'm not interested in service B (or service B is maintained by another department on which I don't want to depend). I would mock service B when testing service A in this case. There are several methods to create mock services. These methods however are mostly not easily usable by testers since they require developing/coding mock services. Testers would benefit from being able to create their own mock services in order to create different tests for a specific service.

In this blog post I provide a brief introduction and describe some features of MockServer. An open source product which can be used to mock services. For a more detailed article (with more examples) you can look at the following written by my colleague Robert van Mölken: http://technology.amis.nl/2014/03/06/functional-boundary-testing-of-a-service-based-environment-using-mockserver/

The below image was taken from http://www.mock-server.com/

Comparison of Jenkins and Hudson: Options for sharing configuration among projects

Continuous Delivery is a practice which follows from the principles behind the agile manifesto (http://agilemanifesto.org/principles.html); 'Our highest priority is to satisfy the customer through early and continuous delivery of valuable software'. Continuous Integration is a part of the process of Continuous Delivery in which source code changes are integrated and tested frequently in an automated way. Hudson and Jenkins are two products which can be used to implement Continuous Integration. These tools provide build job management, security, integration for products providing reporting capabilities, integration with version control and numerous plugins are available to provide additional functionality.

Hudson and Jenkins share a history. Sun Microsystems was the owner of Hudson. Oracle took over Sun Microsystems. Some friction ensued between the original developers of the product and Oracle. Since Oracle applied for the trademark in 2010 but was not the most contributing party, several developers decided to rename/fork Hudson and Jenkins was born. Since then the projects have diverged.

In this blog post I will look at how job configuration can be reused among projects in Jenkins and Hudson. Since the projects have diverged, the solutions provided will differ. Jenkins provides the Inheritance Plugin (https://wiki.jenkins-ci.org/display/JENKINS/inheritance-plugin) and the Template Project Plugin (https://wiki.jenkins-ci.org/display/JENKINS/Template+Project+Plugin). Hudson provides a core feature called Cascading Projects (http://www.eclipse.org/hudson/the-hudson-book/book-hudson.chunked/ch06.html#section-cascading-project).

Hudson Cascading Job configuration

Controlling BPEL process flow at runtime

When using Oracle BPEL it is often desirable to allow a certain amount of configuration of the process flow at runtime. To allow configuration, properties/preferences/parameters can be used. These can be implemented in various ways. Lucas Jellema has described a method in the Oracle SOA Suite 11g Handbook (http://www.amazon.com/Oracle-SOA-Suite-Handbook-Press/dp/0071608974 page 252) for system parameters which uses Business Rules. In this blog post I compare three other methods; using Domain Value Maps, using BPEL preferences and using a database table. I look at performance, development, re-use potential, updating the preference at runtime and when to use which method.

The Jenkins Build and Delivery Pipeline plugins

Continuous Delivery (CD) is a design practice used in software development to automate and improve the process of software delivery (http://en.wikipedia.org/wiki/Continuous_delivery). Continuous delivery uses the notion of a deployment pipeline in order to validate code. At an abstract level, a deployment pipeline is an automated manifestation of your process for getting software from version control into the hands of your users (http://www.informit.com/articles/article.aspx?p=1621865&seqNum=2). How can such a deployment pipeline be implemented?

In this blog post I'll describe the setup of my environment and my first experience with the Jenkins/Hudson Build and Delivery Pipeline plugins. What it can do to help implement a deployment pipeline and what it won't do for you.

(https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin)

(https://wiki.jenkins-ci.org/display/JENKINS/Delivery+Pipeline+Plugin)

Using the Java embedding activity in BPEL to gain more Composite information and control

Java can be used to extend functionality provided in Oracle SOA Suite BPEL. For example to interface with technologies for which there is no adapter available or to provide more specific functionality as is provided by the standard available activities. In this blog post I'll describe an example of how a composite can control its own state by using Java embedded code.

This mechanism can for example be used in exception handling implementations to retire a composite in case of errors.

Oracle SOA fault handling with ordered guaranteed delivery using BPEL, JMSAdapter, custom JMS headers, JMS message selectors, a JMS topic and durable subscribers

In this blog post I will demonstrate an error handling mechanism which can be used to achieve guaranteed delivery of messages in a specific order. To implement this I have used Oracle SOA Suite 11g, BPEL 2.0. The method described however can also be implemented by other technologies/languages. The method used is different from (as far as I know) previously described methods to implement exception handling in Oracle SOA Suite. A single JMS topic is used and JMS message selectors based on custom JMS headers are used by clients. By using a JMS topic, the services are loosely coupled. This method also allows tracing of flows over the topic in the Enterprise Manager Fusion Middleware Control (when Oracle SOA Suite is used). A screenshot of this mechanism implemented is shown in the screenshot below. It will be explained in more detail below.