You are on page 1of 4

IT2401 SERVICE ORIENTED ARCHITECTURE LTPC 3003 OBJECTIVES: To gain understanding of the basic principles of service orientation To learn

rn service oriented analysis techniques To learn technology underlying the service design To learn advanced concepts such as service composition, orchestration and Choreography To know about various WS-* specification standards UNIT I 9 Roots of SOA Characteristics of SOA - Comparing SOA to client-server and distributed internet architectures Anatomy of SOA- How components in an SOA interrelate Principles of service orientation UNIT II 9 Web services Service descriptions Messaging with SOAP Message exchange Patterns Coordination Atomic Transactions Business activities Orchestration Choreography - Service layer abstraction Application Service Layer Business Service Layer Orchestration Service Layer UNIT III 9 Service oriented analysis Business-centric SOA Deriving business services- service modeling - Service Oriented Design WSDL basics SOAP basics SOA composition guidelines Entity-centric business service design Application service design Taskcentric business service design UNIT IV 9 SOA platform basics SOA support in J2EE Java API for XML-based web services (JAX-WS) - Java architecture for XML binding (JAXB) Java API for XML Registries (JAXR) - Java API for XML based RPC (JAX-RPC)- Web Services Interoperability Technologies (WSIT) - SOA support in .NET Common Language Runtime - ASP.NET web forms ASP.NET web services Web Services Enhancements (WSE) UNIT V 9 WS-BPEL basics WS-Coordination overview - WS-Choreography, WS-Policy, WSSecurity TOTAL = 45 PERIODS TEXT BOOKS: 1. Thomas Erl, Service-Oriented Architecture: Concepts, Technology, and Design, Pearson Education, 2005. REFERENCES: 1. Thomas Erl, SOA Principles of Service Design (The Prentice Hall Service-Oriented Computing Series from Thomas Erl), 2005. 2. Newcomer, Lomow, Understanding SOA with Web Services, Pearson Education, 2005. 3. Sandeep Chatterjee, James Webber, Developing Enterprise Web Services, An Architects Guide, Pearson Education, 2005. 4. Dan Woods and Thomas Mattern, Enterprise SOA Designing IT for Business Innovation OREILLY, First Edition, 2006

4.3. The roots of SOA (comparing SOA to past architectures)

4.3.1. What is architecture? For as long as there have been computerized automation solutions, technology architecture has existed. However, in older environments, the construction of the solution was so straight forward that the task of abstracting and defining its architecture was seldom performed.With the rise of multi-tier applications, the variations with which applications could be delivered began to dramatically increase. IT departments started to recognize the need for a standardized definition of a baseline application that could act as a template for all others. This definition was abstract in nature, but specifically explained the technology, boundaries, rules, limitations, and design characteristics that apply to all solutions based on this template. This was the birth of the application architecture.
Application architecture

Application architecture is to an application development team what a blueprint is to a team of construction workers. Different organizations document different levels of application architecture. Some keep it high-level, providing abstract physical and logical representations of the technical blueprint. Others include more detail, such as common data models, communication flow diagrams, application-wide security requirements, and aspects of infrastructure. It is not uncommon for an organization to have several application architectures. A single architecture document typically represents a distinct solution environment. For example, an organization that houses both .NET and J2EE solutions would very likely have separate application architecture specifications for each. A key part of any application-level architecture is that it reflects immediate solution requirements, as well as long-term, strategic IT goals. It is for this reason that when multiple application architectures exist within an organization, they are almost always accompanied by and kept in alignment with a governing enterprise architecture.
Enterprise architecture

In larger IT environments, the need to control and direct IT infrastructure is critical. When numerous, disparate application architectures co-exist and sometimes even integrate, the demands on the underlying hosting platforms can be complex and onerous. Therefore, it is common for a master specification to be created, providing a high-level overview of all forms of heterogeneity that exist within an enterprise, as well as a definition of the supporting infrastructure. Continuing our previous analogy, an enterprise architecture specification is to an organization what an urban plan is to a city. Therefore, the relationship between an urban plan and the blueprint of a building are comparable to that of enterprise and application architecture specifications. Typically, changes to enterprise architectures directly affect application architectures, which is why architecture specifications often are maintained by the same group of individuals. Further, enterprise architectures often contain a long-term vision of how the organization plans to evolve its technology and environments. For example, the goal of phasing out an outdated technology platform may be established in this specification. Finally, this document also may define the technology and policies behind enterprise-wide security measures. However, these often are isolated into a separate security architecture specification.

Service-oriented architecture