SOA PROBE

XML appliances

2010-09-06T00:59:00.000-07:00

An XML appliance is a specialised piece of almost ESB-like hardware offering facilities like:

Hardware encryption/decryption
Digital signature creation/verification
Fine grained Authentication, Authorization, and Auditing
XML threat protection
Dynamic routing
Message filtering
MIME, DIME, and MTOM attachment processing
XML acceleration
Web services management
Service level monitoring
EIS integration (Protocol conversion, MQ, JMS, Database, Webservices)
WS-* support with registry/repository integration

So why would you want to use one of these?

Enhance performance by removing the burden of CPU intensive XML processing from servers offering services
Appliances are "hardened" in security terms (as compared to an out of the box server) so ideal for DMZ deployment
Lower total cost of ownership
Wrap legacy systems with limited service offerings with WS-* capable services
Platform integration

IBM for example offers a suite of such appliances in its DataPower range: see the "IBM® WebSphere® DataPower® SOA Appliance Handbook" for a good introduction to the topic and IBM's offering.

Canonical Data Model

2010-09-03T00:16:00.000-07:00

You won't be doing SOA for long before you encounter the concept of a Canonical Data Model (CDM). The idea is that you analyse your business processes, and derive a set of standard data types that you model using XML schema and use in your services - the Canonical Data Model. Perhaps you go one step further and bring in an industry model like IBM's IFW and use that as a starting point.

In the real world however, there is an estate of legacy systems that will tend to have a narrower view of data types than that proposed by the CDM. Some will only be interested in a particular aspect of the CDM types, some subset of the attributes, whereas others will have a different view completely. The issue is that there are different ways to model things.

THe CDM approach assumes that all systems' data is mappable to the CDM types, so through CDM all systems will be able to communicate with each other through your SOA. Of course some optionality will need to be built in since not all systems will have the CDM data attributes.

Anything that is not in the CDM is not deemed of enterprise interest. Those quirkly little data attributes that exist in system X are not in the CDM because they are not of interest to anyone else. If they become of interest, then of course the CDM will need to be changed and this is where your optionality/extensibility model is key. You want to be able to add the quirkly little attribute without breaking the rest of your enterprise.

CDMs need to have room for minor change and growth, but it is assumed that anything more fundamental would not be required because the CDM models the company's business processes which are stable in theory.

And of course agile too, which feels a bit oxymoronic, but what do I know? :)

Accepting Change

2010-09-01T00:11:00.000-07:00

"The only constant is change" and the world of SOA is no different. No matter how much upfront business process modeling is done, or how perfect your service granularity is, or how wonderfully compliant you are with WS-*, the reality is that your services will have to change to keep pace with change - business agility implies change. And if your SOA has been working, there should be a whole host of consumers of those services who will not be happy at all with having to change. Change involves project cost, cost requires budgetary approval, and approval requires a Business appetite for the change. But since the change won't always appear to benefit the Business, it will very often not be approved, and your SOA will go the way of most system landscapes: to legacy, riddled with complexity, redundancy and consequent fragility.

So how do we get the Business to accept Change as a necessary evil to allow them the agility they dream of?

There are several approaches, including:

1. Governance - the "stick" approach - regulate/force change through rigourous software and portfolio managment processes - this requires an organisational culture of sufficient maturiry and Business buy-in to the concept of Enterprise Architecture to work

2. Charging - the "carrot" approach - charge for the use of services and make it cheaper to reuse than to build, and to be on the latest version than a "legacy" version.

Orchestration vs Choreography?

2009-10-22T01:46:00.000-07:00

I was going to write a post on this subject but found an excellent article by Mike Rosen instead.

Job done. :)

What do I put in my registry?

2009-10-22T01:08:00.000-07:00

I'll talk later about asset management, but for now, what exactly belongs in a service registry?

Well, services obviously, stupid.

But what about stored procedures? Or legacy, remotely invokeable services? Or batch feeds? Or ETL (Extract Transform and Load)?

I would suggest that the answer to this is "yes". I know there is no fancy XML contract that can be enforced at runtime etc but so what?

