Implementing SOA Using Java EE: Evolution of Service Oriented Architecture
- Services Oriented ArchitectureThe Description
- Early Architectures
- Paradigm Shifts
- Arrival of Web Services and SOA
- SOA Implementation Technologies
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
The requirement of service orientation for the enterprises first emerged with the advent of the Internet and World Wide Web. The IT world has since witnessed numerous paradigm shifts, as newer technologies such as XML and Java impacted enterprise solution requirements. The business of "service delivery" started gaining momentum among the enterprises and their collaborators. But the IT definition of the term "service" was not aligned with that of the business definition, and this cohesion was crucial for the enterprises to remain competitive in the dynamically changing market conditions. Evolution of business components such as Enterprise JavaBeans, as a part of J2EE technologies, on the one hand, and the emergence of core constituents of web services such as SOAP, WSDL, and UDDI, on the other, provided the opportunity to draft service definitions in alignment with the business requirements. Furthermore, the eventuality of loosely composing these services and binding them with the business process of the enterprise resulted in the arrival of Service Oriented Architecture (SOA).
The idea of SOA is not completely new. Different forms of service orientations were previously attempted and implemented as enterprise solutions by many vendors on different businesses and enterprises during the era of client/server. These architectures were implemented as enterprise solutions with different degrees of success, but they were never known or termed as SOAs during those eras. Regardless, none of these attempts could be considered successful implementation of SOAs. Before the arrival of XML and other web services, SOAs, (though not referred to as such), were implemented as a solution, without snazzy name and fanfare. In this chapter, we first explore the concept of service orientation and then analyze how the emergence of different architectures' combined paradigm shifts in enterprise technologies led to the evolution of web services and SOA.
Services Oriented Architecture—The Description
SOA can be described as a unique style of architecting and designing the enterprise solution using business services throughout the life cycle—from concept to retirement. SOA also enables for provisioning the IT infrastructure of the enterprise so that disparate applications1 can exchange data as a part of the business process.
Business services can be defined as a set of actions or tasks an organization provides to different service stakeholders. Some of the service stakeholders are customers, collaborators, clients, employees, and so on. Consider that whereas an SOA can be defined as an approach to building IT systems, the business services are considered the key organizing principle for aligning IT systems for business needs.
The key point here is business services and alignment of IT infrastructure as per business services and business process requirement. Service orientation, therefore, enables the architects to focus on the description of the business problem rather than any development or execution environment of the enterprise solution. Because these two are delinked, a business solution that is architected as per SOA would be loosely coupled, flexible in nature, and allow implementation of dynamic needs of the enterprise business requirements.
It is important to notice here that the description of SOA does not mention the requirement of web services technologies as a prerequisite. Technologies such as CORBA or J2EE can still be efficiently and effectively used to implement the enterprise solution so that enterprise architecture is service oriented. However, what is crucial in the context of service orientation is the possibility of separating the service interface from the execution environment. An SOA that is appropriately implemented provides a scope in which it is possible to mix and match the execution environment.