Re: What's next for SCA?

[Jim Marino]

On Oct 24, 2006, at 9:37 AM, Jeremy Boynes wrote:

With M2 mostly behind us, I'd like look forward to things that we  
can tackle next for SCA/Java.


I think there is still some cleanup to be done - fixing bugs that  
we find in M2, cleaning up some of the compromises we made, and so  
forth. As part of that I think we still need more coverage on  
testing at all levels - unit, function, integration. I'd like to  
see us be in a position to regularly publish development snapshots  
that can be run through some form of test suite.


I also think there's quite a few improvements we can make to the  
classloading infrastructure. The issues with Spring and SDO show  
the need for a controlled way to share classes between application  
code and the runtime; we also need to deal with the isolation  
issues in the itest plugin (as in, dealing with the current lack of  
isolation). This is part of a general issue related to packaging  
formats and how composites correspond to physical artifacts in  
general.


Yes I think this is critical, especially in multi-VM environments. In  
the spec group we are dealing with the issue of deployment and  
packaging now so I think our work on this would correspond nicely to  
that.


This leads into the question of how we deploy things to servers. At  
the moment we only support server functions by being part of a WAR  
deployed to an application server; a user still needs to do quite a  
bit of work to set up the war (although the plugin helps). To  
support users in general and integration testing I think we need a  
way to deploy/undeploy SCA applications to running servers in some  
native form. We can do this either through extensions to existing  
servers (like the Tomcat integration from M1) or by enhancing the  
standalone environment.


Existing server integration is a nice-to-have but IMO we require a  
standalone environment that can support the full range of SCA  
features which is not easily done in the former.


Once we have the notion of multiple environments, I think we're in  
a position to tackle the more interesting aspects of SCA dealing  
with the composition of services across a network rather than  
locally as we have now. Finding a way to map a logical SCA system  
onto a mesh of servers and handling the interconnections between  
the system's services.


Yes this will likely entail some type of service discovery. I've been  
looking at zeroconf and perhaps UPnP as ways of doing this (support  
should be pluggable) and when I have a better idea I will post a  
write-up to the list.


Tied into that we should also start to look at the policy and  
intention parts of the specification, providing support for core  
aspects such as security, reliability and transactions. We have the  
hooks in the fabric for attaching policy but we need the  
implementations of these policies and the mechanisms for ensuring  
the right implementations get engaged.


We are going to need to deal with how intents are mapped to policy  
sets and then runtime artifacts. I see this "intent engine" as a key  
subsystem moving forward. I was discussing this the other day with  
Felix and I'll kick off another discussion on the list related to  
that since it is a broad topic.


We may also need to revisit the async programming model, both from  
the spec side and our implementation. I have a gut feeling that  
there are issues lurking there that don't make this as easy for  
users as we would like. We also need to extend what we have to  
support async MEPs on the wire rather than the simple sync MEP we  
have now.



Yes plus handling of stateful conversations
Finally, there's a general issue with adding additional bindings  
and containers and finishing what we have already (there were quite  
a few in M2 that we didn't think were ready for binary  
distribution). There seem to be quite a few in the pipe with talk  
of JMS and EJB, JDBC and declarative DAS.


This is just of brain dump of where my thinking is at the moment,  
I'm sure everyone has their own thoughts about things we should  
tackle. It would be good to get to them all on the table :-)


It may make sense to start to categorize these in buckets. My brain  
dump would be:


1. SCA fabric, a.k.a. "SCA system"
- How an SCA System is (auto)constituted
- Service discovery

2. Deployment, provisioning and Management

- How to get things into an SCA system, how logical artifacts are  
mapped to physical runtime artifacts, and how to manage what is going on


3. Spec alignment
- Refactoring of core to support pending spec changes around services  
and references


4. Host environments
- A "real" standalone container, particularly to support 1 & 2
- OSGi support

5. Programming model
- Our programming model needs to support "high-value" SCA features
- Stateful conversations
- How databinding is specified
- Complex property support
- Improved autowire capability, including the ability to autowire by  
intents and exposu

Re: What's next for SCA?

[Meeraj Kunnumpurath]

Hi,

I have been having few thoughts on federated deployment as well. Currently 
we wire services to references statically. However, I think this is more of 
a runtime concern rather than a build/package/deploy time concern. An SCA 
system could be realised as a set of federated heterogenous JVMs each 
hosting a different set of components. Each component would publish the 
services it provide based on supported MEPs, IN/OUT parameters, supported 
transport bindings and policy intent. Based on the published information, an 
adminstrator should be able to wire this services to a compatible reference 
for a consumer component at runtime. This wiring should be dynamically 
amendable to cater for such requirements like meeting SLAs, policy changes 
etc. I am not sure how much this currently fits into the SCA spec. However, 
as a user this is something I have looked for in ESBs. I would say a 
consumer component only need to know about the contract and MEP (to a 
certain extent) of the service it use. The assembly of an available 
prospective service instance is more of a runtime concern than deployment 
time.


Another thing I am curious about is scope containers, instance pooling and 
thread confinement. This is kind of related to the JPA integration work I 
have been doing. Certain resources that are injected into components may not 
be thread safe. In such scenarios, how do we make sure the components 
themselves are thread confined to avoid race conditions. Is instance pooling 
for stateless components a possible solution?


Ta
Meeraj



From: Jim Marino <[EMAIL PROTECTED]>
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: Re: What's next for SCA?
Date: Tue, 24 Oct 2006 10:21:45 -0700


On Oct 24, 2006, at 9:37 AM, Jeremy Boynes wrote:

With M2 mostly behind us, I'd like look forward to things that we  can 
tackle next for SCA/Java.


I think there is still some cleanup to be done - fixing bugs that  we find 
in M2, cleaning up some of the compromises we made, and so  forth. As part 
of that I think we still need more coverage on  testing at all levels - 
unit, function, integration. I'd like to  see us be in a position to 
regularly publish development snapshots  that can be run through some form 
of test suite.


I also think there's quite a few improvements we can make to the  
classloading infrastructure. The issues with Spring and SDO show  the need 
for a controlled way to share classes between application  code and the 
runtime; we also need to deal with the isolation  issues in the itest 
plugin (as in, dealing with the current lack of  isolation). This is part 
of a general issue related to packaging  formats and how composites 
correspond to physical artifacts in  general.


Yes I think this is critical, especially in multi-VM environments. In  the 
spec group we are dealing with the issue of deployment and  packaging now 
so I think our work on this would correspond nicely to  that.


This leads into the question of how we deploy things to servers. At  the 
moment we only support server functions by being part of a WAR  deployed 
to an application server; a user still needs to do quite a  bit of work to 
set up the war (although the plugin helps). To  support users in general 
and integration testing I think we need a  way to deploy/undeploy SCA 
applications to running servers in some  native form. We can do this 
either through extensions to existing  servers (like the Tomcat 
integration from M1) or by enhancing the  standalone environment.


Existing server integration is a nice-to-have but IMO we require a  
standalone environment that can support the full range of SCA  features 
which is not easily done in the former.


Once we have the notion of multiple environments, I think we're in  a 
position to tackle the more interesting aspects of SCA dealing  with the 
composition of services across a network rather than  locally as we have 
now. Finding a way to map a logical SCA system  onto a mesh of servers and 
handling the interconnections between  the system's services.


Yes this will likely entail some type of service discovery. I've been  
looking at zeroconf and perhaps UPnP as ways of doing this (support  should 
be pluggable) and when I have a better idea I will post a  write-up to the 
list.


Tied into that we should also start to look at the policy and  intention 
parts of the specification, providing support for core  aspects such as 
security, reliability and transactions. We have the  hooks in the fabric 
for attaching policy but we need the  implementations of these policies 
and the mechanisms for ensuring  the right implementations get engaged.


We are going to need to deal with how intents are mapped to policy  sets 
and then runtime artifacts. I see this "intent engine" as a key  subsystem 
moving forward. I was discussing this the other day with  Felix and I'll 
kick off another discussion

