From: Jim Marino <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: Sample framework
Date: Fri, 18 Aug 2006 01:00:51 -0700
I'd give this a big +1 and would add async/conversations as nice feature
to show as well. I think we really lack something that demonstrates why
people need SCA.
Related to this, a couple of my colleagues were working on porting an
existing application, MedRec, which uses Spring and OpenJPA and shows how
SCA could be used to wire it (hopefully Andy and Chris will show up on the
list soon ;-) ):
http://dev2dev.bea.com/pub/a/2005/09/
spring_integration_weblogic_server.html?page=1
I have had a quick look at the MedRec sample using Spring and JPA, we use
Spring with Hibernate JPA at work. Spring's JPA support is terrific.
One thing I like about taking an existing application is it shows how SCA
can be used to add value to technology people already know.
Absolutely, that is one of the key sellers of SOA as well, ability to reuse
your existing assets.
I also think there should be another "pure SCA" sample as well.
Unfortunately, BigBank has gotten really bloated and I would like to see
just an SCA version.
Let me know if you are interested in helping out or providing input on
MedRec. For the "pure sample" maybe we could start outlining what specific
scenarios we want to show?
I am interested in helping out, is that a Tuscany initiative? On the pure
sample, shall I create a JIRA and we can elaborate it further?
Jim
On Aug 18, 2006, at 12:48 AM, Meeraj Kunnumpurath wrote:
Jeremy,
I think it is important to have a realistic application that demostrates
the key capabilities of SCA as a technology. From, that perspectice focus
should be on how SCA can be an SOA enabler, in terms of integrating
systems built on disparate platforms using a variety of technologies and
exposing existing software assets though new channels.
If we can build an application with a coherent set of use cases that will
demonstrate a set of container types and bindings working together, it
would demostrate the capabilities of SCA as a technology and Tuscany as
an implementation. I don't know how much the big bank sample fits the
bill, however, if it is realistic enough, we can build a realistic sample
using the big bank scenarios. From that angle we can look at,
1. The components involved in realising the solution
2. Container types for each component. For example, some components will
be in Java, some other will use a scripting language, some will be
realised as database stored procedures etc.
3. Define the appropriate binding types for integrating these components
together and exposing their services to external clients.
The application should demonstrate the following capabilities,
1. Different container types working together
2. Different binding types
3. Ability to enforce policies to realise enterprise-level QoS aspects.
The application with proper documentation on the implementation
architecture and model would be a good demonstrator for using SCA as a
technology platform for realising SOA.
Ta
Meeraj
From: Jeremy Boynes <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Sample framework
Date: Wed, 16 Aug 2006 15:53:55 -0700
We have had a rapid increase in the number of samples recently many of
which do essentially the same thing. Some feedback from M1 also said
that we seemed to have invented the greatest number of varieties of
HelloWorld but that it was hard to tell if SCA could do anything else.
I'd like to propose a change in how we structure the samples so that we
make it clearer to illustrate the technology to users.
Rather than having separate projects for each technology variant, I'd
like to suggest we have just a couple of projects that provide a
framework and then have instructions in the documentation for each
technology that clearly show how to apply it.
For example, I can see two framework environments:
a) a client environment with a simple command line client wires
together a couple of local components
b) a webapp environment with a simple JSP client that also wires
together a couple of local components
Then, for example, the JavaScript extension could say:
To illustrate the use of JavaScript as a component, take the client
a) and
1) replace <implementation.java class="Foo"/> with
<implementation.javascript script="foo.js"/>
2) Install javascript extension
2) rebuild/run sample
Or, to illustrate the WebService binding:
Server
1) Take webapp and add <service><binding.ws ...>
2) Install Axis binding extension
3) Deploy server app to Tomcat
Client
1) Take client application and replace <component name="foo" ...>
with <reference><binding.ws ...>
2) Install Axis binding extension
3) Run client
The basic idea being, have a common framework and the instructions on
how to use the particular extension.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
The new Windows Live Toolbar helps you guard against viruses http://
toolbar.live.com/?mkt=en-gb
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Be the first to hear what's new at MSN - sign up to our free newsletters!
http://www.msn.co.uk/newsletters
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
