Showing posts with label environment. Show all posts
Showing posts with label environment. Show all posts
Monday, August 6, 2018
Running Spring Tool Suite and other GUI applications from Docker containers
Running an application within a Docker container helps in isolating the application from the host OS. Running GUI applications like for example an IDE from a Docker container, can be challenging. I'll explain several of the issues you might encounter and how to solve them. For this I will use Spring Tool Suite as an example. The code (Dockerfile and docker-compose.yml) can also be found here. Due to (several) security concerns, this is not recommended in a production environment.
Sunday, December 10, 2017
10 reasons NOT to implement Blockchain now
A secure distributed ledger with smart contract capabilities not requiring a bank as an intermediary! Also a single source of truth with complete traceability. Definitely something we want! Blockchain technology promises to make this possible. Blockchain became famous through cryptocurrency like Bitcoin and Ethereum. The technology could also be considered to replace B2B functionality. With new technologies it is not a bad idea to look at pro's and con's before starting an implementation. Blockchain is the new kid on the block and there is not much experience yet on how well he will play with others and will mature. In this blog I summarize some of my concerns concerning blockchain of which I hope will be solved in due time.
Regarding new/emerging technologies in the integration space, I'm quite open to investigate the potential value which they can offer. I'm a great proponent of for example Kafka, the highly scalable streaming platform and Docker to host microservices. However, I've been to several conferences and did some research online regarding blockchain and I'm sceptical. I definitely don't claim to be an expert on this subject so please correct me if I'm wrong! Also, this is my personal opinion. It might deviate from my employers and customers views.
Most of the issues discussed here are valid for public blockchains. Private blockchains are of course more flexible since they can be managed by companies themselves. You can for example more easily migrate private blockchains to a new blockchain technology or fix issues with broken smart contracts. These do require management tooling, scripts and enough developers / operations people around your private blockchain though. I don't think it is a deploy and go solution just yet.
Regarding new/emerging technologies in the integration space, I'm quite open to investigate the potential value which they can offer. I'm a great proponent of for example Kafka, the highly scalable streaming platform and Docker to host microservices. However, I've been to several conferences and did some research online regarding blockchain and I'm sceptical. I definitely don't claim to be an expert on this subject so please correct me if I'm wrong! Also, this is my personal opinion. It might deviate from my employers and customers views.
Most of the issues discussed here are valid for public blockchains. Private blockchains are of course more flexible since they can be managed by companies themselves. You can for example more easily migrate private blockchains to a new blockchain technology or fix issues with broken smart contracts. These do require management tooling, scripts and enough developers / operations people around your private blockchain though. I don't think it is a deploy and go solution just yet.
Tuesday, January 22, 2013
Generic configuration plan for SOA Suite 11g composite deployments
In order to adapt deployments of SOA Suite 11g composites to specific environments, configuration plans can be used to rewrite the composite.xml file. These configuration plans can be used during deployment by the Oracle supplied ANT scripts. See for example; http://biemond.blogspot.nl/2009/09/deploy-soa-suite-11g-composite.html on how these ANT scripts can be used to deploy composites.
A configuration plan can be generated from the composite.xml file. See figure 41-1 on http://docs.oracle.com/cd/E14571_01/integration.1111/e10224/sca_lifecycle.htm.
When however using the JDeveloper default generated configuration plan per process, adding new references, WSDL files, XSD files, JCA files, imports, properties, etc requires updating the configuration plan. Maintaining the configuration plans can become quite cumbersome when there are a lot of composites, endpoints and regular changes in environments.
As stated in http://www.oracle.com/technetwork/articles/soa/start-small-luttikhuizen-1502916.html; 'Another best practice is to avoid creating a separate configuration plan per composite per environment.'
This led me to want to create such a common configuration plan file which would be composite independent and thus reusable.
Implementation
Usually development is done against a development environment. The processes which are under version control have endpoints and properties specific to the development environment. To make a process specific for other environments, the development references are replaced by for example test references.
I generated a standard configuration plan for a process and made it generally usable. I reduced the standard generated configuration plan to the following (of course the http://dev and http://tst should be replaced with your specific environment);
<?xml version="1.0" encoding="UTF-8"?>
<SOAConfigPlan xmlns:jca="http://platform.integration.oracle/blocks/adapter/fw/metadata"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy"
xmlns:edl="http://schemas.oracle.com/events/edl"
xmlns="http://schemas.oracle.com/soa/configplan">
<composite name="*">
<import>
<searchReplace>
<search>http://dev</search>
<replace>http://tst</replace>
</searchReplace>
</import>
<reference name="*">
<binding type="ws">
<property name="endpointURI">
<searchReplace>
<search>http://dev</search>
<replace>http://tst</replace>
</searchReplace>
</property>
</binding>
</reference>
<reference name="*">
<binding type="ws">
<attribute name="location">
<searchReplace>
<search>http://dev</search>
<replace>http://tst</replace>
</searchReplace>
</attribute>
</binding>
</reference>
</composite>
<wsdlAndSchema name="*">
<searchReplace>
<search>http://dev</search>
<replace>http://tst</replace>
</searchReplace>
</wsdlAndSchema>
</SOAConfigPlan>
This configuration plan works composite independent and replaces all imports, references to endpoints and location references and environment references in all WSDL, XSD and JCA files.
Conclusion
Configuration plans are the recommended option to use for making composites environment specific (http://www.oracle.com/technetwork/articles/soa/start-small-luttikhuizen-1502916.html). Efficient use of configuration plans can greatly reduce the work required per process.
The configuration plan as displayed above does not replace BPEL properties which might also be environment specific. To achieve replacing of BPEL properties, the properties should be consistent in name and value among processes. In order to add such replacement code to the configuration plan, you can add properties to your BPEL process, generate a configuration plan, adapt the generated code and add the relevant portion to the generic configuration plan.
You should check if using this configuration plan does what is required by validating it in JDeveloper and checking if all required references are replaced. The danger of not having all references replaced is that messages meant for for example the test environment end up on development or even worse; production messages end up in development. Also message definitions can change among environments. If an XSD from a wrong environment is imported, conflicts can arise.
An alternative for using configuration plans is deploying against localhost. Localhost is a reference to the current machine. When developing for example on a standalone machine, localhost refers to that machine. When the process is deployed on a different server, localhost refers to that different machine. This method has several drawbacks however and is thus not recommended. Questions arise when using such a method;
- How to deal with external services? (especially if they differ amongst environments). Using an abstraction to the actual service endpoints (such as a service registry) can help, but you will undoubtedly encounter other similar issues in this category.
- How to deal with load balancing in a clustered environment? Localhost is the current machine so a process initiated on one machine does not initiate processes on the other machines in the cluster and thus load balancing is limited.
A configuration plan can be generated from the composite.xml file. See figure 41-1 on http://docs.oracle.com/cd/E14571_01/integration.1111/e10224/sca_lifecycle.htm.
When however using the JDeveloper default generated configuration plan per process, adding new references, WSDL files, XSD files, JCA files, imports, properties, etc requires updating the configuration plan. Maintaining the configuration plans can become quite cumbersome when there are a lot of composites, endpoints and regular changes in environments.
As stated in http://www.oracle.com/technetwork/articles/soa/start-small-luttikhuizen-1502916.html; 'Another best practice is to avoid creating a separate configuration plan per composite per environment.'
This led me to want to create such a common configuration plan file which would be composite independent and thus reusable.
Implementation
Usually development is done against a development environment. The processes which are under version control have endpoints and properties specific to the development environment. To make a process specific for other environments, the development references are replaced by for example test references.
I generated a standard configuration plan for a process and made it generally usable. I reduced the standard generated configuration plan to the following (of course the http://dev and http://tst should be replaced with your specific environment);
<?xml version="1.0" encoding="UTF-8"?>
<SOAConfigPlan xmlns:jca="http://platform.integration.oracle/blocks/adapter/fw/metadata"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy"
xmlns:edl="http://schemas.oracle.com/events/edl"
xmlns="http://schemas.oracle.com/soa/configplan">
<composite name="*">
<import>
<searchReplace>
<search>http://dev</search>
<replace>http://tst</replace>
</searchReplace>
</import>
<reference name="*">
<binding type="ws">
<property name="endpointURI">
<searchReplace>
<search>http://dev</search>
<replace>http://tst</replace>
</searchReplace>
</property>
</binding>
</reference>
<reference name="*">
<binding type="ws">
<attribute name="location">
<searchReplace>
<search>http://dev</search>
<replace>http://tst</replace>
</searchReplace>
</attribute>
</binding>
</reference>
</composite>
<wsdlAndSchema name="*">
<searchReplace>
<search>http://dev</search>
<replace>http://tst</replace>
</searchReplace>
</wsdlAndSchema>
</SOAConfigPlan>
This configuration plan works composite independent and replaces all imports, references to endpoints and location references and environment references in all WSDL, XSD and JCA files.
Conclusion
Configuration plans are the recommended option to use for making composites environment specific (http://www.oracle.com/technetwork/articles/soa/start-small-luttikhuizen-1502916.html). Efficient use of configuration plans can greatly reduce the work required per process.
The configuration plan as displayed above does not replace BPEL properties which might also be environment specific. To achieve replacing of BPEL properties, the properties should be consistent in name and value among processes. In order to add such replacement code to the configuration plan, you can add properties to your BPEL process, generate a configuration plan, adapt the generated code and add the relevant portion to the generic configuration plan.
You should check if using this configuration plan does what is required by validating it in JDeveloper and checking if all required references are replaced. The danger of not having all references replaced is that messages meant for for example the test environment end up on development or even worse; production messages end up in development. Also message definitions can change among environments. If an XSD from a wrong environment is imported, conflicts can arise.
An alternative for using configuration plans is deploying against localhost. Localhost is a reference to the current machine. When developing for example on a standalone machine, localhost refers to that machine. When the process is deployed on a different server, localhost refers to that different machine. This method has several drawbacks however and is thus not recommended. Questions arise when using such a method;
- How to deal with external services? (especially if they differ amongst environments). Using an abstraction to the actual service endpoints (such as a service registry) can help, but you will undoubtedly encounter other similar issues in this category.
- How to deal with load balancing in a clustered environment? Localhost is the current machine so a process initiated on one machine does not initiate processes on the other machines in the cluster and thus load balancing is limited.
Subscribe to:
Posts (Atom)