service oriented architectures (SOA), including today's most commonly
posed problems of security and quality. By ignoring security and
quality in the development cycle corporations risk exposing themselves
to a multitude of risks that will further hinder them throughout the
services lifecycle.
Andrew Nash Several keys exist in the SOA and Web services lifecycle,
but it boils down to a list of five keys to avoid security,
reliability and compliance issues.
First and foremost is simulating the production environment in
development. One of the most important steps in bulletproofing SOA and
Web services is ensuring developers have an environment that simulates
the production reality. A service that is great in development can
have holes once it hits production, resulting in significant time
delays and cost overruns. By developing the service in near-proximity
to the production environment, the number of surprises when the
service hits the production environment is suppressed, resulting in
less time needed to tend to those surprises. For example, if a
corporation's production environment is going to leverage
intermediaries (such as XML Gateways), the development environment
should be developing with the intermediaries. Furthermore, the
development and test team must have access to a SOA aware testing
environment to emulate the production environment.
Second is to articulate policies for consumers and providers and make
trade-offs regarding compatibility, security and throughput. A client
needs to behave as expected when messages are received from the
service. This includes figuring out what fields to encrypt, while also
mapping the identity authorities of consumers to providers.
Third is creating and testing messages for both the service customer
and the service provider. Once the policies are articulated it is
necessary to test them. Doing so requires the creation of both
positive and negative test messages that put the policies, services
and intermediaries under stress. In order to eliminate surprises,
positive, negative and random variations of the test messages must be
sent to exercise the different policies.
Fourth is testing each consumer and provider separately for every
policy and potential exception to be used in production. Fire messages
at the gateway and monitor what happens. Tests include:
What authentication methods are going to be accepted?
What happens when they come and what happens if something different
is received?
Is SSL going to be used?
Can bilateral handshakes be handled efficiently?
Are credentials to be mapped?
What is the mapping mechanism and logic?
Schema validation
Authorization - not just who is coming in, but what service are the
allowed to access?
Content-based routing: testing for a different route than what the
policy specifies.
Message transformation
Protocol mediation
Fire malicious content at the service; what happens if there is bad,
mal-formed content in the XML?>>
You can read the article in full at:
http://news.zdnet.com/2100-9593_22-6076996.html?tag=zdnn.alert
Gervas
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
