IT2401 Service Oriented Architecture (SOA) - Important / Expected Question for NOV/DEC 2013

IT 2401 SOA

(INFORMATION TECHNOLOGY)

EXPECTED QUESTIONS FOR NOV/DEC 2013

UNIT I

1. Characteristics of SOA.
2. Comparing SOA to Client-Server and Distributed Architecture.
3. Principles of Service Orientation.


UNIT II

1.  Messaging with SOAP.
2.  Message Exchange Pattern.
3. Atomic Transaction.
4. Service Layer Abstraction.


UNIT III

1. Service Oriented Analysis.
2. Service Oriented Modelling.
3. Service Oriented Designing.
4. WSDL Basic & SOAP Basic.


UNIT IV

1. WS support in J2EE.
2. WS support in .NET


UNIT V

1. WS-Policy.
2. WS-Security.
3. WS BPEL Basics.



All the best :)

IT2401 SERVICE ORIENTED ARCHITECTURE SYLLABUS - VII SEMESTER - FINAL YEAR - IT DEPARTMENT

IT2401 SERVICE ORIENTED ARCHITECTURE

UNIT I

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

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

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

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

Architect’s Guide”, Pearson Education, 2005.

4. Dan Woods and Thomas Mattern, “Enterprise SOA Designing IT for Business

Innovation” O’REILLY, First Edition, 2006

Contemporary SOA is an achievable ideal

Contemporary SOA is an achievable ideal

A standardized enterprise-wide adoption of SOA is a state to which many organizations would like to fast-forward. The reality is that the process of transitioning to this state demands an enormous amount of effort, discipline, and, depending on the size of the organization, a good amount of time. Every technical environment will undergo changes during such a migration, and various parts of SOA will be phased in at different stages and to varying extents. This will likely result in countless hybrid architectures, consisting mostly of distributed environments that are part legacy and part service-oriented.

Further supporting this prediction is the evolving state of the technology set that is emerging to realize enterprise-level SOAs. As companies adopt SOA during this evolution, many will need to retrofit their environments (and their standards) to accommodate changes and innovations as SOA-related specifications, standards, and products continue to mature.

However, the majority of the contemporary SOA characteristics we just covered are attainable today. This book provides a series of tutorials and step-by-step process descriptions that explain how to manifest them.

Contemporary SOA is still maturing

Contemporary SOA is still maturing

While the characteristics described so far are fundamental to contemporary SOA, this point is obviously more of a subjective statement of where SOA is at the moment. Even though SOA is being positioned as the next standard application computing platform, this transition is not yet complete. Despite the fact that Web services are being used to implement a great deal of application functionality, the support for a number of features necessary for enterprise-level computing is not yet fully available.

Standards organizations and major software vendors have produced many specifications to address a variety of supplementary extensions. Additionally, the next generation of development tools and application servers promises to support a great deal of these new technologies. When SOA platforms and tools reach an adequate level of maturity, the utilization of Web services can be extended to support the creation of enterprise SOA solutions, making the ideal of a service-oriented enterprise attainable.

If you needed to provide an accurate definition of SOA today, you would not be out of line to mention the state of its underlying technology. Considering the rate at which the IT industry as a whole is adopting and evolving the SOA platform, though, it should not be too long before an accurate definition will no longer require this statement.

Contemporary SOA is an evolution

Contemporary SOA is an evolution

SOA defines an architecture that is related to but still distinct from its predecessors. Itdiffers from traditional client-server and distributed environments in that it is heavily influenced by the concepts and principles associated with service-orientation and Web services. It is similar to previous platforms in that it preserves the successful characteristics of its predecessors and builds upon them with distinct design patterns and a new technology set.

For example, SOA supports and promotes reuse, as well as the componentization and distribution of application logic. These and other established design principles that are commonplace in traditional distributed environments are still very much a part of SOA.

Contemporary SOA is a building block

Contemporary SOA is a building block


A service-oriented application architecture will likely be one of several within an organization committed to SOA as the standard architectural platform. Organizations standardizing on SOA work toward an ideal known as the service-oriented enterprise (SOE), where all business processes are composed of and exist as services, both logically and physically.

When viewed in the context of SOE, the functional boundary of an SOA represents a part of this future-state environment, either as a standalone unit of business automation or as a service encapsulating some or all of the business automation logic. In responding to business model-level changes, SOAs can be augmented to change the nature of their automation, or they can be pulled into service-oriented integration architectures that require the participation of multiple applications.

