Web Services Intermediary features
With the adoption of Web Services in the SOA space WS based intermediaries are gaining importance. The key factors for this adoption are because no matter how Web services are provisioned finally they would be consumed by some applications, the consumption of such services will demand certain functionality which is not related to the service itself, functionalities such as Security, SLA, and Routing for high availability etc.
One could argue that these features could be part of the application that hosts the service. Well, on second thoughts you would agree that all these features would provide more value if isolated and handled by an intermediary.
1) Different application servers which have hosted services can utilize these features rather than implementing such logic.
2) Policy enforcement can be done agnostic of any application server’s native features.
3) Performance would not be hindered due to Application server’s bottle-necks
4) Performance can be managed by dealing with the intermediary
5) The load of processing the components can be separated out and let the Application server handle just the Web services
6) Apart from the additional functions there would be certain maintainability aspects relating to the intermediary such as , handling Policies, data persistence, handling statistics, EPR routing etc
7) Clustering of proxies would serve multiple Applications servers and cater to HA
1.1 Components
1.1.1 Authentication
Authentication details will be taken from a) WS Security Token, b) protocol headers and checked against the following:
SAML assertion
Kerberos tokens
LDAP
Database
File based
1.1.2 Authorization
Depending on the Authentication, user’s groups and roles will be assigned and based on their privileges will allowed to administer the intermediary.
Users: users would belong to a group and share roles.
Group: groups will have roles
Role: roles would have none or many privileges
Privileges: Users can be directly assigned privileges

1.1.3 WS Security – SOAP Based
Security features will be applicable to the SOAP request as well as SOAP response but will also depend whether it’s synchronous or Asynchronous.
Signature
Encryption
Signature Verification
Decryption
Timestamp
CRL
Certification Path validation/Certificate Chain
1.1.4 XML Security
This will be used for XML based services such as REST
1.1.5 SLA – Service Level Agreement
Response time
Priority
Metering
Custom rule based
1.1.6 BAM – Business Activity Monitoring
KPI definition
Rules
Actions
1.1.7 Deprecation
Date time range
Custom rule based
1.1.8 WS-BPEL orchestration
1.1.9 Incentive based contract overriding
Number of hits
Promotion based
Custom rules
1.1.10 Routing
1.1.10.1 Context
Context would depend on the underlying protocol
JMS
HTTP
Email
1.1.10.2 Content
Content evaluation will be on the SOAP message. Evaluation will be based on xpath.
XPath based
Strategies could be Until Success
1.1.10.3 Blind
Random selection of endpoint
1.1.10.4 Parallel
First available service
1.1.10.5 Round Robin
Until success
1.1.10.6 Failover
On Network error, soap fault and timeout; default to the next available service
1.1.10.7 Performance
Cached priority based service endpoint performance
1.1.11 Protocol translator
This feature will act as a protocol translator. This will be applicable in cases where a customer sends a SOAP request using HTTP for a service but the native or endpoint service is say JMS or uses some other protocol.
1.1.12 Content translator
This will be used when the request SOAP or xml needs to be changed. Probable use case would be operation change due to versioning.
1.1.13 Outbound Credential translator
This would be required when the native service requires auth tokens such as WS Security Token, Signed request.
1.2 Services
1.2.1 Embedded SOAP Stack
The embedded SOAP stack could be used to host two types of services:
a) System Services: All system related services such as resource adaptors for integration with application, instrumentation of statistical data.
b) Embedded Web services: For high performance Web services that may be required by clients.

1.2.2 Hot deployment of configuration files
To orchestrate components configuration files need to be hot deployed without affecting requests in the pipeline.
1.2.3 Callback based extension processors
Each component could utilize external components to process the messages. Common cases would be to say eternalize SLA processing.
1.2.4 Polled Extension adaptors
Apart from the intermediary related configuration files some background processes could be required to run on a timely basis.
1.2.5 Service performance statistics
Instrumentation using Web service and MBeans for maintaining state as well as instrumentation.
1.2.6 WS-Notification
Less of acceptance.
1.2.7 Monitoring & Rule based Alerts
SNMP traps
Email
SMS
1.2.8 Logging
Log4j
1.2.9 Events
Service level transaction
System exception
Service level business exception
Intermediary start
Intermediary stop
Service start
Service stop
1.2.10 Reliable Messaging
JMS based reliable message delivery
1.2.11 Resource Adaptors - integration
UDDI interface
Web services interface
Servlet interface
Email interface
1.2.12 Data Persistence
Database
1.2.13 System wide data backup
Rule based
Manual

1.2.14 Clustering
Sharing of resources across clustered intermediaries
1.2.15 Automated endpoint service tweaking
Monitoring and eliminating rouge services – Rule based
1.2.16 PKI management
· Keystore
Maintain keystore for WS-Security and SSL
· Keypair
Manage Keypairs in various keystores
· CRL
To manage Certification Revocation List’s by polling for CRLs from different CAs
1.2.17 MIB Management
Manage MIBs
1.2.18 Intermediary Policy Management
Create and manage service policies

1.3 Bindings
The possible bindings for commonly used protocols are as follows
1.3.1 HTTP
Could be used for synchronous high security based Web service request with WS-security functionalities
1.3.2 HTTPS
Could be used for synchronous low security based Web service request
1.3.3 JMS
Could be used for asynchronous Web service requests
1.3.4 Email
Could be used for asynchronous Web service requests
1.3.5 FTP
Could be used for asynchronous Web service requests
1.4 Technology
1.4.1 SOAP
1.4.2 UDDI
1.4.3 JMS
1.4.4 J2EE
1.4.5 Java
1.4.6 WSDL
1.4.7 WSDM
1.4.8 WS-Security
1.4.9 XML
1.4.10 JMX
1.4.11 RDBMS
1.4.12 Directory Servers
1.4.13 SNMP
1.4.14 SMTP/POP
1.4.15 X509 Certificates
1.4.16 PKI
1.4.17 JAAS

Soumadeep Gourangi