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/

Local import of WSDLs and XSDs for design time in JDeveloper

Local import of WSDLs and XSDs for design time in JDeveloper

The following problem occured to me in a project:

The remote Webservice, which should be referenced by a composite is secured with http basic authentication (username and password). This means you cannot use the normal dialogue, because it cannot access the remote service.

You need the WSDL-file and the corresponding XSD-Schema-Files. There is no way around that.
When you managed to get those, you can create the Webservice-Reference and import the WSDL locally into your project.

This way you should be able to create your reference to the remote Webservice. The imported local WSDL-file should show up in your project-folder in JDev.

The same goes for the .XSD-schema-files. If e.g. you want to expose your composite as a Webservice, you must generate a new WSDL for that.

In the "Create WSDL"-dialogue, choose "Browse for schema file".

There, choose you .xsd-files for request, reply and fault, if necessary.

Now the "Exposed Services" and the "Externel References" of your composite are ready.

If you do not import the xsd-files locally, you will get errors while trying to deploy the composite to the WLS! JDeveloper needs access to those files at design-time!

The disadvantage of this is, when the Webservice parameters are changed, you need to to reimport the thing and redeploy it to your WLS.

Integration of legacy systems into a modern enterprise SOA (part 8)

Integration of legacy systems into a modern enterprise SOA - Part 8 (last part)

8. Conclusion

The integration into a modern architecture can often be an opportune and flexible alternative to full replacement or redevelopment of an existing legacy system. The advantages of an integration using the SOA approach are:

- preservation of the business logic of the legacy system
- reduction of risk: No expensive and complex replacement or redevelopment necessary
- reduction of TCO
- Usage of the existing modern (SOA-) IT landscape (including infrastructure and hardware)
- guranteed future and flexibility because of standards, frameworks and reference architectures
- modern business processes because of service-oriented architectures and their advantages (loose coupling, reusability, flexibility, interoperability, standardization, less maintanance, ...)

The integration of legacy systems into a modern IT landscape kann be a complex project. Endurance is needed for the development to a flexible and agile company.

Integration of legacy systems into a modern enterprise SOA (part 7.3)

Integration of legacy systems into a modern enterprise SOA - Part 7.3

7. Approach

5. Transformations

The required data transformations or the necessary mapping must be implemented at the interface. For this the essential transformation steps have to be identified and implemented. If necessary the creation of mapping tables for data and business objects is inevitable. If a canonical data model exists, the transformations and the mapping are directly based on that. If, in one of the earlier phases you decided to implement a canonical data model, this is the time to implement and integrate it.

6. Adjust the calling business logic

Often, changes in the logic of the calling business processes are also necessary. Possibly, activites and processes have to be newly cut or stripped down, so that the call to the legacy system can be integrated.

7. Integrate the legacy interface into the SOA landscape

In a final step the legacy system will be integrated into the present SOA landscape. The needed web service calls and adaptors are integrated into the available business logic.


Part 8 will follow next week...

Integration of legacy systems into a modern enterprise SOA (part 7.2)

Integration of legacy systems into a modern enterprise SOA - Part 7.2

7. Approach (part 2)

3. Choise of adaptors and connectors

By means of the analysis of the legacy systems, the decision can be made, if it can easily later be augmented with modern interface technologies (java interfaces, web services). The choice of the right communication technology depends on that. Depending on the demands of performance and transaction security, oftentimes this decision is made towards Java Connector Architecture (JCA) and/or the WS framework. The use of a standard adapter, which is offered my different software companies, often represents the low-priced alternative. If the demands or the legacy systems do not allow the use of standard adapters, these can also be developed by yourself. The JCA framework is often used for this.

4. Customizing the legacy system

As said it is often necessary to implement changes in the legacy system, to be able to integrate it into a modern SOA. If the documentation was evaluated as "not sufficient" in the planning phase, an additional phase of documentation must be carried out. In a worst case scenario this could meand reverse engineering. The necessary changes can then be implemented.

Part 7.3 will follow next week...