Saturday, 25 February 2017

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 !)

Tuesday, 21 February 2017

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! ).