If you are planning to develop software using Service Oriented architecture
then it is advised to learn at least basics of Web Services.
The following books are recommended to learn basics of Web Services:
If you would like to appear for Sun's Web Service Developer certification then you can find preparation plan and exam cram notes here.
The promise of service oriented architecture is to liberate business from the constraints of technology and unshackle technologists from the chains they themselves have forged. This has major implications both for the business and for the IT that supports the business.
The main purpose of a service-oriented architecture (SOA) is to offer synergy between the business and IT groups in an organization and to offer the organization greater flexibility.
One of the biggest deals in the SOA world is the idea that you don’t throw things out. You take the stuff (software assets) that you use every day — well, the best of the stuff you use every day — and package it in a way that lets you use it, reuse it, and keep on reusing it.
With SOA, these important programs become business services. You end up with one single business service for a given function that gets used everywhere in your organization. With SOA, when you need to change a business policy, you change it in one place and, because the same service is used everywhere, you have consistency throughout your organization.
SOA uses the find-bind-execute paradigm. In this paradigm, service
providers register their service in a public registry. This registry is used by
consumers to find services that match certain criteria. If the registry has such
a service, it provides the consumer with a contract and an endpoint address for
that service.
SOA-based applications are distributed multi-tier applications that have
presentation, business logic, and persistence layers. Services are the building
blocks of SOA applications. While any functionality can be made into a service,
the challenge is to define a service interface that is at the right level of
abstraction. Services should provide coarse-grained functionality.
SOA allows for the reuse of existing assets where new services can be created from an existing IT infrastructure of systems. In other words, it enables businesses to leverage existing investments by allowing them to reuse existing applications, and promises interoperability between heterogeneous applications and technologies. SOA provides a level of flexibility that wasn't possible before in the sense that:
The Enterprise Service Bus (ESB): The ESB is actually an architectural
construct that can be designed and deployed in a manner that will parallel the
business processes environment. The bus can be implemented in various ways, such
as with classical messaging, EAI, and brokering technologies or by using
platform-specific components such as the service integration buses in J2EE
systems (such as WebSphere Application Server). The ESB can also be a
combination of both EAI and application server technologies, but the
implementation should not affect the overall architecture. The selection between
possible implementations will be the result of an initial architecture
assessment, including existing IT infrastructure, skills, and processes in the
evaluation.
Mediation in an ESB enables the intelligent processing of service
requests and responses, events, and messages. These mediations can be
implemented at application service endpoints (either requestor or provider) or
can be distributed through the infrastructure of the bus.
Mediation capabilities include the following:
Transformations: XML-to-XML translations, database (DB) lookups, and
aggregations.
Message validation: This can consist of verification of any data field or
a combination of fields with specific rules.
Content or quality service selections: This requires a service selection
based on content or on required quality of service. As an example, a priority
customer should probably be routed to a higher throughput server than others of
lesser priority.
Content-based routing: As an example, if the service parameters contain
some country information, the request can be routed to a provider in that
country.
Customized logging: This is a legal requirement that might ask for
logging and audit tracks of the services interactions. Mediation is potentially
a good place for this purpose.
Metering and monitoring: A bus should have all of the manageability
anchor points to enable control of its behavior and of the integrated services.
Autonomic behavior: This is used to react when events are detected—to
self-configure, heal, optimize, and so on.
Policy management: This allows a description of all of the behavior rules
that are required for the previous items in this list through externalized
policies based on XML.
Mediators are intermediary components that operate on logical Web service SOAP message representations between the requestor and the provider. These mediator components can be located close to requestors, providers, or halfway between both requestors and providers as true intermediaries. SOAP messages usually contain a header that has to be processed by the mediation handlers, but mediation can be used for purposes other than just SOAP processing and routing.
You can implement an ESB in many different ways. It is important, however, to reuse whatever standard infrastructure services already exist, ensuring compatibility and reliability. Thus, in a best-practice-based implementation, mediators should use the standard Java Web services SOAP-handling standard: JAX-RPC. This standard provides access to the SOAP headers via the handler API and can be hosted in a J2EE application server infrastructure. Handlers can be easily chained in series and reused across systems. In addition, using embedded mediations, the ESB supports a broad spectrum of ways to hop on and off the bus. The ESB includes business connections that enable external partners in B2B interaction scenarios to participate in the service interaction flows. In this B2B case, it provides the additional mediations and security that external access imposes. Mediation on the protocols that attach to the bus enables the connectivity with existing service-oriented components. These protocols include CORBA, RMI/IIOP, TCP/IP, JCA, native JMS, and other Java protocols.
A Web services gateway is an additional component of a bus that
provides controlled access to the bus for external partners, hiding details of
individual internal services, validating user access, controlling access, and
auditing requests. The gateway uses core bus components such as mediation and
security to implement its routing and management services.
Because business processes are essential to the SOA approach, the model must
also integrate an additional standard for this aspect: the Business Process
Execution Language (BPEL). BPEL is used by business analysts to model the
business processes and by programmers to implement the choreography of services.
SOA implementation guidelines:
Every vendor provides some guidelines to asses your organizations SOA readiness. Once you have assessed your current architecture and deployment, these are some basic guidelines to move towards SOA.
SOA Maturity Levels
A complete overnight realization of SOA is not a viable solution. Implementing SOA is a five step process.
Level1: Initial Service - In the first stage companies service-enable
their applications using standard APIs. The costs are modest.
Level2: Architected Service- In second stage companies use SOA services
to build new or refractor existing integration points. The company should
establish visibility into the entire service list and their consumers. It
becomes feasible to reuse services because more thought is put into policies
that services must adhere to, such as security and uptime requirements.
Level3: Business and Collaborative Service - Third stage involves the
introduction of business-oriented services, such as business process management
(BPM). With a focus on the partnership between technology and business
organizations, Level 3 optimizes the flexibility of business processes, allowing
IT to respond quickly to changing business requirements.
Level4: Measured business services - Level 4 provides continuous feedback
on the performance and business impact of the processes implemented at Level 3.
The key focus at this level is collecting data and providing that data to
business users, enabling them to transform the way they respond to events. It
could involve logging and monitoring service health constantly.
Level5: Optimized business services - At this final level,
business-optimization rules are added, and the SOA becomes the nervous system
for the enterprise. Automatic responses to the measurements and displays of
Level 4 allow an organization to take immediate action on events. A Level 5
project can take the request messages entering the ESB and route that
information to an event-stream processor. This service correlates the behavior
of all traders across multiple execution venues and identifies important
patterns. This information might be used to execute new trades or stop a rogue
trader who is out of view of compliance officers.
There are several SOA lifecycle stages mentioned by different vendors.
Soa levels defines by SOA consortium:
Soa levels defined by BEA:
References:
Service Oriented Enterprise by Setrag khoshafian
Service Oriented Architecture For Dummies
Service-Oriented Architecture Compass: Business Value, Planning, and Enterprise
Roadmap
By Norbert Bieberstein,, Sanjay Bose,, Marc Fiammante,, Keith Jones,, Rawn Shah
SOA for the Business Developer: Concepts, BPEL, and SCA, First Edition
byBen MargolisandJoseph Sharpe