SOA is about organising your enterprise as much as anything else, which is why I believe Enterprise Architecture is a pre- or co-requisite to SOA (but that's another rant), and if you are documenting and governing your services (of all types) then you're well on your way to the path of SOA enlightenment.

Standardisation of protocol and interface will follow.

We have a registry!

2009-10-21T05:53:00.000-07:00

How exciting. At long last I am a working somewhere with thousands of services, a registry/repository, a service registrar and established governance processes around the use of services.

Could life get any better for an SOA believer?

Yes, because unfortunately some groups have decided that all this stuff is too much bother and have come to a peer-peer arrangement regarding the use of services.

So the registry is inaccurate.

So the whole house of cards collapses in a horrible, useless heap.

You see, reuse like recycling only works if the there are practical as well as ideological reasons for doing it. In this case either the governance was not strong enough, or the populace were not sufficiently bought into the enterprise benefit of SOA. Take your pick.

Lesson? A registry does not an SOA make, whereas an organisation (emphasis on organise) just might have a chance.

Competitive Services

2009-10-04T10:08:00.000-07:00

I have been reviewing ITIL 3 with a view to updating my article on Service Management, and came across the notion of competitive services.

This is a very common notion when one looks at services in the usual, non-SOA sense where services are being offered in a market place and have to compete, but does it apply to SOA?

Well, clearly if you are looking at services offered in the internet by companies engaged in Cloud computing and such like, e.g. Google or Amazon, the answer is yes, but what about your typical corporate enterprise landscape?

I think the answer is still yes, but for different reasons.

Outside a corporation you expect multiple service providers to offer similar services, and to compete in terms of functionality, but within a corporation, the whole point of SOA is to eliminate redundancy, so we're not expecting there to me more than one service of any particular kind.

No, within a corporation, services are competing not against each other, but against the old way of building software. There is still a fair bit of resistance out there to the services way of doing software. Its a bit like recycling: wonderful concept in theory, after all who does not want to save the world? But the minute it gets inconvenient for the individual you see it going in the bin, so to speak.

Neptune Software Plc

2009-08-17T05:43:00.000-07:00

Please note that as of August 2009 I am no longer associated in any capacity with Neptune Software Plc.

Migrating Weblogic to JBoss (4)

2008-11-12T00:29:00.001-08:00

Ok, so now you have some fairly respectable, though not yet perfect, style sheets, but how do you apply them to hundreds of deployment descriptors, potentially repeatedly as you refine the stylesheets?

Ant, is the simplest answer. Ant is widely used to build and deploy J(2)EE applications and includes a very hand XSLT task which fits the bill perfectly. For .Net-ers, there is NAnt

For example...

Migrating Weblogic to JBoss (3)

2008-11-06T06:05:00.000-08:00

My XSLT skills are coming on pretty nicely, but the real battle in all of this is finding equivalent features for those Weblogic application server specifics that we've used. So far I've been able to map most features 1-1 between the respective deployment descriptor files, but today I encountered one that doesn't fit this pattern. In Weblogic, entity-cache is in the weblogic-ejb-jar.xml, whereas in JBoss its equivalent is in the jbosscmp-jdbc.xml not jboss.xml, so XSTL becomes tricky.

I'm also pondering moving to XDoclet since it would allow us to maintain one source going forward and still target multiple application servers, but that would mean redoing all our Weblogic descriptors and involves some element of risk, particularly as I'm not certain all the features we use are covered by XDoclet.

If you've not used XDoclet before, it allows one to embed deployment configuration within Java and then generate XML deployment descriptors using an Ant task. For example see below (notice the use of @ejb, @jboss, @weblogic and @websphere tags.) An additional benefit of this approach is it enables one to see clearly which open and which app server specific JEE features are being used.

/**
* This is a teller bean. It is an example of how to use the XDoclet tags.
*
* @ejb.bean name="Teller"
* description="Teller example bean"
* jndi-name="ejb/bank/Teller"
* type="Stateless"
*
* @ejb.ejb-ref ejb-name="Account"
* ref-name="ejb/bank/Account"
*
* @jboss.ejb-local-ref ref-name="File"
* jndi-name="blah/File"
*
* @ejb.ejb-ref ejb-name="Customer"
*
* @ejb.security-role-ref role-link="Administrator"
* role-name="admin"
*
* @ejb.permission role-name="Teller"
* @ejb.permission role-name="Administrator"
*
* @ejb.transaction type="Required"
* @ejb.transaction-type type="Container"
*
* @ejb.resource-ref res-auth="Container"
* res-name="jdbc/DBPool"
* res-type="javax.sql.DataSource"
*
* @jboss.resource-ref res-ref-name="jdbc/DBPool"
* resource-name="MyDataSourceManager"
*
* @jboss.container-configuration name="Standard Stateless SessionBean"
*
* @jboss.ejb-ref-jndi jndi-name="ejb/bank/Account"
* ref-name="bank/Account"
*
* @weblogic.pool initial-beans-in-free-pool="1"
* max-beans-in-free-pool="3"
*
* @weblogic.stateless-clustering stateless-bean-call-router-class-name="Whatever"
* stateless-bean-is-clusterable="True"
* stateless-bean-load-algorithm="Whazzup"
* stateless-bean-methods-are-idempotent="Sure"
*
* @websphere.bean timeout="239"
*
*/

Agile SOA?

2008-11-05T05:48:00.000-08:00

SOA promises business agility, so the question naturally arises whether Agile methodologies (as in XP, Scrum etc) are better suited to SOA development than more traditionaly (albeit iterative) methodologies such as RUP.

If you're not familiar with Agile principles you've probably been marooned on an island somewhere. Agile is the slated answer to the software development crisis. To quote the Agile Manifesto (http://www.agilemanifesto.org/principles.html):

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The key principles of Agile methodologies include things like:
- Customer satisfaction through rapid, continuous delivery of functional software
- Working software, not documentation, is the principal measure of progress
- Change is welcomed
- Close, face-to-face daily cooperation between business people and developers
- Projects are built around motivated individuals, who should be trusted
- Continuous attention to technical excellence and good design
- Continuous integration of source code changes
- Simplicity
- Self-organizing teams
- Regular adaptation to changing circumstances
- Test driven development

Agile methodologies are in general suited to small teams of senior developers with rapidly changing requirements and an end user. Some work has been done to apply Agile on the larger scale but in general the larger the scale and number of interworking groups, the less agile is applicable "to the whole".

The last phrase is key, because certainly there is no issue with organising service development teams in an Agile manner, however Agile as a methodology for delivering enterprise SOA is surely inappropriate?

SOA is highly planned, requires a defined architectural and organisational framework in which to operate, needs lots of up front business modeling to help drive service requierments, needs formally defined and well-documented contracts, needs formal rigorous change management, and finally some measure of stability because of the cost of change to clients.

Is SOA Non-Trivial?

2008-10-29T08:53:00.000-07:00

I have just published an article on this topic over at SOA World.

Migrating Weblogic to JBoss (2)

2008-10-28T09:14:00.000-07:00

Hmmm, I may have spoken a tad early.

The XSLT scripts I found only translate the very basic deployment descriptor elements. The remaining elements are usually of the vendor-specific performance optimisation type which often don't have a 1-1 equivalent, if they have one at all.

The JBoss community forums are very quiet on these fronts. Perhaps there is a conspiracy to drive me to JBoss.com's migration programme...

Grumble.

Migrating Weblogic to JBoss (1)

2008-10-23T08:10:00.000-07:00

This is the first in a series of posts on the joys of migrating our JEE application from Weblogic to JBoss. Being JEE it should be trivial right? ;-)

The steps so far...

Stripped out a couple of EJBs from our application to port as a POC
Jboss download from jboss.org and installation was very quick and painless.
Read some of the documentation which is fairly good, and fine when supplemented with Google, but not as good as Weblogic's
JBoss runs pretty much out of the box and is very quick. Needs Sun JRE - it didn't like JRockit (which is bundled with Weblogic)
Setup Oracle datasources (non XA for now) and message queues and topics. Found the documentation clear as mud and had to get help from examples
Rebuilt our JEE application against the Sun JRE and JBoss EE library and found that we were using some Weblogic classes. No more.
Found a free set of XSLTs to transform our Weblogic EJB deployment descriptors to JBoss. Worked mostly but needed some manual tweaking. I'll fix the XSLTs sometime.
Dropped our application EAR in to the deploy folder
Started JBoss
Removed the CreateException from our MDB ejbCreates. JBoss complained rightly that these violated the EJB spec and even gave the section number! How cool is that?
Changed the JNDI properties in our application configuration files
Application deployed pretty much first time which surprised me no end
Ran a little test and got some cryptic SQL error (Invalid scale size. Cannot be less than zero) which after much hunting turned out to be an Oracle-Sun JDBC incompatibility issue resolved by using -Doracle.jdbc.J2EE13Compliant=true on the server
And that was pretty much it folks!

J(2)EE rocks and vendor extensions don't! Fortunately our app was built with portability in mind so it should have been this easy. Porting was an interesting exercise and much nicer than Powerpoint architecture for a change.

Initial JBoss impressions? Very favourable (apart from the imperfect documentation).

Now I have to get a cluster running and test messaging, but a cup of coffee beckons. first.

P.S. Happy to share some of the details with you if you email me

Service Characteristics - Contract based

2008-10-23T06:23:00.000-07:00

Software in general is required to conform to a defined functional interface, and services are no different in this respect. For example, web service interfaces defined in WSDL (Web Service Definition Language) allow the definition of data types, input and output messages, operations, invocation protocols, and even the location of services. WS-Policy may be additionally used to define additional elements of the interface such as security policies.

Interfaces are however very weak on the behavioural aspects (semantics) of services. A service could return structurally correct data to a consumer but still not meet its functional obligations. Ensuring that services satisfy the behavioural contract is best done through automated test suites in my experience. Perhaps one day we will be able to define pre- and post-conditions and have these verified by the service management software but I wouldn't hold your breath.

In addition to functional obligations, services also have operational obligations both the consumers but to their operators. In other words service contracts are much more like SLAs and OLAs than traditional functional interfaces.

Contracts should ideally be kept in the service registry/repository, and where possible in a machine readable format to be used by service management software to help enforce the contracts at runtime.

Of course such runtime enforcement of contracts comes with a performance penalty, but lets not spoil a lovely ideal with picky details... ;-)

