Skip to main content

How To Avoid Risks In SOA Implementation?

  • It is very important to know your customer's requirements,expectations and improved business processes in advance before starting any analysis and design exercise.
  • A continuous communication with your client is must so that you can understand their business processes very well and should be able to identify problem areas with some concrete solutions in mind.
  • If you have a suggestions related to business processes improvement then get an approval from your client on business requirements as they keep changing all the time.So scope of work is clearly defined to you and your customer with extensive project planning.
  • If a customer does not see any qualitative improvement in complex business processes simplification/replacement with new improved business processes,he is going to make a lot of hue and cry about introducing new technological architecture.
  • An organisation is always interested in synchronisation and improvement of its business process with its customers,suppliers and partners for improved productivity irrespective of what technological steps are required to achieve it.Hence if anything goes disastrously wrong then SOA will bear all blame along with people involved.
  • Do not end in developing spaghetti services,it means,do not jump into implementation of services right away without analyzing its impact and overall inclusion in a large picture.
  • Avoid duplication of services and create standards based infrastructure to build services upon.
  • A service must be properly designed to address unexpected issues which may come in future.
  • A solution to avoid spaghetti services is creation of a single Enterprise Services Bus(ESB). 
  • An ESB is a distributed infrastructure that is based on service standards.It is a single point for routing,securing messages(single sign on etc.).It enables any system to talk to other systems which are plugged in to ESB by providing necessary transformations required to messages to do that.An ESB empowers network administrators to monitor and audit all message traffic to provide with accurate metrics, giving complete visibility into how the services are being used, and how performance can be tuned. 
As SOA is paradigm shift from object oriented technology to messages, which is a base unit of a service, based development, it is quite significant to distinguish and application from a service.So segregation of application team from a services team leads to a focused approach where applications developed will have interfaces which are consumed by services.The interfaces give lot of flexibility in order to integrate applications with services, so a great care should be taken in mind in designing and developing them.


A multi-layered services development is a smart approach of building services.First chalk out all fine grained services which may exist in SOA based solution and then build coarse grained services aggregating fine grained ones.In this way, the solution will be able to withstand requirement changes occurring every now and then.Even design patterns will also fit well in such scenarios, session facade and mediator design patterns gel very well to web services.


A plan for configuration management,performance tuning and scalability is must.None will care whether SOA is in place or not but how a solution efficiently runs a business that matters most to the end user.They want a high performance and do not want their system to work at snail's pace.The architects have to plan for scaling issues at design time for improved performance of the system.The database resources,session state management,services usage pattern,security of services involving cryptography,XML processing , they all are highly CPU engaging activities.So deciding about the right choice of hardware and scaling techniques are essentials of design time.The grid computing is highly scalable and robust but then the choices made are highly dependent on what requirements one has.

Comments

Popular posts from this blog

Asynchronous Vs. Synchronous Communications

Synchronous (One thread):   1 thread -> |<---A---->||<----B---------->||<------C----->| Synchronous (multi-threaded):   thread A -> |<---A---->| \ thread B ------------> ->|<----B---------->| \ thread C ----------------------------------> ->|<------C----->|

WebSphere MQ Interview Questions

What is MQ and what does it do? Ans. MQ stands for MESSAGE QUEUEING. WebSphere MQ allows application programs to use message queuing to participate in message-driven processing. Application programs can communicate across different platforms by using the appropriate message queuing software products. What is Message driven process? Ans . When messages arrive on a queue, they can automatically start an application using triggering. If necessary, the applications can be stopped when the message (or messages) have been processed. What are advantages of the MQ? Ans. 1. Integration. 2. Asynchrony 3. Assured Delivery 4. Scalability. How does it support the Integration? Ans. Because the MQ is independent of the Operating System you use i.e. it may be Windows, Solaris,AIX.It is independent of the protocol (i.e. TCP/IP, LU6.2, SNA, NetBIOS, UDP).It is not required that both the sender and receiver should be running on the same platform What is Asynchrony? Ans. With messag...

Advantages & Disadvantages of Synchronous / Asynchronous Communications?

  Asynchronous Communication Advantages: Requests need not be targeted to specific server. Service need not be available when request is made. No blocking, so resources could be freed.  Could use connectionless protocol Disadvantages: Response times are unpredictable. Error handling usually more complex.  Usually requires connection-oriented protocol.  Harder to design apps Synchronous Communication Advantages: Easy to program Outcome is known immediately  Error recovery easier (usually)  Better real-time response (usually) Disadvantages: Service must be up and ready. Requestor blocks, held resources are “tied up”.  Usually requires connection-oriented protocol