Sunday, November 16, 2008

SOA Implementation in ERP

Service-Oriented Architecture (SOA) is another buzzword in IT world. Everybody has different understanding of what SOA is. Trying to change all software architecture for the sake of SOA is another pitfall I witness. “Everything integrates without any mess and pain with SOA” but everything should be SOA-enabled. SOA-enabling all software is very long journey that hasn’t been taken yet. I don’t find the answer how the legacy systems will be SOA-enabled and what the cost we will pay for this. I read many SOA projects that are blue-sky projects trying to make everything a service without any return for the cost. This is why many projects are subject to failure.

I have following observations about SOA:
SOA is meaningful and feasible in integration (i.e. In Enterprise Application Integration (EAI)): Best place for SOA is to use it in integration functions. This integration may be at application, system or business process level. In Java world same mistake (making everything SOA) is done in EJB component architecture. Every component thought to be accessible remotely with RMI-enablement making them very heavy without any remote need. Some components may be used remotely but this is a rare condition. Eventually EJB components supported local-only options but it took years to fix the architecture problem. I think in integration spots we need SOA with web service or interface form. Other parts of software should not need SOA-enablement. Let’s say every API doesn’t necessarily be a service (i.e. web service). But if we need to integrate applications, then their integration API can be made SOA-enabled. If your application is locally used why do you need to bring its API to ESB?

SOA technologies are still evolving (Is there an end?): Web services technologies are aimed to replace CORBA but it is still evolving and changing. Sometimes same problem solution set has 2 different standard bodies (i.e. different security standards lead by IBM and Microsoft) destroying interoperability. On the other hand, XML taxonomies and vocabularies have many duplicate branches ruining common definitions. New alternatives are emerging to solve the same problem like REST against SOAP. I think some mature SOA technologies may be used as a wrapper of current defined application interfaces. Application interfaces don’t depend on technological changes. Adopting all SOA technologies and making a huge investment on them must be evaluated carefully. SOA technology changes affect platforms, products, tools and finally your software.

We implemented SOA in 2 parts of our ERP architecture:
1- Application Infrastructure Services: We know that service architecture is used in MS Windows OS. From the System Management, this OS services are registered, unregistered, started, stopped and disabled. We adopted same manner and in our ERP runtime, every application infrastructure services can be managed transparently from applications. This enables fault-tolerance, fail-over and managed services. In this way, we are using the benefits of SOA as architectural principle not the technology stack.

We have following “Application Infrastructure Services” managed from admin module similar to Windows OS. This is why we call our platform as Application Operating System (AOS):
· Object Cache Service
· DB Connection Cache Service
· Message Service
· Database Log Service
· Data Control Service
· Log Service
· HTTP Control Service
· Persistent Session Service
· Authorization Service
· Authentication Service
· Lock Manager Service
· Identity Service
· Email Service
· Profile Service
· Schedule Service
· Meta Data Cache Service
· Resource Profiler Service
· Replication Service
· Rule Service
· Workflow Service

2- Application Function Interfaces: Integration needs among ERP modules or applications are much more than any other software. Therefore every module needs to access (CRUD) other modules tables and functions (i.e. Purchase module may update Sales module’s tables). We achieved this by defining application interfaces (Adapters) without direct table access. Direct table access has problems like lock bypassing, business function duplication etc. These interfaces can be accessed from any application directly in local process. Remote access is achieved via our Messaging backbone (ESB). We plan to “web service”-enable this adapters to make them integration solution for third party integration needs.

No comments: