SIA 102 –

Systems
Integration and
Architecture 2

MODULE 1.1 -
INTEGRATION
TECHNOLOGIE
SXML Integration Best Practices

What is XML
Integration?
 programming
it acts as a
“Translator” between

it allows different
suppliers
customers and
languages
 (usually XML) to compatible.
be

Types of XML Integration:

 INTEGRATI
ON
PULL XML
INTEGRATI
ON

PUSH XML

PUSH XML INTEGRATION suppliers provide clients

 their availability, rate, etc. suppliers must update
availabilities using XML suppliers are required to
update the information

PUSH XML INTEGRATION

Advantages
• suppliers do not have to support so much traffic

Disadvantages
• no activities occur in real time
• complex, and require more development time

PULL XML INTEGRATION

• It is a two-way system where clients send the request and the

• supplier responds to the request instantly the supplier is obliged to inform the
client about the changes in their system

PULL XML INTEGRATION

Advantages
• Real time communication

Disadvantages
• Support a higher traffic that needs bigger system investment

10 XML best practices

 5. Validate all messages
6. Transform all message
7. Sign all messages
1. Secure the transport layer 8. Timestamp all messages 9.
2. Implement XML filtering 3. Encrypt message fields 10.
Mask internal resources Implement secure auditing
4. Protect against XML denial-of
service attacks
1. Secure the transport layer
• XML Web Services rely on IP and HTTP as a transport layer to connect applications
and associated resources. Robust XML Web Services security is built on a strong
foundation of transport-layer security, so that sensitive information cannot be
intercepted and read in transit.
• SSL VPNs are simple to deploy and provide a flexible security model for securing
extranets. Furthermore, best practice includes the use of server certificates and
client certificates during the authentication process. Hardware-based accelerators
are the preferred way to secure the transport layer, while maintaining high
performance for transactions.
2. Implement XML filtering
• XML requires sophisticated processing to ensure that transactions are known
to be good before they penetrate deep within the organisation. XML filtering
provides managers with a range of functionality as complex rule-sets can be
built around network-level information, message size, message content and
other variables. Because filters are XML-based, they are easily updated as
new threats are detected. Setting up simple filters based on message size or
XML Digital Signatures is an easy place to start. As application usage
increases, filtering based on content and other parameters enables the
security staff to implement sophisticated and granular business rules.
3. Mask internal resources
• One sound security practice deployed by many companies is the use of
Network Address Translation (NAT) to obscure internal IP addresses. In
addition to using NAT, one effective way to mask and protect internal
resources from external parties is to disallow direct TCP connections
between application servers and outside parties. By using an XML proxy to
rewrite URLs and other information otherwise exposed by web services,
enterprises can quickly and simply hide a significant amount of their internal
configuration.
4. Protect against XML denial-of
service attacks

• XML DoS attacks (XDoS) might not be as popular as the syn-flood attacks of the
dotcom era, but they are more easily launched and capable of much more damage.
To protect against XDoS, security staff should implement reasonable constraints for
all incoming messages.
 • With the use of an XML security gateway as a proxy, network managers can
configure simple settings on message size, frequency and connection duration. The
goal is to allow access to resources, while simultaneously using XML filtering rules
to reduce the "aperture of entry" into the corporate network.

5. Validate all message

• Because XML is text-based and, in many instances, generated by humans, there is
significant room for error in message creation. One simple way to prevent this
problem is to use XML Schema Definitions (XSD) to validate both inbound and
outbound data. XSD is the successor to Document Type Definitions (DTDs) because
they are more useful and extensible. This best practice reduces the risk of security
 holes of unknown/undocumented fields or protocol features that might otherwise
compromise resources. In addition to performing Schema Validation, managers
should also check messages for XML well-formedness, (during parsing), improper
identity or lack of resource references, protocol (such as SOAP) validity and other
message validity checks.

6. Transform all messages

• By transforming all outbound XML messages, network managers enable "XML
Address Translation": mapping between the private internal data layout and the
external one. This kind of application-layer protection is easily implemented today
using XSLT, one of the most mature XML technologies. Using XSLT, businesses can
 obscure internal schema and object layouts from outside parties. As the number of
XML dialects and terms increases, message translation will become a key first step
in processing any application request. Because standards are still forming, XSLT is a
key asset – it enables an enterprise to support various message formats and
standards simultaneously.

7. Sign all messages

• Senders can create a secure audit trail by logging each message with a
signature that can be verified post-transaction. Because each log entry is
signed, their contents cannot be modified or altered and the sender gains
 non-repudiation protection. While signing and verifying every incoming and
outgoing message might seem processing-intensive, use of a hardware
appliance avoids the performance bottlenecks that accompany software
based solutions.

8. Timestamp all messages

• Enterprises can augment non-repudiation capabilities by using the Network
Time Protocol (NTP) to synchronize all XML network nodes to a single
authoritative reference time source. This simple step adds timestamps to all
incoming and outgoing messages. When used with XML Digital Signatures,
 network managers now have a cryptographically secure timestamp that
enhances non-repudiation capabilities by being able to definitively prove at
what time a given transaction took place.

