Hello Olaf I haven't been using ServiceMix for all that long. My knowledge might be marginally (if at all) better than your own, so I think I could offer some enlightenment.
> For me it would be more clear, if servicemix would say: > - this is a servicemix-http component. > You can use it to implement a service unit. > This service unit will be reachable by HTTP. That's about right. I think the HTTP Service Unit (SU) is complete in itself. However, some of the SU implementations actually provide as much customisation as possible to leave a smaller piece of functional code for you to write. I have been having fun with such an SU - servicemix-jsr181 which (theoretically at least) allows one to wrap a POJO of one's choosing inside an SU. It promises ease of development, but that objective has yet to be realised by me. > - on the other hand, there is an adapter, a client. > you can use it to connect to a servicemix-http component I think the servicemix-jsr181 SU I have just described is one example of such a beast as you desire here. Read on for information about how I think this is done. > - the adapter and the servicemix-http component talk with each other > by HTTP Via a Service Assembly (SA), which, I yet again believe, contains the instructions that the NMR needs for message exchange. > - the adapter/client offers an inbox and an outbox I think that depends on the message exchange pattern (MEP) your SU implements. The HTTP SU is complete, and is rather fixed as a request-repsonse MEP, but other adaptors where you have to supply the final bit of custom code (jsr181 for example), you can elect to have either one-way or request-response communication. That's up to you. I think I could be wrong about the HTTP SU, but I hope at least to have illuminated the theory of what is going on. > - write the defined messages into the outbox and it will be uploaded > to the SU > - if something arrived from the SU, i > can read it from the inbox Hmmm... not quite. Say, for instance, you have a simple Service Assembly that manages two service units. One of the SU's acts as an adaptor to whatever internal legacy system you have information on, and the other is an HTTP SU that you expose to the outside world so that one can proxy requests between the internal system and the outside world using this service. > But thats my own picture. And still i can not get rid of it. > I do not find access to your picture, yet! The whole SA, and ServiceMix instance it is deployed on acts as an adaptor to get information from your internal system out as a web service. > To me it seems, i have to write something on my own > to be able to talk with my SU, which just extends/uses servicemix-http. > The servicemix-http component just helps me to talk with this SU, > it is just something like a little webserver? You still need the Service Assembly (SA). > But how i will talk to the SU, what i will talk on top of HTTP, this > will be my own business? > I am not sure, if iam on the right way. Am i close? > Thanks a lot in advance again. :) > Olaf Krische The key you appear to be looking for is the SA. It ties everything together. Additionally, I think you are looking to locate your ServiceMix installation on one host, and have this single host talk over the wire to all your internal systems as though it were the centre of a star network. If this is true, I think there is a better way to go than this. I think it is better to have an instance of ServiceMix on all the machines that host internal systems. You then deploy SA's that get what is on those internal systems out into a web services format. Then, through the magic of federation, you can tie all these services together into what is known as an ESB, and incorporate BPEL and other goodies to your federation. I like the fact that ServiceMix appears to implement only what is necessary (WSDL and SOAP) to give one only what one needs, and no more than that. You might like to host the bulk of your BPEL processing on a web server, but at the moment, I am of the opinion that ServiceMix might also be able to host some BPEL for subroutines that involve co-hosted internal systems, so you can distribute your BPEL for speed and network management too. Anyway, this has given me a chance to rabbit on about what I have in my head regarding an SOA. If anyone has a differing opinion or wants to clarify, or even wants me to clarify, I'd welcome the chance to be corrected, to receive clarification, or to clarify if I can. Have a good day, Owen.
