On Aug 26, 2006, at 3:33 AM, ant elder wrote:
On 8/25/06, Jim Marino <[EMAIL PROTECTED]> wrote:
<snip/>
More importantly, if we are trying to make the use case of a
>> single reference used by a J2SE client easier, I'd would say don't
>> use SCA for that. Just use Axis (or some other transport)
>> directly. Where SCA is valuable is in assembly of multiple
services.
>>
>
> I'm not sure :-) I think it should also be possible for these guys
> to take advantage of SCA (I assume SCA can simplify programming).
>
SCA doesn't simplify all programming. Sometimes it's just easier to
avoid the unnecessary overhead of "frameworks".
Could this be an interesting scenario to support which may appeal
to people
like those using the old WSIF framework? Advertising this and
documenting a
migration path from WSIF to the SCA programming model could get us
a bunch
of new users who may not otherwise be looking at SCA.
At the risk of starting a flame war IMO we need to be careful not to
portray SCA as a "successor" to WSIF, as they address quite different
things (I have seen this brought up at several public events). For
example, SCA is a model for describing service assemblies and
components, not "services", and it intentionally does not provide
location transparency. One of the other significant differences I
see is that WSIF is very WSDL-centric, while in SCA not all services
must be expressible in WSDL (only remotable) and hopefully the
application developer never need see one. The one similarity I do see
is the ability to switch bindings, although in SCA this does not have
to involve changing any WSDL. I'm not sure, though, how far I would
take this similarity as I suspect SCA's concept of expressing remote
services through "business interfaces" has important differences.
As a migration path, I would recommend the following. If there is a
simple J2SE client that invokes some services and it works, just
leave it and it can invoke into an SCA system. If someone wants to
rewrite the client, I assume it is either because they are re-
architecting or find that the framework currently being used doesn't
meet their needs. For both cases, I would say if the client is not
participating in a service assembly and only invokes a few services,
all over a common transport, just use the transport API. If things
such as the transport changes frequently (not something I have seen
too often) or IT wants to introduce capabilities such as policy,
tracing or monitoring, then the client application should probably be
placed in a service assembly and it would be run in an SCA container.
If someone wants a client that uses a boat-load of transports or
policies and it will not benefit from being part of an assembly, then
they could use the SCA J2SE host and the classpath isolation it
provides seems like a simpler solution than cramming everything onto
one classpath.
Jim
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
