The JBoss SOA Modeler is one member of a tool set for defining/constructing/configuring services. This tool set is shown below:
At the base level, we have typical XML tools for directly editing JBoss SOA-P descriptors that specify the definition of services (such as the jboss-esb.xml file found in ESB archives). An alternative at this level could have been a simple text editor, but commonly available XML editors in open source allow for a higher level of functionality.
The next level up is the JBoss ESB Configuration File Editor (that is, an editor for jboss-esb.xml). This graphical editor, included as part of JBoss Tools, simplifies the creation and editing of JBoss ESB configuration files using Eclipse-standard mechanisms such as tree views/properties for XML structure and forms for adding common elements (such as actions or listeners). The advantage of such an editor is, of course, that it frees the user from having to edit XML directly, and also helps to ensure that the XML structure is syntactically correct. There will be occasions, however, when configuration not supported by the editor is required, and users will then need to edit the XML directly. This trade-off between increased abstraction (also ease of use) and full capability access will reoccur throughout the tooling stack.
The Service Designer will be a graphical editor for the creation and editing of JBoss ESB services. While this tool does not exist yet, some discussion can be found in JBIDE-2068. The essential idea is to allow graphical service construction by "wiring together" providers to action chains. Users would select from predefined/discovered elements or create new elements for use in the service diagram. The service definition then could be included in a JBoss ESB configuration file for deployment as part of a ESB archive. Here too the level of abstraction is raised, since the user can concentrate on specific services in absence of the deployment descriptor.
At the highest level of abstraction is Service Modeler. Here users (could be developers, but equally likely to be a cross-functional team responsible for service architecture) analyze just what services should be created to satisfy business requirements. Considerations likely also include security constraints, service level agreements, and specification of service functionality (semantics). As the highest level of abstraction in service definition, the Service Modeler concentrates on helping users to discover, define and refine the service inventory. Implementation bindings (to JBoss SOA-P, but others theoretically possible) translate the service model into a form that can then be used to drive implementation using the other tools in the service tool set.
The Service Modeler does not exist currently, but there is a design document from Thomas Erl referenced in JBIDE-2070, and candidate designs/implementation technologies are being considered.
Comments