Yahoo! Soon we will be able to modify running BPEL instances.
Ever since I started to work with BPEL, we ran into the problem that when you upgrade a BPEL process to reflect a changed situation, you will have to think about how to handle the already running instances. There were not many options: you either let them run their course or aborted them to restart them with the new version.
In our case we had a lot (15.000+) of rather long-running processes (up to 14 months). So you can imagine both options were not very attractive. Yesterday I had an upgrade about the upcoming Oracle SOA Suite 11g. The very good news was that in Oracle BPEL 11g you are able to modify already running instances. That is very very good news indeed.
It will have some limitations however, but that has more to do with the structure of the process. You will have to think about where you will allow any modification on running instances.
Tuesday 2 December 2008
Monday 13 October 2008
A Must Read!
Last week, at the International SOA Symposium in Amsterdam, Thomas Erl launched two new books which I think are a must read for any serious SOA practitioner. The first one to be launched was Web Service Contract Design & Versioning for SOA, which I've started reading already. It's a massive book (again), but so far I'm impressed. Easy to read, good examples, definitely worth the time reading it.
I'm even more eager for the second book that was announced: SOA Design Patterns. Unfortunately this book is still on its way from Amazon to my home, so I cannot give any insights, but I do expect a lot from it. As Thomas explained during his presentation at the International SOA Symposium, it consists of 85 real-world, real-practice design patterns. One of the nice things with this book is, that there's a website along with it, containing all the 85 design patterns, but also the candidates that didn't make it into the book. If you have a design pattern you think should be in the book, publish it on the site, and maybe it'll be in the next release ....
For more information go to Thomas Erl's SOA Books website.
I'm even more eager for the second book that was announced: SOA Design Patterns. Unfortunately this book is still on its way from Amazon to my home, so I cannot give any insights, but I do expect a lot from it. As Thomas explained during his presentation at the International SOA Symposium, it consists of 85 real-world, real-practice design patterns. One of the nice things with this book is, that there's a website along with it, containing all the 85 design patterns, but also the candidates that didn't make it into the book. If you have a design pattern you think should be in the book, publish it on the site, and maybe it'll be in the next release ....
For more information go to Thomas Erl's SOA Books website.
Saturday 27 September 2008
Will Dell Be Oracle's Next Acquisition?
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 .....
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 .....
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 .....
Friday 22 August 2008
Oracle ACE Office Hours
Will you be visiting Oracle Open World this year? When you do, make sure to free up some time to visit the ACE's. Every day they will hold office at the OTN Lounge in Moscone West (3rd level). Sort of like a roundtable, advice session or a "live" discussion forum thread-- however you want to view it.
What: Oracle ACE Office Hours
Where: OTN Lounge, Moscone West, 3rd Level
Oracle ACE Office Hours:
Monday, September 22
12:00 – 1:30 and 4:00 – 5:30pm
Tuesday, September 23
12:00 – 1:30 and 4:00 – 5:30pm
Wednesday, September 24
12:00 – 1:30 and 4:00 – 5:30pm
Thursday, September 25
11:00 am – 12:00 pm
I'll be there!
What: Oracle ACE Office Hours
Where: OTN Lounge, Moscone West, 3rd Level
Oracle ACE Office Hours:
Monday, September 22
12:00 – 1:30 and 4:00 – 5:30pm
Tuesday, September 23
12:00 – 1:30 and 4:00 – 5:30pm
Wednesday, September 24
12:00 – 1:30 and 4:00 – 5:30pm
Thursday, September 25
11:00 am – 12:00 pm
I'll be there!
Monday 28 July 2008
Growing Pains
It’s not hard to build an SOA. That is, technically. Once the domains are clear and the services defined, it’s kinda easy to implement. Sure, there’s lots of work to be done, but no rocket science. But, what happens after you’ve done your Proof of Concept and your first and maybe even your second real-life project?
By then you’re sitting on top of a lot of services, of different granularities and of different types, all mixed together. If you’re lucky, the semantics are still correct (no mismatches yet!). Maybe you even have an ESB running. Slowly but surely the need for additional tooling becomes evident. How are you going to manage this whole environment? How are you going to make sure the next project reuses the generic services that have been so painstakingly defined?
A logical first step would be to get a UDDI, where you can at least register your services. Usually this is not a tool that you would implement in your first project, as you do not yet have the need for location transparency or runtime service discovery. That may change, however. But the main reason for the introduction of a UDDI is the discovery of services: what are the reusable assets my organization has?
If you grow even bigger and you get more and more services, a UDDI will not be enough. You will also need to implement a Service Life Cycle Management environment.
Managing a handful of services (say up to 50) can be done manually, without the need for advanced tooling. As the people involved know about the upcoming changes and are involved in bringing the changes into effect, you can manage a whole lot of services. But .. up to a point. There will be a moment in time when you will have to formalize the procedures and support those with tooling. This is where a Service Repository comes in.
What will a Service Repository bring you? A lot! First of all it will give you a tool for implementing Service Life Cycle Management, as it will support discovery (through visibility), impact and depency analysis, monitor compliance (assets, policies & standards), collect metadata, automate lifecycle staging, etc, etc. What I really like about a repository is that it will become the central focus of development, test and deployment. In the repository you will find all the information you will need, from service contracts, SLA’s, documentation, dependencies, tests, policies, service usage (requires closed loop data gathering). Your repository will be the single point of truth in your SOA!
Unfortunately there’s not many repositories around. According to Forrester (The Forrester Wave: SOA Service Life-Cycle Management, Q1 2008) there are just 3 good repositories available at the moment: Oracle Enterprise Repository (rebranded from BEA AquaLogic Enterprise Repository), Software AG’s CentraSite Governance Edition and LogicLibrary’s Logidex.
Oracle Enterprise Repository, formerly known as BEA ALER, will be rebranded and integrated into the Oracle SOA Suite as well as certified against the Oracle BPA Suite. This is one of the reasons I’m very happy with the BEA acquisition by Oracle. OER is by far the most sophisticated repository around and will be making my life a lot easier!
By then you’re sitting on top of a lot of services, of different granularities and of different types, all mixed together. If you’re lucky, the semantics are still correct (no mismatches yet!). Maybe you even have an ESB running. Slowly but surely the need for additional tooling becomes evident. How are you going to manage this whole environment? How are you going to make sure the next project reuses the generic services that have been so painstakingly defined?
A logical first step would be to get a UDDI, where you can at least register your services. Usually this is not a tool that you would implement in your first project, as you do not yet have the need for location transparency or runtime service discovery. That may change, however. But the main reason for the introduction of a UDDI is the discovery of services: what are the reusable assets my organization has?
If you grow even bigger and you get more and more services, a UDDI will not be enough. You will also need to implement a Service Life Cycle Management environment.
Managing a handful of services (say up to 50) can be done manually, without the need for advanced tooling. As the people involved know about the upcoming changes and are involved in bringing the changes into effect, you can manage a whole lot of services. But .. up to a point. There will be a moment in time when you will have to formalize the procedures and support those with tooling. This is where a Service Repository comes in.
What will a Service Repository bring you? A lot! First of all it will give you a tool for implementing Service Life Cycle Management, as it will support discovery (through visibility), impact and depency analysis, monitor compliance (assets, policies & standards), collect metadata, automate lifecycle staging, etc, etc. What I really like about a repository is that it will become the central focus of development, test and deployment. In the repository you will find all the information you will need, from service contracts, SLA’s, documentation, dependencies, tests, policies, service usage (requires closed loop data gathering). Your repository will be the single point of truth in your SOA!
Unfortunately there’s not many repositories around. According to Forrester (The Forrester Wave: SOA Service Life-Cycle Management, Q1 2008) there are just 3 good repositories available at the moment: Oracle Enterprise Repository (rebranded from BEA AquaLogic Enterprise Repository), Software AG’s CentraSite Governance Edition and LogicLibrary’s Logidex.
Oracle Enterprise Repository, formerly known as BEA ALER, will be rebranded and integrated into the Oracle SOA Suite as well as certified against the Oracle BPA Suite. This is one of the reasons I’m very happy with the BEA acquisition by Oracle. OER is by far the most sophisticated repository around and will be making my life a lot easier!
Tuesday 8 July 2008
Oracle vs Open Source
I work a lot with Java developers and software architects. Often there's a discussion in the projects about which software to use for what purpose. Increasingly i find people to be very rigid about this choice: it's all OSS or nothing. In a way it reminds me of the old anti-Microsoft atmosphere.
Therefore I'd like to start a poll, to find out if this issue is alive or that it's just me :p.
Do me a favour and fill in the poll on the side?
Therefore I'd like to start a poll, to find out if this issue is alive or that it's just me :p.
Do me a favour and fill in the poll on the side?
Monday 7 July 2008
So, is WSDL the standard for service contracts?
A Service Oriented Architecture is based upon the use of services (hence service orientation). It's implementation is based upon standards. One of which is the way services interact, namely by messages (XML messages usually).
Standardization is the most important thing for SOA to become a working concept. XML has become the de facto standard for the definition of messages between services. That's fine, but in my opinion we are missing one critical item. THERE IS NO STANDARD FOR SERVICE CONTRACTS.
EH??? Some people will argue that WSDL is THE standard for the service contract, but that's not quite true. A WSDL is an implementation of a service contract, specifically for web services. However, a service does NOT have to be a webservice!
Let's approach it theoretically. What do I need to know to access and use a service? I need several different things at different times. When I need a service to fulfill a specific task, I need to know what services are available, what their service consist of, what data it uses (in) and delivers (out), depencies (if any), security constraints and QoS.
At runtime I need to know where it is located, how it is accessible, what credentials to use, how it is secured, etc.
To manage it I need to know: where it is located, its resource requirements, what technical depencies it has (services it uses, but also db access), what security profile is active, SLA requirements (availability), etc.
All we have now is a WSDL, being the Web Service Definition Language, which is used for webservices at runtime. It does NOT have all the information that is listed above.
So, to answer my own question: Sorry to say, but NO, WSDL is not the standard we need!
Standardization is the most important thing for SOA to become a working concept. XML has become the de facto standard for the definition of messages between services. That's fine, but in my opinion we are missing one critical item. THERE IS NO STANDARD FOR SERVICE CONTRACTS.
EH??? Some people will argue that WSDL is THE standard for the service contract, but that's not quite true. A WSDL is an implementation of a service contract, specifically for web services. However, a service does NOT have to be a webservice!
Let's approach it theoretically. What do I need to know to access and use a service? I need several different things at different times. When I need a service to fulfill a specific task, I need to know what services are available, what their service consist of, what data it uses (in) and delivers (out), depencies (if any), security constraints and QoS.
At runtime I need to know where it is located, how it is accessible, what credentials to use, how it is secured, etc.
To manage it I need to know: where it is located, its resource requirements, what technical depencies it has (services it uses, but also db access), what security profile is active, SLA requirements (availability), etc.
All we have now is a WSDL, being the Web Service Definition Language, which is used for webservices at runtime. It does NOT have all the information that is listed above.
So, to answer my own question: Sorry to say, but NO, WSDL is not the standard we need!
Tuesday 1 July 2008
Oracle & BEA: A Match Made in Heaven?
Today Charles Phillips and Thomas Kurian disclosed Oracle's strategy concerning the integration of BEA and Oracle. Lots of changes, though most are not surprising. Oracle's vision towards SOA has been clear for the last few years, and I look upon this merger as one of the highlights. I am surprised that there's relatively little overlap between BEA and Oracle's offering. In fact, it is an example of realworld synergy, leading to a best-of-breed SOA technology stack. In that sense I fully agree with the closing words of Thomas Kurian:this is the best middleware suite in the industry. So, the answer is yes: it's a Match Made in Heaven!
Some highlights
Not surprisingly, Oracle has integrated WebLogic into both JDeveloper and the Application Server, replacing OC4J. This will be good for performance and stability. But, it gets better. Oracle has announced Oracle Service Bus, in fact replacing ESB with AquaLogic Servicebus (ALSB). Customers will have several years to decide to stay on current installation of ESB or ALSB, and migrating later. JRockit, the world's leading VM will be the standard VM for Oracle, Coherence will be the central component for dehydration. So we get zero latency in the VM and unparallelled performance for the dehydration store. I feel like I'm in a candy store!
Oracle Service Bus
Thomas presented a roadmap towards Oracle Service Bus. This does not mean that the ESB and the Aqualogic Service Bus are discontinued, but they will converge towards the OSB. No forced migration here, but the OSB will consist of the strong points of both ESB and AL-SB.
The Oracle SOA offering will look like:
Oracle BPA Suite
Another interesting development is the integration of BPM Studio into the BPA Suite. It's fair to state that the Oracle BPA Suite, in conjunction with the Oracle SOA Suite (BPEL PM in particular) is the world's best-of-breed for procesmanagement, -design and execution. The added functionality from BPM Studio will create a comprehensive set of tools to support both process architecture, design and execution in a fully supported roundtrip engineering environment. This will also mean that from the new version onward, XPDL will be supported.
Integrating all the tools will take some time, but in the end we will have the BPA Suite for architectures and high level proces modeling, the BPM Suite for building processes in XPDL/BPMN and BPEL to execute them. The roundtrip engineering will be between BPM Suite and BPEL. Oracle aims to deliver a web-based Proces Designer, although the details about this are not yet fully clear.
The Road to 11g
So, when will 11g be available? Well, JDeveloper 11g will probably go GA towards the end of the year (might even be launched during OOW 2008). Fusion Middleware will take some longer, due to the ongoing integration. I think it's worth waiting for. The newly added components JRockit, Coherence and BPM Studio will make the whole Suite a lot better. Besides, it also gives Oracle time to finish WebCenter and WebCenter Spaces, products that will revolutionize the way we build web apps.
IDE
And the winner is ....... JDeveloper. Yes, JDeveloper will continue to be the central IDE for Oracle. All the components in the stack will have a plugin in JDeveloper to increase production and quality. Of course, Eclipse will still be supported, but not for BPA and BPEL.
If you want to read more about Oracle's strategy, go to http:www.oracle.com/goto/july1. The webcast will be made available soon too.
Some highlights
Not surprisingly, Oracle has integrated WebLogic into both JDeveloper and the Application Server, replacing OC4J. This will be good for performance and stability. But, it gets better. Oracle has announced Oracle Service Bus, in fact replacing ESB with AquaLogic Servicebus (ALSB). Customers will have several years to decide to stay on current installation of ESB or ALSB, and migrating later. JRockit, the world's leading VM will be the standard VM for Oracle, Coherence will be the central component for dehydration. So we get zero latency in the VM and unparallelled performance for the dehydration store. I feel like I'm in a candy store!
Oracle Service Bus
Thomas presented a roadmap towards Oracle Service Bus. This does not mean that the ESB and the Aqualogic Service Bus are discontinued, but they will converge towards the OSB. No forced migration here, but the OSB will consist of the strong points of both ESB and AL-SB.
The Oracle SOA offering will look like:
Oracle BPA SuiteAnother interesting development is the integration of BPM Studio into the BPA Suite. It's fair to state that the Oracle BPA Suite, in conjunction with the Oracle SOA Suite (BPEL PM in particular) is the world's best-of-breed for procesmanagement, -design and execution. The added functionality from BPM Studio will create a comprehensive set of tools to support both process architecture, design and execution in a fully supported roundtrip engineering environment. This will also mean that from the new version onward, XPDL will be supported.
Integrating all the tools will take some time, but in the end we will have the BPA Suite for architectures and high level proces modeling, the BPM Suite for building processes in XPDL/BPMN and BPEL to execute them. The roundtrip engineering will be between BPM Suite and BPEL. Oracle aims to deliver a web-based Proces Designer, although the details about this are not yet fully clear.
The Road to 11g
So, when will 11g be available? Well, JDeveloper 11g will probably go GA towards the end of the year (might even be launched during OOW 2008). Fusion Middleware will take some longer, due to the ongoing integration. I think it's worth waiting for. The newly added components JRockit, Coherence and BPM Studio will make the whole Suite a lot better. Besides, it also gives Oracle time to finish WebCenter and WebCenter Spaces, products that will revolutionize the way we build web apps.
IDE
And the winner is ....... JDeveloper. Yes, JDeveloper will continue to be the central IDE for Oracle. All the components in the stack will have a plugin in JDeveloper to increase production and quality. Of course, Eclipse will still be supported, but not for BPA and BPEL.
If you want to read more about Oracle's strategy, go to http:www.oracle.com/goto/july1. The webcast will be made available soon too.
Monday 30 June 2008
SOA Components
What do you really need in an SOA technology stack? To answer that question, let's first have a look as to what SOA really is. SOA is an architectural style, based on service orientation. Ok, so what's architecture? If you Google that term, you'll find 1 gazillion different definitions. I like to look upon architecture as the structure a company gives to its vision. It addresses all the choices (trade-offs) an organization has to make regarding its structure, the way it is organized, how it addresses customers, suppliers, partners and personnel, how and where resources are used (one of them being IT) ... and a lot more. So it's not even about IT, even though a lot of people think so.
If you start working with architecture and especially SOA, sooner or later you will apply it to IT as well. From that point of view, let's see what components you need. Service orientation, as it name says, is based on the use of (business) services.
Let's start at the bottom: services usually make use of data, which will be stored in a database (usually). Next, services exchange data thru messages, so you need something to transport your messages. As different services use different messages (alas!), you will also need a component to transform messages from one format to another. Finally you will need a platform to support a user interface to which the service can be exposed, even though this really is outside the SOA stack. So, basically what you need for an SOA platform is:
- database
- routing & transformation (ie a 'bus')
- UI platform
However, there's more to it. Life isn't that simple anymore. One of the strengths of an SOA is the ability to combine services into a new service: orchestration. So we want to add an orchestration engine to the stack. What else do we need/want? Well, building an SOA is one thing, managing one is another. As you can imagine, the number of services might get large very soon. So you will need at least two additional components: a sort of repository where you can register your services and a management tool that shows you how your services are doing.
Are we done yet? Nope! Managing services is more then just taking care of availability, we also have to take care of security. Who is allowed to use what service? To maintain the reusability of a service, we want a non-intrusive form of security, as a separate layer.
Ok, let's step back and see what we have now:
- database
- routing & transformation (ie a 'bus')
- UI platform
- orchestration engine
- service repository and registry
- management tools
- non-intrusive security
To top it all off, I would like to add a rules engine, to be able to reuse business logic in services, orchestrations, UI, routing and transformations.
Luckily you don't need the whole stack when you start out with SOA, especially when you start small and only within your company. But as SOA is especially very good at organizing processes within your company but also between companies, it will grow fast.
Unfortunately there are not many vendors around who can offer you the full stack. For each and every component I've mentioned there are commercial best-of-breeds and Open Source alternatives. However, integrating tools from just a single vendor can be a challenge, and integrating a lot of best-of-breed tools from different vendors and OSS can be a nightmare (and usually is :p). This is one of the reasons I am very enthusiastic about the Oracle SOA Suite, as it delivers a well integrated suite of components. Most of these are even best-of-breeds, especially the Oracle BPEL Process Manager. I think the integration with BEA will make the Oracle stack even more complete and robust.
Also good to see is that there are a number of OSS projects like GlassFish, who are delivering good SOA components. Unfortunately there are not enough standards yet to overcome the integration challenges. Enough work to do!
If you start working with architecture and especially SOA, sooner or later you will apply it to IT as well. From that point of view, let's see what components you need. Service orientation, as it name says, is based on the use of (business) services.
Let's start at the bottom: services usually make use of data, which will be stored in a database (usually). Next, services exchange data thru messages, so you need something to transport your messages. As different services use different messages (alas!), you will also need a component to transform messages from one format to another. Finally you will need a platform to support a user interface to which the service can be exposed, even though this really is outside the SOA stack. So, basically what you need for an SOA platform is:
- database
- routing & transformation (ie a 'bus')
- UI platform
However, there's more to it. Life isn't that simple anymore. One of the strengths of an SOA is the ability to combine services into a new service: orchestration. So we want to add an orchestration engine to the stack. What else do we need/want? Well, building an SOA is one thing, managing one is another. As you can imagine, the number of services might get large very soon. So you will need at least two additional components: a sort of repository where you can register your services and a management tool that shows you how your services are doing.
Are we done yet? Nope! Managing services is more then just taking care of availability, we also have to take care of security. Who is allowed to use what service? To maintain the reusability of a service, we want a non-intrusive form of security, as a separate layer.
Ok, let's step back and see what we have now:
- database
- routing & transformation (ie a 'bus')
- UI platform
- orchestration engine
- service repository and registry
- management tools
- non-intrusive security
To top it all off, I would like to add a rules engine, to be able to reuse business logic in services, orchestrations, UI, routing and transformations.
Luckily you don't need the whole stack when you start out with SOA, especially when you start small and only within your company. But as SOA is especially very good at organizing processes within your company but also between companies, it will grow fast.
Unfortunately there are not many vendors around who can offer you the full stack. For each and every component I've mentioned there are commercial best-of-breeds and Open Source alternatives. However, integrating tools from just a single vendor can be a challenge, and integrating a lot of best-of-breed tools from different vendors and OSS can be a nightmare (and usually is :p). This is one of the reasons I am very enthusiastic about the Oracle SOA Suite, as it delivers a well integrated suite of components. Most of these are even best-of-breeds, especially the Oracle BPEL Process Manager. I think the integration with BEA will make the Oracle stack even more complete and robust.
Also good to see is that there are a number of OSS projects like GlassFish, who are delivering good SOA components. Unfortunately there are not enough standards yet to overcome the integration challenges. Enough work to do!
How hard is it?
As you can see, I'm quite an evangelizer for SOA. The main reason being that it delivers (in my humble opinion) the alignment between IT and Business. Delivering business services (recognizable and usable services for the business community) is what IT is all about. However, whenever I get into discussions with IT personnel, I usually meet a lot of (initial) resistance. Of course, change is stressfull and can even be threatening, I understand that. But what I really don't understand, from a technical point of view, is: isn't it great to have all those new technological challenges out there? Isn't it marvellous to see you can build services so easily and building return on investment?
Monday 5 May 2008
Service discovery, part 3: Meet in the Middle
Finally I found some time to finish this series. My apologies to those who've been waiting for part 3, but ..... here it is.
I have outlined two different approaches so far: bottom-up and top-down. As is usually the case, both have merits and drawbacks. In fact, the real solution is to do both, and not just one. That's what I call 'Meet in the Middle'. The top-down approach is very important to achieve the business goals, where the bottom-up approach is just as important to utilize the investments made in the current systems for the last few years. By combining these two approaches you get the best of both worlds: integration with the current application infrastructure (in a service-oriented way) and preparedness for more process driven functionality which supports the business needs.
But (of course there's a but) there's a little more to it. Matching the two approaches is not as easy as it sounds. There will be quite a gap between the business services as described in the top-down approach and the application services discovered in the application infrastructure. The trick is now, to take a business service and analyse which of the application services youi need to compose a service that will bridge the gap. This composite service can be multi-layered, and usually is.
One of the paradigms we use in grouping and discovering services is domain driven design (see Eric Evans marvellous work). Stated shortly: we define business domains (top-down here) consisting of delimited data and corresponding services (multi-level services: from data manipulation to business level services). This domain (and therefore its data) can only be accessed through the services. These are the building blocks for the future business functionality.
The attentive reader will have seen the problems looming on the horizon. The main issue is, that the domains we have recognized will be spread over the existing application infrastructure. So, how are you going to delimit the domains? That's the hardest part. In a greenfield it's easy, because you can define and build the domains. In real life situations you will usually build a part of the domain and integrate it with the existing applications. So you will need composite domain services which will present a unified view towards its consumers, and will integrate the different data sources on the back-end.
How hard this is, usually depends on the openness of the systems involved. Even though a lot of systems are walled of, there are usually several strategies you can employ. This goes from the use of service adapters, wrappers, up to direct database calls and file interfaces. You'd be surprised how far you can get.
I have outlined two different approaches so far: bottom-up and top-down. As is usually the case, both have merits and drawbacks. In fact, the real solution is to do both, and not just one. That's what I call 'Meet in the Middle'. The top-down approach is very important to achieve the business goals, where the bottom-up approach is just as important to utilize the investments made in the current systems for the last few years. By combining these two approaches you get the best of both worlds: integration with the current application infrastructure (in a service-oriented way) and preparedness for more process driven functionality which supports the business needs.
But (of course there's a but) there's a little more to it. Matching the two approaches is not as easy as it sounds. There will be quite a gap between the business services as described in the top-down approach and the application services discovered in the application infrastructure. The trick is now, to take a business service and analyse which of the application services youi need to compose a service that will bridge the gap. This composite service can be multi-layered, and usually is.
One of the paradigms we use in grouping and discovering services is domain driven design (see Eric Evans marvellous work). Stated shortly: we define business domains (top-down here) consisting of delimited data and corresponding services (multi-level services: from data manipulation to business level services). This domain (and therefore its data) can only be accessed through the services. These are the building blocks for the future business functionality.
The attentive reader will have seen the problems looming on the horizon. The main issue is, that the domains we have recognized will be spread over the existing application infrastructure. So, how are you going to delimit the domains? That's the hardest part. In a greenfield it's easy, because you can define and build the domains. In real life situations you will usually build a part of the domain and integrate it with the existing applications. So you will need composite domain services which will present a unified view towards its consumers, and will integrate the different data sources on the back-end.
How hard this is, usually depends on the openness of the systems involved. Even though a lot of systems are walled of, there are usually several strategies you can employ. This goes from the use of service adapters, wrappers, up to direct database calls and file interfaces. You'd be surprised how far you can get.
Monday 11 February 2008
Service Discovery, part 2: Top-down
Time for part II. In Part I I explained that the Bottom-up approach is valid in itself, but it is does have its limitations.
A logical alternative is the Top-down approach. In short: this approach looks at the processes in the business, decomposes them into subproces/tasks/functions until 'logical units of work' are defined, which we call services.
Is that all there is to it? In principle: yes. However, there's more to it than meets the eye. A pure BPM (Business Process Management) approach, for example as advocated by IDS Scheer, will deliver a 4-layered process structure for the entire organization. Since the introduction of the Oracle BPA Suite you are then able to convert the lowest level of process to an executable process (BPEL) in which individual tasks become service-operations.
The decomposition of the process in itself is not enough to discover services, because you will have to convert the 'candidate-service' into a real-world executable and discoverable service. This means you will have to compare the functionality of the service with the available infrastructure (which consists of more services, hopefully). Quite often, the service functionality is delimited by specific functionality not being available. For example, suppose you run a very specific proprietary financial system where you cannot interact with either the business logic or the data store. If this is the ultimate source that you will have to use, the chance of being able to fulfill the service functionality needs are quite slim.
Does this invalidate this approach? Of course not. I find this approach working very well in those areas where SOA is used to add new functionality to an existing infrastructure or in a complete greenfield situation (which are quite rare). What this approach does for you is that it's easy to involve the business into designing the new services. The defined services are very recognizable for the business, but not always easy to implement.
Using tools to convert services that are discovered during the process analysis, means that the process analysis has to be done very thoroughly. And, even more important, the process analyst should have knowledge of the limitations of the execution platform. Otherwise you'll end up with services and orchestrations that work rightly on paper, but will never execute in reality. How to address that will be explained in part III.
A logical alternative is the Top-down approach. In short: this approach looks at the processes in the business, decomposes them into subproces/tasks/functions until 'logical units of work' are defined, which we call services.
Is that all there is to it? In principle: yes. However, there's more to it than meets the eye. A pure BPM (Business Process Management) approach, for example as advocated by IDS Scheer, will deliver a 4-layered process structure for the entire organization. Since the introduction of the Oracle BPA Suite you are then able to convert the lowest level of process to an executable process (BPEL) in which individual tasks become service-operations.
The decomposition of the process in itself is not enough to discover services, because you will have to convert the 'candidate-service' into a real-world executable and discoverable service. This means you will have to compare the functionality of the service with the available infrastructure (which consists of more services, hopefully). Quite often, the service functionality is delimited by specific functionality not being available. For example, suppose you run a very specific proprietary financial system where you cannot interact with either the business logic or the data store. If this is the ultimate source that you will have to use, the chance of being able to fulfill the service functionality needs are quite slim.
Does this invalidate this approach? Of course not. I find this approach working very well in those areas where SOA is used to add new functionality to an existing infrastructure or in a complete greenfield situation (which are quite rare). What this approach does for you is that it's easy to involve the business into designing the new services. The defined services are very recognizable for the business, but not always easy to implement.
Using tools to convert services that are discovered during the process analysis, means that the process analysis has to be done very thoroughly. And, even more important, the process analyst should have knowledge of the limitations of the execution platform. Otherwise you'll end up with services and orchestrations that work rightly on paper, but will never execute in reality. How to address that will be explained in part III.
Tuesday 8 January 2008
Oracle ACE Director
I'm very proud to announce that I've been awarded the Oracle ACE Director status. I'd like to thank Clemens Utschig and Jürgen Kress for their nomination. If anything, this will intensivy my activities around SOA in general and Oracle SOA in particular. Thanks guys!
Monday 7 January 2008
Does SOA Deliver?
I read this very interesting article by Max Pucher. He builds up a quite convincing case about why SOA is, as he calls it, an overhyped buzzword. Every vendor is jumping on the bandwagon, afraid of losing out on this hype.
He does pose some very interesting and helpful considerations, that every SOA architect should keep in mind. Let's not forget that SOA is NOT a silver bullet. SOA is also NOT a technology, but an approach to build architectures which are more tailored to the needs of the business (which sometimes includes educating the business).
He does pose some very interesting and helpful considerations, that every SOA architect should keep in mind. Let's not forget that SOA is NOT a silver bullet. SOA is also NOT a technology, but an approach to build architectures which are more tailored to the needs of the business (which sometimes includes educating the business).
Subscribe to:
Posts (Atom)