Change management, as it used to be called, or the new buzzword ‘governance’ is a key component of any SOA.
If we consider that one of the main benefits of SOA is reuse, this can sometimes only happen when slight modifications are made to a service to allow it to be used for a different purpose. The change will normally not impact on the previous use but to ensure reuse, the change must be made.
There has traditionally been a gap between what the business wants from its IT and what IT can deliver. At its worst, many people on the business side consider the IT guys to be too interested in technology; while many IT people don’t always understand why the business asks for what it does.
The problem stems from the fact that up until now, there hasn’t really been a way for the business to express what they want and for the IT guys to fully understand it and why.
Working with SSL certificates is not common sense. Applying a new certificate on a server for outgoing messages is not a walk in the park. Do not think installing a client certificate on top of SSL configuration is easy.
In this article I want to share you some useful statements that for creating SSL connection on the Oracle Application Server, this is the Weblogic Server. But can also be applied on others app servers.
During my project work I had to tune the SOA dehydration store on more than one occasion. Through this posting I would like to share the tuning tips collected during these exercises. It is not a step-by-step guide, because with tuning there never is a 'one-size-fits-all' in my humble opinion, but I provide in general a guidance that you can use as a reference for your own situation. I will also refer to related Oracle documentation where available.
I was recently introduced to the website Software Advice because they wrote an Introductory Article on SOA entitled The Plain English Guide. It's a pretty good overview for any beginner to SOA trying to grasp the fundamental concept.
Sometime ago, I wonder if we could deploy many small applications and access them on a central application. This is to avoid redeployment of the whole application every time there are new pages being created. Just as the the Oracle Forms and Reports developers are used to, they develop a form, compile, and put the compiled form on a directory and voila!,