(This article uses terms defined in the SOA Modeling Language.)
What is the SOA Modeler?
The purpose of the SOA Modeler is to enable discovery, definition, and refinement of Services. The details of these Services, captured in Service Definitions, then become the basis upon which solution implementations are generated through specific target bindings.
SOA Modeler users are envisioned to be cross-functional, including (but not limited to) developers, architects, business analysts, subject matter domain experts, and business partner representatives. In other words, the SOA Modeler is a tool through which these diverse stakeholders can think about and discuss Service inventories for their enterprises.
Why not using existing tools?
While there are relatively few tools designed specifically for SOA modeling, there are generic tools which could serve the purpose. Also, individual SOA vendors tend to have tool sets for their SOA infrastructure, and these often have capabilities similar to modeling.
There are two main reasons why the SOA Modeler is preferable to these alternatives:
- The SOA Modeler is designed specifically to model services at a high level of abstraction. General purpose modeling tools/languages do not capture the requirements of service modeling, and lower-level vendor specific tools are tied to implementation details. The SOA Modeler is carefully positioned in a stack of SOA tools to enable efficient and effective modeling in the SOA domain.
- The SOA Modeler has bindings that generate code for specific implementation platforms. Thus, users get the dual benefits of being able to defer implementation details during modeling but also to tightly bind model features to implementation details during the appropriate steps in the solution implementation process. Generic modeling tools/languages cannot offer the same connections from abstract to implementation.
What is MDSOA and how does the SOA Modeler fit in?
Model Driven SOA (MDSOA) recognizes the need in SOA development to have tool sets for specific users, and the need to tie these tools together into a suite that makes sense and works well as a whole. As currently conceived, the SOA Modeler sits at the "top" of this work flow:
Note the arrow directions: The Service Modeler generates artifacts for use in the other tools, but reverse generation is not supported. (For details on this point, see [Kelly-Tolvanen2008]) That is, the SOA Modeler is a Domain Specific Modeling (DSM) tool for SOA. For the rest of the tool set, the goal is to enable full rendering of service details from JBoss ESB configuration files (jboss-esb.xml) in the Service Designer, and full rendering of all JBoss ESB configuration file details in the JBoss ESB File Editor. Whether this complete coverage is possible or even useful has yet to be determined. The relationships established in the tool set do, however, enable recourse to a lower-level tool when desired options are not available (either because they have been intentionally abstracted away or simply are not supported) in the higher-level tool. (It might make sense to have the SOA Modeler visualize services, but round tripping support has a number of pitfalls.)
Comments