Re: What's next for SCA?

[Jim Marino]

ead safe, we may  
want to inject a proxy that resolves to the correct instance on every  
invoke (similar to what we do when a service is injected, e.g. a  
session-scoped service injected on a module-scoped component). This  
would allow us to have different scopes such as thread-confined or  
transactional or re-use existing ones (request) which may correspond  
to the lifetime of a Hibernate session or JPA context more closely.  
This would allow us to confine the specific resource as opposed to  
the entire component. This will not solve the issue of race  
conditions but sometimes the best thing to do is not try and do too  
much.


The Java spec is also going to include some revised wording on how  
client code should behave with respect to threading (e.g. spawning  
threads and calling into SCA code may yield unpredictable results;  
use WorkManager).


Jim



Ta
Meeraj



From: Jim Marino <[EMAIL PROTECTED]>
Reply-To: tuscany-dev@ws.apache.org
To: tuscany-dev@ws.apache.org
Subject: Re: What's next for SCA?
Date: Tue, 24 Oct 2006 10:21:45 -0700


On Oct 24, 2006, at 9:37 AM, Jeremy Boynes wrote:

With M2 mostly behind us, I'd like look forward to things that  
we  can tackle next for SCA/Java.


I think there is still some cleanup to be done - fixing bugs  
that  we find in M2, cleaning up some of the compromises we made,  
and so  forth. As part of that I think we still need more  
coverage on  testing at all levels - unit, function, integration.  
I'd like to  see us be in a position to regularly publish  
development snapshots  that can be run through some form of test  
suite.


I also think there's quite a few improvements we can make to the   
classloading infrastructure. The issues with Spring and SDO show   
the need for a controlled way to share classes between  
application  code and the runtime; we also need to deal with the  
isolation  issues in the itest plugin (as in, dealing with the  
current lack of  isolation). This is part of a general issue  
related to packaging  formats and how composites correspond to  
physical artifacts in  general.


Yes I think this is critical, especially in multi-VM environments.  
In  the spec group we are dealing with the issue of deployment  
and  packaging now so I think our work on this would correspond  
nicely to  that.


This leads into the question of how we deploy things to servers.  
At  the moment we only support server functions by being part of  
a WAR  deployed to an application server; a user still needs to  
do quite a  bit of work to set up the war (although the plugin  
helps). To  support users in general and integration testing I  
think we need a  way to deploy/undeploy SCA applications to  
running servers in some  native form. We can do this either  
through extensions to existing  servers (like the Tomcat  
integration from M1) or by enhancing the  standalone environment.


Existing server integration is a nice-to-have but IMO we require  
a  standalone environment that can support the full range of SCA   
features which is not easily done in the former.


Once we have the notion of multiple environments, I think we're  
in  a position to tackle the more interesting aspects of SCA  
dealing  with the composition of services across a network rather  
than  locally as we have now. Finding a way to map a logical SCA  
system  onto a mesh of servers and handling the interconnections  
between  the system's services.


Yes this will likely entail some type of service discovery. I've  
been  looking at zeroconf and perhaps UPnP as ways of doing this  
(support  should be pluggable) and when I have a better idea I  
will post a  write-up to the list.


Tied into that we should also start to look at the policy and   
intention parts of the specification, providing support for core   
aspects such as security, reliability and transactions. We have  
the  hooks in the fabric for attaching policy but we need the   
implementations of these policies and the mechanisms for  
ensuring  the right implementations get engaged.


We are going to need to deal with how intents are mapped to  
policy  sets and then runtime artifacts. I see this "intent  
engine" as a key  subsystem moving forward. I was discussing this  
the other day with  Felix and I'll kick off another discussion on  
the list related to  that since it is a broad topic.


We may also need to revisit the async programming model, both  
from  the spec side and our implementation. I have a gut feeling  
that  there are issues lurking there that don't make this as easy  
for  users as we would like. We also need to extend what we have  
to  support async MEPs on the wire rather than the simple sync  
MEP we  have now.



