-
1. Re: SOA Modeling and the SOA Modeler component
Jon,
I am working on a SOA development process (as part of our consulting efforts), and very interested in how various tools support that process, and how they work together. In your diagram SOA Modeler in Context, you show four tools, with SOA Modeler at the top. The tools each support the corresponding step in the SOA development process (service oriented analysis, service oriented design, and service development - this last step supported by the JBossESB File Editor and an XML Editor). Our process also includes as a first step, business analysis, which focuses on business process analysis and calls for the use of tools such as the PI4SOA CDL modeler and the Eclipse BPMN editor. The idea here is that business process requirements can be used to identify service candidates, that are then modeled in the service modeler.
You also have included a discussion on Control and Data Flow for Service Diagrams. Would these types of diagrams only be used when the composite service is not an orchestrated service? In the case of an orchestrated service we could represent the orchestration in BPMN. Also, these diagram probably should represent data flow, not just control flow, since when services communicate directly (i.e., they are not part of a BPEL orchestration), they pass data as part of the message. Strict message typing is desirable at the modeling stage (optional is fine). While it is true that the service implementation decides how to react to various message types, the service developer creates this logic based on information conveyed in the model. Service oriented analysis should be able to define the message types (leaving the exact specifics of the content of the message to service design).
What information do you see being present in the SOA Modeler? I would assume the capabilities / task of the service would be listed (e.g., an Entity service might have create, update, get, and delete capabilities). Also the message types the service supports, as well as the service compositions discussed above.
Also, a link on the wiki is broken:
/repos/soag/trunk/docs/tooling/Service Modeler 02.pdf was not found on this server.
Thanks,
Jeff -
2. Re: SOA Modeling and the SOA Modeler component
Hi Jeff,
I think there are a number of ways that Service Candidates can be discovered, including using the tools you mention. To my mind, the SOA Modeler is the tool in which the Service Candidates can be analyzed and refined. Doing so may well result in additional Service Candidates being identified. The key difference between the SOA Modeler and other tools (related, such as BPMN tools, or potential substitutes such as UML) is that the SOA Modeler concentrates on Service Candidate definition and composition, in a way that matches the underlying implementation technology (that is, a message-based system with 1...n semantic branches in a service). Also, Service Modeling would be a natural time to think of "non-functional" service requirements that then might be expressed in a contract and/or subject to governance.
I'll post more here and on the wiki (with a notice here) over the next day or so to discuss the more detailed questions in your post.
In general, though, I'd be interested in the SOA development process you are working on, so I can see how Model-driven SOA, including the SOA Modeler component, can help. Is this process discussed/posted somewhere?
-- John