Redundant code and functions in services: Normalization

Redundant code and functions in services: Normalization

If your SOA landscape exists for a while, there could be a problem, which you could also know from system, that do not use service-oriented archtecture: Redundant code or functions!

Redundant code or functions means programming logic, which exists more than once in your system or programming logic, which creates exactly the same result. Redundant code is dispensable. That means, if you do it right, you can delete the redundant code or function and the results will be the same. Also the logic of your services can overlap, which means, that only parts of it are redundant.

When will it happen?

If the number of services in your system grows or already has increased over the years, redundant code and functions can happen very easily, if your analysis of logic and content is not what it should be.

Problem

If the logic of an existing function changes, you have to adjust every part of your system, where this redundant logic was implemented. Often it is very hard to identify all those places in your system. Also, this has negative impact on the re-usability of your services.

Solutions

A possible solution would be a normalization of (the logic of) your services, which prevents redundance and overlapping in the service-logic of your SOA.

Your efforts to avoid redundant code and functions in your services should start very early in your development process. Right from the start of the analysis phase should be assured, that conjoint logic is identified and marked as such. At design time each of those functions should be united and exposed in one service. It does not matter if you deal with business or technical logic. Business logic is packed into a business service, which can be consumed by other business services, whereas technical logic is implemented in a technical service, which can be consumed by business services or technical services.
The boundaries of the services(-logic) have to be defined and must strongly be observed, to avoid overlaps.

If you observed already redundant logic in your services, the only solution is a review and consequent refactoring. The redundant implementation of logic for related or identic problems by different developers at different places occurs oftenimes, especially on the technical level.

SOA

The SOA paradigm makes the refactoring easier in this case. If a identic function or logic was identified in different places of your code, those can be cut out and be implemented as an own service. At the cut-out areas the new service must be consumed. At this, you have to keep some important patterns in mind, to meet the SOA paradigm: Are the services still lousely coupled afterwards? Which message pattern must be used? Do you need a proxy- or a wrapper-service? And so on...

Normalized services and a normalized service repository will help you with re-usablitiy, simplifies your maintenance and makes thinks clearer, regarding your logic and services.

More information about service normalization:
http://en.wikipedia.org/wiki/Service_Normalization_Pattern
http://www.soapatterns.org/service_normalization.php

Oracle Enterprise Gateway OEG

This time, I will give some information about the Oracle Enterprise Gateway OEG.

The OEG (formerly Vordel XML Gateway) is a high performance gateway, which can help you expose webservice to domains, which are not under your control.

It consists of two main features: the transparent sercurity proxy and the service broker. The service broker acts as a control center for webservices and is divided into a definable external facade and a configurable internal mediator.

One of the main purposes is the easy development and implementation of security features in a central place. It can also be used to implement a Pay-as-you-use model (e.g. in a cloud). It is also very easy to provide standards (like REST) to the external world.

http://www.oracle.com/us/technologies/soa/soa-governance/enterprise-gateway-345737.html
(Oracle's main page for OEG)

The fascade is the service broker. It acts as the WSDL interface and control point. Methods can be activated and deactivated here. A security proxy does the authentication and authorization using policies. It holds a security token service and features for encryption, decryption, signing and XML threat protection. The mediator is the internal service broker. You can use it for content based routing, (protocol) transformations and as a load balancer. Usually the OEG is placed in the DMZ, between the external firewall and the internal network.

Cross domain exchange

One of its main purposes is the exchange of informations between different security domains. Different security tokens and identity formats can be administered by the OEG. Tokens are translated between the different security domains.

Policies

Different policies can be added and used with your web access management. Those policies are pre-configured. You do not have to change your existing web access management.

Enrichment

XML data which are transported through the OEG can be enriched if necessary. If additional data are e.g. needed by an internal webservices, but those data are not provided by the caller, the XML message can be enriched with those data. For example those data can be selected from a database.

Firewall

The OEG can also be used as a XML firewall. This way, internal webservices can be exposed to the outside world. The OEG can block attacks on the http-, SOAP- and XML-level.

Protocoll transformation

SOAP- and REST-requests can be transformed and both used to call internal services. The OEG implements service virtualization for external callers.

Token adding

If a caller cannot deliver the required security tokens for a webservice, the OEG can act as a security token service. It can add the necessary security tokens to the XML messages, so that the calls to the internal webservice are valid.

http://www.oracle.com/technetwork/middleware/id-mgmt/oeg-tech-wp-apr-2011-345875.pdf
(OEG Technical Whitepaper)

You can find the OEG 11.1.1.6 documentation here:
http://docs.oracle.com/cd/E27515_01/index.html

You can downlaod the OEG from Oracle here:
http://www.oracle.com/technetwork/middleware/id-mgmt/oeg-300773.html?ssSourceSiteId=ocomen#downloads

Was hat SOA mit Innovation zu tun?

Interesting article in german IT magazine about SOA and innovation:

Was hat SOA mit Innovation zu tun?
http://www.computerwoche.de/management/it-strategie/2509277/