Billing Options

Billing Options

• Physical Goods
• Assets Owned
• Usage Based Services
• Professional Services
• Recurring Servicies

The REST architectural style - six constraints

The REST architectural style describes six constraints. These constraints, applied to the architecture, were originally communicated by Roy Fielding in his doctoral dissertation (see http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm) and defines the basis of RESTful-style.

The six constraints are:

• Uniform Interface
  The uniform interface constraint defines the interface between clients and servers. It simplifies and decouples the architecture, which enables each part to evolve independently. The four guiding principles of the uniform interface are:

  Resource-Based

  Individual resources are identified in requests using URIs as resource identifiers. The resources themselves are conceptually separate from the representations that are returned to the client. For example, the server does not send its database, but rather, some HTML, XML or JSON that represents some database records expressed, for instance, in Finnish and encoded in UTF-8, depending on the details of the request and the server implementation.

  Manipulation of Resources Through Representations

  When a client holds a representation of a resource, including any metadata attached, it has enough information to modify or delete the resource on the server, provided it has permission to do so.

  Self-descriptive Messages

  Each message includes enough information to describe how to process the message. For example, which parser to invoke may be specified by an Internet media type (previously known as a MIME type). Responses also explicitly indicate their cache-ability.

  Hypermedia as the Engine of Application State (HATEOAS)

  Clients deliver state via body contents, query-string parameters, request headers and the requested URI (the resource name). Services deliver state to clients via body content, response codes, and response headers. This is technically referred-to as hypermedia (or hyperlinks within hypertext).

  Aside from the description above, HATEOS also means that, where necessary, links are contained in the returned body (or headers) to supply the URI for retrieval of the object itself or related objects. We'll talk about this in more detail later.

  The uniform interface that any REST services must provide is fundamental to its design.
• Stateless
  As REST is an acronym for REpresentational State Transfer, statelessness is key. Essentially, what this means is that the necessary state to handle the request is contained within the request itself, whether as part of the URI, query-string parameters, body, or headers. The URI uniquely identifies the resource and the body contains the state (or state change) of that resource. Then after the server does it's processing, the appropriate state, or the piece(s) of state that matter, are communicated back to the client via headers, status and response body.

  Most of us who have been in the industry for a while are accustomed to programming within a container which provides us with the concept of “session” which maintains state across multiple HTTP requests. In REST, the client must include all information for the server to fulfill the request, resending state as necessary if that state must span multiple requests. Statelessness enables greater scalability since the server does not have to maintain, update or communicate that session state. Additionally, load balancers don't have to worry about session affinity for stateless systems.

  So what's the difference between state and a resource? State, or application state, is that which the server cares about to fulfill a request—data necessary for the current session or request. A resource, or resource state, is the data that defines the resource representation—the data stored in the database, for instance. Consider application state to be data that could vary by client, and per request. Resource state, on the other hand, is constant across every client who requests it.

  Ever had back-button issues with a web application where it went AWOL at a certain point because it expected you to do things in a certain order? That's because it violated the statelessness principle. There are cases that don't honor the statelessness principle, such as three-legged OAuth, API call rate limiting, etc. However, make every effort to ensure that application state doesn't span multiple requests of your service(s).
• Cacheable
  As on the World Wide Web, clients can cache responses. Responses must therefore, implicitly or explicitly, define themselves as cacheable, or not, to prevent clients reusing stale or inappropriate data in response to further requests. Well-managed caching partially or completely eliminates some client–server interactions, further improving scalability and performance.
• Client-Server
  The uniform interface separates clients from servers. This separation of concerns means that, for example, clients are not concerned with data storage, which remains internal to each server, so that the portability of client code is improved. Servers are not concerned with the user interface or user state, so that servers can be simpler and more scalable. Servers and clients may also be replaced and developed independently, as long as the interface is not altered.
• Layered System
  A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers may improve system scalability by enabling load-balancing and by providing shared caches. Layers may also enforce security policies.
• Code on Demand (optional)
  Servers are able to temporarily extend or customize the functionality of a client by transferring logic to it that it can execute. Examples of this may include compiled components such as Java applets and client-side scripts such as JavaScript.

  Complying with these constraints, and thus conforming to the REST architectural style, will enable any kind of distributed hypermedia system to have desirable emergent properties, such as performance, scalability, simplicity, modifiability, visibility, portability and reliability.

  NOTE: The only optional constraint of REST architecture is code on demand. If a service violates any other constraint, it cannot strictly be referred to as RESTful.

AnyPoint Platform Exchange 2.0 - Whats New?

AnyPoint Platform Exchange 2.0 - Whats New?

VM connector in the flow

VM connector creates a transport barrier in the flow: 

In a transport barrier, your Mule message goes through an entire serialization and deserialization process which results in a new Mule message with the same payload. 

Read about the effect of transport barrier on a mule message here.

When one would prefer to use a VM transport over a flow reference?


One case would be that VM endpoints enable message redelivery strategies to be configured in your exception handling blocks – this is not possible with flow-refs. 

VMs can do this because they internally use a queue to hold messages while flow-refs are similar to simple method calls.

Difference between flow, sub flow and private flow in MuleSoft

All three Flow types can be referenced from a Flow Reference component.

Flow is a message processing block that has its own processing strategy and exception handling strategy. Used in integration tasks, data processing, connecting applications, event processing, etc.

