Service Oriented Architecture

Service-Oriented Architecture (SOA)

Service-Oriented Architecture (SOA)

Service oriented architecture in this field is a collection of services that communicate to each other to achieve a particular task that was intended during its design. For organizations to offer this service, they should integrate various loosely coupled technologies like Extensible Markup Language XML so that they can effectively offer their services. This is very beneficial to various institutions and organizations as they can use it to suite their requirements and meet their needs as they want to. In comparison to traditional software design and all other steps that one may follow, it is also beneficial in several other aspects of service delivery. Some of these advantages include; cost saving, very consistent and reliable, Product flexibility and in time to the market. For this reason, organizations opt for Service-Oriented Architecture (SOA) (Juric, Verma & Utschig, 2007).

The first way in which this service oriented architecture reduces cost is because it is independent of any vendor, product or technology. Using such reduces the general cost because the technology is out there to be utilized by everyone. No one out there will have to be issued with the request to use it. Utilizing this will greatly reduce the cost. Vendors normally charge for the use of their products. There is also several commissions that are involved when handling such service. All this will be minimized through Service-Oriented Architecture (SOA) since everything is handled within the institution or organization that needs to use it. Over time, Enterprise IT group can plan to deliver services directly to the end-users by integrating multiple systems. It means that services offered by applications such as enterprise resource planning (ERP) and the customer relationship management (CRM) systems, will be made available to the end-users, which results in an the overall reduction in the TCO for supporting the business functions and operations.

SOA promises to continue stimulating conversation in the IT industry and maintain the increasing interest to businesses seeking to reduce or lower cost of operation, leverage on existing assets, increase return on the investment (ROI), and integrate the systems used. In addition to that, interest in Entity Aggregation solutions will increase in line with the popularity of the Service Oriented Architecture.

Through the integration of multiple systems, the final cost is drastically reduced. The systems will no longer be idle and thus put into production by utilizing the ones that need to be in production. Maximum utilization of the readily available services will reduce the overall cost of operation. Just like in the organizations that have implemented this, it has been found that the efficiency increases and also resulting in the final outcome of the organization involved. Standard based integration puts all fields involved at bar thus cutting on all the cost involved.

From all the measures that can be implemented, all of them will ensure that the risks associated with it are kept at their low. This will minimize at all cost and loses that are involved with unreliable third party services. Service-Oriented Architecture (SOA) ensures the delivery of services that have been well made and managed by the company to serve them particularly to their needs. Third party may contain bugs that can leak some information to some unintended parties therefore costing the organization involved a lot of money as can be seen in some recent software that contain code that sends the information to some illegal servers located in foreign countries. All this is also according to (Juric, Verma & Utschig, 2007).

According to (Arenas, 2010), XML has very many functions in this area of Service-Oriented Architecture (SOA). All the functions are beneficial to the environment. One way is through message verification. You can develop World Wide Web Consortium (W3C) XML Schema Definitions (XSDs) that your XML network can use to verify the syntax of your XML documents. Message verification on the other hand is very important in carrying out different tasks as the clients communicate. It boosts the quality of communication in many cases and avoids making errors. It is also used for Context-Based Routing. Use of XML Path (XPATH) route messages based on data stored within the XML documents. The most popular being routing stock exchange quotes to the desired location immediately the value of stock drops below An Indicated threshold.

Compression and Caching is also a means through which XML effectively does this. You may cache XML documents that are frequently requested and compress XML documents thus reducing network bandwidth. Just like XML encryption, caching and compression can be performed using hardware or software that is XML-accelerated. This is very important in carrying out the daily activities in an SOA environment. XML is also important in Application-Layer Request Translation. It can be used in networking to convert non-Web service requests into a standard Web service requests. Similar to integration brokers, vendor-specific adapters are needed to translate between Web Sphere MQ, SOA and TIBCO Web services (Arenas, 2010).

One other very important way is through XML translation. XML Style–sheet Language Transformations (XSLT), XML documents can be translated to other non-XML formats directly within your network. This aids a lot in data and information exchange in a language that all the clients could understand. From the above roles, they prove to be very important in data and information exchange between clients and servers using Web Services in an SOA environment as asserted by (Arenas, 2010)

Loose coupling architecture is a way of interconnecting components in a system or network so that these components rely on each other to the extent practicable. Coupling thus refers to the level direct knowledge each component has over the other. The main aim of loose coupling is to reduce the risk that a change made within one element that will affect other functions of the other elements within the system. Limiting interconnections will of course isolate problems when there is something wrong in the system thus simplifying maintenance and troubleshooting procedures. A loosely coupled architecture can be broken down into their specific elements. The level of coupling can be measured by the amount of elements that can be changed without adversely affecting the system and its functions. Though this type of coupling minimizes unnecessary interaction between systems, it can bring a lot of problems when this interaction is necessary (Messerschmitt, 1999). An example is some systems that need a high degree of synchronization so interaction is required.

