Application Platform Strategies Blog

Bushwhacking Denodo

Blogger: Richard Monson-Haefel

Product demos are a bit of a dog and pony show so I like to mix things up by doing what I call bushwhacking.

I had a briefing with Denodo yesterday and bushwhacked them. They provide a mashup server product. It’s actually very nice.  In the middle of their canned presentation I asked Denodo to create a web service that provided access to the Java ME product device table – that was totally unexpected and is standard procedure in a bushwhacking.

We had 20 minutes left and I figured if the tool was a good as they say it is it should be a snap. It was. They accessed the Java ME device table web site, wrote an spider to extract the data, and had it working in about 8 minutes. Pretty impressive! If you are looking for a data mashup server than consider Denodo’s product – take it for a test drive or better yet ask for demo and then bushwhack them like I did. Bushwhacking is fun and informative.

Oracle Makes another Bid for BEA

Blogger: Anne Thomas Manes

Well, it took a while, but Oracle finally came back with another bid for BEA. This time, the bid is $8.5 billion.

More info on the deal is available here.

MuleSource Releases Another RESTful Open Source Registry Repository

Blogger: Anne Thomas Manes

Following closely on the heels of WSO2, MuleSource (the commercial entity behind Mule, the popular open source ESB) has released another RESTful open source registry/repository. This new product, called Galaxy, is a bit more feature complete and mature that the WSO2 repository.

Like the WSO2 repository, Galaxy treats each piece of information captured in the repository as an identified resource--i.e., a resource with a URI--which can be accessed and manipulated using the traditional HTTP verbs. The repository also supports remote access and notifications using the Atom Syndication Format (Atom) and the Atom Publishing Protocol (AtomPub).

Also like the WSO2 repository, Galaxy does not conform to the prevailing registry standard, UDDI, and therefore presents a bit of a challenge to organizations looking to use a registry to enable information exchange among heterogeneous SOA infrastructure components. Galaxy provides deep runtime integration with Mule and with the Apache CXF service platform, but connecting it with other ESBs and platforms (e.g., WebSphere, AquaLogic, Microsoft WCF) and with other management and mediation systems (e.g., XML gateways and SOA management systems) is left as an exercise for the implementor. REST makes that exercise relatively straight forward, but work is required.

At this point, three vendors provide fully RESTful repositories: MuleSource, WSO2, and HP Systinet. The IBM WSRR product also supports RESTful access to some of the entities in its repository. HP and IBM both support automatic synchronization between their repositories and a UDDI registry. The folks at MuleSource tell me that a similar synchronization feature is potentially on their roadmap, depending on customer demand.

Unfortunately, all four RESTful repositories use proprietary data models. It would be very helpful if these vendors got together to try and bang out some standards.

A Minimalist's Perspective on ESBs

Blogger: Anne Thomas Manes

Steve Jones has just posted a blog and a specification of what he calls a Business Service Bus (BSB), which he defines as "a simple mechanism for exchanging information between business domains". Steve is proposing that a BSB should be very simple -- doing only what is absolutely essential to enable information exchange--and explicitly disallowing more complex transformation capabilities typically associated with an Enterprise Service Bus (ESB).

To get a better sense of Steve's proposal, you should also read his previous post on the subject, in which he separates out ESB capabilities into two tiers:

• Business Service Bus (BSB)
• Domain Service Bus (DSB)

The DSB supports information exchange within a particular business domain, and typically supports more integration features than the BSB.

A Proposed Taxonomy for Thinking about SOA

Blogger: Anne Thomas Manes

Jeff Schneider has just proposed a new taxonomy for thinking about SOA, which he calls "Balanced Views of SOA". The views pertain to the various perspectives that people with a particular role in the organization have when working on the SOA initiative. To some degree his post is in response to the discussion we've been having on the Yahoo! service-orientated-architecture mailing list, where Todd Biske and I have been asserting that SOA is an enterprise architectural style. Jeff's point is that from an enterprise architect's perspective, SOA is an enterprise architectural style. But people with other roles have a different perspective, and therefore a different view. Good point--but I don't think it fundamentally changes the fact that SOA is an enterprise architectural style. These views refer to different aspects of the service lifecycle, not to different levels of architecture. But leaving the EA style question aside, I think this taxonomy of views is very valuable.

Jeff defines the following view categories:

• Service Portfolio Views: The enterprise architects' perspective. Services are assets in a portfolio. "These views help in the prioritization and planning process and to keep things organized."
• Individual Service Views: The implementors' perspective. After the planners determine that a service should be implemented, implementors must focus on designing, implementing, testing, deploying, configuring, and monitoring a specific service.
• Consumer-Service Views: The contract management perspective. A service isn't of value unless someone is consuming it. This perspective focuses on the needs to manage contracts between service consumers and providers.

I would add at least one additional set of views:

• Service Management Views: The operations, management, and policy enforcement perspective.

Perhaps Jeff groups the management views in with the consumer-service views, but many aspects of management apply to all services regardless of their specific contracts, and therefore deserve distinct views. These views address core infrastructure and management issues such as security, reliability, availability, monitoring, incident tracking, etc.

I'm sure I will come up with additional views.  For example, there are application views (a specific application's perspective), business intelligence views (what information about the business can be gleaned from the service portfolio), etc. 

The difference between SOA and 3-tier

Blogger: Anne Thomas Manes

Jeff Schneider recently started a thread on the Yahoo! service-orientated-architecture discussion list asking for a comparison between SOA and 3-tier. Here's my response:

3-tier or n-tier application architecture is just that -- an *application* architecture. It's focus is on building monolithic applications that can be distributed across multiple processors to increase performance and scalability. The tiers represent different aspects of the application: presentation, business logic, and data access. But the fundamental architecture doesn't talk about services, and it has never stressed reusability -- except at the DBMS layer.

SOA and n-tier are somewhat orthogonal -- you can build the various application tiers from services. Folks that built n-tier systems with CORBA or similar service-oriented technology were more likely to use services than most others. But consider the predominant n-tier development environment in use today -- Java EE:

• presentation implemented with JSP/servlets
• business logic implemented with POJOs or EJBs
• data access logic implemented with JPA/Hibernate

I don't see much that looks like SOA in this model.

SOA operates at a significantly different level from n-tier. SOA is focused on reducing the amount of redundancy in the corporate application portfolio. I've said it before: SOA is an enterprise architectural style rather than an application architectural style. SOA doesn't focus on individual application architecture. It focuses on encapsulating discrete functionality into services.

SOA and n-tier architectures have one thing in common -- they focus on separation of concerns. But SOA takes SoC to a new level. I think of it as refactoring application systems. (similar to refactoring code,
but on an enterprise  application architectural level).

As industry experience with SOA matures, I expect we'll start to develop new application architectures that more effectively exploit a development model based on services. SCA is a start, although still
way too immature for prime time. I expect to see some synergy develop among RIA, widgets and gadgets, mashups, composite application development, and services.

I also expect that the concept of "application" is likely to go away. Why is it that we as systems users have to be constrained by the limits of this artificial boundary called an application? Why do I have to shift my focus among multiple applications? Why do I have to copy data from one application to another? Why do I have to launch this stupid browser or that stupid application to get my work done? Why isn't everything just accessible to me from my desktop (via widgets and gadgets) or from within my preferred operating context (e.g., email)? Why can't I just link to whatever I need? (think REST)

Think outside the box!

Chris Haddad talked a little about the need to abandon traditional n-tier concepts and the MVC design patterns in his blog post, MVC Matrix and the Red Pill.We'll be talking a lot more about this next generation application platform this year. Stay tuned.