Yes plus handling of stateful conversations
Finally, there's a general issue with adding additional bindings   
and containers and finishing what we have already (there were  
quite  a few in M2 that we 

RE: What's next for SCA?

[Meeraj Kunnumpurath]

Hi,

I think when the dangling wires are resolved depends on, as you said,
what the definition of deployment is. The requirement is for the wires
to be all resolved, before a composite is active and service ready.
Regardless of what we mean by deployment, I think there should be still
ability to rewire components in active composite, to cater for meeting
SLA requirements, policy changes etc.

Roles are a kind of interesting thing. J2EE specs have always mentioned
these different roles. However, mostly the roles of developer/assembler
and deployer/administrator amalgamate into one. 

Also, it terms of advertisement and discovery, would you prefer a
registry-based approach or a more peer-to-peer model, where components
auto-advertise their availability and resolving the wires can either be
auto-discovery or manual. From that perspective, deployment could be a
two phase process. First, activating all the components with dangling
wires and then resolving all the wires and activating the whole
composite.

Ta
Meeraj

>> -Original Message-
>> From: Jim Marino [mailto:[EMAIL PROTECTED] 
>> Sent: 25 October 2006 08:23
>> To: tuscany-dev@ws.apache.org
>> Subject: Re: What's next for SCA?
>> 
>> 
>> On Oct 24, 2006, at 4:48 PM, Meeraj Kunnumpurath wrote:
>> 
>> > Hi,
>> >
>> > I have been having few thoughts on federated deployment as well.  
>> > Currently we wire services to references statically. 
>> However, I think 
>> > this is more of a runtime concern rather than a 
>> build/package/ deploy 
>> > time concern.
>> +1
>> > An SCA system could be realised as a set of federated heterogenous 
>> > JVMs each hosting a different set of components.
>> Yes, I think this is a key difference between what Tuscany 
>> is trying to do and more traditional application server 
>> environments that have a more homogenous 2- or 3-tier 
>> topology. Some nodes may not be VMs.
>> > Each component would publish the services it provide based on 
>> > supported MEPs, IN/OUT parameters, supported transport 
>> bindings and 
>> > policy intent. Based on the published information, an adminstrator 
>> > should be able to wire this services to a compatible 
>> reference for a 
>> > consumer component at runtime. This wiring should be dynamically 
>> > amendable to cater for such requirements like meeting SLAs, policy 
>> > changes etc. I am not sure how much this currently fits 
>> into the SCA 
>> > spec.
>> I think it will fit. In SCA we identified a couple of roles 
>> (they may be the same person sometimes, or different 
>> individuals), one of which is an "assembler". This person is 
>> responsible for resolving unbound or dangling wires, 
>> configuration, etc. Also, one of the changes being 
>> considered is the introduction of "intents" which could 
>> correspond to the things you mentioned above. As part of 
>> these changes, we were also considering autowiring by 
>> intent. This will provide even more flexibility since it 
>> will allow the runtime to choose wire targets, bindings, 
>> etc. based on a set of constraints. I believe these changes 
>> will make things a lot easier as having to 
>> "manually/explicitly" wire can get tedious (as well as 
>> result in globs of XML).
>> 
>> So my picture of how things would work at a high level is:
>> 
>> 1. Tuscany nodes come up
>> 
>> 2. The nodes can either be pre-configured to know about 
>> themselves or would autodiscover each other through a 
>> protocol such as zeroconf. We should look at other protocols 
>> as well but I am currently interested in zeroconf since it 
>> is language-neutral, works with existing TCP/IP 
>> infrastructure and does not require a central registry (the 
>> service discovery part which Tuscany would use can be run 
>> over multi-cast or uni-cast DNS), works in small devices 
>> (e.g. printers and cameras), and is an IETF standard.  Nodes 
>> could be different Tuscany instances running on a variety 
>> host environments, just an agent talking to a middleware 
>> instance with no Tuscany runtime, or represent some 
>> middleware cluster.
>> 
>> 3. An SCA system would be constituted from these nodes, and 
>> would itself be represented as a composite.
>> 
>> 4. There would be a provisioning infrastructure responsible 
>> for mapping and deploying SCA assemblies to physical nodes. 
>> This may entail breaking a composite apart and deploying 
>> child components to various nodes according to some 
>> (pluggable, ex

Re: What's next for SCA?

[Jim Marino]

On Oct 26, 2006, at 3:11 AM, Meeraj Kunnumpurath wrote:


Hi,

I think when the dangling wires are resolved depends on, as you said,
what the definition of deployment is. The requirement is for the wires
to be all resolved, before a composite is active and service ready.
Regardless of what we mean by deployment, I think there should be  
still

ability to rewire components in active composite, to cater for meeting
SLA requirements, policy changes etc.

Yes absolutely. I view policy application as similar to AOP in except  
the meta-model is a service assembly and not a Java class. We should  
support the ability to to do this "live" such as say "I want to  
monitor traffic going over binding X". Jeremy and I were speaking  
about this the other day and it occurred to us what we are doing is  
also quite similar to subversion in that we are mutating the wiring  
fabric, or applying a diff against it. If we one of the things we  
support is deployment of SCDL artifacts, we should literally be able  
to use a diff ;-)
Roles are a kind of interesting thing. J2EE specs have always  
mentioned
these different roles. However, mostly the roles of developer/ 
assembler

and deployer/administrator amalgamate into one.

Yes and I think one of the problems with J2EE (EJB and packaging in  
particular) is that it never recognized that the roles often are  
carried out by the same individual. That said, I do think they are at  
least conceptually different.

Also, it terms of advertisement and discovery, would you prefer a
registry-based approach or a more peer-to-peer model, where components
auto-advertise their availability and resolving the wires can  
either be

auto-discovery or manual. From that perspective, deployment could be a
two phase process. First, activating all the components with dangling
wires and then resolving all the wires and activating the whole
composite.

I was thinking more distributed, i.e. non-registry based using  
multicast, for local-link communications but we may need some  
centralized mechanism for communication beyond a local link such as a  
DNS server (e.g. zeroconf used dynamic DNS queries for this). Do you  
have any preference?


On the wiring algorithm, at a high level that seems right since it  
roughly corresponds to what we do within a composite. One difference  
though is we are probably going to need to be able to handle cycles  
between composites.


Jim


Ta
Meeraj


-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 25 October 2006 08:23
To: tuscany-dev@ws.apache.org
Subject: Re: What's next for SCA?


On Oct 24, 2006, at 4:48 PM, Meeraj Kunnumpurath wrote:


Hi,

I have been having few thoughts on federated deployment as well.
Currently we wire services to references statically.

However, I think

this is more of a runtime concern rather than a

build/package/ deploy

time concern.

+1

An SCA system could be realised as a set of federated heterogenous
JVMs each hosting a different set of components.

Yes, I think this is a key difference between what Tuscany
is trying to do and more traditional application server
environments that have a more homogenous 2- or 3-tier
topology. Some nodes may not be VMs.

Each component would publish the services it provide based on
supported MEPs, IN/OUT parameters, supported transport

bindings and

policy intent. Based on the published information, an adminstrator
should be able to wire this services to a compatible

reference for a

consumer component at runtime. This wiring should be dynamically
amendable to cater for such requirements like meeting SLAs, policy
changes etc. I am not sure how much this currently fits

into the SCA

spec.

I think it will fit. In SCA we identified a couple of roles
(they may be the same person sometimes, or different
individuals), one of which is an "assembler". This person is
responsible for resolving unbound or dangling wires,
configuration, etc. Also, one of the changes being
considered is the introduction of "intents" which could
correspond to the things you mentioned above. As part of
these changes, we were also considering autowiring by
intent. This will provide even more flexibility since it
will allow the runtime to choose wire targets, bindings,
etc. based on a set of constraints. I believe these changes
will make things a lot easier as having to
"manually/explicitly" wire can get tedious (as well as
result in globs of XML).

So my picture of how things would work at a high level is:

1. Tuscany nodes come up

2. The nodes can either be pre-configured to know about
themselves or would autodiscover each other through a
protocol such as zeroconf. We should look at other protocols
as well but I am currently interested in zeroconf since it
is language-neutral, works with existing TCP/IP
infrastructure and does not require a central registry (the
service discovery part which Tuscany would use can be run
over m

Re: What's next for SCA?

[Andy Piper]

At 17:21 24/10/2006, Jim Marino wrote:

Existing server integration is a nice-to-have but IMO we require a
standalone environment that can support the full range of SCA
features which is not easily done in the former.


FWIW if you want to drive adoption then I think this is more than 
nice-to-have.
I think you need to seriously tackle the issue of the whole world not 
being Tuscany (see note below). This is not just the issue of 
providing a fully featured SCA implementation in hosted environments, 
but interacting with other SCA runtimes that are not Tuscany and 
other services that are not SCA at all. I think this probably means a 
much clearer separation between the parts of the Tuscany runtime that 
are core and those that are targeted to a particular implementation 
(standalone for example). Given clearer SPI access into the core I 
think you will have a lot more success in driving Tuscany into the real world.



Yes this will likely entail some type of service discovery. I've been
looking at zeroconf and perhaps UPnP as ways of doing this (support
should be pluggable) and when I have a better idea I will post a
write-up to the list.


The key here is pluggable. Any clustering infrastructure does this 
and to date they are all different (e.g. WebLogic, Geronmo, Active 
MQ, JBoss, WAS), datacenter managers will not thank you for more :) 
It might also be worth looking at ActiveCluster since it does 
something similar here (I think it may use Zeroconf anyway), although 
I have to say that if I had my way everyone would use UPnP.


Although don't you actually need something a bit higher level? E.g. 
UDDI or AD or something that allows you to publish all of the 
associated meta data as well.


My $0.02

andy 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What's next for SCA?

[Jim Marino]

On Nov 2, 2006, at 4:37 AM, Andy Piper wrote:


At 17:21 24/10/2006, Jim Marino wrote:

Existing server integration is a nice-to-have but IMO we require a
standalone environment that can support the full range of SCA
features which is not easily done in the former.


FWIW if you want to drive adoption then I think this is more than  
nice-to-have.
I think you need to seriously tackle the issue of the whole world  
not being Tuscany (see note below). This is not just the issue of  
providing a fully featured SCA implementation in hosted  
environments, but interacting with other SCA runtimes that are not  
Tuscany and other services that are not SCA at all. I think this  
probably means a much clearer separation between the parts of the  
Tuscany runtime that are core and those that are targeted to a  
particular implementation (standalone for example). Given clearer  
SPI access into the core I think you will have a lot more success  
in driving Tuscany into the real world.


I definitely agree we need to do a better job tackling the issue of  
there being other things besides Tuscany :-) Up to now, I have viewed  
most of the work we have been doing as concentrating on in-VM wiring  
infrastructure. As part of next steps, I think we need to address  
(for lack of a better term) the "service fabric". This definitely  
goes beyond just providing a full-featured VM-based implementation  
that we have been working on to-date.


 I would say there are a number of issues here:

1. The ability to deploy Tuscany on a variety of runtimes
2. The need for a standalone environment to leverage all the  
capabilities of SCA assembly

3. Interacting with non-SCA services
4. Better APIs/SPIs into Tuscany
5. Support for a service fabric/network or "SCA system"

1-4 basically involve dealing with the in-VM wiring infrastructure  
that we have today. For example, (1) embedding Tuscany in Tomcat, (2)  
providing a full-featured SCA standalone environment, (3) increasing  
the number of supported bindings, and (4) management/extensions, etc.


We still have a lot of work in the above areas to do. However, for me  
the real benefits of Tuscany will come to the fore when we provide  
capabilities that allow us to support service networks. I was viewing  
this as the ability to describe a logical service topology (services  
and their dependencies, SLAs, policies, qualities of service) and  
have runtime infrastructure that is able to provision and manage it.  
A key characteristic of these networks will be that while there is a  
unified logical topology, their physical manifestations will be  
heterogeneous. For example, a service network could be deployed  
across Tomcat instances, WAS clusters, WLS clusters, a Tuscany  
standalone container, even potentially Microsoft WCF. In some  
instances, the Tuscany in-VM wiring infrastructure may not be  
present. In this case, a deployment agent would be responsible for  
provisioning artifacts to a particular runtime. The job of Tuscany  
will be to provide the fabric that ties this all together and  
constitutes an "SCA system".






Yes this will likely entail some type of service discovery. I've been
looking at zeroconf and perhaps UPnP as ways of doing this (support
should be pluggable) and when I have a better idea I will post a
write-up to the list.


The key here is pluggable. Any clustering infrastructure does this  
and to date they are all different (e.g. WebLogic, Geronmo, Active  
MQ, JBoss, WAS), datacenter managers will not thank you for more :)
Agreed that most of what we should do needs to be pluggable. However,  
I was viewing "service discovery" as something distinct from  
clustering. If the SCA system mentioned above is itself a composite,  
then it could have various services such as deployers and  
provisioners. There may be particular composites deployed in the SCA  
system that run, for example, on an app server cluster and services  
within those composites may use the clustering facilities provided by  
that infrastructure. At the higher level of the SCA system, we need a  
discovery mechanism that may work across a variety of runtimes as a  
way for the SCA system to "auto-constitute" itself.