Service Characteristics - Composable

2008-10-22T01:02:00.000-07:00

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.

This uniformity includes things like:

Interface granularity

I hate the phrase “coarse grained” because its almost meaningless in any practical sense, however services do need offer a uniform level of granularity in order to be composable.

Error Handling

Service consumers need to be able to differentiate between unexpected “system” exceptions, and recoverable “business exceptions” which may be retried under different conditions or by supplying different data. In the case of system exceptions the consumer won't know for sure if the service operation completed or not, since for example the network connection might have died after the service completed its transaction. For this reason its desirable that services be idempotent, I.e. retriable. Where services are not idempotent, compensating (undo) operations should be offered.

Security

Composable services should ideally offer a uniform security model to consumers, including single sign on abilities, channel or payload encryption.

Whilst it is possible to design such uniformity into your services, the reality is that in a typical enterprise landscape the underlying service platforms and functional interfaces will be quite varied. This is where Enterprise Service Buses come in, providing features such as multi channel adapters, single sign-on, security adapters, routing and message transformation.

Service Characteristics - Abstract

2008-10-17T13:39:00.000-07:00

Services must be abstract in the sense that they offer a functional interface that is not tied to any particular underlying implementation of that interface. In other words they should hide implementation details such as programming language, operating system platform, database structure, internal object model, etc. Abstraction supports other service characteristics such as reusability, extensibility and reduces coupling between producer and consumer.