What this all boils down to is that an individual service-oriented application can, in its entirety, be represented by and modeled as a single service. As mentioned earlier, there are no limits to the scope of service encapsulation. An SOA consists of services within services within services, to the point that a solution based on SOA itself is one of many services within an SOE.

This past set of characteristics has further broadened our definition. Let's append the definition with the following:


SOA can establish an abstraction of business logic and technology that may introduce changes to business process modeling and technical architecture, resulting in a loose coupling between these models. These changes foster service-orientation in support of a service-oriented enterprise .

Contemporary SOA promotes organizational agility

Contemporary SOA promotes organizational agility

Whether the result of an internal reorganization, a corporate merger, a change in an organization's business scope, or the replacement of an established technology platform, an organization's ability to accommodate change determines the efficiency with which it can respond to unplanned events.

Change in an organization's business logic can impact the application technology that automates it. Change in an organization's application technology infrastructure can impact the business logic automated by this technology. The more dependencies that exist between these two parts of an enterprise, the greater the extent to which change imposes disruption and expense.

By leveraging service business representation, service abstraction, and the loose coupling between business and application logic provided through the use of service layers, SOA offers the potential to increase organizational agility (Figure 3.16).
Figure 3.16. A loosely coupled relationship between business and application technology allows each end to more efficiently respond to changes in the other.






Other benefits realized through the standardization of SOA also contribute to minimizing dependencies and increasing overall responsiveness to change: notably, the intrinsic interoperability that can be built into services and the open communications framework established across integration architectures that enable interoperability between disparate platforms. Change imposed on any of these environments is more easily facilitated for the same reasonsa loosely coupled state between services representing either ends of the communication channel.

Organizational agility is perhaps the most significant benefit that can be realized with contemporary SOA.

Contemporary SOA promotes loose coupling throughout the enterprise

Contemporary SOA promotes loose coupling throughout the enterprise

As we've established, a core benefit to building a technical architecture with loosely coupled services is the resulting independence of service logic. Services only require an awareness of each other, allowing them to evolve independently.

Now, let's take a step back and look at the enterprise as a whole. Within an organization where service-orientation principles are applied to both business modeling and technical design, the concept of loose coupling is amplified.

By implementing standardized service abstraction layers, a loosely coupled relationship also can be achieved between the business and application technology domains of an enterprise (Figure 3.15). Each end only requires an awareness of the other, therefore allowing each domain to evolve more independently. The result is an environment that can better accommodate business and technology- related changea quality known as organizational agility.
Figure 3.15. Through the implementation of service layers that abstract business and application logic, the loose coupling paradigm can be applied to the enterprise as a whole.

Contemporary SOA implements layers of abstraction

Contemporary SOA implements layers of abstraction

One of the characteristics that tends to evolve naturally through the application of service-oriented design principles is that of abstraction. Typical SOAs can introduce layers of abstraction by positioning services as the sole access points to a variety of resources and processing logic.

When applied through proper design, abstraction can be targeted at business and application logic. For example, by establishing a layer of endpoints that represent entire solutions and technology platforms, all of the proprietary details associated with these environments disappear (Figure 3.14). The only remaining concern is the functionality offered via the service interfaces.
Figure 3.14. Application logic created with proprietary technology can be abstracted through a dedicated service layer.






It is the mutual abstraction of business and technology that supports the service-oriented business modeling paradigm we discussed and further establishes the loosely coupled enterprise model explained in the following section.

Contemporary SOA supports a service-oriented business modeling paradigm

Contemporary SOA supports a service-oriented business modeling paradigm

In our description of a primitive SOA, we briefly explored how business processes can be represented and expressed through services. Partitioning business logic into services that can then be composed has significant implications as to how business processes can bemodeled (Figure 3.13). Analysts can leverage these features by incorporating an extent of service-orientation into business processes for implementation through SOAs.
Figure 3.13. A collection (layer) of services encapsulating business process logic.






In other words, services can be designed to express business logic. BPM models, entity models, and other forms of business intelligence can be accurately represented through the coordinated composition of business-centric services. This is an area of SOA that is not yet widely accepted or understood . We therefore spend a significant portion of this book exploring the service-oriented business modeling paradigm.

Contemporary SOA emphasizes extensibility