9. Encrypt message fields

• XML Encryption requires one to parse the XML transaction, then select the
section(s) to encrypt/decrypt and finally perform a set of processing
intensive XML and crypto operations. Because both crypto and XML
processing are very resource-intensive, deploying both XML encryption and
its companion, XML digital signature, can have a significant performance
impact on high-transaction applications. Consolidating some of the functions
 on to an easy-to-manage secure network device that can encrypt/decrypt or
sign/verify XML transactions on their way through the network can cut
administrative hassles.

10. Implement secure auditing

• The importance of auditing cannot be underestimated. While many network
managers rely on syslog for creating audit trails, this alone is not totally
secure. By using a combination of XML Digital Signatures and time stamping,
a manager can quickly and easily create secure e-business transaction logs
 that can be used for non-repudiation. In many instances, legal requirements
demand that the logging technology used is secure and verifiable.

Summary

• People sometimes think XML Web Services security is an all-or-nothing

proposition requiring the installation of complex applications or the
ratification of many standards. But as XML Web service deployments continue
to rise, many organizations will need to tailor these security best practices to
meet individual needs.But there exist pragmatic, field-tested practices in XML
security that enable organizations to enjoy the cost-cutting, revenue-driving
benefits of XML Web Services.
MODULE 1.2 -
INTEGRATION
TECHNOLOGIES
Web Services Best Practices

What are Web Services

• Web services are a type of internet software that use standardized messaging
 protocols and are made available from an application service provider's web
server for use by a client or other web-based programs.
• Web services can range from major services such as storage management or
customer relationship management (CRM) down to much more limited services
such as the furnishing of a stock quote or the checking of bids for an auction
item. The term is sometimes also referred to as application services.

How web services work

Web services are built using open standards and protocols to integrate with various
applications. The different protocols that web services use include:
• XML
• SOAP
• WSDL
• UDDI
• REST

Extensible Markup Language

(XML)

• This is used to tag, code and decode data.

Simple Object Access Protocol

(SOAP)
• This is used to transfer the data. The SOAP protocol was developed so that
different programming languages could communicate quickly and with minimal
effort.

Web Services Description

Language (WSDL)

• This is used for telling the client application what is included in the web service
and how to connect.

Universal Description, Discovery

and Integration (UDDI)

• This is used to list what services are available within one application. It also
allows web services to be discoverable to other services.

Representational State Transfer

(REST)

• While not all web services use the REST protocol, applications built with RESTful
APIs are more lightweight, manageable and scalable.
• Web services allow different organizations or applications from multiple
 sources to communicate without the need to share sensitive data or IT
infrastructure. Instead, all information is shared through a programmatic
interface across a network. This interface can then be added to a GUI, like a
web page, to deliver specific functionality to users. This means web services
are not specific to one programming language or operating system and do not
require the use of browsers or HTML.

Web Services Best Practices

Use standard protocols

Design for simplicity and

clarity Follow RESTful

principles

Versioning

Use appropriate HTTP status codes

Web Services Best Practices

Implement proper error

handling Implement security

 measures Implement caching

Test and monitor

Document your web service

1. Use standard protocols:

• Use widely accepted protocols such as HTTP, REST, SOAP, and JSON for web
service communication. This ensures compatibility and interoperability with
 various client applications.

2. Design for simplicity and clarity:

• Keep your web service design simple and easy to understand. Use clear and
meaningful names for endpoints, methods, and parameters. Avoid
unnecessary complexity and minimize the number of required
dependencies.

3. Follow RESTful principles:

• If designing a RESTful web service, adhere to the principles of
Representational State Transfer (REST). Use HTTP verbs (GET, POST, PUT,
DELETE) for different operations, and ensure that resources are identified by
unique URLs.

4. Versioning:
• Plan for versioning your web service to handle future changes and updates.
Use version numbers in the URL or headers to maintain backward
compatibility and allow clients to choose the appropriate version.
5. Use appropriate HTTP status codes:
• Return appropriate HTTP status codes to indicate the success or failure of a
request. For example, use 200 for a successful response, 404 for a resource
not found, and 500 for server errors.

6. Implement proper error handling:

• Provide meaningful error messages and use appropriate error codes to help
clients understand and handle errors. Include details such as error
descriptions, error codes, and suggestions for resolution.

7. Implement security measures:

• Protect your web service from unauthorized access and data breaches. Use
secure communication protocols (HTTPS), implement authentication and
authorization mechanisms, and validate and sanitize user input to prevent
security vulnerabilities.

8. Implement caching:
• Use caching mechanisms to improve performance and reduce the load on the
server. Cache static or infrequently changing data and set appropriate cache
control headers to control caching behavior.

9. Test and monitor:

• Thoroughly test your web service to ensure its functionality and performance.
Monitor the service for uptime, response times, and error rates. Use logging
and analytics to track usage patterns and identify areas for improvement.

10. Document your web service:

• Provide comprehensive documentation for your web service, including API
documentation, usage examples, and sample requests and responses. This
helps developers understand how to interact with your service effectively.
Summary
• By following these best practices, you can
design and implement web services that are
efficient, secure, and easy to use.