SOA and REST with Grails

In my previous articles I’ve introduced REST and how to leverage RESTful web services on the Grails platform. We will further discuss Grails in a service-oriented architecture using RESTful services, and we will try to visualize the architecture in detail. Continue reading “SOA and REST with Grails”

Grails – RESTful Webservice using JAX-RS plugin

I discussed about RESTful architecture consideration and how to build RESTful web services using Jersey JAX-RS [JSR 311]  in JAVA. Today I am going to discuss how to build the RESTful web services using Grails framework.

GRAILs framework is the platform which provides end to end solution to build web application from scratch to advance intuitive RIA web application. Grails potentially be a one-stop shop for all your enterprise application development. Grails is modular, allowing you to pick and choose which modules are applicable for your application Continue reading “Grails – RESTful Webservice using JAX-RS plugin”

Best Practices – SOA Service Registry

  

Use the Right Type of Module:

  • Think about mediation logic vs. process logic.
  • Use Mediation Modules (Oracle ESB) for integration / mediation logic:
    • Short-running, minimal choreography.
    • Supports header manipulation.
  • Use (Integration) Modules (Oracle 11g Suite) for business / process logic:
    • Can be long-running, powerful choreography and business logic

Design your System Topology

  • Check if need more than one server.
  • Use clustering for scalability, For failover etc
  • Database selection.
  • Need to use a load balancer / HTTP server for failover and scalability.

Spend Time on Interfaces and Business Objects

  • Refactoring support is limited inside mediation flows, so good to get this right first time round.
  • Adopt a naming convention.
  • Add constraints?
    • Add modelled faults?
  • Think about namespaces.
  • Configure default namespace policy before you start.

Consider How you Split up Mediation Modules

  • How many mediation flows inside each mediation flow component?
    • Large number of modules impacts performance / deployment.
    • Small number impacts ease of development.
  • Remove unused library content.

Select your Binding Types Carefully

  • Often binding type dictated by circumstance.
  • But if you have the scope to decide:
    • Prefer SCA default/native for inter communications
    • Prefer Web Services for synchronous service exposure
    • Prefer JMS for asynchronous service exposure
  • Sometimes you have alternatives. For example:
    • Web Services binding : allows easy access to SOAP headers
    • Or
    • HTTP with SOAP data binding : allows access to HTTP headers but not SOAP headers

Consider your Custom Coding Strategy

  • Custom mediation:
    • Most useful for one-off coding.
    • Cannot be re-used between modules.
    • ‘Visual’ mode available which may be useful to those less comfortable with Java/SDO API.
    • Custom primitive (also called roll-your-own primitive):
    • A first-class new primitive: same abilities as any other primitive type (XSLT, Endpoint Lookup…).
    • Can have customisable properties.
    • Appears in palette in WID.
    • More re-usable, but more work to create.

Consider your Logging Strategy

  • You will want one; consider it before you start developing.
  • Options include:
    • Message Logger – limited functionality – logs only to a fixed schema database table.
    • JDBC or Flat File Adapter (in separate mediation module?)
    • Custom mediations logging.
    • Custom primitives.

Use Source Control & Do Automated Builds

  • Use source control and integrate with IDs
  • Only one developer per mediation module at once.
  • Automated build direct from source control.

Do Unit Testing
Do the unit testing before check –in