The degree of service abstraction that is achieved is often linked to whether the service was designed top down or bottom up.

Top down services begin with business domain model and processes which translate ultimately to service operations and types, e.g. in the form of WSDL and XML schema in the case of web services. Such services will offer the highest level of abstraction since are designed without an implementation in mind. However, top down services require a translation between the interface and implementation which can sometimes introduce a performance penalty, e.g. translating business keys to database identifiers.

Bottom up services begin with an implementation and typically involve the use of toolkits to generate the service interfaces. Such services are closely coupled to their implementations and consumers. However, bottom up services are enticing because firstly they offer the ability to quickly expose existing code as services, and secondly because they allow the use of implementation specifics such as database identifiers to improve performance.

These gains offer a false economy and should be resisted. The long term gains of well designed, adaptable services that reflect a business domain far outweigh any short term performance or time to market gains.

Service Characteristics - Autonomous

2008-10-17T05:18:00.000-07:00

A service is autonomous if it has full control over its internal logic. This requires that it has clearly defined and isolated (decoupled) functional and operational boundaries, that it is independent of other services and only communicates via contract-driven messages and policies.

A consumer should exercise no influence over the service other than to execute it and to provide input values. The service should have minimal dependency on its execution environment.

Autonomy benefits both the service consumer and provider:-
- Consumers are protected in that the service adheres strictly to agreed contracts.
- Providers have greater reassurance because service level agreements are adhered to and services offer deployment flexibility because of their environment independence

SaaS and J(2)EE

2008-10-16T05:38:00.000-07:00

Introduction

Multitenancy refers to the architectural principle whereby a single instance of software runs on a software-as-a-service (SaaS) vendor’s servers, whilst serving multiple client organizations (tenants). This is in contrast to multi-instance architecture where separate software instance or hardware systems are set up for different client organizations. in other words, under a multitenant architecture, applications are required to virtually partition data and configuration so that each client organization works with a customized virtual application instance. Customization typically includes aspects like user interface branding, access control, data and configuration, workflow, etc

The primary goal of multitenancy is cost savings, both for the SaaS provider and client. For the client the saving results from not having to operationally manage the application. For the provider the saving results from lower operational costs because of a single application instance on shared infrastructure providing a sevice to multiple tenants.

Deployment Options

