Ok, it’s time to wax a wee bit technical this time around. I’m less than worried though, because if you’re researching the SaaS SOA concept, then you’re not intimidated by the technicality of this piece, right?
So, we’re all familiar with the application of service oriented architecture, and we have been for a long time really. As users, we’ve grown used to the standardization of applications on a specific platform, using shared controls, shared system calls that let them work with the operating system in closely cooperative ways. We’ve gotten used to software suites made of multiple applications which share services and functions across them and with the operating system as well.
So, considering the nature of software as a service, SaaS SOA is obviously going to get a lot of attention, right? Yeah, but the mistake people make here is that it’s not the same kind of SOA environment which operating systems and application instances work in.
The concept’s not different, but the application of it truly is. Let’s take a look at some things to keep in mind.
#1 – Watch Function Overlap
The first mistake that people make in web based SOA is multiple services running which overlap certain functions. This can cause two different service modules on the server, both of which make writing queries to the database, or to browser cookies.
This can cause double entries, corrupt data or for one component to get out of date data because its read precedes the write it needs data from.
#2 – Use Standard Ingredients
When you’re creating and implementing multiple server-side services to work together to yield a singular output to the browser, such is the case here, you need to be wise about these services running on the same kinds of technology. Mixing, say, ASP and PHP services, or Oracle and MySQL data structures is not a wise idea.
Oh, a little of this is going to happen, but avoid it if you can. Otherwise, moves to other servers, support by third party technicians and other such things may be … challenging.
#3 – IEEE, ISO and W3C Compliance
Yeah, compliance is a nuisance but it’s important. Whether you’re designing a service yourself, or integrating boxed ones in a custom framework, you need to make sure that everything meets standards and competence compliance tenets via IEEE, ISO and W3C.
This ensures that if there’s a problem, diagnosing it is much more straightforward. Along with this, it also ensures browser compatibility across a number of platforms and browser labels. Mobile devices, PCs, Macs, gaming devices and set top boxes – everything can properly render and talk to all of the services so that the unity of smaller objects into a singular force is truly cemented.
SaaS SOA practices can be more complicated than this, if you’re getting into creating the services yourself more deeply, or building complex modeled frameworks of original or boxed services. Coding and protocol design is a much bigger task, and brings in the skills needed for competent software engineering. But, even with that level of depth, above all, the principles above still shape the ultimate result. Never forget this.
