By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
1)E-mail Client: Client invokes a Web service, gets a response over SMTP in the form of e-mail. Client replies to that message using a normal e-mail client[say, Outlook Express]. That e-mail message goes to the destination, where it results in invokation of the Web service.
2)Mobile Client: Client invokes a Web service by sending SMS, gets a response over WAP in the form of SMS. Client replies to that message using SMS. That SMS goes to the destination, where it results in invokation of the Web service.
How do I go about it? Are there tools, guidelines, tutorials, code samples, case studies?
SMTP may be used to transport SOAP messages, but in many ways, the transport mechanism is a different issue from the synchronicity of the Web service. In other words, you can implement synchronous Web services with asynchronous transports (such as SMTP and JMS), and you can implement asynchronous Web services with synchronous transports (such as HTTP). This is one of the beautiful features of SOAP. It provides a layer of abstraction between your programming model and the communication protocol.
In both of your cases, though, the client application (the e-mail client or the mobile client) is not a Web service client. When a SOAP engine uses SMTP to transport messages, the SOAP engine acts as the e-mail client. It is responsible for packaging a SOAP request into an e-mail message and sending the message to the SMTP server for delivery. On the other end, another SOAP engine is responsible for receiving the e-mail message, extracting the SOAP message, and invoking the appropriate service. During the response processing, the remote SOAP engine packages the response SOAP message into an e-mail and sends it to the SMTP server, and then the local SOAP engine receives the e-mail, extracts the SOAP message, and returns the response to the calling application. In normal SOAP processing, the client and service applications don't ever interact via e-mail. They communicate using SOAP.
One thing I want to point out is that SOAP is all about application-to-application communication. In your two scenarios you're trying to perform human-to-application communication. In both of these scenarios, your clients must connect to the SOAP environment though some type of client "gateway". Let's look at the two scenarios:
1) If I understand you correctly, you want to do the following:
a) A client application invokes a Web service. (you don't indicate what mechanism it uses, so I'll assume HTTP using a one-way message, although it really doesn't matter -- the point is that it's an application program issuing a standard SOAP request.)
b) When the Web service completes it's processing, it sends an e-mail with the results of its processing to an e-mail address (which may be predefined, or perhaps it was specified as a parameter in the SOAP request message).
c) A human user retrieves the e-mail using a standard e-mail client (such as Outlook Express). That human replies to the message. (This is the tricky part, because the human will need to ensure that the e-mail reply message is formatted properly -- similar to the way list server e-mail processing requires strictly formatted e-mail messages.)
d) An application picks up the e-mail reply message, extracts the information it needs from the formatted reply message, and invokes another Web service (again, this could be done via HTTP, although it really doesn't matter).
Click here to read part two of this answer.
Dig Deeper on Simple Object Access Protocol (SOAP)
Related Q&A from Anne Thomas Manes
Anne Thomas Manes explains the differences between open source clients and open source implementations.continue reading
Anne Thomas Manes discusses the best way to go about creating an enterprise data dictionary and why the systems works well.continue reading
Anne Thomas Manes explains the difference between 'hard' real time and 'live' real time systems.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.