From a deployment perspective there are several options whereby the requirement to host multiple tenants may be supported. For each option there are the following criteria to considered by the SaaS provider:
• the capability of the underlying platform to host the desired configuration
• the trade off between operational cost and application performance
• regulatory requirements
• perceived data isolation
• operational costs
• solution extensibility
• business continuity
• liability regarding breaches

JEE Application Server Deployment Scenarios

1. Fully Isolated Application server

Each tenant accesses an application server running on a dedicated server

2. Virtualized Application Server

Each tenant accesses a dedicated application running on a separate virtual machine

3. Shared Application Server

The tenants shared the application server and access application resources through separate session or threads.

Database deployment scenarios

1. Fully isolated data center

The tenants do not share any data center resources

2. Virtualized servers

The tenants share the same host but access different database running on
separate virtual machines

3. Shared Server

The tenants share the same server (Hostname or IP) but access different databases

4. Shared Database

The tenants share the same server and database (shared or different ports) but access different
schema (tables)

5. Shared Schema

The tenants share the same server, database and schema (tables). Their respective data is segregated by key and rows.

Challenges to JEE Applications

Typical JEE applications using EJBs with a DBMS back-end that have not been built with multitenancy in mind can usually support most of the deployment options above quite easily. The challenge is supporting that shared application server and schema model. An approach for these is proposed below.

Application Server Challenges

For a single server instance (JVM), hosting the same application more than once will require a some changes, e.g. a unique web context root for each instance and a mechanism for ensuring the JNDI names do not clash. This would typically require a build brocess that generates EARs targeted at tenants, tweaking the context root and JNDI names in the deployment descriptors. The use of resource references to remove hardcoded JNDI names from source code would also be required.

In addition, the tenant id would need to be propagated all the way through the application to enable correct JNDI lookups to be performed.

Of course the ideal would be that only stateless session beans are used and are packaged in a way that they are common to multiple tenant web applications. This is one more instance where entity beans suck.

Database Challenges

For a single database schema to be shared amongst multiple tenants, 2 options exist. Either (i) use a DBMS native feature such as Oracle Virtual Private Database to create multiple, tenant-specific virtual schemas, or (ii) add an ENTITY_ID column to every table and SQL statement in the application.

The former is of course much easier, but if portability is important then the latter option is preferred. The impact to the application server is in the first instance that a different datasource would be required for each tenant, and in the second instance, that the tenant id be added to each SQL statement.

So if your sales team has dropped you in it and sold your J(2)EE application to a SaaS provider, you now know that its not the end of the world! ;-)

Service Characteristics - Extensible

2008-10-16T01:02:00.001-07:00

The only constant in life is change, and this is no different for services. Services must be built with this in mind: that they will have to adapt to new or changing requirements. Extensibility is the ability for services to adapt whilst preserving existing consumer contracts.

We would expect the following types of changes to services to have no impact on other consumers:
- internal source code changes
- interface changes
- take on of new consumers
- environmental changes

Internal code changes

Insulating consumers from internal changes is achieved through another service characteristic: Abstraction, I.e. it is critical that that services do not “leak” implementation detail into the interface. A typical example of this is the use of underlying database identifiers in the interface instead of meaningful business keys.

Interface changes

In general interface changes will break existing code. The exceptions to this are the adding of new operations or certain types of service data types extension. Where breaking changes are introduced then a versioning scheme is required to separate the old and the new, whilst supporting both concurrently. Versioning for web services is typically done via the introduction of major and minor numbers to XML namespaces, such as proposed here, or alternatively via a service registry.

New consumers take-on

The take-on of new consumers will increase the load on a service. Services need to ensure that previously agreed consumer service level agreements (SLA) are not violated. Achieving this will involve a combination of automated performance regression test suites and runtime SLA monitoring.

Environmental changes

Services need to ensure that any planned maintenance that is performed on their underlying execution platform such as the application of critical patches does not affect consumers. Services need to run in a cluster with the ability for service instances to be transparently taken out of commission during maintenance periods whilst other service instances continue to support consumer requests. It is advisable to run automated regression test suites after such maintenance.

Service Characteristics - Discoverable

2008-10-15T00:59:00.000-07:00

For services to be of use of anyone they must be discoverable. Discoverability is usually taken to refer to the ability for consumers to find a relevant service by attributes (tags) at runtime via a service registry. In other words, consumers go to a service “yellow pages” and find at runtime services that best meet their needs.

#ifdef OPINION_COUNTS

