SCA and JBI, match made in heaven?

A while back Edwin made a post about SCA and JBI and the differences between them. I won't bother repeating what he said, and explained, around the differences between the two. Applying this to the previous post on treating IT as a business domain, where its important not to get bogged down in these technology discussions made me think about how JBI and SCA work very well together in terms of mentally helping people to separate the technology challenge for integrating products (JBI) from the development challenge of invoking multiple business services (SCA).

Having this clear architectural, and mental, separation between these two areas is liable to make architectures based on them much clearer than those who adopt a single approach. SCA wasn't designed to do infrastructure (IMO), while JBI was 100% not aimed at helping developers! Currently IBM and BEA are SCA only in their strategy, while Sun are only JBI. Microsoft of course have neither... its a bit of a hint to the folks in Redmond, don't you think you need a component/deployment approach?

I should put my hands up to a vested interest as a member of the JBI group, that said at work we were also heavily involved in the IBM Process Server beta programme which is where SCA made its debut. Both are good technologies, SCA IMO is brilliant for development, and it will be interesting to see how SAP and Oracle (who have both said they will support both) develop their products in the coming 12 months.

Technorati Tags: SOA, SCA,JBI,Service Architecture

SAP and Oracle - what do you own, what do you rent?

One effect of the package vendors, mainly Oracle and SAP, taking up SOA has been the relentless charge in the number of "services" these companies claim to deliver. Thousands of services are being claimed already by these folks and they both have effectively the same strategy namely:

Middleware on a package, not the world's most advanced architecture but its certainly a start. Both are talking about moving processes into the middleware layer and both are talking about the package becoming the basic services which are then orchestrated in the middleware layer.

What this does mean is that package development is shifting already, and will shift even more in the coming years. If you take something like Salesforce.com as a model in this area, and think about what these packages normally represent then there is another way to think about the diagram, namely that packages represent the capabilities and the real services will live in the middleware. The reason that SAP and Oracle are claiming thousands of services is that they are taking a fine grained approach to what a service is, namely just exposing what they have. This means that to create a proper business architecture on top of these things will require you to moderate access to the package via the middleware.

With SAP pushing Process, and Oracle always struggling to get beyond data, its important that businesses look at how the represent these packages in a way that suits them. Central to this is the idea that the capabilities of the package should be left untouched (as package modification is always a dangerous thing) while your business service architecture should be realised in the middleware.

So don't think of buying Services from Oracle and SAP (at least not yet) think of buying capabilities from them that you can construct into Services. In this way you can get the advantage of standardisation and commoditisation without having to completely adapt your view of the world to the package. A package should commoditise the capabilities of an organisation where it is used, the service should provide a business correct view onto those capabilities.

What all this means of course is that the real value in this world is clearly split. The package represents the reduction of cost by selecting commodity capabilities, while the middleware represents both services the package delivers and the higher value services which undertake orchestration across those services.

So as with Salesforce.com, it begs the question with Oracle Fusion and SAP. Why would you own the package? If you aren't modifying these capabilities but just want to access and orchestrate them in your own way (i.e. provide services) then the only bit that is unique to you is the middleware.