Tightly coupled architecture on the other hand is a type of coupling where all the hardware and software and tightly interlinked and connected together. Both software and hardware are dependent of each other. Unlike the loosely coupled system where some elements can be disabled, in this system, all the elements are shut down/ disabled in case of a problem maintenance or any other thing. This is basically since one part cannot function without the other.

Loosely coupled architecture and tightly coupled have several differences. The first being the physical link . For tightly coupled, there is a direct link physically while for loosely coupled there is a physical intermediary. The communication style for tightly coupled is synchronous while for loosely coupled is asynchronous. The type of system for tightly coupled is strong i.e. when it comes to the interface while it is weak while the system is weak when it comes to loosely coupled. Loosely coupled is data centric with self-contained messages while tightly coupled is OO-style navigation of complex object trees. There is a Central control of process logic for tightly coupled system while in loosely coupled it is distributed to the components. In terms of Service discovery and binding, tightly coupled has statistically bound services while loosely coupled is dynamically bound. When it comes to the platform dependencies, tightly coupled is Strongly OS and programming language dependent while loosely coupled is independent according to (Messerschmitt, 1999)

Both loosely and tightly coupled systems are very beneficial when it comes to handling different tasks and responsibilities in an organization. Various tasks need various methods of handling them for a particular work to be successful. This brings in the issue of their similarity between the two. The both work on a system in an organization or any environment suited. They both have a certain way of working, dependent or independent, their architecture remains the same. They need some code or operating system to work and do the functions and responsibilities that each of them is assigned to. The similarities go further to how these two are developed from coding to the final stages when they will in the field function. Loosely coupled is first made in a way such that it will be in a position to accommodate several modifications. Tightly coupled also when ding their functions are majorly to support the system it is made for. Both are responsible for supporting the system one way or the other.

Business integration is very important in day to day life in many organizations. Most of them understand the need of integrating their applications in order to smoothly run the day to day activities. They also recognize the need to enable different data bases to communicate and share data efficiently. For a company, there are two different activities performed by the respective personnel. This standards based integration comes with its own advantages and disadvantages just like any other means and integration technique.

Standard based architecture has several advantages, three of them are discussed. The first being that a standards-based integration strategy like the SOA enables integrators to develop high level which more generic standardized processes instead of the lower-level, project-specific solutions developed using a tactical approach. Standardized and more coherent integration infrastructures keep the project repeatable, clean, and more so technologically-agnostic. Standards based approach for a fact reduces the total cost and thus the expenditure that will be used at the end of the project. This is mainly because al what will be needed will be readily available and the people responsible for this case will just need to properly utilize them to finally benefit from it. This by far makes the service Oriented architecture more precise and cost effect when compared to other fully fledged software acquisition or development. Another way in which is more advantageous is its easy way of modification (Juric, Verma & Utschig, 2007). Service oriented architecture normally involves loosely coupled architecture where there is more control of the system. The people responsible will just modify it later to achieve the desired function or role. Unlike other methods where you can just generalize everything and end up with a baggage at the end of it all, this method is more project specific and do not include other things that won’t be functional at the end of it all.

Like any other way, it also disadvantages associated with it. Developing it is more standardized and thus requires experts to work on it. Getting them are not normally that easy or if found, they are normally expensive. This will cost the organization a lot at the end of it all. The organization will have to incur the cost of maintaining them as their system and all other system need to. The loosely coupled nature might make it more difficult to identify and detect errors in the system since each element rely on itself. The system might still be functioning normally with or without it. As much as this is more advantageous for being project specific, problems arise when something else need to be added, modified or changed. Everything will have to start from scratch just like in the beginning of the project. It means a lot has to be spent and thus the organization incurring the cost finally according to (Juric, Verma & Utschig, 2007).

In conclusion, standard based architecture is very helpful when it comes to businesses and organizations when offering their products and services and trading partners using a standards-based integration protocol. As it can be noted above, it is very helpful economically to the organization and everyone that uses their services. From all the reasons and detailed discussions above, it is clear that this method is beneficial. Finding the correct means and IT persons to implement this is the key towards realizing its success. From the experiences of the companies that have implemented this, it can be found that it has worked and working for the better.

References

Arenas, M. (2010). Relational and XML data exchange. San Rafael, Calif. (1537 Fourth Street, San Rafael, CA 94901 USA): Morgan & Claypool.

Juric, M. B., Verma, M., & Utschig, C. (2007). SOA approach to integration XML, web services, ESB, and BPEL in real-world SOA projects. Birmingham, U.K.: Packt Pub..

Messerschmitt, D. G. (1999). Networked applications: a guide to the new computing infrastructure. San Francisco, Calif.: Morgan Kaufmann.