Interesting interview with Jürgen Menge (Oracle Sales Consultant) about ADF, APEX, Migration of Forms-Applications and the question: "Are german architects too carefull?"
In german language:
DOAG@Talk: Sind Architekten in Deutschland zu vorsichtig?
http://www.doag.org/home/aktuelle-news/article/doagtalk-sind-architekten-in-deutschland-zu-vorsichtig.html
Donnerstag, 21. Juni 2012
Freitag, 15. Juni 2012
Virtualization: Issues with Oracle VM 3
Here is an interesting article from the german Oracle user group DOAG concerning the recent issues with Oracle's virtualization Oracle VM 3 (in german language):
http://www.doag.org/home/aktuelle-news/article/doag-und-oracle-wollen-das-thema-oracle-vm-3-gemeinsam-angehen.html
http://www.doag.org/home/aktuelle-news/article/doag-und-oracle-wollen-das-thema-oracle-vm-3-gemeinsam-angehen.html
Dienstag, 12. Juni 2012
Oracle SOA Suite 11.1.1.6 VirtualBox now available from Oracle
You can now download, test and try Release 11.1.1.6 of the Oracle SOA Suite without installing the whole stack by yourself! Oracle just published an image (VirtualBox) which contains SOA Suite 11.1.1.6 (including OSB), BPM Suite 11.1.1.6 and Webcenter Suite 11.1.1.6. You do not need to install or configure everything. It's ready to use.
You will find every necessary information and the download here:
http://www.oracle.com/technetwork/middleware/soasuite/learnmore/vmsoa-172279.html
Have fun!
You will find every necessary information and the download here:
http://www.oracle.com/technetwork/middleware/soasuite/learnmore/vmsoa-172279.html
Have fun!
Mittwoch, 16. Mai 2012
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
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
Freitag, 11. Mai 2012
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
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
Dienstag, 8. Mai 2012
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/
Was hat SOA mit Innovation zu tun?
http://www.computerwoche.de/management/it-strategie/2509277/
Donnerstag, 26. April 2012
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.
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.
Abonnieren
Posts (Atom)