Phprpc SOA from dream to reality
SOA is a programming idea, which has already appeared in ancient times (computer history). It is the decomposition of the system, the data and business logic part as far as possible independent, and then serve as a service to other systems to share.
There are also some tools that can implement SOA, such as DCOM, CORBA, but the former is limited to Windows, the latter is too complex, but also only for C + +, Delphi, Java and other languages have better support, but also are commercial development software will be included, Support is poor or even unsupported for open-source scripting languages (because it's too complex to be implemented by anyone, and it takes a lot of patience to read the entire CORBA specification, and it doesn't have to be fully understood). After the internet developed, Xml-rpc appeared, Xml-rpc is very simple, but also too simple (because it is just a SOAP experimental prototype only), simple data can be transmitted, complex point of No way, so later developed into the name of SOAP is simple and practical but very complex monster, although SOAP is complicated enough, but it just defines the data format, and then it has a bunch of WS-* additions. This becomes the same as CORBA, no one can understand, what people can achieve, or in addition to large companies and large organizations have this ability, other people basically do not have the ability to intervene. Then people suddenly want to find the treasure, found a few years ago was brought out of rest, so a bunch of called rest services appear again, this thing looks simple, but in fact, the data conversion, transmission and so on the problem are all thrown to the user to solve their own. Finally, the rest godfather denies these services, which are called rest. In addition to these, there are, of course, other options, such as Hessian, ICE, Adobe's AMF3-based communication program, and so on, which cannot be said to be good technology, but not confined to a certain number of languages, or confined to a specific application scope. So there's a need for SOA to be transformed between these different protocols and solutions, and that's when the ESB comes out and it looks good and powerful. But can it really solve the problem? Are you really not making new problems? Of course it solves a certain problem, but it also creates more new problems. It is very good to be able to switch between various technologies, but it is a very difficult thing to master one of these very complicated techniques, but also to learn several kinds of things, which is the challenge! Another problem is that these protocols are inherently slow to kill (for example, SOAP-based Web Service), and the process of adding a transformation is more efficient. So, the ESB finally becomes "Oh, idiot"! SOA has become something that sounds beautiful and hard to do.
But actually we're going to go back and think about what we want SOA to accomplish. is not to decompose the system, and then the heterogeneous reorganization? The final question is so simple that what we need is not necessarily a SOAP-based Web Service, not necessarily an ESB that transforms various protocols. What we need is a technology that can effectively exchange data between heterogeneous systems, so that we can already build SOA systems. Other technology I dare not say, at least for the moment Phprpc did this, you can easily exchange data between Java,. NET, and the open source scripting languages of PHP, Ruby, Python, Perl, and you can use delphi/ BCB to do the Windows interface of the front desk, you can also use JavaScript to do the Web front desk, you can also use flash/flex/ria/wpf/silverlight these to do a richer foreground, and all these front desk can share the same backstage, There is no need to care about what language the backstage is used to achieve. Even the J2ME,. NET CF, Flash Lite, and Mobile browser JavaScript on your phone can be perfectly supported. With the PHPRPC, you suddenly have so many choices, even with the development of PHPRPC, you will have more choices, SOA from now on is no longer unreachable dream.
98/F kimmking 2009-03-05
Mathgl wrote
Do not know how serialization of complex objects
Hessian for the
Class XX
{
IList xx
}
The inside of the XXX is mapped to HashMap. Become IList This is tricky to handle in some languages. I wonder whether phprpc can solve this problem.
Even the RPCFX is serialized into array for list collection,
Then add an actual type of label ~
Don't know Phprpc how to deal with ~
99/F Andot 2009-03-05
Mathgl wrote
Do not know how serialization of complex objects
Hessian for the
Class XX
{
IList xx
}
The inside of the XXX is mapped to HashMap. Become IList This is tricky to handle in some languages. I wonder whether phprpc can solve this problem.
This is C #, right? C # generics are better than Java and can get to the actual type of XXX, so when deserializing, restore exactly the type you declared.
100/F Mathgl 2009-03-05
Andot wrote
Mathgl wrote
Do not know how serialization of complex objects
Hessian for the
Class XX
{
IList xx
}
The inside of the XXX is mapped to HashMap. Become IList This is tricky to handle in some languages. I wonder whether phprpc can solve this problem.
This is C #, right? C # generics are better than Java and can get to the actual type of XXX, so when deserializing, restore exactly the type you declared.
Mistake is List I tried Hessian even if the server and client are Java lists Or will it be mapped to a list
I don't know what PHPRPC has improved on this. After all, hashmap performance is not good.
101/F CHENJIANJX 2009-03-05
The first paragraph of the landlord's words is very good, concise and vivid
I'm interested in lightweight remote calls. Want to ask the landlord, put aside the performance problem, Phprpc and XML-RPC and Hession/burlap compared to the main features of what are the advantages?
102/F Icewubin 2009-03-05
Kimmking wrote
Mathgl wrote
Do not know how serialization of complex objects
Hessian for the
Class XX
{
IList xx
}
The inside of the XXX is mapped to HashMap. Become IList This is tricky to handle in some languages. I wonder whether phprpc can solve this problem.
Even the RPCFX is serialized into array for list collection,
Then add an actual type of label ~
Don't know Phprpc how to deal with ~
Because Java is a erased generic, the runtime absolutely does not get the definition xxx type of the generic type.
But the question is, can you get the class type of each element by reflecting the GetClass method?
103/F Andot 2009-03-05
Mathgl wrote
Andot wrote
Mathgl wrote
Do not know how serialization of complex objects
Hessian for the
Class XX
{
IList xx
}
The inside of the XXX is mapped to HashMap. Become IList This is tricky to handle in some languages. I wonder whether phprpc can solve this problem.
This is C #, right? C # generics are better than Java and can get to the actual type of XXX, so when deserializing, restore exactly the type you declared.
Mistake is List I tried Hessian even if the server and client are Java lists Or will it be mapped to a list
I don't know what PHPRPC has improved on this. After all, hashmap performance is not good.
That seems to be Java, Java generics are not as good as C # (no run-time type information). Therefore, only XXX is a custom class that can be handled correctly. If the other is a container, it should be Assocarray, other basic types do not use this generic container way, directly with the array to correctly transform.
104/F Mathgl 2009-03-05
Icewubin wrote
Kimmking wrote
Mathgl wrote
Do not know how serialization of complex objects
Hessian for the
Class XX
{
IList xx
}
The inside of the XXX is mapped to HashMap. Become IList This is tricky to handle in some languages. I wonder whether phprpc can solve this problem.
Even the RPCFX is serialized into array for list collection,
Then add an actual type of label ~
Don't know Phprpc how to deal with ~
Because Java is a erased generic, the runtime absolutely does not get the definition xxx type of the generic type.
But the question is, can you get the class type of each element by reflecting the GetClass method?
Hmmm ..... C + +/CLI for the previous project client. The display type over there is hashtable. Try the Phprpc effect in the evening.
105/F Icewubin 2009-03-05
Mathgl wrote
Icewubin wrote
Kimmking wrote
Mathgl wrote
Do not know how serialization of complex objects
Hessian for the
Class XX
{
IList xx
}
The inside of the XXX is mapped to HashMap. Become IList This is tricky to handle in some languages. I wonder whether phprpc can solve this problem.
Even the RPCFX is serialized into array for list collection,
Then add an actual type of label ~
Don't know Phprpc how to deal with ~
Because Java is a erased generic, the runtime absolutely does not get the definition xxx type of the generic type.
But the question is, can you get the class type of each element by reflecting the GetClass method?
Hmmm ..... C + +/CLI for the previous project client. The display type over there is hashtable. Try the Phprpc effect in the evening.
The runtime, I say, refers to the runtime of the serializer (Java side), not the run time of the RPC client.
106/F raymond2006k 2009-03-09
The landlord's analysis is very reasonable. Due to the inherent concept and customary usage of binding with Soap,webservice, SOA,ESB and so on do become relatively slow, the implementation effect is difficult to satisfy the customer
It is up to the underlying protocol to get SOA out of the way and really go back to the thinking of service and service integration.
107/F Yangyi 2009-05-06
raymond2006k wrote
The landlord's analysis is very reasonable. Due to the inherent concept and customary usage of binding with Soap,webservice, SOA,ESB and so on do become relatively slow, the implementation effect is difficult to satisfy the customer
It is up to the underlying protocol to get SOA out of the way and really go back to the thinking of service and service integration.
The three issues of SOA are not addressed in this framework:
1) How to change a Java,spring,bpel to this protocol very quickly by configuration?
2) How do you use this protocol to access a service written by someone else with JMS,WS?
3) How the framework above this protocol forms a process for the components that meet the relevant communication protocols
108/F RELOAD_CN 2009-05-07
Yangyi wrote
raymond2006k wrote
The landlord's analysis is very reasonable. Due to the inherent concept and customary usage of binding with Soap,webservice, SOA,ESB and so on do become relatively slow, the implementation effect is difficult to satisfy the customer
It is up to the underlying protocol to get SOA out of the way and really go back to the thinking of service and service integration.
The three issues of SOA are not addressed in this framework:
1) How to change a Java,spring,bpel to this protocol very quickly by configuration?
2) How do you use this protocol to access a service written by someone else with JMS,WS?
3) How the framework above this protocol forms a process for the components that meet the relevant communication protocols
I'm trying to answer that.
1: Write code. That's what PHPRPC does.
2: Write the code. Since PHPRPC can support multiple languages, you write Java code to remove the JMS chant, ws whatever you want, in what language not
3: Still write code.
1) Define a "process service" like workflow or BEPL to package and this component (if you write in Java, I recommend you use JBPM, if it is multi-lingual, then you'd better expose the WS interface and then use BPEL encapsulation), and then write code in the PHPRPC to tune this "process service "It's OK."
2) directly with Phprpc a tune, and then write their own process logic can not do it.
Haha, nonsense, don't take it seriously.
109/F Lottons 2009-06-02
Look at this post from beginning to end, really long ah. But I have learned a lot, and I know many things. I think Phprpc still has a promising future, although I haven't tried it yet (try it out tonight). What SOA is not SOA, the theory of such things, has never been born to fool people. Like the Java EE specification, these things. My point of view has always been that as long as it is able to solve the actual problem is a good thing, what he is what theory, what norms. But then again, good things need theoretical support. But now the business of the Society, the theory has gone sour. IBM should be said to be the provider of SOA theory, and IBM is in the guise of SOA.
In addition, I remember seeing someone think of Tibico as a message queue, I don't know if I have actually used Tibico, in fact Tibico is an intermediate fusion agent. Above the so-called system data heterogeneous conversion, can be used tibico such things to do. Tibico is able to do data conversion and mapping, I think in SOA such a "false, big, empty" theory system of the most useful part should be tibico such things (IBM also has as if it is called interface Change Server referred to as ICS) with this thing, The integration of the A1 system at the outset is no problem. For example, if A1 is using WS, if it is to be fused, it can be easily fused with Tibico to develop a responsive adapter, tibico such things should be said to block the protocol.
Also, the landlord really does not need to PHPRPC and SOA relationship, what is the purpose of PHPRPC? I don't think it's for SOA,PHPRPC to have its own unique application scenario.
Also, I think the future development of PHPRPC should be gradually shifted to ease of use, convenience, simplicity. Performance I think is strong enough, not necessarily as the main purpose. Look at the soap at the beginning it was designed to be easy to use, with XML messages that everyone can read and use.
Landlord still need to consider how the definition of the service can be unified description, similar to the WSDL definition. After all, it is necessary to do the service integration, and it is very useful.
Said a bunch of nonsense, their own views do not know right, welcome to shoot Bricks!
110/F yuzhongzhu110 2009-07-13
I am a beginner of SOA, thank the landlord of the introduction afternoon study to see
111/F Whatwhat 2009-07-13
You're a little big on the subject.
SOA has become a reality,
The question now is, can we make this reality better?
PHPRPC Cross-language? It's just that you're constantly supporting more languages.
It seems to me that Phprpc is more like an RPC framework
112/F Icewubin 2009-07-23
Yangyi wrote
raymond2006k wrote
The landlord's analysis is very reasonable. Due to the inherent concept and customary usage of binding with Soap,webservice, SOA,ESB and so on do become relatively slow, the implementation effect is difficult to satisfy the customer
It is up to the underlying protocol to get SOA out of the way and really go back to the thinking of service and service integration.
The three issues of SOA are not addressed in this framework:
1) How to change a Java,spring,bpel to this protocol very quickly by configuration?
2) How do you use this protocol to access a service written by someone else with JMS,WS?
3) How the framework above this protocol forms a process for the components that meet the relevant communication protocols
JMS is asynchronous, and WS can be put together to say? The concepts and application scenarios vary greatly.
113/F Grdje 2009-07-23
Icewubin wrote
Yangyi wrote
raymond2006k wrote
The landlord's analysis is very reasonable. Due to the inherent concept and customary usage of binding with Soap,webservice, SOA,ESB and so on do become relatively slow, the implementation effect is difficult to satisfy the customer
It is up to the underlying protocol to get SOA out of the way and really go back to the thinking of service and service integration.
The three issues of SOA are not addressed in this framework:
1) How to change a Java,spring,bpel to this protocol very quickly by configuration?
2) How do you use this protocol to access a service written by someone else with JMS,WS?
3) How the framework above this protocol forms a process for the components that meet the relevant communication protocols
JMS is asynchronous, and WS can be put together to say? The concepts and application scenarios vary greatly.
How can not put together to say .... You're the only one who's ever seen a big commercial product.
For example, SAP's PI supports this scenario.
114/F Icewubin 2009-07-24
Grdje wrote
Icewubin wrote
Yangyi wrote
raymond2006k wrote
The landlord's analysis is very reasonable. Due to the inherent concept and customary usage of binding with Soap,webservice, SOA,ESB and so on do become relatively slow, the implementation effect is difficult to satisfy the customer
It is up to the underlying protocol to get SOA out of the way and really go back to the thinking of service and service integration.
The three issues of SOA are not addressed in this framework:
1) How to change a Java,spring,bpel to this protocol very quickly by configuration?
2) How do you use this protocol to access a service written by someone else with JMS,WS?
3) How the framework above this protocol forms a process for the components that meet the relevant communication protocols
JMS is asynchronous, and WS can be put together to say? The concepts and application scenarios vary greatly.
How can not put together to say .... You're the only one who's ever seen a big commercial product.
For example, SAP's PI supports this scenario.
Please contact the context to see the stickers, do not're same page.
I mean: PHPRPC is not asynchronous, and JMS what is like, is compared with soap (Web Service).
115/F Yearbaw 2009-09-06
Unsid wrote
I certainly understand that communication protocols are not language-independent, but I am talking about a very real problem, if the whole system is done by you or your team, OK, no problem, but if the A1 product is involved, then "communication protocol and language-independent" cause you can only achieve and A1 excuses, but A1 is not open, The service side needs to know many A1 to realize the detail is impossible ...
I have a similar dilemma now. In another masterpiece of the landlord, I also consulted. Phprpc if can promote, we all benefit, hehe.
116/F Thebye85 2009-11-02
Andot wrote
Fansofjava wrote
Ask, in Java, if the server returns an object list, why can't I read the data in the list?
Such as:
List
list = new ArrayList
(), List.add ("Dfsfsdf"), List.add ("GGWERTEWR"); List.add (" 1234GGWERTEWR "); user.setlist (list);p Hprpc_server.add (" getList ", user);
When data is being taken from the client,
List List = User.getlist ();
The data is indeed within the list and can be list.size () to know the size of the list, but when accessing the string data in the list, it is always reported java.lang.ClassCastException: [B ...
Excuse me, what is the reason for this?
I personally think that it should be the client does not know what type of the list data returned by the server (even if the list server is passed a string list, the forced transformation will also be wrong), it should be directly in the form of a byte array,
So I'm going to get a list of strings, is not going to pass every byte array into a string yo, if this is true, then a custom object list
It wouldn't be very troublesome.
Your judgment is very correct, and it is true that the string is returned in the form of byte[. String and character arrays are represented as byte arrays in cases where the string type cannot be explicitly learned.
Java generics are just a syntactic sugar, so its generic element type cannot be obtained by reflection (this is completely different from the. NET generics), so Java's generic element type is not properly received if it is set to the base type (including string) and container type. Only custom type objects can be accepted with generic containers, because custom type objects are serialized with accurate type information.
However, to this type, you can receive it in the client by declaring it as string[], as this will get the element type and automatically make the correct conversion. Otherwise, you can only receive it with a non-generic interface (such as list) or a non-generic class (such as ArrayList), and after receiving it, you need to use the Org.phprpc.util.Cast.cast method for the type conversion for the element.
I also encountered this situation during the test, the author can solve it? Otherwise the conversion is troublesome.
117/F Andot 2009-11-02
Thebye85 wrote
Andot wrote
Fansofjava wrote
Ask, in Java, if the server returns an object list, why can't I read the data in the list?
Such as:
List
list = new ArrayList
(), List.add ("Dfsfsdf"), List.add ("GGWERTEWR"); List.add (" 1234GGWERTEWR "); user.setlist (list);p Hprpc_server.add (" getList ", user);
When data is being taken from the client,
List List = User.getlist ();
The data is indeed within the list and can be list.size () to know the size of the list, but when accessing the string data in the list, it is always reported java.lang.ClassCastException: [B ...
Excuse me, what is the reason for this?
I personally think that it should be the client does not know what type of the list data returned by the server (even if the list server is passed a string list, the forced transformation will also be wrong), it should be directly in the form of a byte array,
So I'm going to get a list of strings, is not going to pass every byte array into a string yo, if this is true, then a custom object list
It wouldn't be very troublesome.
Your judgment is very correct, and it is true that the string is returned in the form of byte[. String and character arrays are represented as byte arrays in cases where the string type cannot be explicitly learned.
Java generics are just a syntactic sugar, so its generic element type cannot be obtained by reflection (this is completely different from the. NET generics), so Java's generic element type is not properly received if it is set to the base type (including string) and container type. Only custom type objects can be accepted with generic containers, because custom type objects are serialized with accurate type information.
However, to this type, you can receive it in the client by declaring it as string[], as this will get the element type and automatically make the correct conversion. Otherwise, you can only receive it with a non-generic interface (such as list) or a non-generic class (such as ArrayList), and after receiving it, you need to use the Org.phprpc.util.Cast.cast method for the type conversion for the element.
I also encountered this situation during the test, the author can solve it? Otherwise the conversion is troublesome.
The problem arises because the serialization format used by PHPRPC does not differentiate between binary strings and Unicode strings, so this is a mishap in PHPRPC and cannot be modified. But the good news is that in our commercial open source software Hprose, this mishap is solved, and is completely resolved, all types do not need to do type conversion (even org.phprpc.util.Cast such a helper class does not exist, because it is completely unnecessary). Hprose also has a significant improvement in performance, the efficiency is more than 10 times the PHPRPC, there is also a greater ease of use, if you are interested, you can test it.
