Initial thoughts on the SOA Modeler

[john.graham]

I'm John, who Marked mentioned in earlier threads about the SOA Modeler. I'd like to briefly introduce myself to the community and share some initial thoughts on the SOA Modeler. From the JBoss side, I will be involved in driving this component forward.

I joined the JBoss division of Red Hat in early April this year, reporting to Mark Little and concentrating on SOA tooling. My recent background includes starting and running the top-level Eclipse Data Tools Platform (DTP) project at the Eclipse Foundation from 2005--2008, and Eclipse plug-in development on several commercial products. Part of this product work included SOA tooling, so I also have some experience in this area as well. (Google search for "john graham eclipse" for more details, if you're interested).

My initial assumptions about the SOA Modeler come from reading Erl's document attached to JDIDE-2070, reading Erl's other books, talking to Mark, and general experience in modeling applications. While I know that a number of topics have already been discussed on this forum about the SOA Modeler, I'd like to share my initial thoughts here:

* We're talking about modeling, not service implementation. Thus, we're operating at a high level of abstraction, ideally avoiding entanglement with any specific SOA implementation stack/style.

* Erl's document is a functional specification, and the intent of the SOA Modeler is to follow the spirit of the document, but not the letter. Especially with respect to the screen shots and detailed functional actions, we'll need to tailor accordingly to the hosting environment (most likely Eclipse).

* The purpose of this tool is to enable design and analysis of services, and secondarily to generate service implementation stubs. That is, the value of the SOA Modeler is not is constructing services/composition/etc. implementation, but rather to allow users to think about the design of the services in their service inventory.

* Erl distinguishes design and analysis from implementation by calling services created in the former activity "candidate services." The words "service" and "model" are overloaded and can be used at almost any level of abstraction. Rather than the unwieldy terms starting with "meta-", I will follow Erl's distinction.

* People have mentioned existing open source technology (especially in Eclipse STP) that might be relevant to the Service Modeler: we will be looking into these going forward to determine if there is a good fit.

* We're in the early stages of investigating this tool. There is no code, nor plans for release. It is my intention to keep project progress open, transparent, and community-driven in the tradition of JBoss professional open source.

So, that's my attempt at a start. I look forward to working with the community on this component, since I feel it will be valuable in the SOA tooling space.

A final administrative note: I'm traveling in Asia the week of May 26th, so internet access might be limited/periodic: please don't think a lack of response this coming week on the forum means I don't intend to continue the conversation. :-)

-- John

[objectiser]

Hi John - thanks for the intro and initial thoughts.

Just to clarify one point, as I provoked the point about the modeller dealing with implementation (inadvertantly) - for Overlord to provide dynamic aswell as static governance, we will need a model of behaviour.

Previously I had assumed that this would be part of the service modeller - hence my initial post commenting on Erl's document.

My thought process was that, if the service model had the behaviour description, as well as the service interface, this could then be conformance checked against a choreography description.

How an implementation would be derived/generated/validated against the service model, would then be an internal JBoss tooling issue.

However after rethinking the approach following Mark's response, I am now viewing the service model as just a service description with potentially other governance related information attached - e.g. SLAs, choreography description.

What an 'implementation' tool (such as the JBoss ESB designer or GPDs) decides to do with this information (if anything at all) is a local tool specific issue.

So really the Service Modeller will be used (as you say) to build up a representation of services in the repository (with their associated governance information), and then conformance checking could be implemented in the JBoss ESB designer (for example) - if it has a means to access the repository and identify the relevant service description it is implementing, and that service description has an associated choreography description.

This approach would also be useful in supporting the model driven design by contract approach, as the service design can be used to guide development of both the service interface and behaviour.