It might also be worth looking at ActiveCluster since it does  
something similar here (I think it may use Zeroconf anyway),  
although I have to say that if I had my way everyone would use UPnP.


Do you think UPnP is better direction to go? I liked Zeroconf because  
of its simplicity and support for discovery beyond the local link but  
I don't have any strong opinion either way.




Although don't you actually need something a bit higher level? E.g.  
UDDI or AD or something that allows you to publish all of the  
associated meta data as well.


I definitely think we need a metadata representation of the SCA  
system/service network.  I was imagining that would be done by other  
services which could be segmented to handle particular areas of the  
system. I'

Re: What's next for SCA & BPEL Integration

[ant elder]

On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> Now that we are making more progress with the SCA & BPEL integration
> and have figured out how to make References to work, let's discuss
> what could be the next steps on this area. Below are couple examples
> of what we could do next
>
> - WS-BPEL Process Introspection : Currently we are requiring SCA
> componentType files, we could introspect the BPEL process file to
> generate the component type information from it.
>
> - Integrate BEPL with the store scenario tutorial : We could add a
> OrderProcessing step to the store checkout, and illustrate a more real
> integration scenario.
>
> Other then these, we could review the
> SCA_ClientAndImplementationModelFor BPEL and identify other areas that
> we might need enhancements. Scenarios / Samples / Demos are always
> welcome too. Or if you have other suggestions, feel free to jump to
> the discussion.
>
> BTW: Copying the ODE list in case they want to jump and help, or in
> case they have other ideas.
>
>
Not a very exciting one but is there any clean up of the dependencies
possible? Currently using the implementation.bpel extension brings in 78
addition dependency jars at about 20meg, i wondered if some of those could
get excluded?

   ...ant

Re: What's next for SCA & BPEL Integration

[Luciano Resende]

On Thu, Apr 24, 2008 at 8:53 AM, ant elder <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <[EMAIL PROTECTED]>
>  wrote:
>
>
>  > Now that we are making more progress with the SCA & BPEL integration
>  > and have figured out how to make References to work, let's discuss
>  > what could be the next steps on this area. Below are couple examples
>  > of what we could do next
>  >
>  > - WS-BPEL Process Introspection : Currently we are requiring SCA
>  > componentType files, we could introspect the BPEL process file to
>  > generate the component type information from it.
>  >
>  > - Integrate BEPL with the store scenario tutorial : We could add a
>  > OrderProcessing step to the store checkout, and illustrate a more real
>  > integration scenario.
>  >
>  > Other then these, we could review the
>  > SCA_ClientAndImplementationModelFor BPEL and identify other areas that
>  > we might need enhancements. Scenarios / Samples / Demos are always
>  > welcome too. Or if you have other suggestions, feel free to jump to
>  > the discussion.
>  >
>  > BTW: Copying the ODE list in case they want to jump and help, or in
>  > case they have other ideas.
>  >
>  >
>  Not a very exciting one but is there any clean up of the dependencies
>  possible? Currently using the implementation.bpel extension brings in 78
>  addition dependency jars at about 20meg, i wondered if some of those could
>  get excluded?
>
>...ant
>

Part of this is because we have a Embedded ODE BPEL engine, and that
itself brings several dependencies. But this is certainly something to
investigate. It would be also good if ODE could be more
flexible/dynamic with some dependencies (e.g Saxon) and only really
require these dependencies if they are going to be in use, this would
help our side as well.

-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: What's next for SCA & BPEL Integration

[Matthieu Riou]

On Thu, Apr 24, 2008 at 10:41 AM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> On Thu, Apr 24, 2008 at 8:53 AM, ant elder <[EMAIL PROTECTED]> wrote:
> > On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <[EMAIL PROTECTED]>
> >  wrote:
> >
> >
> >  > Now that we are making more progress with the SCA & BPEL integration
> >  > and have figured out how to make References to work, let's discuss
> >  > what could be the next steps on this area. Below are couple examples
> >  > of what we could do next
> >  >
> >  > - WS-BPEL Process Introspection : Currently we are requiring SCA
> >  > componentType files, we could introspect the BPEL process file to
> >  > generate the component type information from it.
> >  >
> >  > - Integrate BEPL with the store scenario tutorial : We could add a
> >  > OrderProcessing step to the store checkout, and illustrate a more real
> >  > integration scenario.
> >  >
> >  > Other then these, we could review the
> >  > SCA_ClientAndImplementationModelFor BPEL and identify other areas that
> >  > we might need enhancements. Scenarios / Samples / Demos are always
> >  > welcome too. Or if you have other suggestions, feel free to jump to
> >  > the discussion.
> >  >
> >  > BTW: Copying the ODE list in case they want to jump and help, or in
> >  > case they have other ideas.
> >  >
> >  >
> >  Not a very exciting one but is there any clean up of the dependencies
> >  possible? Currently using the implementation.bpel extension brings in 78
> >  addition dependency jars at about 20meg, i wondered if some of those
> could
> >  get excluded?
> >
> >...ant
> >
>
> Part of this is because we have a Embedded ODE BPEL engine, and that
> itself brings several dependencies. But this is certainly something to
> investigate. It would be also good if ODE could be more
> flexible/dynamic with some dependencies (e.g Saxon) and only really
> require these dependencies if they are going to be in use, this would
> help our side as well.
>

Saxon is going to be hard to remove, there are very few BPEL processes that
won't need any XPath expressions to execute so I'm not sure it's one we can
save. But you're right for the embedded engine, right now we use our own
stuff for everything ODE needs to execute: connection pool, transaction
manager, jpa instance, thread pool, ... I'm guessing for many of these we
could reuse what comes with Tuscany.

Cheers,
Matthieu


>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende 
> http://lresende.blogspot.com/
>

Re: What's next for SCA & BPEL Integration

[Mike Edwards]

Luciano Resende wrote:

Now that we are making more progress with the SCA & BPEL integration
and have figured out how to make References to work, let's discuss
what could be the next steps on this area. Below are couple examples
of what we could do next

- WS-BPEL Process Introspection : Currently we are requiring SCA
componentType files, we could introspect the BPEL process file to
generate the component type information from it.

- Integrate BEPL with the store scenario tutorial : We could add a
OrderProcessing step to the store checkout, and illustrate a more real
integration scenario.

Other then these, we could review the
SCA_ClientAndImplementationModelFor BPEL and identify other areas that
we might need enhancements. Scenarios / Samples / Demos are always
welcome too. Or if you have other suggestions, feel free to jump to
the discussion.