Contemporary SOA emphasizes extensibility

When expressing encapsulated functionality through a service description, SOA encourages you to think beyond immediate, point-to-point communication requirements. When service logic is properly partitioned via an appropriate level of interface granularity, the scope of functionality offered by a service can sometimes be extended without breaking the established interface (Figure 3.12).
Figure 3.12. Extensible services can expand functionality with minimal impact.






Extensibility is also a characteristic that is promoted throughout SOA as a whole. Extending entire solutions can be accomplished by adding services or by merging with other service-oriented applications (which also, effectively, "adds services"). Because the loosely coupled relationship fostered among all services minimizes inter-service dependencies, extending logic can be achieved with significantly less impact.

Time to revisit our original definition to add a few adjectives that represent the characteristics we've covered.


Contemporary SOA represents an open, extensible, federated, composablearchitecture that promotes service-orientation and is comprised of autonomous, QoS-capable, vendor diverse, interoperable, discoverable , andpotentially reusable services, implemented as Web services .

Contemporary SOA fosters inherent reusability

Contemporary SOA fosters inherent reusability

SOA establishes an environment that promotes reuse on many levels. For example, services designed according to service-orientation principles are encouraged to promote reuse, even if no immediate reuse requirements exist. Collections of services that form service compositions can themselves be reused by larger compositions.

The emphasis placed by SOA on the creation of services that are agnostic to both the business processes and the automation solutions that utilize them leads to an environment in which reuse is naturally realized as a side benefit to delivering services for a given project. Thus, inherent reuse can be fostered when building service-oriented solutions (Figure 3.11).
Figure 3.11. Inherent reuse accommodates unforeseen reuse opportunities.

Contemporary SOA promotes architectural composability

Contemporary SOA promotes architectural composability


Composability is a deep-rooted characteristic of SOA that can be realized on different levels. For example, by fostering the development and evolution of composable services, SOA supports the automation of flexible and highly adaptive business processes. As previously mentioned, services exist as independent units of logic. A business process can therefore be broken down into a series of services, each responsible for executing a portion of the process.

A broader example of composability is represented by the second-generation Web services framework that is evolving out of the release of the numerous WS-* specifications. The modular nature of these specifications allows an SOA to be composed of only the functional building blocks it requires.

What provides this flexibility is the fact that second-generation Web services specifications are being designed specifically to leverage the SOAP messaging model. Individual specifications consist of modular extensions that provide one or more specific features. As the offering of WS-* extensions supported by a given vendor platform grows, the flexibility to compose allows you to continue building solutions that only implement the features you actually need (Figure 3.10). In other words, the WS-* platform allows for the creation of streamlined and optimized service-oriented architectures, applications, services, and even messages.
Figure 3.10. Different solutions can be composed of different extensions and can continue to interoperate as long as they support the common extensions required.






With respect to our definition, let's represent this characteristic by describing the architecture as a whole as being composable. This represents both composable services, as well as the extensions that comprise individual SOA implementations.

Contemporary SOA promotes federation

Contemporary SOA promotes federation

Establishing SOA within an enterprise does not necessarily require that you replace what you already have. One of the most attractive aspects of this architecture is its ability to introduce unity across previously non-federated environments. While Web services enable federation, SOA promotes this cause by establishing and standardizing the ability to encapsulate legacy and non-legacy application logic and by exposing it via a common, open, and standardized communications framework (also supported by an extensiveadapter technology marketplace ).

Obviously, the incorporation of SOA with previous platforms can lead to a variety of hybrid solutions. However, the key aspect is that the communication channels achieved by this form of service-oriented integration are all uniform and standardized (Figure 3.9).
Figure 3.9. Services enable standardized federation of disparate legacy systems.

Contemporary SOA fosters intrinsic interoperability

Contemporary SOA fosters intrinsic interoperability

Further leveraging and supporting the required usage of open standards, a vendor diverse environment, and the availability of a discovery mechanism, is the concept of intrinsic interoperability. Regardless of whether an application actually has immediate integration requirements, design principles can be applied to outfit services with characteristics that naturally promote interoperability.

When building an SOA application from the ground up, services with intrinsic interoperability become potential integration endpoints (Figure 3.8). When properly standardized, this leads to service-oriented integration architectures wherein solutions themselves achieve a level of intrinsic interoperability. Fostering this characteristic can significantly alleviate the cost and effort of fulfilling future cross-application integration requirements.
Figure 3.8. Intrinsically interoperable services enable unforeseen integration opportunities.

