can anyone explain what is Service Data Object(SDO) and Service Message Object(SMO)?
Questions:
1. what is the purpose of SDO and SMO?
2.how it works?
These concepts aren’t used with Mule, they seem to come from IBM. https://www.ibm.com/support/knowledgecenter/SSFTN5_8.5.7/com.ibm.wbpm.main.doc/topics/cwesb_sca_smo2.html
The equivalent of the SMO in Mule is the Mule Event which you can read about here: https://docs.mulesoft.com/mule-runtime/4.1/about-mule-event
A Mule event contains the core information processed by the runtime. It travels through components inside your Mule app following the configured application logic.
It’s basically an abstraction layer so you don’t have to deal with different protocols and transports.
A Mule Event is composed of these objects:
A Mule Message contains a message payload and its associated attributes.
Variables are Mule event metadata that you use in your flow.
A Http POST for example would be represented as an event.
The event payload would be the body data of the http request
Where as the http headers such as content-type would be attributes on the event.
Same for JMS. The message body would be the payload and the jms header would be attributes.
As for SDO, each SMO has an SDO. This is very specific to that IBM article and not relevant in Mule. But from what I understand it basically allows you to access your heterogenous business data in a common way. I guess Dataweave in Mule accomplishes this as Dataweave is the transformation and expression language in Mule, it allows you to query and transform data in the same way regardless of the data type, xml, Json, CSV and so on.
Related
I just need to ask a question about the type of data in mule message?
is it a java object determined by the message source and processors OR a java object implementing the collection interface?
I dont understand your question. Is related to : mule message structure?
The Mule message is the data that passes through an application via one or more flows. It consists of two main parts:
message header which contains metadata about the message
message payload which contains your business-specific data.
Here official documentation:
https://docs.mulesoft.com/mule-fundamentals/v/3.7/mule-message-structure
We purchased an Enterprise Mule license in May, and I have also bought and read your Mule in Action at Manning.com. I read Enterprise Integration Patterns, and I have used Mule doc extensively -- I cannot seem to find a comprehensive list of what endpoints produce what kind of data types, or what properties are available for that specific message at any one stage of a flow.
Example: I used a JDBC endpoint to read from a mySQL database and received back a list of maps. Yet i don't see a Mule object to process this list of maps, so i had to write a component in Java to process it and return the columns i wanted from the result set.
I stumbled in the dark thru this whole process, and I am not a rookie in Java EE; I have been using Java and WebSphere off and on for 10 years.
I had read the Mule and MVEL docs and all I see are the Mule object/context names, but no more about when and how they will be available or what data format they will return in.
Is there a comprehensive list of what endpoints (or any other Mule object(s)) produce what kind of data types and also what properties are available for that specific message at any one stage of a flow?
Unfortunately, the Mule reference guide still lacks a formal definition of the generated payload types and supported properties (inbound end endpoint). MuleSoft is aware of the lack and has started to document the latter, as you can see for the HTTP transport.
For now your best bet is to use visual breakpoints in Studio or <logger> elements to introspect the message characteristics.
I am still confused when it is appropriate to use the Message type in WCF like below
[ServiceContract]
public interface IMyService
{
[OperationContract]
Message GetData();
[OperationContract]
void PutData(Message m);
}
Why would you want to use it?
Can you use it for streaming?
Thanks
MSDN lists the follow reasons for using the message class directly:
When you need an alternative way of creating outgoing message contents (for example, creating a message directly from a file on disk) instead of serializing .NET Framework objects.
When you need an alternative way of using incoming message contents (for example, when you want to apply an XSLT transformation to the raw XML contents) instead of deserializing into .NET Framework objects.
When you need to deal with messages in a general way regardless of message contents (for example, when routing or forwarding messages when building a router, load-balancer, or a publish-subscribe system).
See Using the Message Class for more detailed information.
Edit to address the streaming question
I didn't find a definitive answer in my quick scan via google, but the article above states "All communication between clients and services ultimately results in Message instances being sent and received" - so I would assume it could be used directly in streaming.
While the reasons listed by Tim are valid, we use messages directly in our services to create one uber routing service.
we have one service that can take any method call you throw at it, Clients are generated by wsdls supplied from multiple sources.
This service would take the message, examine its content and route it accordingly.
So in my opinion if you want to get closer to the wire, or when you dont know the type of incoming messages, you can use the message in the signature directly.
Streaming is a separate concept than message signature, streaming is supported by wcf under very specific bindings and security mechanism and the method signature has to be very specific (i.e it should return/accept stream). Also in streaming the actual stream of data travels outside the scope of soap message.
I have system A which produces an xml-file and system B which takes the file. How can I implement this exchange using Biztalk with WCF?
You have two possible different solutions as I see it and it basically comes down to how typed you WCF service needs to be.
Do you need to transform you message into a new format? Or are you planning to use other features in BizTalk as content based routing etc? Are you at all interested in the content of the message while in BizTalk are you OK with just passing it thru?
If you are looking for a solution with the capabilities as described above you'll need to get the schema for the XML message you want to receive into WCF service and publish that service. Once the message is in BizTalk it's then typed and you can do what ever with it using BizTalk.
If you however just want to pass it thru you could just publish a service that received as message of type XML document and pass that thru. Here's a good post describing the a few different techniques to create a generic service accepting any XML as input.
I'm looking to use the MsmqIntegrationBinding to integrate with a legacy queue which has a serialized object as the message body. Has anyone come up with a way to obtain the "metadata" of the message body and create a service side class to use within the service?
For example, if I put in a serialized Product object from System A and my service needs to consume it, how do I provide MsmqMessage the type if I do not have the Product class on my side? I was thinking of reading off a message in a separate program, deserializing, and then emitting via the code dom. Ideas?
I wholeheartedly recommend against attempting to emit the deserialized type at runtime in the message destination. Either work with the XML at the destination to obtain the data you desire, or build data contracts that both the source and destination can adhere to.
Hmm... in WCF, you can define service methods which take (and optionally return) an untyped Message type. This seems to fit your bill quite nicely.
Other than with strongly typed messages, you'll have to do all the putting together of the message on the client and the taking apart on the server by means of reading the raw XML - but that seems to be what you're looking for, right?
Find more information and samples here:
WCF - Handling Generic Messages
How to pass a generic object through WCF
Untyped messages on WCF
Untyped messages have some restrictions, e.g. you can only read them once on the server, but you should be able to manage your scenario with this, I think.
Marc