I think that this is a task that would be common enough to have a streamlined framework for its implementation.
But for the past few days I have been going through articles on WCF service that go down to a fundamental and detailed level.
Am i missing something here or do I have to go through a bunch of configuration files and multiple projects to implement this seemingly simple task?
Related
Is it even possible more or less natively consume WCF service from Go application?
I can imagine it should be possible to execute SOAP calls in Go, but WCF is a bit more than that only, for example authorization will probably be a problem also...
Have anyone at least approached this area, or maybe someone can give useful me advice in this "wheel reinvention task"?
Thank you in advance for all your input, ideas and suggestions.
I think you should expose a RESTful Service. I myself have the problem with exposing a WCF Service too many clients using PHP, Go, Ruby and all kind of languages. We never ever got it right, to automatically generate a proxy.
The maybe simplest way is to use WCF, like described in this example:
https://www.codeproject.com/Articles/105273/Create-RESTful-WCF-Service-API-Step-
By-Step-Guide
But I recommend to switch to ASP.NET Core (Migration is not that hard) or if you have the budget I would consider https://servicestack.net/
It may be well beyond the wait time for this. However, here is something really interesting that could help. The situation the authors found themselves is relevant even today in some organizations.
https://github.com/khoad/msbingo
Here's the motivation provided by the authors:
Application/soap+msbin1 encoding was a blocking issue for modernizing services from WCF to platform-agnostic technologies such as Go. We needed to be able to make calls to dependency services that spoke msbin1 and were not going to be updated or even reconfigured, but we did not want to introduce unnecessary complexity such as workarounds like .NET-based WCF request translator proxies or deploying Mono with our service instances. Initially we tried the Mono deployment route, which, while it would have worked well enough, significantly complicated our deployment pipeline, thus erasing one of the major advantages of golang.
I found it a useful starting point to begin experimentation.
I have been looking for a good example of WCF and NHibernate facilities working together, (one session per web request, etc) but all the tutorials i find are dated 2009 and older. I am afraid i may lose my time trying to implement all this when there are probably better ways to achieve this.
The other thing i noticed is that Rhino.Commons.NHRepository was popular three years ago, but i can't find anything related to this assembly more recent than that. Any reason for this?
Anyone can point me on good examples on how to implement WCF and NHibernate using facilities?
NHRepository? RIP?
Thanks
It seems to be dead. I would suggest you to use one of popular IoC containers to manage lifetime of session and session factory. Almost all modern containers have integration with WCF including per request lifetime.
We are developing a LOB application using Silverlight and several team members are advocating the use of the canonical design pattern instead of creating simple WCF services. As the lead, I’m trying to balance best practices with an incredibly tight time line.
Here are the reasons I do NOT think Canonical is a good approach for our project.
We have no immediate (<5 years) requirement to expose any internal services to the enterprise.
Time required for governance. (Developing adapters with data transformation logic, developing XSDs, and developing contracts [fault, data, and operation]).
No need to expose a different data contracts than what exists in the data layer
It doesn’t appear that we can easily use ‘self tracking entities’ with the Canonical approach.
Here are some reasons I’m considering using Canonical approach.
We can use the XSD schemas for data type and length validation.
We will be prepared to allow consumption of our services to the enterprise, whether it’s 5 years or 1 year.
We can feel good that we’re implementing best practices. :)
So, is it advisable to follow the Canonical approach with a Silverlight application? It does not seem that the benefits Canonical provide out weigh the additional work. …or perhaps I’m wrong and it’s not additional work.
I think you should definitely go with WCF RIA services. It's extensible in every point possible, it's fast to develop, it's accessible as regular WCF services, it also has plenty different available end point types, and generally very mature. And implements best practices, and validation process is fully customizable. It really is a no brainer, if you have some additional questions about it shoot away, i'll gladly answer them:)
I've seen recommendations (Juval Lowy, et al) that a service contract should have "no more than 20 members...twelve is probably the practical limit". Why? It seems that if you wish to provide a service as the interface to a relatively large db (50-100 tables) you're going to go way past that in just CRUD alone. I've worked with plenty of other services that provided hundreds of 'OperationContracts'...is there something peculiar about WCF? Is there something I'm missing here?
probably the fact that you should not expose CRUD in the SOA world.... the idea is to expose business processes. Inidividual CRUD operations lead to a TERIIBLY slow and granular interface. Look more how RIA Services / ASTORIA do the CRUD thing.
I don tthink this is a technical limit. the idea is a service defines all contracts necessary for a business operation (order management, account management) and should not be TOO complicated.
I think it's related to the principles of SOA. Many people would regard a service with hundreds of OperationContracts as a poorly designed service, even if technically correct.
You should not simply expose a web interface for a bunch of tables. Rather, the services should expose abstract operations (probably mapped to business processes) that interact with those tables under the hood.
I've seen similar recommendations in the past and I think it depends on who's going to use your service.
If, like me, you're writing it to link an app to a remote data source then the most abstract interface you can write will still include a "get" and a "save" method for each logical object in your database.
My latest project has a servicecontract with 246 operation contracts in it. It's a mostrosity of a file and a pig to edit, but the client side code is neat and tidy and it's just easier to work with. It's not like anyone but me is ever going to see it.
In short, there are no technical or performance implications to either approach. Go with whatever seems most appropriate to your project.
Our application is interfacing with a lot of web services these days. We have our own package that someone wrote a few years back using UTL_HTTP and it generally works, but needs some hard-coding of the SOAP envelope to work with certain systems. I would like to make it more generic, but lack experience to know how many scenarios I would have to deal with. The variations are in what namespaces need to be declared and the format of the elements. We have to handle both simple calls with a few parameters and those that pass a large amount of data in an encoded string.
I know that 10g has UTL_DBWS, but there are not a huge number of use-cases on-line. Is it stable and flexible enough for general use? Documentation
I have used UTL_HTTP which is simple and works. If you face a challenge with your own package, you can probably find a solution in one of the many wrapper packages around UTL_HTTP on the net (Google "consuming web services from pl/sql", leading you to e.g.
http://www.oracle-base.com/articles/9i/ConsumingWebServices9i.php)
The reason nobody is using UTL_DBWS is that it is not functional in a default installed database. You need to load a ton of Java classes into the database, but the standard instructions seem to be defective - the process spews Java errors right and left and ultimately fails. It seems very few people have been willing to take the time to track down the package dependencies in order to make this approach work.
I had this challenge and found and installed the 'SOAP API' package that Sten suggests on Oracle-Base. It provides some good envelope-creation functionality on top of UTL_HTTP.
However there were some limitations that pertain to your question. SOAP_API assumes all requests are simple XML- i.e. only one layer tag hierarchy.
I extended the SOAP_API package to allow the client code to arbitrarily insert an extra tag. So you can insert a sub-level such as , continue to build the request, and remember to insert a closing tag.
The namespace issue was a bear for the project- different levels of XML had different namespaces.
A nice debugging tool that I used is TCP Trace from Pocket Soap.
www.pocketsoap.com/tcptrace/
You set it up like a proxy and watch the HTTP request and response objects between client and server code.
Having said all that, we really like having a SOAP client in the database- we have full access to all data and existing PLSQL code, can easily loop through cursors and call the external app via SOAP when needed. It was a lot quicker and easier than deploying a middle tier with lots of custom Java or .NET code. Good luck and let me know if you'd like to see my enhanced SOAP API code.
We have also used UTL_HTTP in a manner similar to what you have described. I don't have any direct experience with UTL_DBWS, so I hope you can follow up with any information/experience you can gather.
#kogus, no it's a quite good design for many applications. PL/SQL is a full-fledged programming language that has been used for many big applications.
Check out this older post. I have to agree with that post's #1 answer; it's hard to imagine a scenario where this could be a good design.
Can't you write a service, or standalone application, which would talk to a table in your database? Then you could implement whatever you want as a trigger on that table.