Contemporary SOA promotes discovery

Contemporary SOA promotes discovery


Even though the first generation of Web services standards included UDDI, few of the earlyimplementations actually used service registries as part of their environments. This may have to do with the fact that not enough Web services were actually built to warrant a registry. However, another likely reason is that the concept of service discovery was simply not designed into the architecture. When utilized within traditional distributed architectures, Web services were more often employed to facilitate point-to-point solutions. Therefore, discovery was not a common concern.

SOA supports and encourages the advertisement and discovery of services throughout the enterprise and beyond. A serious SOA will likely rely on some form of service registry or directory to manage service descriptions (Figure 3.7).
Figure 3.7. Registries enable a mechanism for the discovery of services.

Contemporary SOA supports vendor diversity

Contemporary SOA supports vendor diversity


The open communications framework explained in the previous section not only has significant implications for bridging much of the heterogeneity within (and between) corporations, but it also allows organizations to choose best-of-breed environments for specific applications.

For example, regardless of how proprietary a development environment is, as long as it supports the creation of standard Web services, it can be used to create a non-proprietary service interface layer, opening up interoperability opportunities with other, service-capable applications (Figure 3.6). This, incidentally, has changed the face of integration architectures, which now can encapsulate legacy logic through service adapters, and leverage middleware advancements based on Web services.

Organizations can certainly continue building solutions with existing development tools and server products. In fact, it may make sense to do so, only to continue leveraging the skill sets of in-house resources. However, the choice to explore the offerings of new vendors is always there. This option is made possible by the open technology provided by the Web services framework and is made more attainable through the standardization and principles introduced by SOA

Contemporary SOA is based on open standards

Contemporary SOA is based on open standards

Perhaps the most significant characteristic of Web services is the fact that data exchange is governed by open standards. After a message is sent from one Web service to another ittravels via a set of protocols that is globally standardized and accepted.

Further, the message itself is standardized, both in format and in how it represents its payload. The use of SOAP, WSDL, XML, and XML Schema allow for messages to be fully self-contained and support the underlying agreement that to communicate, services require nothing more than a knowledge of each other's service descriptions. The use of an open, standardized messaging model eliminates the need for underlying service logic to share type systems and supports the loosely coupled paradigm.

Contemporary SOAs fully leverage and reinforce this open, vendor-neutral communications framework . An SOA limits the role of proprietary technology to the implementation and hosting of the application logic encapsulated by a service. The opportunity for inter-service communication is therefore always an option.

Contemporary SOA is fundamentally autonomous

Contemporary SOA is fundamentally autonomous

The service-orientation principle of autonomy requires that individual services be as independent and self-contained as possible with respect to the control they maintain over their underlying logic. This is further realized through message-level autonomy where messages passed between services are sufficiently intelligence-heavy that they can control the manner in which they are processed by recipient services.

SOA builds upon and expands this principle by promoting the concept of autonomy throughout solution environments and the enterprise. Applications comprised of autonomous services, for example, can themselves be viewed as composite, self-reliant services that exercise their own self-governance within service-oriented integration environments.

Later we explain how by creating service abstraction layers, entire domains of solution logic can achieve control over their respective areas of governance. This establishes a level of autonomy that can cross solution boundaries.

Contemporary SOA increases quality of service

 Contemporary SOA increases quality of service

There is a definite need to bring SOA to a point where it can implement enterprise-levelfunctionality as safely and reliably as the more established distributed architectures already do.

This relates to common quality of service requirements, such as:

• The ability for tasks to be carried out in a secure manner, protecting the contents of a message, as well as access to individual services.
• Allowing tasks to be carried out reliably so that message delivery or notification of failed delivery can be guaranteed .
• Performance requirements to ensure that the overhead imposed by SOAP message and XML content processing does not inhibit the execution of a task.
• Transactional capabilities to protect the integrity of specific business tasks with a guarantee that should the task fail, exception logic is executed.

Contemporary SOA is striving to fill the QoS gaps of the primitive SOA model. Many of the concepts and specifications we discuss in Part IISOA and WS-* Extensions provide features that directly address quality of service requirements. For lack of a better term, we'll refer to an SOA that fulfills specific quality of service requirements as "QoS-capable."