Showing posts with label ESB. Show all posts
Showing posts with label ESB. Show all posts

Wednesday, 14 January 2015

What is SOA?

What is SOA?  SOA or Service-Oriented Architecture is a software architecture pattern in which applications or systems are constructed from underlying (and usually distributed) software services that conform to a specific set of characteristics, namely:

1.Contract based
2. Location transparency
3. Autonomous
4. Abstract
5. Reusable
6. Composable
7. Stateless
8. Discoverable
9. Extensible
10. Loosely coupled

The primary goal of SOA is software development agility, i.e. the ability to respond the change easily, and cheaply, thus allowing businesses to rapidly respond to changing markets.

Services are typically (but by no means exclusively) implemented as web services, i.e. they operate over the ubiquitous web HTTP protocol, and are implemented either using XML-based SOAP or the lightweight (and more popular) REST paradigm.

The highly distributed nature of this architecture has resulted in a need for a runtime platform (the Enterprise Service Bus, ESB) to help manage the operation of these services, but also to handle complex enterprise integration scenarios involving multiple (and often legacy) platforms, protocols and security models - products like Oracle Service Bus or the open source Mule ESB.

In addition to being an integration solution, the service-oriented pattern also offers an opportunity for easier implementation of high-level business processes using Business Process Management (BPM) solutions that are often offered as part of the ESB product suite.

Service-oriented architecture is highly relevant to the rapidly growing cloud computing model where applications are built in the cloud as orchestrations over public cloud-based APIs, and we are seeing ESB vendors like WSO2 and MuleSoft in or moving into this space, offering cloud-based versions of their products, as well as API management products.

Some will argue that SOA is not new, and that distributed programming involving services has existed for a long time, and they are right.  However those early efforts stumbled on the hurdles of platform incompatibility and standards complexity.  Now, with ubiquitous, and easy to use protocols like REST, web service API development is growing rapidly, and the integration possibilities seem endless.

(What is SOA, Service Oriented Architecture)

Share:

Tuesday, 27 November 2012

How my wife explained ESB to me

Wife: I've been thinking...

Me: (Oh no... what now?) Well done! ...  Ouch! ...

Wife: That service thingy you told me about the other day... lots of little services all helping each other out...

Me: Service-oriented Architecture.  What about it?

Wife: Well, it's a nice idea in principle, but sounds like it would be a nightmare to manage.  A bit like a juggler trying to cope with lots of objects in the air, all different shapes and sizes...

Me: That's a really good analogy.  Yes, service-oriented architecture needs a juggler.  They call it an ESB or enterprise service bus.

Wife (laughing): You men and your three letter acronyms.

Me: It's actually quite a cool concept, a bit like a telephone switchboard.  Services are connected in flexible ways via the bus, without being physically connected to each other.  The bus looks after the connections, and can reroute calls when connections fail for example.

Wife: Like an automatic switchboard operator.

Me: Yes, exactly!  You're fabulous, you know?

Wife: You've only discovered that now?

Me: Er...
Share:

Thursday, 15 November 2012

Choosing an Enterprise Service Bus (ESB) Product

 
Which Enterprise Service Bus (ESB) product you evaluate and choose will depend on your exact ESB requirements, your budget, and any existing vendor relationships or products, but according to Forrester (and me), you might want to at least look at the following ESB products:

Commercial Enterprise Service Bus Products



Open Source Enterprise Service Bus Products



As an aside, Spring Integration  provides an easy entry into the world of ESB concepts, providing a single instance, easy to use integration container with many ESB-like features.  Regardless of which ESB product you end up with, I would consider, assuming you're using Java, decoupling your code from the underlying ESB or low-level protocols using Spring Integration.


Share:

Thursday, 4 October 2012

What is Service Oriented Architecture - Cost

Service-Oriented Architecture (SOA) is great isn't it? Chaos becomes order. Services are available for everybody to reuse. Costs are lowered. The business is truly agile. Shareholders are smiling.

Ah, but its gonna cost you!

Here are some of the items you will need.

  • One big expensive Enterprise Service Bus for all your infrastructural needs.
  • Many application servers for those newly built services.
  • Lots of training and consultancy from the "experts".
  • EAI adapters for those troublesome legacy systems.
  • One pilot project, probably of neglible business benefit.
  • One Enterprise Architecture function to help with your systems governance.
  • One SOA Center of Excellence.
Share:

Wednesday, 3 October 2012

Why Service-Oriented Architecture (SOA)?

If you take a look at a typical medium to large company, the enterprise landscape is littered with systems and applications that firstly use diverse and often obsolete or hard to support technologies, and secondly overlap in terms of the business functionality that they offer. The result is a maintenance and operational nightmare that is increasingly costly to run and hampers business growth.

There are two aspects to this problem: (i) the technology platforms, and (ii) the applications.

The answer to the first is virtualisation, i.e. the ability to standardise on a minimal set of technology platforms that can be grouped and offered as virtual platform service to the enterprise. This reduces operations costs and allows cost effect use of the platforms as economies of scale are applied.

The answer to the second, which is what people usually mean when they say SOA (Service Oriented Architecture), is a way of organising software so that instead of applications being rigid monoliths they become dynamic collaborations of autonomous software services, each providing a distinct function.
The key to achieving both of these is standardisation, both of the enterprise technology set, but also the business processes that utilise that technology. In other words the most fundamental precondition for SOA is a mindset change: that the strategic needs of the enterprise supersede the tactical needs of the local business unit. So before you go out and buy an ESB and the other goodies that will give your business "agility" and other such gloriously profitable attributes, make sure your organisation understands and is prepared for this, that it will need things like an enterprise architecture function, governance and a very patient and even enlightened business community.
Share:

Enterprise Service Bus (ESB) Benefits - Building a business case

Enterprise Service Bus (ESB) benefits to IT could include:
  • facilitates enterprise integration
  • provides and infrastructure backbone for Service Oriented Architecture(SOA) applications and services, for both event driven and composite applications
  • allows faster and cheaper integration of existing (legacy) systems
  • increased flexibility, making it easier to change as requirements change.
  • standards-based
  • scales from point solutions to enterprise-wide (distributed) deployment
  • configuration based rather than code based integration
  • reduces cost of implementing new processes through reuse of existing application and data
  • reduced TCO (total cost of ownership)
  • reliable delivery of messages across disparate technologies and protocols
  • highly distributable, centrally managed service hosting
  • disseminates data through the enterprise
  • can be deployed incrementally
Share:

Preparing for an Enterprise Service Bus


Before embarking on a costly Enterprise Service Bus (ESB) project, you must define clearly what requirement you are trying to satisfy, and hence what capabilities are required from your ESB.

An Enterprise Service Bus is not an Enterprise Silver Bullet, and can be defined as a set of infrastructure capabilities implemented by a middleware technology that helps to enable a Service-Oriented Architecture.  Remember the service capabilities you are looking to implement, thing like: loose coupling, location transparency, cohesion, implementation abstraction, policy-based management, scalability, and so on.

Share:

Wednesday, 22 October 2008

What is SOA - Service Characteristics - Composable

Composability is the ability of services to be used in orchestration scenarios by higher level services or processes. It is a special case of the reusability characteristic in that the services need to be uniform as well as reusable. The reason for this primary reason for this requirement is that the orchestrating service will in all probability but built using something like BPEL not a conventional programming language, so any variations in service style become more difficult to deal with.
Share: