Switch styles (Capricorn). XML Feed Calendar
All | Developers | General | Java | Surfing
20060508 Monday May 08, 2006

Best intentions ...

So I had intended on following up my last post regarding the "next wave" with some discussion about Sun's tools and how they are evolving to solve some for the new architectures resulting from service-based technology and a new ecology. However, I wanted to follow-up instead on my last post as a result of questions posed by some who read it ...

One question dealt with whether the increase in bandwidth might change the granularity of the services and what the effect on productivity might be. Interestingly, it could go either way ... with greater bandwidth it would of course be possible to have many more finer-grained services, however it's my contention that standard engineering requirements and practices will prevail (greater bandwidth will enable a vastly larger number of service interconnects, but that doesn't necessarily mean that the services themselves will become finer-grained).

Essentially, I don't believe that the services themselves would be much different than how we build and deliver stand-alone apps and components today in terms of granularity. We build things at coarser levels of granularity for a reason: they are easier to deliver, test, manage and design (it's also typically a side-effect of the way we organize into development teams, etc.). The difference in these new components is the distributed nature of the applications they are used in ... someone else is providing some of our logic, some of services (from "somewhere"). We have to be able to handle that not only from a deployment/management viewpoint but the development/debugging/profiling one as well.

A separate question was how the services industry will evolve. There are (at least) two models which exist (or will exist) ... the first is the "legacy" folks like SAP who take their large systems and wrap it up as a collection of larger services (what's behind, for instance, NetWeaver / ESA and the delivery of "enterprise services") ... this, of course, is happening today as companies with existing infrastructure migrate to more loosely coupled systems. The second model I believe will be that of service aggregators (as a business).

Beyond the apps-to-be-services today, we will likely first see a massive explosion of smaller services for various functions, but over time things will coalesce around larger service providers (example: travel reservations system, financial support system or supply-chain management) who perform a function of aggregating smaller services and providing the management, risk mitigation ... most of the "ilities" for the apps, consumers or heck, other services which consume them. It will lead to an interesting new business model for the new "Dot Coms" as they take on the task of providing meta-services (and likely by in turn building upon things like the Sun Grid ... why pay for all of that infrastructure yourself when it exists at a low cost-per-hour for use by you and your customer ... ) ... anyone think this could be an interesting new business ?

The short answer here is that it will be rare that someone would build a large application of hundreds of services ... there will typically be a "food chain" of increasingly coarser services that applications higher up the chain will build on.

Existing SOA tools working with services (regardless of granularity) will improve productivity (we are visual creatures by nature ... working at the XML level is, to say the least ... painful), but we still need more in this space. While we do still need additional construction / visualization tools (to work at different levels of abstraction or use-case), productivity isn't just about the "building" side of development ... the whole life cycle needs to be addressed as well (which includes, obviously, deployment, debugging, profiling, maintenance, etc.). Coarser services should help somewhat (less to manage), but there is still a lot missing in terms of infrastructure, architecture, blueprints, best-practices, runtimes (and yes tools). The good news is that we (Sun) are thinking about it and in an upcoming blog I'll describe what we're currently doing as well as where I see things moving in the future.

Next week, of course, is Java One, which will be an ideal time to describe the development landscape and the tools needed for them. So until then, keep looking forward ...

Posted by brewin May 08 2006, 06:08:08 PM PDT Permalink

Comments:

Post a Comment:

Comments are closed for this entry.