The usual Initial Ramblings
In my new job I am supposedly THE person in getting an integrated integration solution(along with external consultants) in place and thereby lend for future business process automation. Prior to this one, I was working in Oracle SOA in BPEL-JDeveloper combo. and all was honky dory - basically all where happy and ended/continued in peace and love ! This is not the case now - good to keep me ticking in my integration knowledge pursuit and bad when you see so many difference techniques, approaches, thoughts and more importantly our wonderful vendors pursuit to keep it confusing - may or may not be deliberate but obviously for monetary purposes.
In my new job I am supposedly THE person in getting an integrated integration solution(along with external consultants) in place and thereby lend for future business process automation. Prior to this one, I was working in Oracle SOA in BPEL-JDeveloper combo. and all was honky dory - basically all where happy and ended/continued in peace and love ! This is not the case now - good to keep me ticking in my integration knowledge pursuit and bad when you see so many difference techniques, approaches, thoughts and more importantly our wonderful vendors pursuit to keep it confusing - may or may not be deliberate but obviously for monetary purposes.
Let's Take Off !
Been reading lots of articles, some books and watching my mind in putting together all that was read. Simply put, a lot of stuff and very little conclusion with more towards confusion. Let us go through the list of magic words - SOA, BPEL, ESB, EDA, Messaging, Integration frameworks, Middleware, Process Orchestration, Process Choreography, Process Workflow, BPM, BAM, Queues, Microservices, REST, API and the endless list continues.
Statements like this "Design and publish APIs for end customers, B2B, or mobile - APIs can be in SOA or REST" make things more a hell. This is supposedly from integration leaders' product documentation. APIs can be in SOA ?! SOA is an architectural principle and SOA can be pursued through SOAP over HTTP (that is what the doc. is probably trying to say), REST style services, Microservices and anything more some integration gurus can add to.
Since we touched upon SOA, let us probably look at the different approaches of SOA. The technical gurus prefer the word "Service Oriented Approach" instead of "Service Oriented Architecture", which seems from history (when I was physically a kid !), a failure, across the geography.
From my perspective, SOA could be implemented as "BPEL" or "ESB". The choice of which one depends on the needs, which makes sense isn't it ?! Hope you are part off the minority!
Hope I haven't added another mess to the existing mess in the integration world.
Since we touched upon SOA, let us probably look at the different approaches of SOA. The technical gurus prefer the word "Service Oriented Approach" instead of "Service Oriented Architecture", which seems from history (when I was physically a kid !), a failure, across the geography.
From my perspective, SOA could be implemented as "BPEL" or "ESB". The choice of which one depends on the needs, which makes sense isn't it ?! Hope you are part off the minority!
- BPEL is fine for long-term processes and involves human interaction. Due to the language nature, it is heavy and can involve complex logic, including business ones. This is where it may not suit the new fad of get SOA the right way - Mrs. Microservices, where you want to keep the smarts at the end points and not in the middleware.
- ESB is a mechanism to move messages supposedly in a light weight manner with minimal required logic/actions to the message within the bus/pipe. This may fit the Mr. Microservices design style. The other denouncing term is "Egregious Spaghetti Box". So watch out what you are trying to achieve. Keep you principles clear and focused.
Hope I haven't added another mess to the existing mess in the integration world.
No comments:
Post a Comment