Oracle has taken over a lot of companies during the last few years. Looking back (hindsight is always easy) it shows a very clear strategy. All - or at least most - of the acquisitions have added one or more capabilities to the SOA technology stack that Oracle was building. To say the least: I'm very impressed with that strategy.
The announcement of the Database Machine and the Oracle Exadata Storage made me wonder where Oracle is taking this now. Will they not only acquire for technology but now for hardware as well? Michael Dell might start to get worried .....
Saturday, 27 September 2008
The Future According to Oracle
I'm getting very mixed messages from Oracle, especially here during Oracle Open World. To say the least: I was very surprised when Oracle announced the conversion/migration from Forms to APEX, while at the same time stating that APEX is 'only' for localized applications and while pushing forward on SOA.
In a way I do understand the reasoning behind it. There's so many people out there still relying on Forms and sort of afraid of going down the SOA path. To get these customers move over to APEX will at least mean that they will stay customers of Oracle. However, APEX is no SOA, in fact it is contradictory to SOA, as it is based on a very strong coupling from the front-end to the database.
This development, coupled with the fact that a lot of small and medium businesses find the Oracle product line a bit too expensive for their taste, might lead to a kind of splitting of the market. SMB goes APEX, the rest goes SOA? Or am I just being too cynical .....
In a way I do understand the reasoning behind it. There's so many people out there still relying on Forms and sort of afraid of going down the SOA path. To get these customers move over to APEX will at least mean that they will stay customers of Oracle. However, APEX is no SOA, in fact it is contradictory to SOA, as it is based on a very strong coupling from the front-end to the database.
This development, coupled with the fact that a lot of small and medium businesses find the Oracle product line a bit too expensive for their taste, might lead to a kind of splitting of the market. SMB goes APEX, the rest goes SOA? Or am I just being too cynical .....
Wednesday, 24 September 2008
Service Contracts
A while back I wrote a blog about the WSDL, mainly about the fact that it is not quite what we need to describe the service contract. Last night we had a get-together of Oracle ACEs and Oracle ACE Directors, where we discussed a lot of topics. One of the topics was about the Service Contract.
The discussion focussed on whether or not you need to have things like binding, security and policies in a Service Contract. Soon we found out that you need to forget the WSDL when you're entering such a discussion, because it muddles the discussion.
At 1.30 this morning we quit the discussion, without having reached a consensus. However, it did clear my mind as to my opinion on this matter.
What we do need in a Service Contract is:
- Definition of the interface
- Definition of the Service (what functionality will be delivered, ie what does it do?!)
- Service quality (QoS, SLA, etc)
- Applicable policies
- Allowable bindings
However, this is about the external contract. This does NOT mean that it is all IN the service. For example: adherence to company policies is obviously a matter of importance. However, security and policies are things you should not worry about in a service, but should add to the service before deploying it. It should be decoupled, so that changes in company (security) policies do not lead to changes in the implementation of a service.
As the discussion is not finished, expect me to get back on this real soon. I urge all my readers to comment on this! Would be nice if we could come up with a definition.
The discussion focussed on whether or not you need to have things like binding, security and policies in a Service Contract. Soon we found out that you need to forget the WSDL when you're entering such a discussion, because it muddles the discussion.
At 1.30 this morning we quit the discussion, without having reached a consensus. However, it did clear my mind as to my opinion on this matter.
What we do need in a Service Contract is:
- Definition of the interface
- Definition of the Service (what functionality will be delivered, ie what does it do?!)
- Service quality (QoS, SLA, etc)
- Applicable policies
- Allowable bindings
However, this is about the external contract. This does NOT mean that it is all IN the service. For example: adherence to company policies is obviously a matter of importance. However, security and policies are things you should not worry about in a service, but should add to the service before deploying it. It should be decoupled, so that changes in company (security) policies do not lead to changes in the implementation of a service.
As the discussion is not finished, expect me to get back on this real soon. I urge all my readers to comment on this! Would be nice if we could come up with a definition.
Safe Harbor
One of the running gags here is 'May or May not'. There's hardly any statement made by an Oracle employee that doesn't start or end with it. Of course I'm exaggerating, but we do hear it a lot these days.
Especially around the Database there's some buzz going around. So I'll expect some announcement to be made later today during Larry's keynote. Well, whether or not he does, a Larry Ellison keynote is usually fun to see. Not to be missed!
Especially around the Database there's some buzz going around. So I'll expect some announcement to be made later today during Larry's keynote. Well, whether or not he does, a Larry Ellison keynote is usually fun to see. Not to be missed!
Monday, 22 September 2008
OOW off to a good start!
This morning Oracle Open World started off with keynotes from Charles Phillips and Chuck Rozwat. Again it's fabulous weather during OOW, thousands of attendees on the streets between Marriot and Moscone, and the smell of expectancy in the air. I do expect some announcements these days about new releases and new strategies. Time will tell!
Anything interesting that comes up in the next few days, I will certainly report on here. Right now, I've got to hurry to get to my next assignment: ACE Office Hours in the OTN lounge. Maybe I'll see you there?
Anything interesting that comes up in the next few days, I will certainly report on here. Right now, I've got to hurry to get to my next assignment: ACE Office Hours in the OTN lounge. Maybe I'll see you there?
Thursday, 11 September 2008
Mud Slinging and the Enterprise Service Bus
The last few weeks I've been reading up on the Enterprise Service Bus (ESB). I can tell you: it was an amazing journey. I started out with the book by David Chappell and from then on went to IBM DeveloperWorks which is usually a good spot to get technical info. These two sources combined give a nice overview of what an ESB could offer you, and how to put it to use.
That was not enough. I needed more information, especially on what an ESB really is and how to fit it into our architecture. So I looked at a couple of Blogs around the ESB and the Mediation patterns. What surprised me was the number of discussions and especially the tone of them. It seems the whole ESB discussion has degraded to a kind of mudslinging between different fundamental groups. One group states that the ESB is an architectural monstrosity which is not needed whenever the initial design of the service constructs adhere to standards of good design. The other group argues that there will never be such an environment. Oh btw, both groups think they hold the truth, the whole truth and nothing but the truth. Well, what else is new?
I think I understand where this argument is coming from. Just have a look at the ESBs that vendors today deliver. Probably the only thing they have in common is the name and the fact that it can do some routing and transformation. There the resemblance ends. In short, there's no clear definition of what an ESB is or does.
If I look at the architectural concepts that I found during my search, especially mediation, integration and security, there's a lot to be said about using these patterns. If you can find a tool (whether or not it is called an ESB) that fits your needs now and in the near future, why not use it?
So in my opinion, there's definitely a case to be made about an 'ESB'. Just don't know yet exactly what should be in there and what not .....
That was not enough. I needed more information, especially on what an ESB really is and how to fit it into our architecture. So I looked at a couple of Blogs around the ESB and the Mediation patterns. What surprised me was the number of discussions and especially the tone of them. It seems the whole ESB discussion has degraded to a kind of mudslinging between different fundamental groups. One group states that the ESB is an architectural monstrosity which is not needed whenever the initial design of the service constructs adhere to standards of good design. The other group argues that there will never be such an environment. Oh btw, both groups think they hold the truth, the whole truth and nothing but the truth. Well, what else is new?
I think I understand where this argument is coming from. Just have a look at the ESBs that vendors today deliver. Probably the only thing they have in common is the name and the fact that it can do some routing and transformation. There the resemblance ends. In short, there's no clear definition of what an ESB is or does.
If I look at the architectural concepts that I found during my search, especially mediation, integration and security, there's a lot to be said about using these patterns. If you can find a tool (whether or not it is called an ESB) that fits your needs now and in the near future, why not use it?
So in my opinion, there's definitely a case to be made about an 'ESB'. Just don't know yet exactly what should be in there and what not .....
Subscribe to:
Posts (Atom)