ASP models have been tried before with SAP and Oracle and had variable success (to be kind) mainly because both the capabilities and the configuration was done in the same environment, this made the work harder. With these new models we are able to think about having a clear split, with the package being about capabilities and the middleware being the piece that provides access to it. In that world you don't need to own the package you just need access to the package's capabilities. And if you can drive towards accepting those capabilities as they exist out the box (i.e don't tweak the package) you can reduce or eliminate the traditional upgrade challenges.

As Oracle and SAP move more of their orchestration and (hopefully) start creating proper service functionality within the middleware the dynamics of package development will have been radically altered instead of being a single great big blob it can become a question of:

Rent the capabilities, own the services.

Technorati Tags: SOA, SAP, Oracle, Service Architecture

Services aren't about reuse

One of the often trotted out reasons for SOA is that it enables reuse, now a while back Neil Ward-Dutton blogged about this being wrong. Its this view I'd like to build upon here, with one minor change, instead of thinking of sharing services I think of it as using services.

So what is the difference between use and reuse? Well in the spirit of well known thickie Albert Einstein lets use examples.

• When you finish the christmas biscuits in those big tins that they come in and then reuse the tin to store your receipts, this is (clearly) reuse.
• When you demolish a wall, take the bricks and build a shed you are reusing the bricks.
• When you take a library file and import it into a project you are reusing the library.

Reuse is about taking something and moving it into a different context. This will either change its purpose (the tin) or use it as a piece in a bigger solution (bricks and library).

• When England beat Paraguay on Saturday they will be using the pitch in Frankfurt. When South Korea play Togo on the same pitch a few days later they will also be using the pitch.
• When you order a pen from Procurement you are using them to get the pen. If someone else wants a pen they also use procurement.
• When you include GoogleMaps in a Mashup you are using their functionality.

Use is about using capabilities in-situ, this doesn't mean you can't get to them but that they are left where they are and you invoke them. Mentally the shift is away from thinking of "re-using" a service in a project or "re-using" some code towards using something that already exists, where it already exists.

You don't reuse phones, knives, cars, roads or football pitches, you just use them, so it should be with a well realised service architecture. Don't think about bringing the capabilities within your bounds but of invoking capabilities that exist elsewhere.

Mentally this should also change how you think of building services, it is not the responsibility of the consumer to worry about food, water etc, which is what reuse is about, its the responsibility of the provider to make sure that these elements are catered for. Reuse encourages people to leave such issues to others because it makes consumers understand the lifecycle and make changes based on what they want. Use should be about providing an interface and a mechanism to request change that applies to all, and having all of this managed behind the boundaries.

Reuse tends to focus on functional activities only. Use needs to focus on functionality, the full lifecycle and providing the service to all.

Technorati Tags: SOA, Service Architecture

JavaSE 7 a formal request (sort of)

Okay its time to be clear about what I think Java SE 7 should look to do:

1. Have a standard jar dependency management approach (Ivy or Maven would do)
2. Have a standard mechanism for defining additional elements to download (might that be JNLP?) and where they can be downloaded from
   
3. Have a standard deployment file that indicates the specific elements required for a given application
4. Have the ability to not require/deploy those elements not specifically included

I think that is it for the mechanism, then the second bit is as follows

1. Have a core set of required libraries (maybe as little as java.* maybe as much as everything in Java SE 5)
2. Define a set of standard profiles for three common usage scenarios (server, user desktop, developer desktop) and the ability to dynamically apply profiles (if we can co-host multiple applications then they should each have profiles)

In this way J2EE vendors, and the Spring, Struts, Jini, etc crowds could all define profiles for their applications for different usage scenarios that complement their other deployment efforts, these profiles would indicate what facilities (jar files?) are available to the developers. In this way we could specify SERVER profiles to indicate the facilities available to all, and maybe in time have application profiles to indicate those things that are available to only a specific application.

Now I know some people will argue that in part you could do this using security, but the reality is that most projects work on jar files and then choose what jar files to deploy where, also security means that the jar files are already loaded. So if you think about grid deployments and hydration/rehydration then this gives you the ability to check the deltas that require shifting rather than having to take the whole application context in one go.

Simply put,

• I want to define that my Java Desktop application uses Matisse, Swing, Axis 2.0 (rather than JAX-WS), Log4J and doesn't include Java2D, MIDI support or any form of scripting.
• I want to define that my server application uses EJB 3.0, JAX-WS (the one provided by the app server vendor), Log4J, JSF, MyFaces and no Swing, AWT, JAX-WS (as provided in Java SE 6), scripting, MIDI or Java2D
  

This way Java continues free to innovate (as Bill Joy was famously fond of saying "Most of the smart people in the world don't work for you" something that Sun would do well to remember) while enabling officially endorsed "profiles" and standard mechanisms to enable end users to remain in control of their environment in the way that they need.

For the consumer market sure fine keep pushing the ever bigger bloat out, it will keep the slashdot crowd happy too. But Java is big enough, and professional enough, now and its much bigger than just the JavaSE platform, its time to have a formal recognition of the fact that (to paraphrase Mr Joy) "not all of the best jar files come from Sun".

Technorati Tags: Java, JavaSE 7, J2EE, Spring

SOA and Web 2.0 - not one or the other

There have been some posts out there in the blogsphere and wider world questioning whether SOA is heavyweight or lightweight (and as ever a nice rage against the machine by Dan) the bit I'd disagree with is that its a "Web 2.0 lightweight approach" or an "SOA approach".

Admittedly I'm talking about SOA here as a business concept rather than a technology concept, but that said I think the two go rather well together in fact. Thinking about defining services and then categorising them for delivery might mean that a Web 2.0 with AJAX, monkey nuts and side trimmings of agile could be the right way to deliver a particular service. I've used a 3D grid to try and explain to people that different services require different delivery approaches and to try and break the "one ring to bind them all" approach to project management that often exists.

I like PovRay.... But anyway, part of the aim here is to identify the right software practice (as Dan says one size doesn't fit all) to deliver a given service. For something that is highly visual, interactive with users and needs to integrate multiple external services in a "mashup" type of way then guess what... Web 2.0 with AJAX, monkey nuts and side trimmings of agile could be the way to go.

Equally if one of the services is a package solution that needs almost no configuration and for which the requirements are already known and fixed by the package then you probably don't want to go down the XP route. And if its a business process centric solution like "employee take on" or something with big compliance concerns then again you probably want to pick a more formal method (but naturally one that has iterations).

One size doesn't fit all, and taking an architectural and particularly a business view of SOA helps you pick the right delivery approach for each service rather than trying to shoe-horn one method onto everything.

Its not SOA v Web 2.0, its about understanding the wider problems and understanding what works best where. SOA v Web 2.0 is like arguing Linux v VI, it doesn't make sense. Unless of course its the one that's "vendor bulls***" (how does Tim Bray talk with *s? Must be an XML guru thing) then there might be more of a point, but that is to concede that SOA must be defined solely by marketing hype and never by an actual Service Oriented Approach which is a shame.

Technorati Tags: SOA, Web 2.0, Service Architecture

SOA tools...

I get asked regularly what tools can be used to define a service architecture, and the problem is that most of the big tools in this space are too complicated, too big and fundamentally don't have strong concepts of service in them.

This means I'm afraid that the only tool I can really recommend at the moment for the creation and sharing of a service architecture is a Wiki. Pathetic really but I've not yet come across anything that matches it in terms of flexibility and the ability to navigate the information. It really comes into its own when you start thinking about how process and Service work together as the process elements can link to the service elements via the Wiki.

To draw the images I use Open Office mostly, Visio occasionally and to do the 3D movies and images I sometimes create its down to PovRay. SOA at this level really is a new field from a tooling perspective and while XML, WSDL and BPEL tools are improving there still hasn't been much of a desire to create a business service modelling tool that puts all of those things into context.

Unless anyone can say different?

Technorati Tags: SOA, Service Architecture, SOA Tools