Introduction
Service oriented architecture is a set of design principles that are concerned with connections and comes into use during systems development and integration stages of a project (Marks & Bell 2006). It is basically a collection of services that are loosely integrated and communicate with each other to support different strategic levels of an organization. The communication could be in form of data passing from one station to another or different services supporting a specific activity (Slama 2004). Therefore, for this to be possible there must be a medium for connecting these services to each other and this connection medium is the Web service. In information technology, a service can be described as a properly defined, self supportive function that is independent of other services’ behaviors and responds to user requests.
Components of a service oriented architecture
- Service provider: this is described as a component or set of modules in the architectural design of a service oriented system that takes in user defined inputs and outputs, and based on this executes a function.
- Service consumers: this can be described as a set of modules forming a component that are looking forward to directly use a single or more services that are offered by the service provider.
- Service repository: this is the component that holds the services descriptions defining the state, behavior and characteristics of the services. All services are usually stored in the repository for the consumers to be able to access and make use of as per the definition of their needs.
Reasons for implementing a service oriented architecture
The complexity and wide distribution of IT resources within many organizations in a long time has posed a real challenge in terms of access and management. This, as a result has led to consequences that have proved costly to many organizations. For example, some organizations have failed to meet their business goals after costly spending in management and maintenance thus being unable to enhance growth and adapt to change. To appropriately handle this problem however, it is not advisable for organizations to have a complete overhaul or modification of their systems but instead find a way of leveraging their IT resources to be able to effectively work towards achieving their goals. It is therefore important to note that service oriented architecture design principles offer an appropriate framework to enable organizations meet their business goals with a relatively high amount of ease (Thomas 2005). This is done by making applications respond to business needs in a more effective and efficient way and making applications simple to develop and maintain (Koch 2005).
Advantages of service oriented architecture to an organization
The first advantage is code mobility; this is made possible by one major service oriented architecture attribute described as location transparency. This is the ability of different users of a certain resource to be able to use a particular resource concurrently or at different hours without caring or knowing anything about the location of the resource. This consequently gives an organization the freedom to transfer services to different stations or external source.
The second advantage is improved security. The availability of a service layer in a web system protocol has provided a network interface that can be used by many applications concurrently or at different hours with each having its own security mechanism. This is unlike in the days when systems were developed by client-server strategies where security was usually managed at the front end.
Better maintainability is also another advantage of the SOA. Maintenance in Software development involves locating and correcting errors or defects in a piece of code to enable a system meet the new and arising needs of its users. When an organization possesses a system where by for its business logic it focuses on the service layer of its architecture, then maintenance can be handled with relative ease since the developer of the system can locate and correct errors more easily.
Another advantage is that in SOA there is enhanced reuse. Code reuse has proved difficult to achieve because of programming languages and platform incompatibilities but service reuse on the other hand has proved to be easily achievable.
Service oriented architecture has also brought about better monetary gains to different organizations. Under this architecture different distinct services are mapped to different system domains e.g. having the inventory managed on an inventory service created for it with all the logic on the other hand managed in a different layer that can exist even well past the lifetime of the system it is defined in.
Another notable advantage is that it offers a medium that enhances better testing techniques with fewer errors or defects. The reason is that system services have provided better interfaces that can be easily tested, requiring developers to only write unit tests suites using tools like JUnit. Therefore with this improved and effective testing mechanism there is guaranteed high quality of software with reduced defects.
Another advantage of service oriented architecture is its ability to support a wide variety of users with different skills and abilities. Companies, irrespective of their number and client type, are able to access services with a lot of ease simply because we have the layers divided into client and service layer making it easy to implement different client types (Sadd 2006).
Service oriented architecture also carries with it the benefit of high availability. It is also important to note that this is as result of location transparency whereby there could be many instances of a particular service executing on multiple servers. At the point where a section of the network is interrupted, a device known as the dispatcher can therefore redirect user requests to a different service all this without his or her knowledge. Better scalability of systems has also proved to be of great benefit in system oriented architecture.
Another advantage is that there is improved parallelism in the development of software applications whereby different developers can work on different layers independently without colluding with each other. This can be constructively done by pre-planning on how to allocate the developers to work on different layers depending on their skills and experience on a well documented agreement.
Lastly, the service oriented architecture enhances focused software developer responsibilities whereby in each layer of the software application, there are distinct roles defined for developers requiring a certain set of skills or technical know-how. This therefore in a way offers room for specialization which in hand improves the chance for project success.
Challenges in the implementation
Implementation in software development involves converting designs into a programming language code (Booch 1993). Before implementing service oriented architecture it is important therefore to first have a proper design of the components and the services that will be involved (Hunt 2002). There must also be a clear plan and a proper understanding of an organization’s set standards to ensure a systematic approach is followed in the implementation (Gruman 2006). During the implementation of service oriented architecture, an organization faces a number of challenges that it must consider when making strategic decisions. These challenges are;
Service identification: it is very crucial for an organization to be able to identify the kind of services they need and the corresponding providers to be able to easily develop a service oriented architectural system that do actually meet the needs of its intended users. This should be done bearing in mind the specific user requirements and maybe also a detailed study of the current organizational study.
Service location: in a distributed system, the execution of a service can lead to data being spread across many applications. This in turn could lead to the generation of multiple instances of the system record for the same business entity bearing in mind that the system record is the location for service execution. This therefore offers a challenge in the location of a service. It is therefore important to mention that there are three ways to address this challenge and this is through content routing, service repository-based routing and finally the black-end replication approach.
Another challenge is that of defining the service domain. The grouping of services in logical domains usually makes it easier for organizations to understand and interact with their systems since the amount of modules or components are reduced in the architectural design of the system. The challenge therefore usually arises in determining the required definition of service domains simply because it usually becomes a problem for organizations and the group of developers to come to agree on this. A lot of interest groups and personal interests usually come to play and this might therefore delay the implementation or even stall the whole process. This can therefore be addressed by implementing different units across different platforms.
Another challenge encountered during the implementation of service oriented architecture is that of service packaging. There are computers that experience difficulty showing their functionality as services e.g. the mainframe based legacy systems which were developed back in the day as monolithic systems having all the rules and the logic required for processing in the same system (Surhone 2009).
. In contrast service oriented architecture proposes a situation whereby a service exists on its own without the consent of the other existing services. The challenge therefore arises in determining a way of re-packaging these mainframe systems into independent self existing services. To address this challenge it is advisable to distribute the applicable pieces of program to well defined logical business areas and then inter-linking these pieces of code.
The next challenge is that of routing services. Location transparency is one of the major attributes of service oriented architectures whereby the users of these services are able to access and make use of them without bothering to know where they are located. The challenge arising here therefore is how to support location transparency without interfering with the performance of the system. It is therefore important to bring to our attention that to address this we are supposed to develop location information concerned with each service forming part of the whole system architecture. This can also be addressed by transferring all the intelligence created for routing from all the individual services to a single module specifically created for routing.
Another challenge worth noting in service oriented architecture is that of governance. When modifying current systems or even development of new ones, there are several logical and technical methodologies to be followed. A challenge here therefore arises in determining the person who should evaluate the system, define and give the go ahead on how and when to carry out the required changes to the existing components of services offered within an organization. In order for an organization to address this effectively and conveniently it should establish a governing body from within. There are a number of governance mechanisms that can come into play here e.g. the strong central governance whereby each department of an organization as well as those groups that do not have direct influence to the issue at hand are well represented. The other governance model applicable is the distributed approach whereby unlike the central system, each business department has got full unchallenged control over how services provision is made within its particular unit in an organization.
The next challenge is that of how to adopt service messaging standards. Different business units within an organization due different interests at times may have a difficulty agreeing on a single standard of operation. To address this, it is advisable to be able to determine and define a way in which different business units within an organization can agree to work based on a single standard but in various ways.
Commercial platforms applicable in the implementation of service oriented architecture
WebSphere: This is an IBM platform that is very popular in electronic business. It is an open source platform that gives its users the right to access and use its source code for free without legal actions. It is effective in facilitating fast delivery of results within an organization due to its high adaptability i.e. its ability to support a wide variety of users with different skills and abilities. This therefore translates to a high business growth rate. Structurally, it is a platform that enables organizations to create, implement and integrate different applications that support organizations daily operations. One of its advantages is that it promotes its different class of users’ experiences, meeting their distinct needs (Karim 2004). Another advantage is that it provides a mechanism for integrating applications and automation of daily operations for effective delivery of services.
BizTalk Server: This is a platform that was developed by Microsoft Cooperation with the IT and architectural industry in mind. It facilitates the integration of applications, organization’s workers as well as the other business partners (Woolston 2007). A unique feature seen in this platform is its ability to interlink services which are not web service enabled.
Tibco: This is a platform that provides a mechanism for integrating a wide variety of business units or modules to come up with a new application. It enhances the reuse of mainframe services which can be integrated to form new distinct services (Gurnani 2009).
When you compare the three platforms mentioned above, it is evident that they have a high standard of compatibility. They can support a wide variety of applications developed on different platforms, supporting different types of services and have nothing much in contrast.
Introduction of a service oriented architecture in an organization.
To introduce service oriented architecture in an organization, personally I would advice to a component based approach instead of a complete overhaul of the current system. The component based method could take an approach whereby the less complex components of a new system are introduced in a progressive way as a detailed analysis and evaluation is carried out to locate and correct defects. One major benefit of this approach that would be seen in the implementation of a system is the ease with which progress is showed. It is important also to mention that this approach has some risks too that a development team could come across. These risks include: the ability of business logic to keep evolving which could then lead to redundancy. Another risk associated with this approach is that it may take long to completely introduce a new system to an organization and eventually this could lead to an even higher cost of introduction in terms of finances.
Conclusion
In conclusion therefore, it has been noted that in many organizations IT departments with time are forced to manage increasingly large dockets. As the needs of a business continue to change, all organizations are supposed to ensure that all their resources are directed towards meeting their goals. To ensure this, service oriented architectural designs are the best for doing business. As the report shows in details, the benefits accrued from this architecture out-weighs the risks associated and essentially enhances effective and efficient ways of doing business. Still on the same, this architecture has proved to be convenient due to its compatibility with many different operational platforms and therefore I would recommend all organization to move towards this kind of technology (Fowler 2002).
Reference list
Booch, G, 1993, Object oriented analysis and design with applications, 2nd edition. Boston: Addison Wesley Professional.
Fowler, M, 2002, ’Public versus Published Interfaces’, IEEE Software, Vol.19, No. 2, pp. 18-19.
Gurnani, A, 2009, Web development with TIBCO general interface. Massachusetts: Addison Wesley.
Gruman, G, 2006, ‘Service oriented architecture: True challenge… ain’t technology’. CIO Magazine, vol.6, issue 1, 121-133.
Hunt, A & Thomas, D, 2002, ‘Software Archaeology’, IEEE Software, Vol. 19, No. 2, pp. 20-22.
Karim, Y, 2004, Enterprise messaging using JMS and the IBM Web-Sphere. New Jersey: Pearson Education Inc.
Koch, C, March 2005, ‘A new blueprint for the enterprise’, CIO Magazine, vol. 34, issue 2, 552-561.
Marks, E & Bell, 2006, Service oriented architecture: A planning and implementation guide for business and technology. London: Wiley.
Sadd, J, 2006 ‘If service oriented architecture looks hard to you, you are looking at it wrong’, DM Review Magazine, Vol.12, Issue 3, 221-229.
Slama, K, 2004, Service oriented architecture best practices. NJ: Prentice hall.
Surhone, M, 2009 Service-oriented Architecture: Computing, Service-oriented Architecture Implementation Framework, Service-oriented Modeling, Service Layer, Service Component Architecture. New York: Betascript Publishers.
Thomas, E, 2005, Service oriented architecture: concept, technology & design. Prentice Hall: New York.
Woolston, D, 2007, Foundations of BizTalk server 2006. New York: Springer-Verlag.