This sort of runtime discoverability has not yet taken off despite all the hype. Service contracts are complex beasts that include non-trivial functional interfaces and runtime policies such as security and operational service level agreements. Then there are the capacity management and funding considerations involved in service adoption. Such runtime discoverability is more suited to a market place were variation and competition thrive, than to internal corporate landscapes where reuse and lower total cost of ownership is a key driver.

#endif OPINION_COUNTS

Is that the end of this post then?

No. Services very much need to be discoverable in the sense that they are well publicised to the consumer community. Services will not be reused if they are not known about. Service registries must contain everything the consumer will want to know about the service, e.g. name, description, functional interface, locations, owner, operational and performance criteria, security model, invocation mechanism, cost, etc. but must equally importantly include tags that will make searches possible.

However just having such a service registry is not enough. Governance is required to ensure that development communities making use of the registry; governance not just in the stick sense, i.e. thou shalt use the registry or else, but also in the carrot sense. It is important to capture the hearts and minds of both development and business communities. Reuse is like recycling, fine in principle, with everyone keen to do it, until it becomes inconvenient.

Service Characteristics - Stateless

2008-10-13T22:56:00.000-07:00

A service is said to be stateless if the consumer of that service can make use of any operating instance of that service. This is achieved by services not storing any internal data (state) that would be required if the consumer happened to invoke another instance of that service.

In general this goal is achieve by ensuring that all service data (including state) is kept in an external store common to all instances of that service.

However for performance reasons, service implementers are often inclined to cache back-end system query results or consumer session data. The reason for this is that the back-end systems and data stores which are accessed by services very often become points of contention and a source of bottlenecks, so avoiding the need to query those systems through caching at the service tier is attractive.

Service tier caching requires that cached data is available at all service instances, and that these instances are kept in sync both with each other and the underlying data store. Achieving this requires fairly sophisticated cache management software with cache refresh, propagation and invalidation mechanisms, as well as volatility analysis of the data being cached, i.e. the less volatile data is the more suitable it will be for caching.

JEE applications servers such as Weblogic offer HTTP and Stateful EJB session state caching that can be replicated across a cluster and persisted to a variety of data stores for failover purposes. In addition consumer connections to servers can be made “sticky” so that a given consumer will always return to the same server and only be redirected to another server in a failover scenario. This is fine as long as either the state is replicated or the consumer is happy to lose some conversational state in the rare instance that a server becomes unavailable. It is also possible to store consumer state on the client, either via client cookies or via URL rewriting. Weblogic for example can be configure to use either depending on whether client browser cookies are enable or not.

A viable and arguable simpler alternative to all of the above (where network latency between service and data tiers is not an issue) is to perform caching in the data tier using for example a DBMS feature such as Oracle RAC which provides a cluster of processes with data caches to improve performance and resilience.

Statelessness is a key characteristic of services which is essential for a scalable and fault tolerant SOA. State may be introduced if required but only after careful consideration as it will require complex and potentially less fault tolerant cache management facilities.

Lightweight Enterprise SOA Platform!?

2008-10-10T07:28:00.000-07:00

According to SOA World, Red Hat Will Realease JBoss Enterprise SOA Platform 4.3 and JBoss Operations Network 2.1 At the End of the Month.

My mouth is watering already, though you do have to wonder at anything that is claimed to be a "Lightweight Enterprise SOA Platform" ;-)

Service Characteristics - Distributed

2008-10-10T01:00:00.000-07:00

Services should be distributable, that is they need not and indeed should not run in the same process as the consumer. Services that run in the same process offer no possibility of runtime reuse to other consumers.

In order to achieve this goal you minimally need two things: a remoting framework and location transparency

1. Remoting Framework

A remoting framework is the mechanism whereby consumers are able to locate and invoke remote services. Typically for SOA this means Web Services, though less interoperable protocols such as JEE and .NET may also be used, for example where performance is a critical criterion. However such decisions should not be taken lightly – the ability to interoperate is a key to achieving reuse across the enterprise.

2. Location Transparency

Location transparency refers to the ability for a consumer to use a service without knowing where that service is running. This may be achieved to a degree through the use of DNS names hiding IP addresses, or creating server clusters fronted by an IP load balancer virtual service address. However, both of these still bind the consumer to a logical instance of the service. In contrast a service registry provides additional decoupling in that consumers are searched for by attribute (e.g. name and version number) rather than being bound by name.

Location transparency is also required of the service implementation itself. Services should not be tied to any particular location, both for capacity planning reasons where it may be required to move services between platforms to support load, but also for portability reasons. Achieving environment independence is achieved by running services in a container such as JEE or Spring that insulate the services from the underlying infrastructure, as well as ensuring that services are stateless.

Service Characteristics - Reusable

