woensdag 29 maart 2017
"You don’t want to become an Oracle SOA developer, for two reasons: SOA and Oracle."
Quite a powerful statement, so let's dive deeper into the two reasons mentioned above and explain why I strongly disagree with mr. Vesterli.
First of all, he makes a rightful claim that SOA has over-promised and under-delivered for a decade. I share this feeling, but I do not believe in the bleak picture of the future of SOA that he is painting.
Of course, we can now jump into microservices, which are at the peak of inflated expectations and doomed to fail in their own way with all the downsides and requirements that they have, or we can adjust our perspective on SOA and modernize our architectures. Take elements from microservices, don't run from one extreme to the opposite extreme and find your way into Domain Driven SOA Design, in which I strongly believe. We can and will do this right if we can for once stop thinking so black-and-white.
Apart from that, SOA Suite on-premise and Oracle SOA Cloud Service are exactly the same from a developer's point of view. They are the same products, requiring the same type of code, being developed in the same JDeveloper. And while ICS is very good for integrating SaaS applications with each other, it's not going to be the cornerstone of anyone's enterprise architecture anytime soon. Therefore, SOA will remain relevant for a long time and when you know SOA, you can easily learn about ICS as well. The other way around will be significantly harder!
So, I'd like to conclude by turning mr. Vesterli's statement around: now is a great and exciting time to become an Oracle SOA developer.
dinsdag 10 januari 2017
How to use MDS Events in your BPM processes?
- Copy the event definition that you want to use into your project;
- Let your BPM process use the local event on design time;
- Open your composite.xml in source mode and change the import location of the event definition to the oramds: location;
- Remove the local copy;
- Deploy & enjoy!
maandag 9 januari 2017
How to handle your Canonical Data Model (CDM) in a SOA environment?
Problems occuring with a poorly setup CDM
1. One CDM to rule them all
2. Versioned CDM
3. Design Time CDM
Solution: domain driven CDM
General design consideration
woensdag 4 januari 2017
If you’re into integration, SOA or web services, you’ve probably heard the term Microservices fairly often lately. Is applying Microservices architecture the one-size-fits-all solution that can replace the traditional one-size-fits-all SOA solution that doesn’t fit anymore? Of course not, because the world isn’t just black and white and both architectural concepts have their pros and cons. However, I think we can learn from the Microservices movement to improve and modernize our traditional SOA systems.
Microservices vs traditional SOA?
As tradition dictates, you can’t write an article about Microservices without explaining what Microservices are. So here’s a link to Wikipedia and a picture: https://en.wikipedia.org/wiki/Microservices
So, now we have a clear understanding about Microservices, let’s also have a clear understanding about what I call “traditional SOA”. Traditional SOA, according to me, is a monolithic, semi-loosely coupled way of doing web services, where all services are deployed on a single platform (e.g. WebLogic Server), where services have a lot of dependencies, where scaling is an all-or-nothing effort and where most of the services are both stateful and synchronous. Typically, a canonical data model is used and services are sharing data stores. Obviously, there is much more to it, but you don’t need me to repeat whatever Thomas Erl and countless of other authors have already written.
Flexibility vs Reusability
Quite often, I sense the vibe that traditional SOA is old and irrelevant, while Microservices architecture is the only way forward. This is nonsense. In the end, what it comes down to is that traditional SOA relies heavily on reusability, while Microservices architecture relies heavily on flexibility. So, the main question in your reference architecture should be how much flexibility you need and how much reusability you want to give up on it. If you’re working on a disruptive new system that needs to adapt to changes rapidly, you have a different use case from traditional ERP or CRM integrations, where changes only occur occassionally and sudden scaling demands are not likely to happen. So, before you go and embrace Microservices, think about what kind of business you’re actually in and even if you have a need for Microservices, you probably won’t need them for all your integration efforts. I also strongly recommend using common sense in this matter, because dogmatic belief never leads to anything good. Basically, ask yourself what kind of system your service is for: a system of stability or a system of innovation?
What can traditional SOA learn from Microservices?
Let’s just say that you are not Netflix or Union Pacific and a traditional SOA approach prevails for your needs. Then you should still occasionally re-evaluate your SOA standards. Ideas that may have been great in 2011 might just have reached their expiry date, while new innovations can be analyzed to improve your architecture. I think that the traditional SOA approach can learn from the Microservices movement, because it gives a fresh perspective on things and makes us re-evaluate things we’ve been taking for granted. Even if your SOA implementation is successful and you hardly encounter any problems, establishing that you’re still on the right path can be useful! I’ve been doing SOA for a long time now and in many different projects I’m finding the same problems. How can we learn from Microservices to handle those problems?
Challenge #1: Scaling
Since everything is deployed on the same platform, scaling whatever needs more horsepower means scaling everything. With multitenancy in WebLogic Server 12.2.1, it’s possible to create domain partitions to overcome such problems. Try splitting up your SOA layer into different domains of services that scale together, possibly do the same with the underlying database, add work managers to those domains and you are already winning a lot. For example, I am currently involved in a project that deals with courthouse cases. Some cases are short running and happen often, while others are more rare, but longer running. Putting these into different domains will give you the flexibility to treat them differently, although dealing with underlying reusable services can still be a challenge. Those services could also be in their own domain though, but you could also go as far as deploying them to multiple domains or even having two different versions of such a service. Once again, it depends on the balance between flexibility and reusability.
Challenge #2: Performance
“Our services don’t perform!" is something that I hear too often. Obviously, here you need to look at the platform too: what’s the purging strategy, are we applying patches, is the configuration right? Tons of improvements can be made on that side, but pointing and blaming is no longer cool in the DevOps world, so we also need to look into the mirror: are we doing what we can to make our services perform well? Here we can apply some Microservices patterns: for example, if you are integrating between SaaS applications or between BPM processes and a relational database, do you really need stateful services in between? Think about the minimum of metadata that you need for each service and act on it: maybe use Service Bus instead of a Mediator, look at the use of each component in the service layering and get rid of redundant capturing of state. It will make your services run much faster. Try to be as stateless as you can be without getting into trouble.
Challenge #3: Dependencies
Dependencies are real killers of success. While Microservices are fully responsible for their own well-being, traditional SOA services tend to aggregate, orchestrate and use shared resouces. Aggregation is inevitable, but for orchestration there are some nice alternatives. For example, I’ve worked at a project where we had two BPM layers: one for end-to-end business processes that do orchestration and one for domain-bounded processes that do the actual processing. Instead of letting the top layer do orchestration through web services, you could also make it more loosely coupled through JMS or Events, so the entire building doesn’t collapse when one floors burn downs. At least consider it.
Another major dependency is the canonical data model. Having a general CDM that affects all services can be extremely inflexible and leads to unclear service definitions. I prefer a domain driven CDM approach (also see Challenge #1): make a CDM for each logical domain and have internal reuse of the objects (same namespace), while between domains there can be differences. For example, I have an Employment domain and a Person domain: in this case, a change in Person without relevance for the Employment domain will have no impact. This has the downside of needing some transformations, but at least you have a reasonable balance between flexibility and reusability. Personally, I don’t believe in taking such an approach for each individual service (hello Microservices), because you probably still want to be able to push through non-breaking changes quickly. Find your own balance in this, but try to avoid extreme measures.
Challenge #4: Purpose
With a Microservice, you always know exactly what it does, because it does exactly one thing. In SOA, we should also embrace such an approach, at least partially. Always try to make a service about exactly one object and make seperate services for “get" and transactional operations for the sake of scaling. Logically, aggregations can’t always be avoided, but then the aggregation itself should be considered one object. Also try to not make too many variations of basically the same operation: if needed, use a specific, non-reusable connector service for applications who need specific sorting, filtering etc…
Many organizations are struggling with their SOA approach, while not having a clear use case for rebuilding everything in a Microservices architecture. I believe that reading into the subject helps to understand the challenges that come with traditional SOA and I hope that this blog can help you address those challenges, as well as trigger you to put your design patterns under scrutiny on occasion. By gathering inspiration from different architectural approaches, we can already make a difference without fully adopting those approaches.
maandag 12 december 2016
Oracle Process Cloud ServiceFor those of you unfamiliar with the product: Oracle Process Cloud Service (PCS) is Oracle’s BPM solution for the cloud. While development on Oracle BPM Suite has pretty much come to an end, Oracle Process Cloud Service is the way forward and the platform for all new features related to Business Process Management. This meant that the product that was originally positioned as BPM for the citizen developer had to improve and mature to a full-blown BPM solution. It needs to support long running processes, improve its integration strategy and support case management, to mention some important subjects. While case management is not there yet, it will certainly come to Oracle Process Cloud Service and many other features are already there with the latest release.
Modelling ProcessesAs it used to be, modelling processes is done in the browser. This makes it easy for business and IT to collaborate on processes, because you only need an internet connection to get access. No need for development tools, code repositories and a powerful work station to get started. The main improvement in the process modelling is that Oracle has abandoned the usage of Flash. This makes the process modeller faster and easier to use, creating a far more pleasant and performant development experience.
Selecting integrationsWhen creating a Service Call, whether it’s synchronous or asynchronous, you can now select an Integration from Oracle Integration Cloud Service. Obviously, this is much more practical than dealing with WSDL imports and all the technical stuff related to that, but it also has a bigger meaning. It’s clearly showing that Integration Cloud Service has been strategically positioned as the way to go for process integrations. It’s putting the technical know-how of integration where it belongs, so you will no longer feel tempted to take that kind of complexity into a business process. Therefore, I strongly recommend following this approach as suggested by Oracle, instead of trying to work out your own integrations in PCS. Use these products for their purpose.
Document workflowsOracle Process Cloud Service is still closely connected to Oracle Documents Cloud Service. It was already possible to deal with documents in your processes very easily, but now processes can even be started by putting a document in a certain folder in Documents Cloud Service. It requires minimal configuration on the Documents side, while in PCS you can now use a “Document Start” event for your process.
CorrelationOne important missing feature in PCS was correlation. This feature is there now, so you don’t have to use BPM Suite anymore for your long running, asynchronous interactions with other processes and services. You can use the “Message Catch” event to catch messages with the related correlationId that you have defined. This can be especially handy in cases of migrating your long running processes to a newer version.
QuickStart AppsIf you want to start fast and you’re using relatively standard processes in your business, you can use QuickStart Apps. Currently, there are 6 of those available and I expect more to come in the future. It could also be nice if these could be purchased from the Marketplace.
Embeddable AppsYou can now embed your process forms in other applications, for example various SaaS products. This will help you to create a seamless integration between your processes and other apps.
BI Cloud IntegrationPCS is now integrated with Oracle BI Cloud, where you can use your default or custom analytics. While PCS also has dashboards, they are more for operational information, so this is a nice and much needed extra functionality.
Actionable EmailsJust like in BPM Suite, you can take actions in your processes directly from e-mail messages now. Reusable e-mail templates can be created, in which you can embed process data and actions for users to be taken.
What does the future hold?I think that september’s release has been the biggest one so far for Oracle Process Cloud Service. However, the development team isn’t nearly done yet. Most noticeably on the agenda, there are the new business rule component, as a microservice and based on DMN (Decision Model and Notation), as well as Case Management, which should logically be based on CMMN (Case Management Model and Notation) and hopefully be less complicated than Case Management in BPM Suite. I believe that PCS has grown to be a mature product that can tackle most of your BPM needs already and with the two mentioned additions, it will be ready to fully replace Oracle BPM Suite in a more business-friendly and less technical manner. While not being a trendsetter in the world of BPM, at least Oracle is catching up quickly with modern developments and adding value by seemless integration with other Oracle cloud products.
If you've paid attention to IT news in the last couple of years, you will have noticed that cloud computing is all over the place. Major companies like Oracle, Amazon, IBM and Microsoft are rapidly developing a whole new cloud world for enterprises and most successful startups are embracing the new technologies that come with it. In the meantime, I'm noticing that many of my clients are nowhere near the cloud yet and there's also quite some skepticism among my peers.
Focusing more specifically on Oracle technology, which has been my core business for more than ten years, I think that the movement to the cloud is inevitable. On-premise products are still being supported, but when it comes to new developments, Oracle is taking a cloud-first approach, going as far as abandoning on-premise development altogether for certain products.
As a client, this gives you several options: you can keep moving on a dead end road, still happily run your applications for the next 10-15 years and nothing bad is going to happen. However, you'll be missing out on a lot of new features and business opportunities like that, so you need to be very clear that this on-premise software exactly fits your needs and you won't need anything new. Theoretically, this is possible, but in reality we will hardly see such situations.
So, what are the alternatives? If you really don't want to go into the cloud, you can start replacing your proprietary software with open-source software, because with that you can do whatever you want. No vendor will be telling you that a product will get deprecated, because in the very worst case you can still develop it further yourself if there's no community left to work on it. Obviously, such an approach means quite a lot for your organization: you need to re-educate your technical staff, deal with no or limited support in case of problems and the more modifications you make, the harder it will be to find developers who understand what you're doing.
So, I believe that in most cases it will be viable to develop a strategy for moving to the cloud, even if you decide to move to open source. Find out what's holding you back, check if your concerns are actually making sense (are you sure you can be more secure than Oracle, performing faster than Microsoft or guarantee high availability better than Amazon?) and make an action list to work out the remaining concerns. Maybe you'll end up having some kind of private cloud, either managed by yourself or the cloud provider. As long as you have access to the latest technology, these can be viable solutions, although maybe not optimal when you look at cost of ownership, security or availability.
On the other hand, one should also be mindful to not jump to the cloud without thought: many cloud products are not fully developed yet, so you might be missing some crucial features for your specific needs. Planning carefully is the way to go, but waiting too long might make you lose your competitive edge in the age of digital transformation.
If you're a software developer or admin, what can I say? I remember database developers who didn't believe in middleware and ended up in support roles or unemployed. I remember DBAs who found it unfair that databases got smarter, did nothing to adapt and ended up being pushed off the market. We continuously need to improve ourselves and look to the future.
Of course, if you're happy to do the same work for ten more years and end up being overtaken by those who did reinvent themselves, let it be your decision. But it will not be mine. The cloud is the inevitable future, so you can either jump on the train or be left behind. My decision has been made, what will be yours?
maandag 6 juni 2016
So, what is this country doing to get out of the crisis? Cutting expenses and nothing else. However, this is where things are getting problematic in the long run. Last week, I spent two days at the amazing AMIS conference about Oracle technology. Heard many inspiring stories about the latest developments in IT and realized that none of them are happening in The Netherlands. It's not because we don't have the technological skills: with an incredibly high amount of Oracle ACEs, we're rather the object of envy in the rest of the Oracle world.
In my opinion, the main problem is in the "bookkeeper" mindset. When I was working abroad, companies were using IT to enhance and renovate their businesses. After all, the economic struggle has also become a technical struggle and you need to be on top of things in order to survive.
So I've worked on a project for a Turkish company to enter the digital marketplace and on another project in Australia where IT was moved to the Cloud in order to free up resources, so they can deliver business goals, instead of doing maintenance. In the meantime, in The Netherlands I've been working on a project with the main purpose of taking work out of people's hands, so they can be fired. Also, when I look at disruptive businesses, they are hardly ever from my home country: we're stagnating.
When you look at technical innovation, it's obvious that it has to be driven by business innovation. If you're not going to do anything different with your company, why take the risk of jumping into some new and unproven technology? Why not just optimize what you have and see if you can cut some more expenses?
I have the opinion that innovation is the only way to get out of a crisis. You need to take some risks to have a competitive edge and with the fast developments that are going on, you can't risk waiting too long. You need to have a vision, invest in it and make modern technology the cornerstone of your future business. There are amazing possibilities out there in the Cloud with Internet of Things, Big Data, Analytics etc... and if you don't seize those opportunities, it will be game over sooner rather than later. It's time to start building on the future and the future begins today.