BTW: Copying the ODE list in case they want to jump and help, or in
case they have other ideas.


Luciano,

WS_BPEL Process introspection is top of my list.  Having to write 
componentType side files is a miserable business, particularly when all 
the information you need is sitting there in the BPEL Process XML.  The 
Spring implementation is a good model - the Spring application context 
is ripped through to produce the componentType and so side file is ever 
needed.


A good BPEL sample is called for.  One based on some order process seems 
good to me.  It should also involve the BPEL process making asynchronous 
calls to back end services, which means stretching the support on 
references to include callbacks.


We should consider integrating with the tutorial after building a good 
standalone BPEL sample.



Yours,  Mike.

Re: What's next for SCA & BPEL Integration

[Matthieu Riou]

On Thu, Apr 24, 2008 at 8:37 AM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> Now that we are making more progress with the SCA & BPEL integration
> and have figured out how to make References to work, let's discuss
> what could be the next steps on this area. Below are couple examples
> of what we could do next
>
> - WS-BPEL Process Introspection : Currently we are requiring SCA
> componentType files, we could introspect the BPEL process file to
> generate the component type information from it.
>
> - Integrate BEPL with the store scenario tutorial : We could add a
> OrderProcessing step to the store checkout, and illustrate a more real
> integration scenario.
>
> Other then these, we could review the
> SCA_ClientAndImplementationModelFor BPEL and identify other areas that
> we might need enhancements. Scenarios / Samples / Demos are always
> welcome too. Or if you have other suggestions, feel free to jump to
> the discussion.
>
> BTW: Copying the ODE list in case they want to jump and help, or in
> case they have other ideas.
>

I was thinking about the deployment model as well. Right now you still need
a deploy.xml descriptor to tell ODE how to bind a partnerLink to a concrete
port. In an SCA context I'm thinking this should be handled by the
container.

Matthieu


>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende 
> http://lresende.blogspot.com/
>

Re: What's next for SCA & BPEL Integration

[ant elder]

On Thu, Apr 24, 2008 at 7:59 PM, Matthieu Riou <[EMAIL PROTECTED]>
wrote:

> On Thu, Apr 24, 2008 at 10:41 AM, Luciano Resende <[EMAIL PROTECTED]>
> wrote:
>
> > On Thu, Apr 24, 2008 at 8:53 AM, ant elder <[EMAIL PROTECTED]> wrote:
> > > On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <[EMAIL PROTECTED]
> >
> > >  wrote:
> > >
> > >
> > >  > Now that we are making more progress with the SCA & BPEL integration
> > >  > and have figured out how to make References to work, let's discuss
> > >  > what could be the next steps on this area. Below are couple examples
> > >  > of what we could do next
> > >  >
> > >  > - WS-BPEL Process Introspection : Currently we are requiring SCA
> > >  > componentType files, we could introspect the BPEL process file to
> > >  > generate the component type information from it.
> > >  >
> > >  > - Integrate BEPL with the store scenario tutorial : We could add a
> > >  > OrderProcessing step to the store checkout, and illustrate a more
> real
> > >  > integration scenario.
> > >  >
> > >  > Other then these, we could review the
> > >  > SCA_ClientAndImplementationModelFor BPEL and identify other areas
> that
> > >  > we might need enhancements. Scenarios / Samples / Demos are always
> > >  > welcome too. Or if you have other suggestions, feel free to jump to
> > >  > the discussion.
> > >  >
> > >  > BTW: Copying the ODE list in case they want to jump and help, or in
> > >  > case they have other ideas.
> > >  >
> > >  >
> > >  Not a very exciting one but is there any clean up of the dependencies
> > >  possible? Currently using the implementation.bpel extension brings in
> 78
> > >  addition dependency jars at about 20meg, i wondered if some of those
> > could
> > >  get excluded?
> > >
> > >...ant
> > >
> >
> > Part of this is because we have a Embedded ODE BPEL engine, and that
> > itself brings several dependencies. But this is certainly something to
> > investigate. It would be also good if ODE could be more
> > flexible/dynamic with some dependencies (e.g Saxon) and only really
> > require these dependencies if they are going to be in use, this would
> > help our side as well.
> >
>
> Saxon is going to be hard to remove, there are very few BPEL processes that
> won't need any XPath expressions to execute so I'm not sure it's one we can
> save. But you're right for the embedded engine, right now we use our own
> stuff for everything ODE needs to execute: connection pool, transaction
> manager, jpa instance, thread pool, ... I'm guessing for many of these we
> could reuse what comes with Tuscany.
>
>
These are all the additional dependencies brought in with the Tuscany
implementation.bpel extension, are any of them obviously not necessary?

activeio-2.0-r118.jar
axion-1.0-M3-dev.jar
backport-util-concurrent-3.0.jar
common-2.2.3.jar
commons-codec-1.3.jar
commons-collections-3.1.jar
commons-jexl-1.1.jar
commons-lang-2.1.jar
commons-logging-1.0.4.jar
commons-primitives-1.0.jar
derby-10.3.1.4.jar
dom4j-1.6.1.jar
ecore-2.2.3.jar
ecore-change-2.2.3.jar
ecore-xmi-2.2.3.jar
geronimo-common-1.2-beta.jar
geronimo-connector-1.2-beta.jar
geronimo-core-1.2-beta.jar
geronimo-deployment-1.2-beta.jar
geronimo-ejb_3.0_spec-1.0.jar
geronimo-interceptor-1.2-beta.jar
geronimo-j2ee-1.2-beta.jar
geronimo-j2ee-connector_1.5_spec-1.1.jar
geronimo-j2ee-jacc_1.0_spec-1.1.jar
geronimo-j2ee-management_1.0_spec-1.1.jar
geronimo-jpa_3.0_spec-1.0.jar
geronimo-jta_1.0.1B_spec-1.0.jar
geronimo-kernel-1.2-beta.jar
geronimo-management-1.2-beta.jar
geronimo-naming-1.2-beta.jar
geronimo-security-1.2-beta.jar
geronimo-spec-j2ee-connector-1.5-rc4.jar
geronimo-spec-jta-1.0.1B-rc4.jar
geronimo-system-1.2-beta.jar
geronimo-transaction-1.2-beta.jar
geronimo-util-1.2-beta.jar
howl-1.0.1-1.jar
icu4j-2.6.1.jar
javacc-3.2.jar
jaxen-1.1.1.jar
jdom-1.0.jar
log4j-1.2.13.jar
ode-bpel-api-1.1.jar
ode-bpel-compiler-1.1.jar
ode-bpel-dao-1.1.jar
ode-bpel-epr-1.1.jar
ode-bpel-obj-1.1.jar
ode-bpel-runtime-1.1.jar
ode-bpel-schemas-1.1.jar
ode-bpel-store-1.1.jar
ode-dao-jpa-1.1.jar
ode-jacob-1.1.jar
ode-jacob-ap-1.1.jar
ode-scheduler-simple-1.1.jar
ode-utils-1.1.jar
openjpa-all-0.9.7-incubating.jar
openjpa-persistence-0.9.7-incubating.jar
org.apache.felix.bundlerepository-1.0.0.jar
org.apache.felix.framework-1.0.1.jar
org.apache.felix.main-1.0.1.jar
org.apache.felix.shell-1.0.0.jar
org.apache.felix.shell.tui-1.0.0.jar
regexp-1.3.jar
saxon-8.7.jar
saxon-dom-8.7.jar
saxon-xpath-8.7.jar
serp-1.12.0.jar
tranql-connector-1.1.jar
tuscany-databinding-sdo-2.0-incubating-SNAPSHOT.jar
tuscany-implementation-bpel-2.0-incubating-SNAPSHOT.jar
xalan-2.7.0.jar
xbean-naming-2.7.jar
xercesImpl-2.8.1.jar
xml-apis-1.3.02.jar
xml-resolver-1.1.jar
xmlbeans-2.3.0.jar
xmlParserAPIs-2.6.2.jar
XmlSchema-1.3.2.jar
xom-1.0.jar
xsd-2.2.3.jar

   ...ant

