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. :-)