My initial idea was to write an article on the similarities and differences of BPEL (relatively new to me) and PL/SQL, BPEL being one option for an environment or XML-based language for defining services (What services? I’ll describe an example later…), PL/SQL being the procedural programming language that comes with Oracle (one understatement, sorry).
But hang on! If I wrote an article like that then I would assume that everybody knows PL/SQL. Well, they don’t. This article is therefore not just directed at programmers, but at anyone who wants to learn a little bit more about SOA, BPEL and Services.
When I was first introduced to the term “Services†in terms of software development I knew it wasn’t about services that you get at the next petrol station. Yet, I hadn’t realised that I myself had actually worked with services. So when people were talking about Services, or SOA, then I basically thought I still had to learn a lot (which I do, but never mind…). Until on a bright and sunny day I was talking to one of my colleagues, a very knowledgeable analyst, who pointed out to me that along with her I had worked with SOA, too, but only on the (Oracle) database side. This meant that in my activities at the time as a programmer I prepared messages, XML messages to be precise, that were sent from an Oracle database to … well, to what?
To be honest, I didn’t know. Well, I knew a little. They ominously kept calling it Tibco. Let’s – for the sake of argument – just call it a service.
Some explanation is in place, to set the context: in this particular case I was trying to maintain an application where it was important to establish that a client who was about to take out a mobile phone subscription was solvent (enough). For the purpose of checking this, “my†application checked with an institution, known as BKR, whose main duty is to keep a log of anybody who has some kind of debt in the Netherlands. BKR then reported back whether they knew of any restrictions to allow our (potential) client to have the required subscription or not.
For this purpose BKR needed some information that they accepted as input. Major data here were the client’s name, postcode and date of birth. If this information was given to BKR they would return a code to us indicating the client’s solvency. In addition, BKR would tell us that this status was valid until a certain date.
What is described here could be called a service, or: BKR had made available a service that my application could use. So my smart analyst colleague was correct. I had indeed been working with Services, or SOA.
The aim of my contribution to this blog is to explain that whenever SOA is mentioned, it could be exactly what I described above. SOA is a concept, no more, no less. SOA is not a technology, or a piece of software. It is an architecture, a model.
On a practical note, there are many different methods of SOA implementations available. Part of one that I am currently trying to study is the database adapter, which is really not a service, but a service component. This implies that a database adapter may exist independently, but as such will not serve any purpose. It needs to be called by something else, like a BPEL process, to be part of a sensible, useful process.
My challenge at the moment is to find out what would happen if a date (as in a Date datatype) were not defined properly. In the BKR process that I described above, one of the parameters (the piece of information that BKR needs to be able to render a sensible Service) is the date of birth. What if this date is not delivered properly? What if a person was not born on May 12, 1951 but on December 5, 1951? How does this system of database adapters deal with date formats that vary per country? What is the influence of NLS_PARAMETERS?
BKR being a Dutch institution is likely to use the Dutch way of formatting a date. But what if an American company wants to use this service and adheres to American date formatting? What if a service request comes in at BKR from a country in another time zone? Would it matter?
I hope this piece of text has been useful, informative and maybe somewhat revealing for anybody who is interested in Service Oriented Architecture. Needless to say, SOA is not an architecture that is restricted to Oracle, though in our line of work we tend to concentrate on Oracle (and Java) tools.