2008-10-09T06:52:00.000-07:00

A service is said to be reusable if it can be used in more than one context, even in contexts for which it wasn't originally designed.

So how do we achieve this noble goal?

1. Business domain modelling

If you understand your business domain and model services according to that domain your services stand a better chance of being reused than if they were built in isolation to localised requirements. Business process modelling should drive the requirements for services.

2. Adaptability

If your service can be easily extended then it can be reused. Extensibility is about being able to change the service implementation or extending the interface without affecting existing customers. Extensibility is achieved through interface abstraction and well-defined versioning policies, but also surprisingly through aspects like testability and resourcing capability.

Testability is about verifying service backward compatibility using an automated regression test which includes both functional and performance aspects of that service is key to service extensibility.

With respect to resourcing, delays in making required changes to services will hinder service reuse, so flexible resourcing capabilities are required.

3. Capacity Management

Eh? Yes, unless your service environment can support additional customers, that service cannot be said to be reusable. Capacity management is about sizing and providing service operating environments both for current and projected volumes.

4. Visibility

If people don't know about services then they won't be reused. A well designed and publicised service registry will help potential customers to quickly identify services that meet their needs.

5. Governance

Even if you have done all of the above, people will find reasons not to reuse, e.g. if the service does not exactly match the customer's requirements or the customer is not prepared to wait for the service to be enhanced. To help with such cases, governance using both carrot and stick is required. Governance is first about defining the rules, then helping people to understand and follow the rules.

Service Characteristics - Loosely Coupled

2008-10-08T13:49:00.000-07:00

What does it mean for a service to be loosely coupled?

A service is said to be loosely coupled if its consumers are minimally impacted by changes to that service or its environment. Some coupling is obviously inevitable since the consumer has to make use of the service but can be minimised in a number of ways:

1. Separation of interface and implementation

The service interface is the formal contract between producer and consumer. This is the part that should not change frequently. The implementation however may need to change as more services are created, as the platforms are upgraded or changed etc. Separation of interface and implementation allows services to grow without impacting the client.

Notice that attempting to reduce dependency by providing a weakly typed interface that does not “change” frequently just means runtime as opposed to bind time coupling.

2. Versioning Policy

Service interfaces will change as new consumers bring new requirements or the business domain changes. An effective versioning policy will allow existing consumers to be isolated from service interface changes as much as possible. The policy should consist of mechanisms which allow services to be extended without forcing existing consumers to upgrade, i.e provide some degree of backward compatibility. On the other hand, the policy should also enforce an upgrade interval which consumers would need to comply with.

3. Runtime Contract

The functional contract between a consumer and producer is covered by the interface, but there is also a runtime contract, a service level agreement (SLA) which both the service and its consumers should be subject to. Consumers must be insulated as much as possible (within the bounds of the SLA) from any runtime changes to the service environment such as increased load or platform outage. This is achieved through clustering of services to provide failover, and partitioning hardware so that services do not have a runtime impact other services sharing the same environment.

4. Platform independence

Platform independence is partly achieved through separation of interface and implementation, but primarily requires a platform agnostic communication mechanism such as web services between consumers and the service. Platform independence allows infrastructural changes to occur with minimal impact on service consumers.

5. Location transparency

Services may change location for any number of reasons, e.g. servers are decommissioned, capacity management moves services to underutilised servers. For this reason its important for consumers to be isolated from the exact location of the service. This may be achieved to a degree through the use of DNS names hiding IP addresses, or creating server clusters fronted by an IP load balancer virtual service address. However, both of these still bind the consumer to a logical instance of the service. In contrast a service registry provides additional decoupling in that consumers are searched for by attribute (e.g. name and version number) rather than being bound by name.

JBoss

2008-10-08T00:59:00.001-07:00

I have in the past worked on Websphere and now Weblogic JEE application servers and fortunately never had to port between the two. Just porting from one version of a product to the next is difficult enough, never mind a cross product port! I have found Weblogic to be a fine product, certainly much easier to learn and use than Websphere, but its not cheap, and one of our prospective clients has raised the question of running on JBoss which is of cours open source.

“No problem!” our sales people cry and I wince. JEE is a fine thing in theory and certainly gives you a hope of porting whereas .NET gives you no such hope at all, but the problem is in those little extras that the vendors give you for competition's sake.

So I worry about those JEE implementation variations, some obvious like the Weblogic deployment specific files, some more subtle, like the way CMP works, and I worry about whether JBoss' messaging and clustering will be as tidy as Weblogic's.

So I've downloaded JBoss and will be giving it a go. Hopefully there are some migration guides and even tools out there to simplify my task, but I'm expecting tears and further hair loss.