Re: What's next for SCA & BPEL Integration

[Mike Edwards]

ant elder wrote:



These are all the additional dependencies brought in with the Tuscany
implementation.bpel extension, are any of them obviously not necessary?

activeio-2.0-r118.jar
axion-1.0-M3-dev.jar
backport-util-concurrent-3.0.jar
common-2.2.3.jar
commons-codec-1.3.jar
commons-collections-3.1.jar
commons-jexl-1.1.jar
commons-lang-2.1.jar
commons-logging-1.0.4.jar
commons-primitives-1.0.jar
derby-10.3.1.4.jar
dom4j-1.6.1.jar
ecore-2.2.3.jar
ecore-change-2.2.3.jar
ecore-xmi-2.2.3.jar
geronimo-common-1.2-beta.jar
geronimo-connector-1.2-beta.jar
geronimo-core-1.2-beta.jar
geronimo-deployment-1.2-beta.jar
geronimo-ejb_3.0_spec-1.0.jar
geronimo-interceptor-1.2-beta.jar
geronimo-j2ee-1.2-beta.jar
geronimo-j2ee-connector_1.5_spec-1.1.jar
geronimo-j2ee-jacc_1.0_spec-1.1.jar
geronimo-j2ee-management_1.0_spec-1.1.jar
geronimo-jpa_3.0_spec-1.0.jar
geronimo-jta_1.0.1B_spec-1.0.jar
geronimo-kernel-1.2-beta.jar
geronimo-management-1.2-beta.jar
geronimo-naming-1.2-beta.jar
geronimo-security-1.2-beta.jar
geronimo-spec-j2ee-connector-1.5-rc4.jar
geronimo-spec-jta-1.0.1B-rc4.jar
geronimo-system-1.2-beta.jar
geronimo-transaction-1.2-beta.jar
geronimo-util-1.2-beta.jar
howl-1.0.1-1.jar
icu4j-2.6.1.jar
javacc-3.2.jar
jaxen-1.1.1.jar
jdom-1.0.jar
log4j-1.2.13.jar
ode-bpel-api-1.1.jar
ode-bpel-compiler-1.1.jar
ode-bpel-dao-1.1.jar
ode-bpel-epr-1.1.jar
ode-bpel-obj-1.1.jar
ode-bpel-runtime-1.1.jar
ode-bpel-schemas-1.1.jar
ode-bpel-store-1.1.jar
ode-dao-jpa-1.1.jar
ode-jacob-1.1.jar
ode-jacob-ap-1.1.jar
ode-scheduler-simple-1.1.jar
ode-utils-1.1.jar
openjpa-all-0.9.7-incubating.jar
openjpa-persistence-0.9.7-incubating.jar
org.apache.felix.bundlerepository-1.0.0.jar
org.apache.felix.framework-1.0.1.jar
org.apache.felix.main-1.0.1.jar
org.apache.felix.shell-1.0.0.jar
org.apache.felix.shell.tui-1.0.0.jar
regexp-1.3.jar
saxon-8.7.jar
saxon-dom-8.7.jar
saxon-xpath-8.7.jar
serp-1.12.0.jar
tranql-connector-1.1.jar
tuscany-databinding-sdo-2.0-incubating-SNAPSHOT.jar
tuscany-implementation-bpel-2.0-incubating-SNAPSHOT.jar
xalan-2.7.0.jar
xbean-naming-2.7.jar
xercesImpl-2.8.1.jar
xml-apis-1.3.02.jar
xml-resolver-1.1.jar
xmlbeans-2.3.0.jar
xmlParserAPIs-2.6.2.jar
XmlSchema-1.3.2.jar
xom-1.0.jar
xsd-2.2.3.jar

   ...ant

I suggest that we get the functionality of  
working first before we start to worry about the amount of clobber that 
it involves.  It is barely working at the moment.


I admit that the amount of code is alarming, but we shall have to work 
with other groups to find out what could be removed without harm.  That 
is a longer-term task.


Yours,  Mike.

Re: What's next for SCA & BPEL Integration

[ant elder]

On Fri, Apr 25, 2008 at 11:44 AM, Mike Edwards <
[EMAIL PROTECTED]> wrote:

> ant elder wrote:
>
>>
>>>  These are all the additional dependencies brought in with the Tuscany
>> implementation.bpel extension, are any of them obviously not necessary?
>>
>> activeio-2.0-r118.jar
>> axion-1.0-M3-dev.jar
>> backport-util-concurrent-3.0.jar
>> common-2.2.3.jar
>> commons-codec-1.3.jar
>> commons-collections-3.1.jar
>> commons-jexl-1.1.jar
>> commons-lang-2.1.jar
>> commons-logging-1.0.4.jar
>> commons-primitives-1.0.jar
>> derby-10.3.1.4.jar
>> dom4j-1.6.1.jar
>> ecore-2.2.3.jar
>> ecore-change-2.2.3.jar
>> ecore-xmi-2.2.3.jar
>> geronimo-common-1.2-beta.jar
>> geronimo-connector-1.2-beta.jar
>> geronimo-core-1.2-beta.jar
>> geronimo-deployment-1.2-beta.jar
>> geronimo-ejb_3.0_spec-1.0.jar
>> geronimo-interceptor-1.2-beta.jar
>> geronimo-j2ee-1.2-beta.jar
>> geronimo-j2ee-connector_1.5_spec-1.1.jar
>> geronimo-j2ee-jacc_1.0_spec-1.1.jar
>> geronimo-j2ee-management_1.0_spec-1.1.jar
>> geronimo-jpa_3.0_spec-1.0.jar
>> geronimo-jta_1.0.1B_spec-1.0.jar
>> geronimo-kernel-1.2-beta.jar
>> geronimo-management-1.2-beta.jar
>> geronimo-naming-1.2-beta.jar
>> geronimo-security-1.2-beta.jar
>> geronimo-spec-j2ee-connector-1.5-rc4.jar
>> geronimo-spec-jta-1.0.1B-rc4.jar
>> geronimo-system-1.2-beta.jar
>> geronimo-transaction-1.2-beta.jar
>> geronimo-util-1.2-beta.jar
>> howl-1.0.1-1.jar
>> icu4j-2.6.1.jar
>> javacc-3.2.jar
>> jaxen-1.1.1.jar
>> jdom-1.0.jar
>> log4j-1.2.13.jar
>> ode-bpel-api-1.1.jar
>> ode-bpel-compiler-1.1.jar
>> ode-bpel-dao-1.1.jar
>> ode-bpel-epr-1.1.jar
>> ode-bpel-obj-1.1.jar
>> ode-bpel-runtime-1.1.jar
>> ode-bpel-schemas-1.1.jar
>> ode-bpel-store-1.1.jar
>> ode-dao-jpa-1.1.jar
>> ode-jacob-1.1.jar
>> ode-jacob-ap-1.1.jar
>> ode-scheduler-simple-1.1.jar
>> ode-utils-1.1.jar
>> openjpa-all-0.9.7-incubating.jar
>> openjpa-persistence-0.9.7-incubating.jar
>> org.apache.felix.bundlerepository-1.0.0.jar
>> org.apache.felix.framework-1.0.1.jar
>> org.apache.felix.main-1.0.1.jar
>> org.apache.felix.shell-1.0.0.jar
>> org.apache.felix.shell.tui-1.0.0.jar
>> regexp-1.3.jar
>> saxon-8.7.jar
>> saxon-dom-8.7.jar
>> saxon-xpath-8.7.jar
>> serp-1.12.0.jar
>> tranql-connector-1.1.jar
>> tuscany-databinding-sdo-2.0-incubating-SNAPSHOT.jar
>> tuscany-implementation-bpel-2.0-incubating-SNAPSHOT.jar
>> xalan-2.7.0.jar
>> xbean-naming-2.7.jar
>> xercesImpl-2.8.1.jar
>> xml-apis-1.3.02.jar
>> xml-resolver-1.1.jar
>> xmlbeans-2.3.0.jar
>> xmlParserAPIs-2.6.2.jar
>> XmlSchema-1.3.2.jar
>> xom-1.0.jar
>> xsd-2.2.3.jar
>>
>>   ...ant
>>
>>  I suggest that we get the functionality of 
> working first before we start to worry about the amount of clobber that it
> involves.  It is barely working at the moment.
>
>
Fair enough, I've not tried using it yet so didn't realize it was still so
rough.

   ...ant

