Developer Engagement and Skill Enhancement

Yeah, referring to MuleSoft Champions program. Never been exposed to something like this from a vendor, but loving it.

    The love is basically, there is a propelling force to do "something" to "get something".  The blend of some fun and practical learning is one of the interest which drives. Let us put the fact out, it is a clever, subtle way to spread a company's presence in the market with very little investment. But at the same time to make it successful, the key is, a very active co-ordinator/administrator behind the scenes with an open mind and encouraging constant inputs from the end users. I guess, MuleSoft has done a reasonably good job on this front.

    What I would like to see more is make more challenges esp. in solution implementations. Everytime I pop into their documentation(Eg. Flat file schemas), there are heaps of things to do and not much articles covering that. Putting that as a challenge is one of the ways to go, I guess.

    For now I am getting my points (hopefully including this one !)

Lightweight Mule Journey

Thought of writing-up on my MuleSoft experience so-far, comparing with prior integrations exposure from ActiveX based, point-to-point, XML SOAP web-services to Oracle SOA in BPEL-XLST.

   The one thing I notice on the MuleSoft end is, even though with lots of marketing jargons, there is still a decent thought on the developer-side. Oracle, the mammoth (needs microservice approach for Oracle organization itself !), is quite messy. My reference is towards the Oracle Fusion Middleware, where Oracle SOA is the core.
     This is no way to say that MuleSoft integration uses a standards based approach, but atleast you can see them thinking in terms of Enterprise Integration Patterns(EIP) and API spec-based development. With Swagger (now called open API spec) taking over, MuleSoft has started to increase their support level towards it. Not sure what is the RAML future though, but my 2 cents is that the approach MuleSoft takes is commendable which again reinforces its developer focus, I guess.

  Regarding their desktop application, AnyPoint Studio, a decent editor (but obviously bloated because of the Eclipse genes) is generally functional. Few times we had to close down the Studio and rarely restart the whole system, because of some weird behaviour.
  I like the RAD (Rapid Appliction Development) of the Studio and to my experience the functionality seems to be quite comprehensive with a decent debugging mechanism and the ability to inspect the message flow intuitively. There is a broad thinking and flexibility on your choice of custom scripting/coding (such as Groovy, Java etc..), when certain functionality isn't out-of-the box or one has a special requirement to achieve a particular outcome.
 
  It will be nice to have a single, consistent Mule-specific language, instead of 2 different ones, like the  MEL(Mule expression language) and DWL(Data Weave Language).
 
  Yeah one more thing, they need up their level in terms of monitoring and troubleshooting components, esp. if you have applications on-premises. ARM (AnyPoint Runtime Manager) seems to be a poor cousin when comparing with Oracle SOA's OEM (Oracle Enterprise Monitoring SOA Pack).
 
  Lastly their release seems to be quite often, which is pretty good. Like MuleSoft's offerings (for now! ).

API Management

I was looking for an open-source API Management tool, as MuleSoft seems to be costing an arm and a leg - hope they change their model. It seems they are charging with the intention that all APIs are monetized, which is fundamentally wrong.

   During this research found a nice website which summarized on API Management features. 

Vendor access to Database - Not a Good Idea

Recently, I was queried on what would be the best way to retrieve data from a database within our enterprise, which is required by a vendor to consume. Basically, an external application looking to consume our data.
    As obviously, suggested to expose as API (REST/SOAP) or spew out a CSV/TXT/sth. file which will be consumed by the external vendor. It seems that none of the above could work for the vendor, without writing some customized code. With this stage set, I thought of enumerating why one shouldn't give access to their database to someone whom we aren't in control. Let's begin !

(1) Accessing data through a client application/DB Connectivity API (Eg. JDBC)
NO-NO:   Database patches/upgrades are normal and if we have to do any of those, we need to remind ourselves to check with the external vendor, whether it is all good, from their DB access API/client. This could have a roll-on effect on other databases installed in the same host. A very tight dependency, which DBAs will hate.
      Additionally, there is no assurance of how good the database connectivity life-cycle is. Personally seen external applications screwing up enterprise database, by not closing DB connections or utilizing a high DB processes, which in turn affect other applications performance. The very hard part is debugging the issue, when all that one knows an external application "ABC" is accessing our database.

(2) Giving access as a database view, to prevent any misadventures from external vendor.
NO-NO:  Consider a situation, where we would like to use the same DB view with some minor datatype or new field changes, we need to go to the vendor to check whether this is fine. If not, we will create another database view, very similar to the one used by the external vendor and the schema mess-up begins here.


