I have set up an orhcestration that calls a .net component with scope block
that also has exception handler. I don't care about transactions so I set
the transaction type equal to none (on scope block), which required the
component to be flagged with [Serializable] attribute. I was able to
compile, deploy and test successfully.

Later I moved the .net component into a COM+ server application with a
different security identity. I expclitey stamped this component with com+
transactions not supported. The .net component is then deployed into com+
successfully and the assembly is directly bound to orchestration project.
The orchestration now fails with following:

C:\FilePickUP\Logic.odx(347): a non-serializable object type
'QCustom2.CSimulate varCustomComp' can only be declared within an atomic
scope or service

The funny part is that the .net component (though it derives from
ServicedComponent) is already marked with [Serializable] attribute. I st
ill
don't care about transactions.

1) How can I make the orhestration work with .net component deployed in com+
server app without using transactions?

2) I tried creating an interface and have the .net component implement it.
How can I get a way with referecning only the interface assembly? Should I
use Assembly.Load and CreateInstance to create the object?

3) When I referenced both interface and component assemblies (from 2), it
complained that the interface is not serializable. The .net does not allow
marking an interface serialiable. Is there another solution for using
interface?

I also tried implementing ISerialiable interface on the .net component. That
did not help either.

4) Do I need to use atomic transcation type and mark my component with
support transactions attribute? Or Is there a different way?

I looked up Charles Young's blog on transactions that did not help either.

Thanks.
Raghu/..

[ Post a follow-up to this message ]

Raghu,

>I have set up an orhcestration that calls a .net component with scope block
> that also has exception handler. I don't care about transactions so I set
> the transaction type equal to none (on scope block), which required the
> component to be flagged with [Serializable] attribute. I was able to
> compile, deploy and test successfully.
>
> Later I moved the .net component into a COM+ server application with a
> different security identity. I expclitey stamped this component with com+
> transactions not supported. The .net component is then deployed into com+
> successfully and the assembly is directly bound to orchestration project.
> The orchestration now fails with following:
>
> C:\FilePickUP\Logic.odx(347): a non-serializable object type
> 'QCustom2.CSimulate varCustomComp' can only be declared within an atomic
> scope or service
>
> The funny part is that the .net component (though it derives from
> ServicedComponent) is already marked with [Serializable] attribute. I
> still
> don't care about transactions.

ServicedComponent's are never serializable, doesn't matter that you marked
them with the Serializable attribute (they are MarshalByRef objects, which
have different mechanics here).
You will have to put it into a Atomic Transaction scope, since that's the
only thing that can prevent the BizTalk Orchestration engine from
dehydrating the orchestration instance at runtime (which is what requires
serialization).

You could certainly do something like creating a generic .NET class and use
static methods that call the COM+ component underneath, and call that from
the orchestration, though...


--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/

[ Post a follow-up to this message ]

MarshalByRefObject can be serializable it just means that in situations of r
emote access MarshalByRefObject takes precedence over Serializable.

However, it doesn't make send to seralize the state of a SerrvicedComponent 
(or anything involved in a 2-phase commit transacted scenario) as you either
 have to hold the transaction running (and keep database locks) until the ob
ject is deserialized and c
ompletes its work, or the object comes back up with the transaction having b
een ended in some way but the deserialized has no knowledge that this has ha
ppened and may already be in a state where it assumes parts of its processin
g have already occurred.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

ServicedComponent's are never serializable, doesn't matter that you marked
them with the Serializable attribute (they are MarshalByRef objects, which
have different mechanics here).

[ Post a follow-up to this message ]