Subflow always processes messages synchronously but inherits processing strategy and exception handling strategy from the calling flow. It can be used to split common logic and be reused by other flows.

Private flow does not have source define. It can be synchronous or asynchronous based on the processing strategy selected. Also, they have their own exception handling strategy. Allows you to define different threading profile.

====

Processing strategy

While sub-flow is always synchronous the private flow behavior depends on the processing strategy

Performance

Sub-flow has a better performance when using request-response exchange pattern as they are actually a new processor chain injected in the flow at configuration time. Private flows are instead useful for asynchronous call provided you configured their processing strategy properly

Exception strategy

Private flow: the exception will be trapped by the local ES the exception will not be propagated to that main flow.

Sub-flow: will use the exception strategy defined in the main flow and it will have the exception got in the sub-flow.

Message Properties

In both case all properties, regardless their scope, are preserved from the main flow.

Threading profile

Private flows: allows you to define a different threading profile, but if you don't they will use the default one, not inherit the invoking flow one 

Sub-flows: they will share the parent flow threading profile configuration

Overall

Sub-flows run within the same execution context (exception handler, transaction, properties) of its main flow, while private flow will initiate a new execution context.

To summarize, sub-flow is always recommended except in the case the exception needs to be handled in a separate flow different from the main flow or you are implementing an asynchronous pattern

Agile Methodologies

Agile Methodologies

• SCRUM
• XP - Extreme Programming
• LEAN KANBAN
• CRYSTAL
• Dynamic Systems Development Method (DSDM Atern)
• Feature Driven Development (FDD)
• Agile Project Management (APM)
• OpenUP

Agile Concepts

Tools and Techniques

PMI-ACP Exam Content (7-Domains)
1. Agile Principles and Mindset
2. Value Driven Delivery
3. Stakeholder Engagement
4. Team Performance
5. Adaptive Planning
6. Problem Detection and Resolution
7. Continuous Improvement


Tips, Tricks, Strategies and Tools

Agile adoption leads to effective scaling and faster delivery

Take up more projects and deliver faster

PMI - Agile Certified Practitioner (ACP)

Agile

• Customer requirements and solutions evolve through the repeated cycles of planning, collaboration and delivery
• Iterative and Incremental (Evolutionary)
• Meets changing needs of stakeholders
• "Just Enough Ceremony" - means creating only those documents that justifies the requirement.

Agile Best Practices

• Face to Face communication
• Shorter Development cycle
• Business and Developer Collaboration
• Working software as the primary demonstration of progress
• Effective Engineering Practices
• Frequent demonstrations of progress and early ROI
• Inspect and adapt to business changes
• Retrospectives and continuous improvement

Agile Core Principles and Practices

• Early Delivery of Value through Iterations with Demos
• User Stories reflect Business Value and Priority
• Continuous Involvement of the customer
• Acceptance Tests for all Requirements
• Retrospectives
• Sustainable Pace or Velocity
• Communication
• High Visibility

Scrum Learnings

Three Pillars of Scrum

• Transparency
• Inspection
• Adaptation

Scrum Team & Roles (comprises of FIVE to NINE members 7+-2 excluding the SM & PO)

• Product Owner
• Scrum Master
• Development

Key Terms

• Product Backlog
• All work to be performed in the foreseeable future, both well-defined and that requires further definition
• Sprint 
• period of 30 days or less within which a set of work will be performed to create a deliverable
• Spring Backlog
• A well-defined requirement that can be worked on with little change, 
• over 30 days or less,
• resulting in a tangible, potentially shippable incremental deliverable
• Scrum
• A daily meeting at which progress and impediments to progress are reviewed

- Release Backlog (Shortlisted prioritized items ready for a Sprint execution)

- Visibility and Velocity

Scrum Meetings

• Sprint Planning
• Daily Stand-Up Meeting
• Sprint Review
• Retrospection

a

XP - Extreme Programming

XP

• respond to high cost of changing requirements; and
• establish strong engineering practices to improve software quality

XP introduced revolutionary concepts, such as:

• Test Driven Development;
• Continous Integration;
• Iterations; and
• User Stories

Five Core Principles of XP

• Communication
• Simplicity
• Feedback
• Courage
• Respect

XP Practices

• Fine-scale feedback
• Pair-Programming
• Planning Game
• Test-Driven Development
• Whole Team
• Continuous Process
• Continuous Integration
• Refactoring or design improvement
• Small releases
• Shared Understanding
• Coding standards
• Collective code ownership
• Simple design
• System Metaphor
• Programmer Welfare
• Sustainable pace

AnyPoint Studio 7 Beta

 These are some of new features and improvements in Studio 7 beta:

* Improved palette which enables users to more quickly discover what they’re looking for by searching directly for operations and saving favorites.
* Users can now explicitly manage which connectors and modules are associated with a project.
* Connectors and modules are now managed directly by Anypoint Studio, and do not require users to manage update sites.
* Easily navigate to code from visual view by right clicking on a component and clicking “View XML”
* Maven is now embedded out of the box inside Studio. Additionally, every project now has a Maven POM, making it easier to incorporate projects into CI/CD systems.
* Flows and scopes are now collapsable.
* Updated icons make flows easier to read.
* DataSense metadata is now stored in a human readable format this is easier to share, commit and merge.
* Support for importing API specifications from Design Center
* Improved user experience for connector and modules
* Simplified experience to manage credentials when logging into the Anypoint Platform