(3) Vendor says, direct DB access is the only way
NO-NO:  This is where the principles of integration within organization kick-in. Deviating from it, means we are getting into the "spaghetti" world of integration, which may not be a nightmare tonight, but will happen for sure in the near future.

Can microservices simplify SQL queries?

I have seen very complex SQL queries embedded within code, esp. when they are across business applications boundaries. Eg. Finance, Billing, GIS SQL queries, working together to retrieve data of interest. Disparate systems making it to work as "one",
   Can microservices bring simplicity to that, as it is the very nature of it to implement them in a bounded specific domain-level context ?  It sounds logical to me that the answer is "YES"!
Again, someone for the love/hate of it can make a complex SQL or by the very nature of the complexity of the underlying data relationship. 

NoESB - A Marketing Gimmick ?!

Some API vendors are doing a peaceful web-oriented fighting with some ESB vendors. The core content is, ESB is not required or better don't use it if you want to improve your time to market and making the organizational software foundation agile.
   Well, well, all those arguments I see are related to cloud and new products/development. The interesting part is putting forward that API Gateway is a replacement for the ESB, where the API Gateway does the similar functionality to ESB. Now this argument itself debunks the theory of "NoESB", when you have subset of similar functionality in 2 different approaches.
   Did some more Googling and landed up at WSO2 site - a popular API vendor, not that I am fan of it. In SlideShare API-Centric Architecture  they have a clear point on that their API gateway is actually a full-blown ESB with some constraint and one has the choice to install the missing features to make it a ESB !
   ESB has their role as much as API, like for integrating in complex scenarios, file/ftp based and legacy application integrations. At the same time, I am a strong supporter on "smart ends and dumb pipes", which I have many times seen violated in BPEL processes. Business logic should be encapsulated in its domain and not be floated in a middleware. This is where the µservices principle stands attractive.
   It is a pity to see vendors(again!) playing their marketing games and continuing with the confusion era as much as it started with SOA. Beware is the only word, I say to myself !

  

Journey of Integration

The usual Initial Ramblings
            In my new job I am supposedly THE person in getting an integrated integration solution(along with external consultants) in place and thereby lend for future business process automation. Prior to this one, I was working in Oracle SOA in BPEL-JDeveloper combo. and all was honky dory - basically all where happy and ended/continued in peace and love !  This is not the case now - good to keep me ticking in my integration knowledge pursuit and bad when you see so many difference techniques, approaches, thoughts and more importantly our wonderful vendors pursuit to keep it confusing - may or may not be deliberate but obviously for monetary purposes.

Let's Take Off !

Been reading lots of articles, some books and watching my mind in putting together all that was read. Simply put, a lot of stuff and very little conclusion with more towards confusion. Let us go through the list of magic words - SOA, BPEL, ESB, EDA, Messaging, Integration frameworks, Middleware, Process Orchestration, Process Choreography, Process Workflow, BPM, BAM, Queues, Microservices, REST, API and the endless list continues.

      Statements like this "Design and publish APIs for end customers, B2B, or mobile - APIs can be in SOA or REST" make things more a hell. This is supposedly from integration leaders' product documentation. APIs can be in SOA ?!  SOA is an architectural principle and SOA can be pursued through SOAP over HTTP (that is what the doc. is probably trying to say), REST style services, Microservices and anything more some integration gurus can add to.
    Since we touched upon SOA, let us probably look at the different approaches of SOA. The technical gurus prefer the word "Service Oriented Approach" instead of "Service Oriented Architecture", which seems from history (when I was physically a kid !), a failure, across the geography.

From my perspective, SOA could be implemented as "BPEL" or "ESB".  The choice of which one depends on the needs, which makes sense isn't it ?! Hope you are part off the minority!

•  BPEL is fine for long-term processes and involves human interaction. Due to the language nature, it is heavy and can involve complex logic, including business ones. This is where it may not suit the new fad of get SOA the right way - Mrs. Microservices, where you want to keep the smarts at the end points and not in the middleware.
• ESB is a mechanism to move messages supposedly in a light weight manner with minimal required logic/actions to the message within the bus/pipe. This may fit the Mr. Microservices design style. The other denouncing term is "Egregious Spaghetti Box". So watch out what you are trying to achieve. Keep you principles clear and focused. 

Hope I haven't added another mess to the existing mess in the integration world.