What's worse is that I'm dying to get rid of all our EJBs, introduce Spring and Hibernate, and run in a servlet container rather than full a blown application server. That would certainly be much more portable, since with Spring you are essentially taking your application container with you. Of course then you are tied into Spring...

SOA Service Management

2008-10-07T08:38:00.000-07:00

I have written and published an article at SOA World on SOA Service Management and ITIL.

Cost of SOA

2008-10-01T01:06:00.001-07:00

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.
One agile software development function with well defined, measurable and repeatable processes
One sophisticated service management organisation capable of operating services as enterprise assets.
One patient business community as all this gets set up and they foot the bill.
One adaptive business community who will have to mend their tactical ways and start thinking of the greater good.
One understanding business community who will appreciate that their tactical requirements might need to be subordinated to more general and hence reusable requirements of the enterprise.
One adaptive technical community who will be willing to mend their ways and start reusing rather than reinventing.
One persuasive business case, which may be a challenge since chances are that the organisation will not be very good on the metrics front so providing a much needed concrete ROI is going to be a challenge.

Ah, but it will be a thing of beauty for all to see. :)

Who needs an application server?

2008-09-27T03:13:00.000-07:00

If you are primarily building web services then I would give this question serious consideration.

Why spend a fortune on expensive and complex JEE application servers when the combination of Apache Tomcat, Axis webservices (or your favourite open source alternative), Spring AOP container, ACEGI security framework, Hibernate or iBatis persistence frameworks offers a very viable and free alternative?

Service Management

2008-09-26T05:37:00.000-07:00

Service-oriented Architecture operations management requires a sophisticated service management organisation which is capable of defining and sustaining service levels to its customers across the enterprise. SOA without the service management will result in greater systems fragility and chaos.

ITIL is the widely adopted framework for implementing service management practices and so it figures that it would have relevance to SOA. Under ITIL services must become managed and supportable enterprise assets. This has the following requirements for an organisation:

A service product/consumer model with defined, regulated, monitored and enforced service level agreements
Effective configuration management and the existence of a consistent, accurate, widely accessible and reportable configuration database. SOA requires a service registry with additional features not supported by traditional configuration databases. The usefulness of this registry to clients is central to SOA adoption.
The service desk is the human face of SOA and needs to be knowledgeable and efficient in its processing of incidents, in particular as service adoption grows and services become integral components of various business processes across the enterprise.
Understanding the dependencies (and the operational importance of those dependencies) between services and clients and the between the internal components of those services is crucial for effective incident, change and release management
Automatic verification of the quality, functional correctness, compatibility, and performance of services will greatly facilitate effective change management
Service implementations must share common standards, architecture and core business components. Governance will need to be put in place to ensure adherence to these standards.
Ownership of services and common standards and software must be clearly defined, as well as the change management process
Services must be deployed into a monitored, fault tolerant environment.
An enterprise security model is required to support single sign-on and consistent authorisation policies across the enterprise
Effective service component monitoring, whether infrastructural or software, is required for all the disciplines of service management. The monitoring solution must support both real-time and historical reporting to provide decision support
Capacity management must ensure the availability of spare capacity to support timely service adoption
Charging of services should be considered (either notional or hard charging), but only be implemented if it will give a clear value to the organization and if/when the environment is ready for it.
SOA requires a strong governance function to ensure architectural and functional consistency across services and to encourage reuse. Reuse is a strategic goal and will often be at odds with short term delivery pressures – this must be managed. Consider setting up a service review board involving parties from various business units and enterprise architecture to assist with this.

Why SOA?

2008-09-24T11:14:00.001-07:00

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.

10 Key Service Attributes

2008-09-24T11:09:00.002-07:00

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

Software as a Service (SaaS)

2008-09-24T05:03:00.000-07:00

SOA (Service Oriented Architecture) is fundamentally about enabling software to be constructed from a network of "services", so when I first encountered the SaaS (Software as a Service) acronym I assumed it was marketing hype for the same thing.

It isn't.

Software as a service is a model of software deployment very similar to the traditional ASP (Application Service Provider) model where an application is hosted as a service provided to customers over the internet. The benefit to the customer is that the burden of software maintenance, operation and support is alleviated, whilst for the service provider there is through virtualisation the possbility of applying economies of scale to the operation.

It seems to me that SaaS is just like ASP, but apparently the differences are due to SaaS's focus on the web and multi-tenant back-ends which enable greater economies of scale than ASP.

Its a pity, because I think SaaS as an acronym would have fitted the SOA space better.