Evaluate various alternatives, then implement the easiest and most useful one(s).
Source code, and what can be found in it that's interesting for EasySOA, can be :
design-time information that is mapped to runtime, typically in an MDA approach, ex. eclipse EMF metamodels. However this is more accurately addressed by discovery at design-time, so not a priority here.
java source : service definitions and implementations
through annotations (JAXWS for SOAP, JAXRS for REST ; for now, local-only ones like Spring @Service are not a priority)
or possibly inheritance for some service engines or application servers (ex. RMI's Remote interface, extending Spring's ServletEndpointSupport)
runtime configuration files (configurating service engine or the wider application server) :
WSDLs (WADLs), alone or referenced by other configuration files
for FraSCAti or other SCA runtimes, SCA composites are runtime configuration. Note that SCA Import already adresses that, but at architecture (whatever the implementation) or runtime level (a complete packaged FraSCAti application). So the same code could be leveraged, but with less requirements on application completeness.
Spring XML, and notably service-related subsets : CXF, remoting
web.xml indicate UIs and / or HTTP APIs, but that's not sure enough to be interesting for now.
This mechanism could be plugged in several alternative places :
locally in EasySOA. This is like SCA import. However it would be cumbersome to get access to the source : information to be specified (SVN), source would have to be checked out and something like a local build system to run... that sounds like continuous integration.
in build configuration (maven). In addition, maven could be leveraged to enforce rules on services and their implementation ("the checkstyle / findbugs of SOA"). That's the kind of thing that is best run by continuous integration server (Jenkins / Hudson). Though if each developer ran it, it could also provide information on collaborative service development - but this could be gotten from code history also.
in code quality server (sonar). In addition, sonar could also be leveraged to get and follow SOA-level quality information, like metrics and rules on services and their implementations ("the sonar of SOA").
If it's local, it can use EasySOA native local APIs, otherwise it has to use EasySOA remote APIs,
in realtime, possibly in batches (ex. using Esper , see HTTP monitoring)
or at the end (of build) in a single bulk batch
Source code and configuration visit and parsing can be done by various code processors, have a look.
Evaluate various alternatives, then implement the easiest and most useful one(s).
Source code, and what can be found in it that's interesting for EasySOA, can be :
This mechanism could be plugged in several alternative places :
If it's local, it can use EasySOA native local APIs, otherwise it has to use EasySOA remote APIs,
Source code and configuration visit and parsing can be done by various code processors, have a look.