Probably is a straight-forward question: do you know any tools for combining multiple wsdl + xsd files into a single wsdl?
Thank you.
Edit1:
The service is a WCF service, and I want to have a single wsdl for PHP (as client).
Edit2:
Too bad I need to use .Net 4.0 and not 4.5 where this would be possible. Maybe I could borrow then one of the new MS tools? Do you know which one? Is the svcutil.exe the responsible tool? If yes, what are his dependencies? Because I don't want to jump to .Net 4.5 just yet.
You can build a small application that can generate a flat wsdl. We do generate flat wsdl programatically in C# for building interoperable WCF services. Refer to the link on how to generate flat wsdl.
Hopefully seeing the code you can build a tool that does it for you.
Else you can manually do it using Altova Xml Spy and replacing the xsd import attributes by the xsd schema definition.
For sure, I can recommend a tool that can combine multiple XSD files into the minimum set possible (I am biased here, since I wrote it). This in itself can be a heavy task, if you have a large number of files, many namespaces, or both. The things might get trickier for multiple WSDLs into one, depending on some parameters you may have configure; for example, is it logically one WSDL authored over three layers that maintains separation of messages - portTypes - services, or multiple WSDLs, period? One thing you must ensure is that all share the same types subsystem, there's no conflict for operations, etc. But even this is a task that could be achieved, I could easily put an addon out... If this is refactoring of XML Schemas and WSDLs you see doing often, let me know.
We wanted one wsdl file to make use of some tools to automatically generate soap proxy on PHP side. But we ended up writing the DTO layer manually.
If you have wcf service in .NET 4.5 you can get easily only one wsdl file (inbuilt feature of WCF framework).
Related
I am currently working in a WEB Java project and I have the following requirement: I have to make sure our customers don't have access to the packaged files in order to change them. Actually, I'd like to do that with only a few of those classes but without using any obfuscators due to the size of my project and the resources it uses to accomplish some tasks (reflection, annotations, interceptors, etc).
Does anybody have any tips?
Thanks,
Luan
I have made three different applications in j JHipster with monolithic. I need to merge these applications. I know that by using micro-services my quest can be easy but the current requirement is to do the merging with the monolithic pattern only.
I need to merge two applications with another or main application. I am using MySQL as database. I don't know where I need to change and how. Please help me out, I am a newbie in this scenario.
i tried to create a java file for setter getter methods and and a dao file for three databases and now in the main class file and am trying to take every dao file as an array of object and integrate it and put it into the third db.is it possible.i wanted to show the code bt,since i am new not able to maintain the coding standards to show.
by this i way i tried to involve three databases in a single scenario and want to complete my query through CRUD model.
as you already pointed out, the proper way of merging here would be using the microservice option, which you cannot take, as you are forced to use monolithic architecture...
almost automatic merge
if you did not changed anything to your code, after generating the entities, you just can put the contents of your applications .jhipster directory into one, and run yo jhipster --with-entities to regenerate the entities in one application. You should keep in mind, you will have to take a look at your main/resource/config/liquibase folder, to set the migration ids properly.
manual merge
For this you should be more experienced in the underlying technologies, as you will have to:
recreate your entity classes
recreate zour DAO/Repositories
(maybe) recreate your services, or service implementations
recreate your REST controllers
do a proper liquibase migration
provide some tests
migrate the frontend code, by adding states, components, templates etc..
the most of these things you just can copy paste already generated code.
For more information, you should ask more precise, what is not working, if you already tried something...
i'm newbie in JHipster and i'm trying to figure this, when i create a new entity JHipster generates several files, angular, html and java classes, now if i want a common code for all this generated code i must edit each time that i use the yeoman generator? what i want is:
Custom Index template, and pages, is secure to edit them?.
Customize the entity tables, entity forms using angular, maybe extending yeoman generators
Customize generate java classes, maybe i think using AOP
So i need to edit each time for each generated code? and is a good practice this or what i want? for clarify more i want to use a Custom Bootstrap/angular Dashboard template like Minovate, i see how to customize bootstrap in the documentation but not about what i'm asking for, Thanks.
JHipster is just a code generator, once generated the code is yours.
For angular screens I would say do as much as you can in CSS/SASS.
But it's very likely that you will need to build some screen mixing several entities and change the structure of entity screens.
So you should rather consider them as a starting point and do your own stuff in another folder so that it does not get overwritten by next re-generations.
This way you can still update your entity definitions in .jhipster folder and re-run yo jhispter:entity <entity name> on the entities you modified.
Customising java Entities is usually much simpler and you can easiliy achieve this by merging generated code with git and defining your service classes.
AOP seems overkill here.
Extending a yeoman generator is a lot of work.
I suggest to use some VSC (git, subversion or whatever you like) have a branch dedicated to plain jhipster generated code and another one where you make customization.
Eventually regenerate on jhipster branch and merge back on yours.
You should at least reduce manual intervention.
We are mantaining a java project that consumes a lot of different web services. Service definitions change regularly and new services are added very often. So we need to automate the generation of all the java clients.
We have a batch script that downloads(curl) all the needed wsdls and all the dependent schemas, then generates all the corresponding java clients(wsimport) and finally generates a jar that includes all the clients and all the wsdls and xsds which. We deploy this jar in our artifactory and we use it in our project. We need to include the wsdls and xsds in our jar to avoid jax-ws calls to the wsdls in execution.
The script has become a monster, because we use very different web services. Every wsdl, has it's own different schemas located in different urls, so we have to identify all the files that have to be downloaded and put the xsds in the correct path in the disk.
Our goal would be to have a script that, given a wsdl url list, downloads all the wsdls and dependent xsds in a folder so that we can execute wsimport against them.
SoapUI's "export definition" tool, exports the wsdld and the dependent schemas in a folder, and modifying the "ws:import" paths in the wsdl automaticaly. Is there any way to invoke this tool from command line?
Is there any other tool that would help us improving this process?
thanks in advance
We have multiple test projects that access databases directly. Those tests basically validate our sql queries written in C# code. Unfortunately, they are not separated at the moment and are in the same assemblies that also house true, non-dependent Unit tests (I think those database tests are considered Integration test, correct me if I'm wrong).
Currently, we use 2 testsettings files (sqlserver.testsettings and oracle.testsettings) to deploy a different 'ConnectionStrings.config' file before running the tests. Each of them have connection strings specific to their test databases, that should be created before any tests are run. We do this because we want to test these database methods with both SqlServer and Oracle databases, since some of our clients use SqlServer while others use Oracle.
With this in mind, we have an 'app.config' file on the test projects that contains something along these lines:
<?xml version="1.0"?>
<configuration>
<connectionStrings configSource="ConnectionStrings.config"/>
</configuration>
I would like to know if there would be another way to do this without using the testsettings file, which is in this case already deprecated in favor of the new format used by 'runsettings' files. I can't find the equivalent custom-file-deployment feature on runsettings specifications though, and considered creating multiple build configurations using XML transformations over the ConnectionStrings.config or app.config files.
The problem with XML transforms is that it is currently not supported for these types of projects, and I had a very hard time with SlowCheetah when going to the build server, and ultimately decided against using it (I had this same configSource scenario on one of our Web Application projects and tried transforming the external config file. I ended up merging the file with the web.config and using the standard msdeploy transformation).
What would you recommend in this case? This must also be runnable on our build server. At the moment, we can specify the same tests to be run with both testsettings files there.
Ideally we would also like that SqlServer tests be the standard for all developers, and Oracle tests would only be selected to run on our build server. This does not work right now, since every developer needs to specifically select the sqlserver.testsettings file prior to running the tests the first time. With the build configuration idea this could be achieved, so I'm leaning towards that at the moment, but I would like to hear a potentially better approach to the problem.
I have a feeling we are doing something very wrong in this whole process (and this includes the ideas presented in this post) and that there should be a much easier and straightforward way of doing it.