|
| |
Service Oriented Architecture
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:
- Prentice Hall-J2EE™ Platform Web Services by Ray Lai
- Addison Wesley- J2EE Web Services by By Richard Monson-Haefel
- Sam's Securing Web Services with WS-Security by Jothy Rosenberg, David L.
Remy
If you would like to appear for Sun's Web Service Developer certification
then you can find preparation plan and exam cram notes
here.
Service Oriented Architecture Primer:
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:
- Services are software components with well-defined interfaces that are
implementation-independent. An important aspect of SOA is the separation of
the service interface (the what) from its implementation (the how). Such
services are consumed by clients that are not concerned with how these
services will execute their requests.
- Services are self-contained (perform predetermined tasks) and loosely
coupled (for independence)
- Services can be dynamically discovered
- Composite services can be built from aggregates of other services
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.
- Use blueprint instead of starting from scratch. Do not reinvent the wheel.
Build on other's experiences.
- Make sure the SOA project you choose for your starting point is well
defined and well confined. Prove SOA successful with something that is small,
is achievable in a short time, and will have a significant impact — then build
incrementally.
- Stick to standards and standard interfaces. The proprietary software you
build will be your own downfall. The sooner you part ways from evil
temptations, the happier and healthier your software can be.
- Don’t Neglect Governance: SOA governance won’t happen by itself. Address
it early. SOA governance is as much about the way you work and the processes
you put in place to create a SOA environment as it is about any technology
issues. So, don’t just go and buy a bucket full of tools labeled SOA
governance. SOA governance is about leadership and thinking through how you
are going to get from where you are today to a well-coordinated approach that
conforms to your corporate goals and objectives.
- Pay close attention to the security implications of exposing business
services.
- SOA makes a lot of sense for a lot of things, but not for everything. If
you have an application that is so specialized that it is isolated from other
aspects of the business and works just fine, leave it alone. At the same time,
when you find the software that is appropriate for SOA, you need to
prioritize, scrutinize, and make sure you’re looking at the right level of
granularity. For example, if you make each service very small, you might end
up with thousands of little pieces of code that are hard to find and hard to
reuse. The bigger the reusable service, the easier it will be to find and
reuse. And some things need never, ever be exposed as services.
- Don’t Postpone SOA: SOA is a long journey. The sooner you begin, the
sooner you’ll get somewhere.
- SOA is an architectural style that has been around for years. Web services
are the preferred way to realize SOA.
- SOA is more than just deploying software. Organizations need to analyze
their design techniques and development methodology and
partner/customer/supplier relationship.
- Moving to SOA should be done incrementally and this requires a shift in
how we compose service-based applications while maximizing existing IT
investments.
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
|
