- Posted by: Krishnan Venkataraman
- Posted on: January 13 2003 15:41 EST
I have a conceptual architectural question...
In a nutshell, we are planning to build a BROKER SERVICE on an organisational level to communicate with a trading system (which has a broker on it's side to cater to client requests and is basically based in C) and will have java and non-java client applications within the organization communicating with this webservice based broker.
Now to architect our broker I am planning to have this as a webservice oriented architecture(message oriented and not RPC)...the idea is to have this webservice layer as an EAI ...assuming that I am going to write this webservice layer on weblogic in java .... how would non-java clients in the organization communicate with the webservice...depending on the WSDL can non-java(eg: C) based clients generate the libraries to talk to the java based webservice...and what would the best way for my webservice based broker to communicate with non-java systems(eg: C)
If people who are building or built such an architecture, I would really appreciate if you can share the architecture.
- Webservice Architecture(broker) for EAI by Steve Watt on January 14 2003 11:05 EST
- Webservice Architecture(broker) for EAI by Doron Sherman on January 15 2003 17:43 EST
- Orchestration by Steve Watt on January 16 2003 11:41 EST
You actual architecture isnt that clear, due to the wording of the description, but If I am reading it right, then this is your design:
[Trading App] <-> [Web Service] <-> [Client: Java/NonJava]
This is a fairly standard Web Service architecture. The clients dont care whats behind your web service they just need to be able to produce and consume your Web Service XML DTD/Schema.
Now, if you are writing all the clients then you can make sure they comply with the Web Service DTD/Schema. As far as libraries for the client go, you dont have to have a Web Service API, an XML parser is just as good to read the XML coming in an out. In some cases, I have even uses string manipulation to get the data I need to process out of the XML Document.
But, you did mention EAI, which may mean that you do not have control of ALL clients that are producing and consuming from your Web Service. i.e. One of your business partners Web Services will be communicating with yours. You cannot always expect them to change their XML DTD/Schema to yours, so you may need to build a Web Service Translation layer for DTD conversion into your architecture. We do this.
Thus the EAI architecture is :
If I have got the wrong end of the stick, feel free to rephrase your question more specifically.
Now to architect our broker I am planning to have this as a webservice oriented architecture(message oriented and not RPC)...the idea is to have this webservice layer as an EAI
Is the interaction with the trading system synchronous or asynchronous? If it's the latter, you are essentially looking at Web service orchestration. There are solutions out there that are likely addressing the problem you are describing on top of a J2EE app server, like WebLogic.
Disclaimer: my company, Collaxa, makes an orchestration server.
Can you go into a bit of depth and tell us what functionality orchestration servers provide and what problems they resolve for us (relating to Web Services ?)
Also, Krish, all the work I've been doing is with a mixture of synchronous and asynchronous web services. Usually, we reply synchronously, that we received data and have persisted it, and then the next response is asynchronous.
Also, something to think about is whether your Trading App is Stateful or Stateless. Stateless is less complex and modelled on the simple stateless HTTP Request/Response idea.
With Stateful, I believe you can use ebXML X.790 DTD/Protocol, which specifies Transaction ID, Message ID and Process ID within the DTD. You can then use these ID's when recieving data and tie them to your session state. I guess, this would mean figuring out how to associate ID's with session data in your trading app.
Note: I am only on my first ebXML project, so any constructive criticism or direction on the above comments would be appreciated.
Hope that helps
Can you go into a bit of depth and tell us what functionality orchestration servers provide and what problems they resolve for us (relating to Web Services?)
Application development projects often include the need to integrate existing functionality, such as legacy and services. This normally dictates that the Java developer has to deal with asynchronous interactions and "business flow" within his/her application. Doing that entails XML messaging, exception handling, manual tasks (human intervention) and transaction management (loosely coupled).
An orchestration server is a light weight engine, often implemented on top of J2EE, that provides the infrastructure facilities necessary for carrying out the above requirements, while providing the developer with a productive and flexible abstraction to program orchestration logic.
Most recently, orchestration servers are shifting to support the BPEL4WS standard. You may find more in-depth content here
Thanks for the info. I enjoyed your article on Web Services Journal.
Thanks, Steve. It's nice to know at least one person read it :)
Tanx for ur inputs....
Sorry for the delay guys..have been out for the last week..
I guess we went a bit offtrack from my original question..
Lemme get pictorial...
The problem statement is
MY_ORGANIZATION(many applications) <----C API--> EXTERNAL_SYSTEM_BROKER<->EXTERNALSYSTEM APP
This is what I am thinking to be the architecture on a very high level
MY_ORGANIZATION(many applications) <-SOAP/XML--MESSAGEBASED AND RPC>MY_ORGANIZATION_WEBSERVICE_BROKER<-JNI/IIOP->EXTERNAL_SYSTEM_BROKER<->EXTERNALSYSTEM APP
So MY_ORGANIZATION(any of the applications)just needs to communicate to the MY_ORGANIZATION_WEBSERVICE_BROKER via SOAP/XML and MY_ORGANIZATION_WEBSERVICE_BROKER would talk to the TradingSystemBroker's C-API probably using IIOP.
Now my question is I know how java applications in my organization can talk to MY_ORGANIZATION_WEBSERVICE_BROKER(through WSDL and proxy objects which gets created)...but how would a C application(within my organization) talk to MY_ORGANIZATION_WEBSERVICE_BROKER . How does a non-java client interpret a WSDL and talk to a webservice...?
Next question is ..if I am exposing a stateles bean as a webservice inside the MY_ORGANIZATION_WEBSERVICE_BROKER...what would would be a good protocol to talk from this MY_ORGANIZATION_WEBSERVICE_BROKER to the trading-systems C API..I am thinking IIOP..But I could be wrong...or is JNI better ?
I am thinkin MY_ORGANIZATION_WEBSERVICE_BROKER to cater to both syncronous and asyncronous so that incase there are updates being pushed from the trading system , the MY_ORGANIZATION_WEBSERVICE_BROKER can push it to MY_ORGANIZATION's applications registered with the MY_ORGANIZATION_WEBSERVICE_BROKER to get updates...