The Oracle Service Bus day 1 and day 2 where very interesting. We covered the following things :
- Validation
- Dynamic routing
- Java callout
- service callout
- The Transport Typed services (ejb and flow)
- Reporting and Logging (debugging)

These things are also covered in the best book to read about Oracle Service bus : The Definitive Guide to SOA: Oracle® Service Bus, Second Edition

The teacher gave us a couple of tips about books to read about integration with Oracle Service bus. The first book is about XQuery. This is a query language on XML (on top of Xpath). If you are interested in the book, you can get it here : XQuery

The next book is about Enterprise Integration Patterns. You can get it here : Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley Signature Series)

Overall the course was very good, the teacher answered a lot of technical questions. In our class where 10 people. For the assignments there was a computer available for the students.

Today was the first day at the Oracle Service bus Integration and Design training, located in The Meern, nearby Utrecht in The Netherlands. Things we learned today where :
- What is a business service,
- What is a proxy service

- We did two exercises, about configuring messageflow, plus an extra assignment. The extra assignment was creating a proxyservice which polls a JMS queue and write a file on the filesystem. Learned that it is possible to put a test message on the queue from the console (didn’t know this).
We also had a discussion about versioning of services in a SOA. In the book The Definitive Guide to SOA: Oracle® Service Bus, Second Edition written by Jeff Devies, some theory about versioning about services is written. Pretty good book about implementing SOA using Oracle Service Bus.

Friday we will continue the talk about versioning of services in SOA.

At my current project, we deliver a lot of services in the Oracle Service bus. When a service goes into production, how do you maintain those services ? What do you do when new business requirements needs to be implemented on the service, or what do you do when you need to fix a bug ?

I think when this questions arise, you need to think about versioning of your services. Last week I had a talk with a colleague about naming conventions on services, his opinion is that services have a version number in the name of the service.

So, what are the situations when a services needs to be changed ? In fact there are at least the next 2 situations :

1 – Things you didn’t know at design time, so when the service goes into production, somethings needs to be changed in production.
2 – Business requirements, the services is changed functional, what to do in this situation ?

In situation 1 the service needs to be fixed, so it’s ready to go through the OTAP, but what about situation2 ? In sitation2 the service in production will still be used by different consumers. When the service is changed in behaviour or interface, the current consumers can not use the new service. You can not expect from the consumers that they will change their system so it can use the new service.

For situation 2, version numbering of the service is essential. For instance, in production you will have CustomerService_V1.0, a business change of this service will result in a CustomerService_V1.1.

You can think of a situation that a bug fix will also result in a business change of interface change of the service. In that case a new version number is nescessary. Keep in mind that you need to inform the owners of the consumer systems about the fact a service will be changed.