RE: What's next for SCA & BPEL Integration

[Ashwini Kumar Jeksani]

Hi,

Does Tuscany support SCA Extentions to WS-BPEL? If it doesn't then I guess we 
could look into that one as well.

Thanks & Regards
Ashwini Kumar Jeksani


-Original Message-
From: Luciano Resende [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 24, 2008 11:11 PM
To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: What's next for SCA & BPEL Integration

On Thu, Apr 24, 2008 at 8:53 AM, ant elder <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <[EMAIL PROTECTED]>
>  wrote:
>
>
>  > Now that we are making more progress with the SCA & BPEL integration
>  > and have figured out how to make References to work, let's discuss
>  > what could be the next steps on this area. Below are couple examples
>  > of what we could do next
>  >
>  > - WS-BPEL Process Introspection : Currently we are requiring SCA
>  > componentType files, we could introspect the BPEL process file to
>  > generate the component type information from it.
>  >
>  > - Integrate BEPL with the store scenario tutorial : We could add a
>  > OrderProcessing step to the store checkout, and illustrate a more real
>  > integration scenario.
>  >
>  > Other then these, we could review the
>  > SCA_ClientAndImplementationModelFor BPEL and identify other areas that
>  > we might need enhancements. Scenarios / Samples / Demos are always
>  > welcome too. Or if you have other suggestions, feel free to jump to
>  > the discussion.
>  >
>  > BTW: Copying the ODE list in case they want to jump and help, or in
>  > case they have other ideas.
>  >
>  >
>  Not a very exciting one but is there any clean up of the dependencies
>  possible? Currently using the implementation.bpel extension brings in 78
>  addition dependency jars at about 20meg, i wondered if some of those could
>  get excluded?
>
>...ant
>

Part of this is because we have a Embedded ODE BPEL engine, and that
itself brings several dependencies. But this is certainly something to
investigate. It would be also good if ODE could be more
flexible/dynamic with some dependencies (e.g Saxon) and only really
require these dependencies if they are going to be in use, this would
help our side as well.

--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

 CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are 
not to copy, disclose, or distribute this e-mail or its contents to any other 
person and any such actions are unlawful. This e-mail may contain viruses. 
Infosys has taken every reasonable precaution to minimize this risk, but is not 
liable for any damage you may sustain as a result of any virus in this e-mail. 
You should carry out your own virus checks before opening the e-mail or 
attachment. Infosys reserves the right to monitor and review the content of all 
messages sent to or from this e-mail address. Messages sent to or from this 
e-mail address may be stored on the Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***

Re: What's next for SCA & BPEL Integration

[Mike Edwards]

Ashwini Kumar Jeksani wrote:

Hi,

Does Tuscany support SCA Extentions to WS-BPEL? If it doesn't then I guess we 
could look into that one as well.

Thanks & Regards
Ashwini Kumar Jeksani


Ashwini,

Which extensions are thinking about?

Currently I am working on code that scans the BPEL process and creates 
the SCA component type.  I am handling the extra @service and @reference 
parameters, but there are other ones to do with multi-refs and with 
properties that I have not looked at.  It is taking time because of the 
referenced WSDL files, which need careful scanning to find the 
partnerLinkType definitions and the associated PortType definitions.


One BIG thing that you could do to help here is to start building some 
testcase BPEL + WSDL files that express these capabilities, that we can 
use to test out the code as we add the function.



Yours,  Mike.

RE: What's next for SCA & BPEL Integration

[Ashwini Kumar Jeksani]

Ok mike. I will try to create the test cases for testing the generation of 
component types from the bpel processes.
Could you tell me if there is any standard format/template that you use in 
Tuscany for writing test cases.

Thanks & Regards
Ashwini Kumar Jeksani


-Original Message-
From: Mike Edwards [mailto:[EMAIL PROTECTED]
Sent: Monday, April 28, 2008 8:41 PM
To: tuscany-dev@ws.apache.org
Subject: Re: What's next for SCA & BPEL Integration

Ashwini Kumar Jeksani wrote:
> Hi,
>
> Does Tuscany support SCA Extentions to WS-BPEL? If it doesn't then I guess we 
> could look into that one as well.
>
> Thanks & Regards
> Ashwini Kumar Jeksani
>
Ashwini,

Which extensions are thinking about?

Currently I am working on code that scans the BPEL process and creates
the SCA component type.  I am handling the extra @service and @reference
parameters, but there are other ones to do with multi-refs and with
properties that I have not looked at.  It is taking time because of the
referenced WSDL files, which need careful scanning to find the
partnerLinkType definitions and the associated PortType definitions.

One BIG thing that you could do to help here is to start building some
testcase BPEL + WSDL files that express these capabilities, that we can
use to test out the code as we add the function.


Yours,  Mike.

 CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are 
not to copy, disclose, or distribute this e-mail or its contents to any other 
person and any such actions are unlawful. This e-mail may contain viruses. 
Infosys has taken every reasonable precaution to minimize this risk, but is not 
liable for any damage you may sustain as a result of any virus in this e-mail. 
You should carry out your own virus checks before opening the e-mail or 
attachment. Infosys reserves the right to monitor and review the content of all 
messages sent to or from this e-mail address. Messages sent to or from this 
e-mail address may be stored on the Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***

Re: What's next for SCA & BPEL Integration

[Jean-Sebastien Delfino]

Mike Edwards wrote:

Ashwini Kumar Jeksani wrote:

Hi,

Does Tuscany support SCA Extentions to WS-BPEL? If it doesn't then I 
guess we could look into that one as well.


Thanks & Regards
Ashwini Kumar Jeksani


Ashwini,

Which extensions are thinking about?

Currently I am working on code that scans the BPEL process and creates 
the SCA component type.  I am handling the extra @service and @reference 
parameters, but there are other ones to do with multi-refs and with 
properties that I have not looked at.  It is taking time because of the 
referenced WSDL files, which need careful scanning to find the 
partnerLinkType definitions and the associated PortType definitions.


One BIG thing that you could do to help here is to start building some 
testcase BPEL + WSDL files that express these capabilities, that we can 
use to test out the code as we add the function.



Yours,  Mike.


Another thing is to split the implementation-bpel in at least two modules:
- implementation-bpel - model, SCDL XML and componentType support
- implementation-bpel-ode - integration with the BPEL runtime

or three modules:
- implementation-bpel - model
- implementation-bpel-xml - SCDL XML support
- implementation-bpel-ode - integration with the BPEL runtime

This will allow SCA development, deployment, and management tools for 
example to use the BPEL implementation model to create, describe, 
deploy, wire BPEL components without dragging a dependency on the whole 
runtime.


We've been through that with other extensions, you can find examples of 
this type of split in implementation-java-*, binding-ws-*, 
binding-atom-*, binding-sca-* etc.


I can help with that work if you need help or have questions.
--
Jean-Sebastien

Re: What's next for SCA & BPEL Integration

[Luciano Resende]

This is great, various good ideas and various volunteers...
I'll raise JIRAs to better track progress with these items.

On Thu, May 1, 2008 at 11:22 AM, Jean-Sebastien Delfino
<[EMAIL PROTECTED]> wrote:
> Mike Edwards wrote:
>>
>> Ashwini Kumar Jeksani wrote:
>>>
>>> Hi,
>>>
>>> Does Tuscany support SCA Extentions to WS-BPEL? If it doesn't then I
>>> guess we could look into that one as well.
>>>
>>> Thanks & Regards
>>> Ashwini Kumar Jeksani
>>>
>> Ashwini,
>>
>> Which extensions are thinking about?
>>
>> Currently I am working on code that scans the BPEL process and creates the
>> SCA component type.  I am handling the extra @service and @reference
>> parameters, but there are other ones to do with multi-refs and with
>> properties that I have not looked at.  It is taking time because of the
>> referenced WSDL files, which need careful scanning to find the
>> partnerLinkType definitions and the associated PortType definitions.
>>
>> One BIG thing that you could do to help here is to start building some
>> testcase BPEL + WSDL files that express these capabilities, that we can use
>> to test out the code as we add the function.
>>
>>
>> Yours,  Mike.
>
> Another thing is to split the implementation-bpel in at least two modules:
> - implementation-bpel - model, SCDL XML and componentType support
> - implementation-bpel-ode - integration with the BPEL runtime
>
> or three modules:
> - implementation-bpel - model
> - implementation-bpel-xml - SCDL XML support
> - implementation-bpel-ode - integration with the BPEL runtime
>
> This will allow SCA development, deployment, and management tools for
> example to use the BPEL implementation model to create, describe, deploy,
> wire BPEL components without dragging a dependency on the whole runtime.
>
> We've been through that with other extensions, you can find examples of this
> type of split in implementation-java-*, binding-ws-*, binding-atom-*,
> binding-sca-* etc.
>
> I can help with that work if you need help or have questions.
> --
> Jean-Sebastien
>



-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: What's next for SCA & BPEL Integration

[Jean-Sebastien Delfino]

Mike Edwards wrote:

Ashwini Kumar Jeksani wrote:

Hi,

Does Tuscany support SCA Extentions to WS-BPEL? If it doesn't then I 
guess we could look into that one as well.


Thanks & Regards
Ashwini Kumar Jeksani


Ashwini,

Which extensions are thinking about?

Currently I am working on code that scans the BPEL process and creates 
the SCA component type.  I am handling the extra @service and @reference 
parameters, but there are other ones to do with multi-refs and with 
properties that I have not looked at.  It is taking time because of the 
referenced WSDL files, which need careful scanning to find the 
partnerLinkType definitions and the associated PortType definitions.


One BIG thing that you could do to help here is to start building some 
testcase BPEL + WSDL files that express these capabilities, that we can 
use to test out the code as we add the function.



Yours,  Mike.


Are you guys still making changes to the BPEL code?

I'd like to be able to work with BPEL components in the domain without 
having to boot the whole runtime. I'd like to do it sometime later this 
week but for that to work I'll need to split implementation-bpel in two 
modules (model and runtime) like we've already done for other 
implementation types.


Is now a good time to do that split or is it going to conflict with the 
changes you've been working on? Any chance you guys can commit your 
changes to avoid complex merging? or should I make the split on the side 
in sandbox to give you more time to work on this and then we merge later?


Thanks
--
Jean-Sebastien

Re: What's next for SCA & BPEL Integration

[Mike Edwards]

Jean-Sebastien Delfino wrote:


Are you guys still making changes to the BPEL code?

I'd like to be able to work with BPEL components in the domain without 
having to boot the whole runtime. I'd like to do it sometime later this 
week but for that to work I'll need to split implementation-bpel in two 
modules (model and runtime) like we've already done for other 
implementation types.


Is now a good time to do that split or is it going to conflict with the 
changes you've been working on? Any chance you guys can commit your 
changes to avoid complex merging? or should I make the split on the side 
in sandbox to give you more time to work on this and then we merge later?


Thanks


Jean-Sebastien,

Yes, I am changing the BPEL code to introspect the BPEL process to create the 
componentType.

It has taken longer than I hoped but I am nearly there now and I hope to commit the changes later 
today.  Please don't start the split work before I do that or you'll trash my work.



Yours,  Mike.

Re: What's next for SCA & BPEL Integration - component type update done

[Mike Edwards]

Jean-Sebastien Delfino wrote:

Are you guys still making changes to the BPEL code?

I'd like to be able to work with BPEL components in the domain without 
having to boot the whole runtime. I'd like to do it sometime later this 
week but for that to work I'll need to split implementation-bpel in two 
modules (model and runtime) like we've already done for other 
implementation types.


Is now a good time to do that split or is it going to conflict with the 
changes you've been working on? Any chance you guys can commit your 
changes to avoid complex merging? or should I make the split on the side 
in sandbox to give you more time to work on this and then we merge later?


Thanks


Jean-Sebastien,

OK, the component type introspection updates are done and committed under 
654282.

You're free to go do the split.


Yours,  Mike.

Re: What's next for SCA & BPEL Integration - component type update done

[Luciano Resende]

Cool Mike, this is very good improvement for the bpel impl...

BTW, could you please check if you have committed one of the new model
classes : BPELPartnerLinkTypeExt

On Wed, May 7, 2008 at 2:19 PM, Mike Edwards
<[EMAIL PROTECTED]> wrote:
> Jean-Sebastien Delfino wrote:
>>
>> Are you guys still making changes to the BPEL code?
>>
>> I'd like to be able to work with BPEL components in the domain without
>> having to boot the whole runtime. I'd like to do it sometime later this week
>> but for that to work I'll need to split implementation-bpel in two modules
>> (model and runtime) like we've already done for other implementation types.
>>
>> Is now a good time to do that split or is it going to conflict with the
>> changes you've been working on? Any chance you guys can commit your changes
>> to avoid complex merging? or should I make the split on the side in sandbox
>> to give you more time to work on this and then we merge later?
>>
>> Thanks
>
> Jean-Sebastien,
>
> OK, the component type introspection updates are done and committed under
> 654282.
>
> You're free to go do the split.
>
>
> Yours,  Mike.
>



-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: What's next for SCA & BPEL Integration - component type update done

[Mike Edwards]

Luciano Resende wrote:

Cool Mike, this is very good improvement for the bpel impl...

BTW, could you please check if you have committed one of the new model
classes : BPELPartnerLinkTypeExt

On Wed, May 7, 2008 at 2:19 PM, Mike Edwards
<[EMAIL PROTECTED]> wrote:

Luciano,

The class BPELPartnerLinkExt is a new part of the interface-wsdl-xml module, which was committed 
under 654287, separately from the changes to the implementation-bpel package.


BPELPartnerLinkExt is a class which handles the  elements which turn up as 
extensions in WSDL documents, separate from the BPEL process documents.


I wrote a BPELExtensionHandler class to deal with reading & writing these elements as part of WSDL 
documents and I have added this extension handler to the WSDLDocumentProcessor class, which does the 
handling of WSDL files.  I thought it was better to keep this stuff in the WSDL processing code - 
there may be other extensions which we may well need to handle in WSDL files and I suspect it is 
best to keep all the extensions in one place so that it is plain for everyone to see the full extent 
of our WSDL handling.


I hope it all works - it could for sure do with some more testcases, especially error cases like 
missing links between particular partnerLinks and the portTypes which define their interfaces.



Yours,  Mike.

Re: What's next for SCA & BPEL Integration - component type update done

[Jean-Sebastien Delfino]

Mike Edwards wrote:

Jean-Sebastien Delfino wrote:

Are you guys still making changes to the BPEL code?

I'd like to be able to work with BPEL components in the domain without 
having to boot the whole runtime. I'd like to do it sometime later 
this week but for that to work I'll need to split implementation-bpel 
in two modules (model and runtime) like we've already done for other 
implementation types.


Is now a good time to do that split or is it going to conflict with 
the changes you've been working on? Any chance you guys can commit 
your changes to avoid complex merging? or should I make the split on 
the side in sandbox to give you more time to work on this and then we 
merge later?


Thanks


Jean-Sebastien,

OK, the component type introspection updates are done and committed 
under 654282.


You're free to go do the split.


Yours,  Mike.


Great, Thanks! I'll go and do it soon.

--
Jean-Sebastien