ICS to OIC by Phil Wilkins

We have had a number of interesting conversations of late about the transition from ICS to OIC and to spice the discussion whether it should be OIC or Autonomous OIC. The reality of the situation is that the transition between ICS and OIC is a relatively straight forward one using the export and import tooling.

The real challenge is the impact to organisations appears to be the change in licensing models as OIC works with the newer Universal Credit Model (UCM) where as ICS is in the older arrangement of traditional accounts where you buy the use of specific services, in some ways not too different from traditional Oracle traditional product licensing. For organisations that operate with corporate level buying teams this is organisationally more challenging. As just buying credits can feel like your giving the IT children pocket money and you don’t trust them to ensure the money is spent wisely and they don’t come running back a day later when they say spent all the money can we have some more.

IOC or Autonomous OIC

For the smaller customers where they’re generating less than 5000 Messages per hour (think Integration triggers where each message is <50k – which is fairly big for most needs. Although be aware but moving large files is going to eat through your messages as the transfer cost is file size / 50k = no. messages used (consumed or sent), of effectively 250MB per hour. The autonomous option is a no brainer for smaller use cases in terms of cost as it means on current pricing you have your integrations operating for a lot less than £500 per month (£0.5867 x 24 x 30 – using standard with the flex scheme – https://cloud.oracle.com/en_US/OIC/pricing). With that the SaaS adaptors are also included – that means you could operate say Workday to Oracle Financials for an SME without much problem. Read the complete article here.

PaaS Partner Community

For regular information on Oracle PaaS become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress

Start, Stop and Status of API CS Physical Gateway by Ankur Jain

In our previous blog, we have showcased how to install API Cloud Service physical gateway. In this blog, we’ll execute some useful commands. For instance, how to start, stop and check status of the physical gateway.

Below command must run from the directory where Gateway installer was unzipped.

Command to check the status of Physical Gateway

Run below command to check the status of Physical Gateway

python APIGateway.py -f gateway-props.json -a status

Enter username and password of the Physical gateway which was given during installation
Command to  stop the Physical Gateway

JAVA_HOME path should be set before run the stop command

Run below command to stop Physical Gateway

python APIGateway.py -f gateway-props.json -a stop

Enter username and password of the Physical gateway which was given during installation. Read the complete article here.

PaaS Partner Community

For regular information on Oracle PaaS become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress

Managing Applications in Oracle API Cloud Service (CS) by Ankur Jain

Applications represent the applications API consumers use to send requests to registered APIs in Oracle API CS. Consumers register applications to APIs they use.

Below are steps to create an application using Oracle API CS console

• Login to API CS console and navigate to Applications tab

• Click on Create button

• Enter below information from the Application Dialog and click Create button
  • Application Name: Enter application name
  • Description(Optional): Enter brief description of the application
  • Application Types(Optional): Select zero or more application type from available list
  • Read the complete article here.

PaaS Partner Community

For regular information on Oracle PaaS become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress

IP Filter Validation policy to restrict access in Oracle API CS by Ankur Jain

IP white-listing allows to create lists of trusted IP addresses or IP ranges from which a users can access APIs.

IP white-list is a security feature often used for limiting and controlling access only to trusted users or applications.

Oracle API CS (Cloud Service) provides IP Filter Validation policy to control which IP Addresses can successfully send requests to the API.

The IP address originated by the client is received from the HTTPRequest. This policy checks if the address matches allowed or disallowed IP addressed configured as part of the policy. Upon finding a match, it takes appropriate action as configured. Nonstandard HTTP headers such as X-ProxyUser-Ip, X-Forwarded-For , or HTTP_X_CLUSTER_CLIENT_IP are not supported.

IP Filter Validation policy can be added in the request flow only. It can not be placed first in the flow. Other security polices must be placed before it.

Let’s see how to configure the IP Filter Validation policy using API CS console. To complete this task there should be API configured in API CS. If not, please go through the blog Creating an API in Oracle API Platform Cloud Service Read the complete article here.

PaaS Partner Community

For regular information on Oracle PaaS become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress

Why microservices and monoliths are not simple by Phil Wilkins

Microservices are inherently more complex because they are distributed and shared less, and therefore, require a better foundation.

It’s a bit controversial to say that microservices are not simple given how much is said about using them to simplify and accelerate software delivery. So can this statement even be made? It is, in Chris Richardson’s excellent new book, “Microservice Patterns” (here) and indirectly in Eric Evan’s “Domain-Driven Design” (here). Martin Fowler also agrees that they come at a premium in one of his blogs (here).  So, I’m not the first to say it, and I won’t be the last.

But the assertion that microservices done right are simpler and allow rapid delivery and evolution of solutions is a bit of a contradiction. Since a picture is worth a thousand words, take a look at this:

To make a change with the monolith and understand the impact of the change, you need to have a greater appreciation of how the entire solution works (area highlighted in gray). If changes are implemented without understanding or adhering to the design strategies and patterns, or if changes are rushed to address some urgent need (business deadline, bug, and so on), the design erodes and the effort to understand the change impact for future changes is accelerated. In effect, the monolith becomes difficult and unwieldy.

Microservices are inherently more complex because they are distributed and shared less, and therefore, require a better foundation. So, not only do you need to understand the programming language, and a simple app container, such as Tomcat; you also need Docker and something like Kubernetes or Istio. It is important that the isolation between the different services be more robust; no longer can you just add another import or another method overload on class. It takes more effort and it is easier to govern the points of exposure. As a result, the risk of design degradation is reduced – but not removed.

Moreover, understanding any one part of a solution requires less understanding of the whole. The net result is that there is less temptation to use shortcuts to deliver urgent solutions for just one area. Regardless of whether the solution is a monolith or microservices, sooner or later the solution will reach a point where dedicated skills in those non-functional areas are needed. But in the monolith world, the platform specialist doesn’t have to struggle with the big picture while tuning resources – i.e., some parts of a monolith may be memory-hungry while others need I/O performance. In the microservices world, the Kubernetes specialist only needs to master one set of dependencies at a time in order to optimize deployment and deliver value. Furthermore, there is the possibility that different microservices will have related demands – so they can share infrastructure most suited to those demands and host the microservices with different demands on infrastructure meeting its needs.

Which brings us back to our original statement: since there are moving parts, there is complexity, but it is easier to master any one part because it is smaller. As the solution grows and becomes more effective, it becomes possible to have specialists for each component and layer. While Martin Fowler’s diagram (below) doesn’t show this, I suspect it holds true. Read the complete article here.

PaaS Partner Community

For regular information on Oracle PaaS become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress